Грабли #2: В реальности MSE - почти всегда не лучший выбор ❌

Что ж, мы определились, что ML-метрики не симметричны. В этом случае достаточно логично было лы использовать квантильный лосс
https://medium.com/analytics-vidhya/prediction-intervals-in-forecasting-quantile-loss-function-18f72501586f

Для скоропортящихся товаров прогнозируем, например, 45% квантиль, а для остальных - 55%. Кажется, что тут все очевидно, но есть одна проблема:

ML-модели достаточно хорошо прогнозируют каждый товар в отдельности, но в совокупности - нет

То есть, используя quantile loss c 55% квантилем, по всем товарам в совокупности вы далеко не всегда получите bias +5%.

Причина кроется в распределении продаж - как правило, это пуассоновское распределение с очень тяжелым хвостом. Поэтому помимо quantile loss я бы посоветовал также протестировать poisson loss и его более обобщенную версию - tweedie loss. Например, отдел прогноза спроса в Х5 Retail Group использует именно tweedie

Вывод
Loss крайне важен. Не пугайтесь тестировать нестандартные функции потерь

#metrics

But what loss function?..

Как вам часть про ML-метрики и loss?

Оптимизация промо акций
Часть 3
ML - это не только модели

Хороший подход при построении модели таков:

Строим MVP (базовую модель) - - > тестируем её в бою - - > собираем фидбек/метрики - - > улучшаем

Повторяем цикл несколько раз

Представим, что мы построили MVP с помощью LightGBM и запустили наш ML проект в бой. И отправимся в увлекательное путешествие по граблям ✈️

#pricing #timeseries

Грабли #1: Иногда модель прогнозирует падение спроса при росте скидки 📉

- "Стоп.. Как такое возможно?" - спросите вы
- "Элементарно" - ответит любое решающее дерево

Вроде бы простейшую логику "при росте скидки растёт спрос" деревьям очень сложно выучить. Деревья в целом очень плохо учат около-линейные зависимости

К счастью, в LightGBM есть параметр monotone_constraints, который позволяет задать ограничение на монотонность по каждой фиче

Пофиксили.

Грабли #2: Почему-то модель прогнозирует меньше, чем есть на самом деле.. или проблемы в данных

Несмотря на то, что для большинства категорий мы прогнозируем 55% квантиль, итоговый прогноз в среднем < факта! То есть у нас отрицательный bias. Чтобы разобраться, что случилось, начинаем копаться в данных и видим, что под конец многих акций продажи падаюют в 0, хотя в начале акции они довольно хорошо росли

В ритейле и не только бывают out-of-stock: товар физически заканчивается на полке. Клиенты хотели бы купить больше товаров, но их нет. А нам нужно прогнозировать как раз то, сколько купили бы клиенты, если товаров было бы досатоточно. То есть в среднем таргет в модели < реального прироста продаж

Вариантов решения 2:
1. Если у нас есть данные по out-of-stock (обычно инвентаризация), то мы можем убрать из обучающей выборки те даты, когда товар заканчивался. А лучше еще и пару дней до этого момента
2. Если таких данных нет, то попытаться определить out-of-stock по данным. Для начала можно попробовать простейшие правила вроде:
- Продажи на промо < 1/2 средненедельных продаж без промо
- Продажи на второй неделе промо < 1/4 продаж на первой неделе

Есть шанс, что что-то из этих вариантов сработает

Out-of-stock в реальной жизни

Грабли #3: Прогноз продаж все еще меньше факта.. Или человеческий фактор 👩‍🔧

Но мы же вроде решили проблему out-of-stock. Модель работает хорошо: на валидации с метриками все в порядке. Где же может быть загвоздка?

Типичный флоу ML-продукта:
Данные -->
Модель + прогноз --> Рекомендации (какое промо проводить) -->
Реализация рекомендаций

Чтобы ваш ML-проект реально принес value для бизнеса, нужно убедиться, что в реальной жизни ваши рекомендации / прогнозы / что угодно реально используются. Мне очень нравится фраза одного моего друга-разработчика:

"Поменял цвет кнопки - зайди на сайт и проверь, что он изменился"

Так и в ML-проектах. Если вы что-то сделали - возьмите и физически проверьте, что это работает. Зайдите в магазин и проверьте, идет ли акция, которую порекомендовала завести ML-модель

Зашли в магазин - акции нет. Идем к менеджеру, который заводит промо:

"Ваша модель рекомендует слишком низкие скидки. Мой личный KPI - выручка, а не прибыль. Если я буду пользоваться вашей моделью, то стану меньше зарабатывать"

Упс. Вот это уже серьезная проблема. Не то что ваши лоссы и ml-метрики. Чтобы модель заработала, вероятно, нужно будет поменять KPI менеджеру - через директора(?) - иначе все, что вы делали - зря

Вывод
Проверяйте, как в реальности работает ваша модель / рекомендации. Обычно все проблемы в implementation details. Менеджер с другим KPI - лишь одна из возможных проблем

При работе с некоторыми менеджерами (особенно, если вы автоматизируете их работу через ML) этот мем уже не кажется смешным

Грабли #4: локально оптимальное решение.. или каннибализация

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

Часть 1: Договорённости ДО начала проекта: https://news.1rj.ru/str/ml4value/8
Часть 2: Выбор ML-метрик и Loss: https://news.1rj.ru/str/ml4value/18
Часть 3: ML-это не только модели (сечас вы читаете пост №4 в этой части): https://news.1rj.ru/str/ml4value/24


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

Мы прогнозируем прирост прибыли для конкретного товара в зависимости от параметров акции. И выбираем argmax (profit) по параметрам акции. На самом деле, наше решение оптимально лишь для 1 конкретного товара

Но есть проблема: Каннибализация - рост продаж этого товара снижает продажи всех остальных товаров в категории

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

Подробно про решение проблемы каннибализации я рассказывал на конференции Х5:
https://www.youtube.com/watch?v=2djYDhQG_BM

TL;DR
Продажи категории товаров (газ. напитки) - функция от промо продаж в этой категории. Поэтому можно делать так:

Шаг 1. Прогнозируем продажи всех товаров на промо
Шаг 2. Суммируем их --> прогноз промо продаж в категории
Шаг 3. Обучаем простую модель, где таргет = все продажи в категории, а одна из фичей - промо продажи в категории. Зависимость, очевидно, нелинейная (см. рисунок ниже)
Шаг 4. Вуаля, мы получили, что прирост промо продаж с 1000 до 1200 (+200) увеличивает продажи категории лишь на +150. Каннибализация = 150 - 200 = -50. И ее нужно учитвывать при выборе параметров промо каждого товара

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

Как вам блок про "ML - это не только модели"?

Оптимизация промо акций
Часть 4
Как померить бизнес-эффект? 💰💰

- Очевидно, А/В тестом!
- Да, но не все так просто. Опять мои любимые implementation details:)


Грабли #1: Выбор корректного теста

Классические А/В из учебников применяются не так часто, т.к. столкновение теории с реальностью разбивает первую вдребезги

Что же не так с А/В из учебника? Вспомним, что там пишут:

Шаг 1. Разбиваем юзеров на А и В группы.. Но стоп. Мы же делаем акции на товары в магазине, как же мы побьем юзеров? Правильно - никак. Нужно сплитить магазины

Шаг 2. Провести А/А тест. Обычно в лекциях это упоминается вскользь. Предполагают, что А/А тест всегда успешен. Но в кейсе со сплитом по магазинам зачастую это не так 🙅‍♀ Хьюстон, у нас проблемы

Причин может быть 2:
>> Магазинов мало (даже у Х5 и Магнита их ~20к по всей России) + А/В на полстраны вам запустить никто не даст. В итоге, дай бог, дадут 1-2к магазинов для теста
>> Магазины очень сильно отличаются (разные города, районы города, уровень зп,...)

Что же делать?
1. Можно стратифицированно сэмплировать магазины для А и В групп. Не рекомендую, т к очень сложно подобрать хорошие фичи, по которым вы будете стратифицировать (город? з/п? Население? Все сразу?)

2. Switch back тесты. Рекомендую.
Хорошая статья от DoorDash на эту тему:
https://www.google.com/amp/s/doordash.engineering/2019/02/20/experiment-rigor-for-switchback-experiment-analysis/amp/

TL;DR;
Раз в неделю (в идеале день, но у нас оффлайн ритейл) вы делаете сплитование заново. Если тест идёт 3 недели, то один и тот же магазин может на одной неделе быть в А группе, а на другой - в В. Это позволяет нивелировать различия между средними в А и В группах, и даже снизить дисперсию метрик (ускорить тест)

Вывод
Внимательно следите за тем, какую технику А/В вы используете

#pricing #timeseries

Грабли #2: А/В тест длиною в жизнь

Допустим, мы выбрали относительно хороший дизайн А/В:
-- Метрика - прибыль на 1 магазин за 1 день
-- Switch back тест
-- Нам разрешили взять максимум 2к магазинов в тестовую группу

Всё, запускаем? Вообще, нужно бы посчитать, сколько недель нам нужно держать А/В. Считаем и получаем.. 2 года 😱

И тут мы приходим к необходимости ускорить А/В тест. Ускорить А/В = снизить дисперсию вашей метрики. Я оставлю ссылки на варианты решения этой проблемы и напишу TL; DR

Когда ждёшь, пока прокрасится метрика в А/В, а не ускоряешь его

Ускорение А/В
Способ 1. Стратификация и CUPED
https://youtu.be/pZpUM08mv-E

Стратификация = Сначала посчитать средние в каждой группе (город/страна/сегмент юзеров по доходу/..), а потом взвещенно по кол-во наблюдений в группе усреднить

Тогда итоговое среднее останется таким же как и в классическом подходе, а дисперсия упадёт - - > тест нужно будет держать меньше

CUPED
В видео объяснение довольно сложное, но по сути вы просто строите линейную регрессию вашей целевой метрики на фичи

Важно (!): значение фичей должно быть известно ДО начала эксперимента

Пример фичей:
-- Целевая метрика магазина N недель назад
-- Город, в котором находится магазин
--...

Потом, вы из целевой метрики вычитание её прогноз. И считаете А/В на уже получившейся величине. Это сильно ускоряет тест, но снижает его интерпретируемость

P.S. Для любителей строгой мат.статистики - выше я описал лишь концепцию. Если вдаваться в детали, то текст выше в чем-то не совсем корректен. Но суть идеи передаёт отлично:)

Будьте осторожны с интерпретацией CUPED (под его капотом линейная регрессия)

Ускорение А/В
Способ 2. Выбрать другую метрику 😅

Да-да, вы не ослышались. Можно и иногда даже нужно выбирать другие метрики в А/В, чтобы ждать результатов не 2 года, а 2-3 недели

Прибыль = кол-во заказов * средняя прибыль с одного заказа

Невероятно, но факт (ну, почти всегда факт 😜): дисперсия этих множителей сильно меньше дисперсии прибыли

А значит, А/В успешен, если
хотя бы одна из метрик растёт, а другая - не падает

P.S. Но не забывайте про поправки (например, Бонферонни) для множественного тестирования гипотез

Ускорение А/В
Способ 3: Байесовская статистика
https://youtu.be/Wxw1lseUXVU
(про Байеса - в конце видео)

Одно из немногих успешних применений байеса - А/В тесты и многорукие бандиты

Тут TL;DR не получится, так как много теории. Если интересно, то лучше прочитайте об этом в годных статьях:

Байесовские А/В:
https://link.medium.com/9b4ukKvHK9

Байесовские многорукие бандиты:
https://lilianweng.github.io/lil-log/2018/01/23/the-multi-armed-bandit-problem-and-its-solutions.html

Как вам посты про дизайн и ускорение А/В?

P.S. А ещё: стратификация, линеаризация, байес и т д - просто частные случаи CUPED

Грабли универсальные: Тесты ds-кода

Сразу оговорюсь, что я ни разу не ML Engineer / Devops. Бакалавриат я закончил вообще по мат.методам в экономике. И до начала работы почти ничего не слышал о юнит- и других тестах

Но как только мои модели начали использоваться, даже мне стало очевидно, что без тестов - никуда. Без них пайплайны падают, их починка отнимает кучу времени, а бизнес-заказчики недоумевают где их 300кк/сек от внедрения ML

А если ваши пайплайны падают слишком часто - не за горами тот момент, когда и вы будете недоумевать про свои 300кк/сек 🙂

Так что начнем мое небольшое введение в тестирование ML-пайплайнов!

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

Поэтому я предлагаю покрывать отдельными тестами:
— входные данные (да-да, и для нейронок тоже)
— каждый этап трансформации данных
— predict

В моем идеальном мире, код может выглядеть примерно так:

df = read_data()
test_on_inputs(df)

df = first_transform(df)
test_on_transform(type='first')

df = second_transform(df)
test_on_transform(type='second')

model = MyFavoriteModel()
model.fit(df)
test_on_predict(model, df)

Далее опишу тесты, которые я использую каждый день стараюсь использовать. А чтобы убедить вас, что тесты нужны, добавлю мои самые эпичные фейлы