Написал на хабре статью, как с помощью Оптуны оптимизировать гиперпараметры RAG-системы (это такой карманный поисковик):
https://habr.com/ru/articles/811239/

#Tip43 #EDA

Leaderboard Probing - это различные техники, которые позволяют получить дополнительную информацию о таргете тестового датасета, на котором в соревнованиях производится оценка. И если правильно ею воспользоваться, то вы сможете получить преимущество перед другими участниками. Например, сможете собрать локальный тестовый датасет похожий на тот, что используется в соревновании. Или сможете навесить какую-нибудь дополнительную пост-обработку.

В основном все подходы сводятся к пониманию того, как рассчитываются метрики и манипуляции с их формулами. Но иногда встречаются и другие методы.

Рассмотрим пару примеров (см. картинки):
1. Если в соревновании используется метрика MSE, то выполнив всего два сабмита (один содержит все 0, а второй все 1), мы сможем вычислить среднее тестового датасета.
2. Можно попробовать оценить насколько тестовый датасет похож на тренировочный (и предугадать шейкап :). Допустим у нас многоклассовая классификация. Отправляем столько сабмитов - сколько классов. Каждый содержит только один класс. Тоже самое проделываем и на тренировочном датасете. Далее сравниваем их посредством графика.
З.Ы. Это некий PDP (https://t.me/ds_private_sharing/48).

Встречаются и другие "цели": вычисление количества строк, дисперсия и пр.

Но не все так радужно:
1. Обычно корги пытаются предотвратить такие трюки. Например, делят тестовую выборку на публичную и приватную. И если паблик = 5%, то пробинг становится бесполезным. Или вовсе тестируют на скрытом датасете.
2. Зачастую подход зависит не только от метрик, но и от структуры данных. Поэтому универсальных подходов не так много.
3. На такие вычисления может потребоваться много сабмитов, а они обычно сильно ограничены.
4. Иногда LB probing запрещают явно. А иногда неявно, под примерно такими формулировками: создание избыточной нагрузки на сервер, использование уязвимостей системы для получения преимущества и т.д.

Если знаете интересные примеры LB probing - пишите в комментариях.

#курс

После почти года доработок, я таки дописал последние два урока - про Градиентнный бустинг (регрессия и классификация). И теперь самый лучший в мире курс по ML (Алгоритмы Машинного обучения с нуля) перешел в релизную стадию (версия 1.0).

Напоминаю, что в курсе вам необходимо с нуля (на чистом Python, NumPy и Pandas) реализовать все основные алгоритмы машинного обучения:
1. Линейные модели:
- Линейная регрессия
- Логистическая регрессия
2. Метод ближайших соседей, kNN (классификация и регрессия)
3. Деревья решений (классификация и регрессия)
4. Ансамбли:
- Случайный лес (регрессия и классификация)
- Бэггинг (регрессия и классификация)
- Градиентный бустинг (регрессия и классификация)
5. Кластеризация:
- Метод k-средних (K-Means)
- Иерархическая агломеративная кластеризация
- DBSCAN
6. Снижение размерности (Метод главных компонент, PCA)

Курс бесплатный и находится на платформе степик: https://stepik.org/course/68260/promo

З.Ы.1. По мере возможности буду дописывать и менее популярные темы из классического ML (рекомендашки, SVM и т.д.)
З.Ы.2. Градиентный бустинг оказался не таким простым как о нем рассказывают на вводных курсах :)
З.Ы.3. Спасибо всем кто помогал тестировать курс :)

#Tip42 #EDA #Pandas

На прошлой неделе поучаствовал в хакатоне GO ALGO, организованный Московской фондовой биржей.
Для решения задачи нужно было анализировать биржевую информацию. И наконец-то мне мне удалось применить на практике очень редкий вид графиков — Спарклайны (Sparkline).

Спарклайны — это небольшие немаркированные графики. Обычно они не содержат ни осей ни подписей, поэтому в основном предназначены для передачи какой-то общей идеи.

А т.к. спарклайны очень маленькие, то они отлично помещаются в ячейках Pandas'а :)

```
import base64
from io import BytesIO
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
from IPython.display import HTML

def sparkline(data):
data = list(data)

agg_df = df.groupby('tradedate', as_index=False)['pr_open'].agg(list)
agg_df['sparkline'] = agg_df['pr_open'].map(sparkline)

HTML(agg_df[['tradedate','sparkline']][-10:].to_html(escape=False))
```

Графики можно редактировать в определенных границах: менять их ширину/высоту, можно разукрасить на свое усмотрение. Также вы можете вывести другие типы графиков: барплоты, гистограммы и пр.

З.Ы. Сам хакатон проходил в интересном формате. С одной стороны это был обычный хактон - с чек-поинтами и общением с экспертами. С другой - он длился целых 10 дней (вместо обычных 2-3). А за это время можно было сделать неплохой продукт :)

#competitions

Обычно я не пишу анонсы соревнований, но тут прям интересный случай.

Соревнование по EDA :) Оно же Exploratory Data Analysis, оно же Разведочный анализ данных.

Чтобы поучаствовать даже в ML разбираться не нужно - нужно уметь искать инсайты в данных и рисовать красивые графики.
И вишенка на торте: действие происходит на карте :)

И за это еще и заплатят (три призовых места :)
Подробнее: https://xmas-hack.ru/#case1 (кейс 1)
Регистрация до 19 декабря.

#Tip41 #Pandas

Есть у пандаса такая функция - автоматическое определение типа колонок при загрузке данных. Но тип данных может быть определен не верно. Казалась бы, ну и ладно - переопределим после загрузки. Но тут кроется одна неявная проблема.
Звучит она так: "Категории могут начинаться с 0, а числа - нет".

Яркий тому пример коды ОКАТО, ОКВЭД и пр. Если пандас определит колонки ОКАТО и ОКВЭД как числа он ничего не сообщит, а просто отбросит начальные нули и спокойно загрузит данные. Тем самым изменив идентификатор изначальной категории и, возможно, смешав их с другими категориями. И это можно попросту не заметить (сам с таким сталкивался).

Чтобы избежать этого нужно явно указывать тип колонок при загрузке данных:

```
type_dict = {
'Col_A': 'category',
'Col_B': 'int16',
'Col_C': 'float16',
'Col_D': 'float32'}

df = pd.read_csv(myfile, dtype=type_dict)
```

Написал небольшое эссе (вру, большое :) на тему, какие задачи могут без дообучения выполнять современные большие языковые модели (LLM):
https://habr.com/ru/articles/775870/

#competitions #зашквар

Раз уж астрологи объявили неделю соревновательных постов, то расскажу об еще одном занятном хакатоне, который прошел месяц назад :) GoodsForecast Hack - Определение наличия товаров на полке.

Задача - классификация на временных рядах. Нужно было спрогнозировать, что какой-то товар в каком-то магазине в какое-то время забудут выложить на полку (и Дикси разорится :)

Первые подходы к снаряду выдавали очень веселый ROC AUC на отложенной выборке - ~43% :) Хотя обучение проходило нормально.
Стал разбираться почему и обнаружил такую интересную картину (см. картинку). Это сумма таргета по дням по каждому магазину за каждый день. Тут не вооруженным глазом видно, что в конце тренировочной выборки резко и сильно меняется паттерн данных (и скорее всего это продолжается в тестовом периоде - что потом и подтвердилось). Обучаться на таком нельзя.

Сразу же вспомнилось золотое правило МЛ: дерьмо на входе - дерьмо на выходе.

На вопрос к организаторам: "Что это за порнография?", был получен скромный ответ: "Изменилась модель".
Причем тут модель - не понятно :) Скорее таргет изменился или методология его сбора - хз...

Ничего не оставалось, кроме как выкинуть 80% тренировочной выборки :) После этого скор стал адекватным (~70%).
Но теперь получалось, что у нас на обучение и оценку 10 дней, а предсказывать надо 12. Такой себе временной ряд :)

Не знаю, преследовали ли какую-нибудь цель организаторы, выдавая такой датасет. Но похоже, что просто кто-то недоглядел :)

З.Ы. А чтобы такого не происходило, не забываем про пункт 7: https://t.me/ds_private_sharing/77

#competitions #зашквар

На прошлой неделе участвовал еще в одном соревновании, заслужившим свое место в истории ML-соревнований - DataWagon. Трек 1: Прогнозирование спроса на грузовые ЖД перевозки.
Задача регрессии на временных рядах. Нужно было прогнозировать спрос на вагоны на отдельных ЖД станциях на 5 месяцев вперед.

Но организаторы хотели слишком многого от 2 дней соревнований и откровенно переборщили со сложностью. Например, модель должна была считать одно, а оценивалось другое. Были и другие сложности...

Бейзлайн, который представили организаторы, был очень примитивен: просто копировали последний исторический месяц на 5 месяцев прогноза.

Все попытки построить нормальную ML-модель на временных рядах давали скор заметно ниже бейзлайна. Участники быстро смекнули что к чему и начали мучать бейзлайн :) Например, вместо последнего месяц, брали последние два месяца. Или как-то усредняли значения последних месяцев и т.д. В результате лучшие по скору решения так или иначе были основаны на бейзлайне.

А это значит, что это первое в истории ML соревнование, в котором победили организаторы :)))

Что хочу сказать-то: участвуйте в соревнованиях - это весело :)

З.Ы. А чтобы такого не происходило, нужно всего-то выполнить 7 пункт этого списка: https://t.me/ds_private_sharing/77