О ценности культуры А/В тестирования и не только

Думаю многие слышали, что в компании хорошо бы внедрять MLOPS, единый feature store, code review и многие другие "правила хорошей работы с данными и моделями"

При этом про "правила хорошего А/В" говорят не так активно. Сегодня я покажу, сколько может стоить "маленькая ошибка" при проведении А/В теста

Представьте, что Junior аналитик решил задизайнить А/В тест. Он знает про классический А/В эксперимент из учебника с Т-статистикой (что уже неплохо на самом деле!)

Но продакты просят его сделать А/В/С тест и сравнить там всего 2 метрики - конверсию и средний чек. При этом хотят быть "очень уверенными" в результатах
(Да-да, это то же самое, когда хотят 100% точность классификации)

Junior решил полностью последовать их просьбе ("мы ведь совсем капельку поменяем параметры А/В теста!") и выбрал:
alpha=1% (для уверенности)
power=90% (для уверенности-2)
кол-во групп = 3
кол-во метрик = 2

Напомню, что базовый кейс из учебника - это:
alpha=5%
power=80%
кол-во групп = 2
кол-во метрик = 1

#ab

Долго ли, коротко ли, но наконец я возобновил выступления на конференциях!) Ближайшая будет уже во вторник в 20:00

Там я буду рассказывать про ускорение А/В тестов - приходите, буду очень рад увидеть вас среди зрителей :)

Наткнулся на годную статью про UltraGCN (Ultra Graph Convolutional neural Networks)

Краткая вводная
Недавно стали очень популярны графовые нейронки (часто реализовываются через GCN) в задаче персональных рекомендаций. Единственная проблема - они дико долго обучаются по сравнению с тем же ALS

Что интересного в статье
В статье показано, что UltraGCN - это, по сути, ALS с другим лоссом, который накладывает регуляризацию на основе информации из графов связей пользователи-товары и товары-товары

То есть можно просто учить перемножение двух векторов (примерно как в ALS), но с другим лоссом - и вы уже получите новомодную SOTA модель из графовых нейронок! Это же просто🔥

Мои мысли
Я сделал еще пару выводов из этой статьи:
1. Зачастую важен совсем не тот алгоритм/модель, которым вы решаете задачу. А важно правильно выбрать, какую задачу вы решаете (~лосс). На практике я видел этому очень много подтверждений
2. К сожалению, очень мало рисерчей / образовательного контента про лоссы / метрики / задачи в data science

Поэтому решил, что пару слудеющих постов я напишу о лоссах и метрикам в ML-моделях. И каким образом их "правильно" подбирать под каждую ML-задачу. Как говорится, "Stay tuned" 💪

Метрики ML-моделей регрессии

Часть 1. Простые метрики регрессии: RMSE, MAE

RMSE и MAE - пожалуй, самые простые и самые неверно используемые метрики, оторые я видел

Обычно в лекциях по DS про эти метрики говорят следующее: Лучше использовать MAE, чем RMSE, при скошенных распределениях таргета с длинным хвостом, так как MAE меньше штрафует за большие ошибки в прогнозе

Кажется, что что и есть формула успеха, но нет 😉

#metrics

Во-первых, ошибка прогноза не обязательно связана с формой распределения таргета. Например, у модели, обученной на лог-нормальном таргете, могут быть ошибки прогноза, распределенные нормально. По этой же причине, кстати, не нужно сходу использовать RMSLE на скошенных распределениях таргета

Распределение таргета не имеет значение. Важно только распределение ошибок (y_true - y_pred) модели

Во-вторых, MAE и правда меньше штрафует за большие ошибки прогноза. Но тут важно понимать, какой бизнес смысл за этим стоит

MAE - прогнозирует медиану
RMSE - среднее

В-третьих,
Мы прогнозируем среднее обычно для тех случаев, когда оно используется для расчета E(*)

Например,
E(выручка) = цена * E(спрос)

Поэтому в задачах оптимизации цен, промо и т д обычно прогнозируют среднее --> используют RMSE
*да, еще используют poisson/tweedie loss, но об том в следующих частях:)

Мы прогнозируем медиану (MAE loss) или любой другой квантиль (quantile loss), когда речь заходит о разной цене ошибки прогноза в бОльшую и меньшую стороны

Например, при прогнозе спроса для закупки товаров обычно (не всегда) лучше спрогнозировать чуть больше факта - закупить чуть больше товаров. Поэтому тут можно использовать, условно квантильный лосс и прогнозировать, например, 60-й квантиль

Кстати, обратите внимание, в одной задаче (оптимизация цен, промо) я предлагал использовать RMSE, а для того же прогноза спроса в другой задаче (закупка товаров) - квантильный лосс

В целом, лосс-функцию нужно выбирать исходя из задачи, а не формы распределения таргета

Интересно в следующем посте послушать про MAPE, RMSLE, MALE, SMAPE и WAPE метрики?)

Часть 2. Более продвинутые метрики регрессии

1. MALE и RMSLE (L - Logarithmic)
Для начала, поговорим про аналоги MAE и RMSE, посчитанные на логарифмах таргета: ln(1 + y)

Зачастую их используют, когда у таргета довольно большой разброс значений. Например, когда прогнозируют продажи товаров: есть бОльшая часть товаров с продажами в 0-2 шт, и небольшая с >1000 шт. Это помогает не переобучаться под небольшую часть товаров с относительно большими продажами

Также логарифмирование таргета позволяет вносить нелинейность по фичам. Например, если вы обучаете линейную регрессию, прогнозируя ln(1 + y), то итоговый прогноз y = exp(a0 + a1*x1 + a2*x2) - 1 уже нелинеен по фичам из-за exp

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

В остальных случаях я предложил бы быть крайне аккуратным с логарифмированием, потому что:
- Теряется связь с изначальной бизнес-задачей: бизнес интересует прогноз y, а не ln(1+y)
- Из-за экспоненты может быть неконтролируемое влияние фичи на таргет: небольшое изменение фичи может очень сильно менять прогноз
- Напомню, что только лишь логнормальное распределение таргета - не повод использовать MALE и RMSLE

#metrics

Мои итоги 2021 года
Уже все подвели итоги года - и мне пора) 2021-ый был довольно занятным

Работа
1. Стал тимлидом
Совсем другой опыт - теперь на многие вещи смотрю под другим углом. Полюбил MVP, скрам, дейли митинги и тестирование кода. Поверьте, все это и правда делает жизнь всей команды значительно лучше. Даже тесты кода 😅 - хоть их и очень не хочется писать, но это супер полезно

2. Круто, что я прям вижу прогресс команды
С ума сойти: всего за год наша команда сделала из ничего (это не преувеличение) полноценную платформу А/В тестов в Delivery Club! Через нее прошла уже не одна сотня экспериментов. Даже написали про нее статью на Хабр. Есть еще ооочень много вещей, которые нужно допилить или перепилить полностью, но у нас уже есть довольно хорошо работающий продукт, ну классно же?)

В этом году я своими глазами увидел (и приложил к этому руку и сердце), как с нуля строились большая махина рекомендательной системы: от инфраструктуры продакшена и первых моделей до первых провалов и долгожданных успехов. Под конец года уже несколько моделей в проде, и то ли еще будет:)

3. Немножко побыл продактом
Помог в формировании нескольких фич... и узнал, что это ни капли не просто! Не уверен, проще ли стать хорошим продактом или дата саентистом) Огромное спасибо нашему продакту Лизе за бесценный опыт, которым она со мной поделилась. Это правда словно другой мир - не менее интересный и сложный, чем мир DS

4. Провел около 50 собеседований
Очень круто меняется отношение к собесам в целом, когда оказываешься по "ту сторону стола". Из лично моих открытий:
(1) Не смотря на бесчисленные онлайн школы, факультеты университетов, MADE, ШАД и другие способы образования, есть крайне мало людей даже junior, которые основательно разбираются в реально прикладном ML. Нет, не в нейронках, а чем отличаются where и having в sql-запросах:) Немного утрирую, но если вы собираетесь залететь в мир DS - заботайте лучше SQL и pandas: на первых порах да и потом тоже они (или их аналоги) будут составлять огромную часть вашей работы
(2) С другой стороны иногда встречаются действительно таланты, у которых можно даже узнать что-то новое на собседовании. C одним кандидатом (он теперь в нашей команде!) мы часа 3 общались про развитие платформ А/В тестов. В общем, я недоумеваю, куда исчез "средний класс" в data science)
(3) Начал спрашивать ML system design - топовая вещь 💪
Практически всегда одного его достаточно, чтобы определить уровень кандидата
(4) Задачу, которую я придумал где-то год-полтора назад для собеседований, ушла в массы) Возникла она из реального вопроса бизнеса, и в оригинале звучит так:
У ресторана есть радиус доставки (R). Во сколько раз увеличится среднее время доставки, если увеличить радиус доставки в 2 раза? Для простоты можно считать распределение клиентов по площади круга равномерным. Подсказка - он вырастет меньше чем в 2 раза / ровно в 2 раза / больше чем в 2 раза? Если есть интерес и желание - пишите ответы в комментариях)

Extracurricular
1. Начал снова писать в канал
За этот год на ml4value подписалось почти 500 человек (х2.5 к 2020)! Огромное спасибо всем моим читателям за комментарии и личные сообщения после постов. Еще стал замечать, что многие из новых знакомых уже знают меня через канал - чуть-чуть почувствовал себя знаменитым)

2. Выступил на конференции (если интересно, ссылка на видео тут)
Уже давно собирался - и безумно рад, что выступил!
Еще с конференциями связано 2 факапа года - пропустил буквально на недельку запись на выступление на МатеМаркетинге. Написал, но не успел до конца года опубликовать статью на Хабр(
Успех года - волей случая прошел на Highload++ 2022, присоединившись в последний момент к моему коллеге Жене. Спасибо тебе огромное - думаю, у нас получится классные дуэт!)

3. Сходил на 10+ встреч Random Coffee от ODS
Успел встретить всех: от девушки с моего же факультета до знаменитого Леши Натекина (один из основателей ods)


Ну и в конце, лично мое открытие года - кофе в дрип-пакетах. Это просто шикарно - больше нечего добавить:)
Всех с наступающим Новым Годом🎄

Задача с собеседований из поста выше оказалась довольно интересной, судя по ответам в комментариях) Поэтому сделаю опрос с немного усложненным вариантом задачи 🧐

Кажется все, кто хотел ответить на вопрос, сделали это - давайте разберем задачку 🤓

*в комментариях идет интересная дискуссия про то, что есть 2 понимания "равномерного" распределения на круге. Поэтому есть 2 варианта решения

На самом сама задача довольно простая, но в ней есть несколько сложных подводных камней. Однако довольно много подписчиков (12%) ответили верно!)

(1) Равномерное распределение клиентов по площади круга
Первое, что интуитивно приходит в голову при решении - среднее пропорционально либо радиусу R, либо площади круга Pi * R^2. И это первый подводный камень) Давайте аккуратно его обойдем и для начала посчитаем, какое среднее время доставки в круге радиуса R

У равномерного распределения есть прекрасное свойство: медиана = среднему. Поэтому среднее время доставки = радиусу (X) круга, который по площади в 2 раза меньше круга радиуса R

Pi * X^2 = Pi * R^2 / 2
X = 1 / sqrt(2) * R

Если увеличить R в 2 раза, то среднее (X) тоже увеличится в 2 раза!
---------

(2) Реальное распределение клиентов по площади круга
И вот он второй подводный камень: клиентов доставки, а не просто всех людей. Клиент = тот, кто заказывает. Вероятность заказа падает при росте времени доставки. Поэтому бОльшая часть клиентов будет сосредоточена ближе к центру круга, а не равномерно. Поэтому:

Pi * X^2 < Pi * R^2 / 2
X < 1 / sqrt(2) * R

Ответ: (1) ровно в 2 раза; (2) < 2 раз
---------

На самом деле есть еще довольно много бизнесовых причин, почему так происходит. Например, на дальние расстояния начинают ездить курьеры на машинах, а не ходить пешком. И в реальности среднее время доставки Х сильно меньше 1 / sqrt(2) * R !

Кстати, в том числе благодаря выводам из такой простой модели мы наслаждаемся доставкой из Самоката / Лавки на даче 🏡. Они могли увеличить радиус доставки с условных 5 км до 20 км без очень драматичного роста в среднем времени доставки

Продолжаем серию постов про метрики регрессии
Предыдущие посты - часть 1 про MAE и RMSE, часть 2 про MALE и RMSLE

Часть 3. Первая относительная метрика: MAPE

Абсолютные метрики (RMSE, RMSLE, ...) хороши своей простотой, но имеют ряд недостатков:
- Сложно интерепретировать и презентовать бизнесу ("у модели MAE = 307"; - "И что я должен с этим делать? Хороша ли модель-то?")
- Проблемы при обучении на разнородных обьектах (у одного товара 1к продаж в неделю, у другого - 5. Если усреднить RMSE этих товаров, то получится нечто странное)

Поэтому придумали относительные метрики!
Note:
- Macro average = считаем метрику по каждому обьекту, затем усредняем. Дальше речь пойдет именно о таком усреднении
- Micro average = считаем числители и знаменатели по каждому обьекту. Складываем все числители, все знаменатели. Делим один суммарный числитель на суммарный знаменатель. Это полный аналог MAE: macro MAPE = MAE / mean(y_true)

MAPE (Mean Absolute Percentage Error) = MEAN(|y_true - y_pred| / y_true)

Это простая и интуитивно понятная метрика, но есть нюансы:
- Может быть > 1
- Не симметрична: по-разному штрафует недопрогноз или перепрогноз
- Плохо работает при маленьких y_true. На практике можно делать так: MEAN(|y_true - y_pred| / (y_true + offset)). Это частично решает проблему

При обучении некоторых ml-моделей можно указать MAPE как лосс. Но у него неприятная производная. Поэтому на практике MAPE аппроксимируют через MALE, потому что:
1. ln(1 + f(x)) ~ f(x) при f(x) --> 0
2. ln(1 + |y_true - y_pred| / y_pred) --> |y_true - y_pred| / y_pred = MAPE при -//-
3. ln(y_pred + |y_true - y_pred|) - ln(y_true) --> MAPE при --//--
4. Сильное предположение, но на практике выполняется: |y_true - y_pred| --> 0 при |y_true - y_pred| / y_pred --> 0
5. ln(y_pred + |y_true - y_pred|) - ln(y_true) --> ln(y_pred) - ln(y_true) --> MAPE при -//-
6. Не забудьте взять модуль у первого выражения и получите, что MALE --> MAPE при небольших разницах в |y_true - y_pred|

Хороший рецепт: Loss = MALE, Метрика на валидации/тесте = MAPE

#metrics

Во многом моя концепция ML4Value сформировалась благодаря бакалавриату по мат методам в экономике. Путь из экономики в ML был довольно тернистым. До первой работы чисто в ML я прогнозировал временные ряды инфляции и ВВП в научной лабе, строил модельки риск-менеджмента на МосБирже и занимался sql-аналитикой в одном крупном банке. Когда-нибудь я обязательно рассказажу про этот путь в DS.

А пока рекомендую интервью о пути из бизнеса в DS известного каггл-грандмастера по ноутбукам Андрея Лукьяненко. Путь Андрея чем-то похож на мой, и здорово показывает, почему бизнес-бекграунд очень полезен в ML

Кстати, у интервьюера Ромы Васильева есть отличный канал про начало карьеры в DS: там есть другие занятные интервью и полезные материалы по ML

Ссылка на канал Ромы: https://news.1rj.ru/str/start_ds