Привет!
Меня зовут Иван Максимов,
@Ivan_maksimov. Достаточно долгое время я работал в data science консалтинге: делал оптимизацию промо-акций, аплифт, определение оптимальной локации и многое другое. А сейчас уже около года развиваю ML в Delivery Club
Наверняка вы прошли пару курсов по ML. Знаете архитектуру моделек, умеете считать метрики и, возможно, даже писали свой микросервис!
Но горькая правда в том, что между созданием хорошей ML модели и реальной пользой бизнесу находится огромная пропасть. О том, как её преодолеть, не учат на курсах. Крайне редко рассказывают на конференциях. И в целом, в DS-сообществе считается, что "Мы тут делаем SOTA, поэтому это точно полезно нашей компании". И именно поэтому около 80-90% data science проектов так и не принесут реального Value
О том, как я пытался преодолеть эту пропасть, и сделать настоящий "ML for Value" и пойдёт речь в этом канале. А также о собранных на этом пути граблях :)
Все это будет рассказано на примере истории решения проблем, реальных и вымышленных, с которыми сталкивается почти каждый DS. Структура изложения будет выглядеть так:
Проект
> Часть 1
--- Грабли #1
--- Грабли #2
> Часть 2
--- Грабли #1
--- Грабли #2
Меня зовут Иван Максимов,
@Ivan_maksimov. Достаточно долгое время я работал в data science консалтинге: делал оптимизацию промо-акций, аплифт, определение оптимальной локации и многое другое. А сейчас уже около года развиваю ML в Delivery Club
Наверняка вы прошли пару курсов по ML. Знаете архитектуру моделек, умеете считать метрики и, возможно, даже писали свой микросервис!
Но горькая правда в том, что между созданием хорошей ML модели и реальной пользой бизнесу находится огромная пропасть. О том, как её преодолеть, не учат на курсах. Крайне редко рассказывают на конференциях. И в целом, в DS-сообществе считается, что "Мы тут делаем SOTA, поэтому это точно полезно нашей компании". И именно поэтому около 80-90% data science проектов так и не принесут реального Value
О том, как я пытался преодолеть эту пропасть, и сделать настоящий "ML for Value" и пойдёт речь в этом канале. А также о собранных на этом пути граблях :)
Все это будет рассказано на примере истории решения проблем, реальных и вымышленных, с которыми сталкивается почти каждый DS. Структура изложения будет выглядеть так:
Проект
> Часть 1
--- Грабли #1
--- Грабли #2
> Часть 2
--- Грабли #1
--- Грабли #2
👍4
Оптимизация промо-акций.
Часть 1
Зачем понимать ДО начала проекта, что хочет бизнес 💼
Представьте, что вы работаете DS-ом в крупном ритейлере (условно, Дикси/Пятерочка). К вам приходит менеджер и предлагает оптимизировать промо-акции с помощью ML, выбирая оптимальную скидку на каждый товар.
Первым делом нужно узнать:
- Что значит оптимильная скидка (max продаж в шт, выручки, прибыли)
- Как будет использоваться ваша ML модель (Менеджер видит её прогноз и принимает решение, автоматическая устонавка скидки, ...)
Допустим, у вас хороший менеджер, и он сказал, что:
- Оптимальная скидка = max(Прибыли)
- Ваш инструмент будет использовать менеджер для установки скидок. Он подаёт на вход id товара, а ваш инструмент показывает прогнозы прибыли при всех возможных скидках и оптимальную скидку
Так, кажется, что вводные есть, можно формулировать задачу в терминах ML и выбирать метрики!
..но не забыли ли мы кое-что?
#pricing #timeseries
Часть 1
Зачем понимать ДО начала проекта, что хочет бизнес 💼
Представьте, что вы работаете DS-ом в крупном ритейлере (условно, Дикси/Пятерочка). К вам приходит менеджер и предлагает оптимизировать промо-акции с помощью ML, выбирая оптимальную скидку на каждый товар.
Первым делом нужно узнать:
- Что значит оптимильная скидка (max продаж в шт, выручки, прибыли)
- Как будет использоваться ваша ML модель (Менеджер видит её прогноз и принимает решение, автоматическая устонавка скидки, ...)
Допустим, у вас хороший менеджер, и он сказал, что:
- Оптимальная скидка = max(Прибыли)
- Ваш инструмент будет использовать менеджер для установки скидок. Он подаёт на вход id товара, а ваш инструмент показывает прогнозы прибыли при всех возможных скидках и оптимальную скидку
Так, кажется, что вводные есть, можно формулировать задачу в терминах ML и выбирать метрики!
..но не забыли ли мы кое-что?
#pricing #timeseries
👍5👏2
Грабли #1. В каких разрезах нужен прогноз?
Вариантов огромное множество:
> все продажи / по региону / по магазину
> по дням / неделям
> по SKU* / PLU**
При этом почти всегда чем более агрегирован таргет, тем точнее прогноз.
Поговорив с менеджером, вы понимаете, что акции формируются на 1/2 недели (т.к. печатают каталог) на уровне SKU и региона (т.к. есть ограничения логистики)
Также вы узнаете, что акции формируются за 2 недели до их начала, поэтому вам нужен прогноз не на 2 недели вперёд, а на 4. И метрики вы будете изменять на 2-ух последних неделях из 4-ех прогнозируемых
*SKU - все вкусы питьевого йогурта Epica, 3.2%
**PLU - конкретный вкус питьевого йогурта Epica, 3.2%
Вывод:
Важно заранее узнать не только сам таргет (прибыль), но и в каких разрезах необходимо его прогнозировать
Вариантов огромное множество:
> все продажи / по региону / по магазину
> по дням / неделям
> по SKU* / PLU**
При этом почти всегда чем более агрегирован таргет, тем точнее прогноз.
Поговорив с менеджером, вы понимаете, что акции формируются на 1/2 недели (т.к. печатают каталог) на уровне SKU и региона (т.к. есть ограничения логистики)
Также вы узнаете, что акции формируются за 2 недели до их начала, поэтому вам нужен прогноз не на 2 недели вперёд, а на 4. И метрики вы будете изменять на 2-ух последних неделях из 4-ех прогнозируемых
*SKU - все вкусы питьевого йогурта Epica, 3.2%
**PLU - конкретный вкус питьевого йогурта Epica, 3.2%
Вывод:
Важно заранее узнать не только сам таргет (прибыль), но и в каких разрезах необходимо его прогнозировать
❤6
Грабли #2: А что прогнозируем в итоге? 📈📉
Прибыль? Заказы? Изменение чего-то из первых двух? Аплифт? Это самые опасные грабли, на которые вы можете наступить. Прогноз не того, что реально нужно бизнесу = 99% провал ML-проекта
Бизнесу нужно выбрать, какая акция лучше по критерию прироста прибыли. При этом будут сравнивать:
- Разные акции для одного товара
- Разные товары по одной акции
Т.к. у разных товаров разная прибыль без промо (базис), то gross продажи/прибыль нам не подходят. Соответственно выбор между Uplift vs WoW (week over week) изменение
Поймите меня правильно - корректный ответ с математической и экономической точки зрения - Uplift. Но с точки зрения бизнеса ответ - WoW. Но почему??
Ваше решение захотят проверить. И проверять его будут через WoW,а не через разницу фактических продаж по промо и гипотетических продаж без (т.к. факт гипотетических продаж без промо мы не знаем). Грустная история, но такова жизнь 👿
Вывод:
Прогнозируйте и измеряйте то же самое, что и бизнес-заказчики
Прибыль? Заказы? Изменение чего-то из первых двух? Аплифт? Это самые опасные грабли, на которые вы можете наступить. Прогноз не того, что реально нужно бизнесу = 99% провал ML-проекта
Бизнесу нужно выбрать, какая акция лучше по критерию прироста прибыли. При этом будут сравнивать:
- Разные акции для одного товара
- Разные товары по одной акции
Т.к. у разных товаров разная прибыль без промо (базис), то gross продажи/прибыль нам не подходят. Соответственно выбор между Uplift vs WoW (week over week) изменение
Поймите меня правильно - корректный ответ с математической и экономической точки зрения - Uplift. Но с точки зрения бизнеса ответ - WoW. Но почему??
Ваше решение захотят проверить. И проверять его будут через WoW,а не через разницу фактических продаж по промо и гипотетических продаж без (т.к. факт гипотетических продаж без промо мы не знаем). Грустная история, но такова жизнь 👿
Вывод:
Прогнозируйте и измеряйте то же самое, что и бизнес-заказчики
Лайфхак: трюки с таргетом ⚡️
Идеально было бы прогнозировать прирост прибыли, т.к. именно его мы хотим показывать, но:
- Прибыль очень волатильна
- Зависит не только от скидок, но и от стоимости закупки
Поэтому можно прогнозировать прирост продаж (d Sales), а затем через статическую формулу получить прирост прибыли:
d Profit = Profit_t - Profit_t-1=
(Sales_t-1 + d Sales) * (price - discount - cost) - Sales_t-1 * (price - cost)
Вывод:
Иногда стоит выходить за рамки: например, поменять таргет
Идеально было бы прогнозировать прирост прибыли, т.к. именно его мы хотим показывать, но:
- Прибыль очень волатильна
- Зависит не только от скидок, но и от стоимости закупки
Поэтому можно прогнозировать прирост продаж (d Sales), а затем через статическую формулу получить прирост прибыли:
d Profit = Profit_t - Profit_t-1=
(Sales_t-1 + d Sales) * (price - discount - cost) - Sales_t-1 * (price - cost)
Вывод:
Иногда стоит выходить за рамки: например, поменять таргет
Как вам первая часть про уточнение деталей ДО начала проекта? 🤯
Оптимизация промо-акций
Часть 2
Выбор ML-метрик и Loss
Часть 1: договорённости ДО начала проекта. https://news.1rj.ru/str/ml4value/8
Грабли #1: Неочевидные ML метрики 🎯
С таргетом определились. Потихоньку начинаем выстраивать цепочку:
Бизнес метрика --> Таргет --> ML-метрика --> Loss
Давайте обсудим, как выбрать ML-метрики, по которым мы будем оценивать модель. В этом деле важны 2 детали:
1. Насколько страшны большие ошибки прогноза (увеличение ошибки с 0 до 100 и с 100 до 200 съедает одинаковое кол-во прибыли?)
2. Одинакова ли стоимость ошибки в сторону недопрогноза и перепрогноза (ошибка в -100 и +100 заказов - это одинаково плохо для бизнеса?)
Первый пункт влияет на линейность функции ошибки (условно, RMSE или MAE). Если увеличение ошибки с 0 до 100 заказов не приводит к потере денег, а со 100 до 200 - приводит к огромной потере ---> скорее всего, вам нужно смотреть в сторону RMSE. В случае с прогнозом спроса, я бы сказал, что нужно выбирать более линейную функцию ошибки (MAE или схожую)
#pricing #timeseries
Часть 2
Выбор ML-метрик и Loss
Часть 1: договорённости ДО начала проекта. https://news.1rj.ru/str/ml4value/8
Грабли #1: Неочевидные ML метрики 🎯
С таргетом определились. Потихоньку начинаем выстраивать цепочку:
Бизнес метрика --> Таргет --> ML-метрика --> Loss
Давайте обсудим, как выбрать ML-метрики, по которым мы будем оценивать модель. В этом деле важны 2 детали:
1. Насколько страшны большие ошибки прогноза (увеличение ошибки с 0 до 100 и с 100 до 200 съедает одинаковое кол-во прибыли?)
2. Одинакова ли стоимость ошибки в сторону недопрогноза и перепрогноза (ошибка в -100 и +100 заказов - это одинаково плохо для бизнеса?)
Первый пункт влияет на линейность функции ошибки (условно, RMSE или MAE). Если увеличение ошибки с 0 до 100 заказов не приводит к потере денег, а со 100 до 200 - приводит к огромной потере ---> скорее всего, вам нужно смотреть в сторону RMSE. В случае с прогнозом спроса, я бы сказал, что нужно выбирать более линейную функцию ошибки (MAE или схожую)
#pricing #timeseries
👌2
Второй пункт про симметричность ошибки. Недопрогноз --> потеря прибыли из-за того, что товара но полке меньше, чем хотят купить. Перепрогноз - товаров слишком много. И они, например, могут портиться.
Тут начинается интересное:) В большинстве кейсов для ритейла лучше, если товара на полке > чем хотят купить. Пустые полки - самый большой страх. НО в категориях скоропортящихся товаров ситуация ровно обратная, т.к. ритейлер несет существенные потери из-за утилизации испорченных продуктов. +когда клиент видит гнилой банан/помидорку на полке - это не очень хорошо. Поэтому наша ML метрика будет зависеть от категории товара! 🍫/🍌
Важно: менеджеры понимат только симметричные метрики в интервале от 0 до 100%. Поэтому мы можем измерить 2 метрики:
MAPE = sum(|y - y_true|) / sum(y_true)
Bias = sum(y - y_true) / sum(y_true)
И будем говорить, что для большинства категорий мы хотим минимизировать MAPE при bias от +1% до +5%, а для скоропортящихся товаров - минимизировать MAPE при bias от -1% до -5%
(!) Не забываем, что нужно измерять MAPE и MAE для изменения прибыли, а не продаж. Иногда такую метрику называют WAPE - Weighted average percent error
Вывод:
Используйте метрики, нормированные от 0 до 100%, чтобы их было легко объяснить. Учитывайте стоимость ошибки в большую и меньшую стороны
Тут начинается интересное:) В большинстве кейсов для ритейла лучше, если товара на полке > чем хотят купить. Пустые полки - самый большой страх. НО в категориях скоропортящихся товаров ситуация ровно обратная, т.к. ритейлер несет существенные потери из-за утилизации испорченных продуктов. +когда клиент видит гнилой банан/помидорку на полке - это не очень хорошо. Поэтому наша ML метрика будет зависеть от категории товара! 🍫/🍌
Важно: менеджеры понимат только симметричные метрики в интервале от 0 до 100%. Поэтому мы можем измерить 2 метрики:
MAPE = sum(|y - y_true|) / sum(y_true)
Bias = sum(y - y_true) / sum(y_true)
И будем говорить, что для большинства категорий мы хотим минимизировать MAPE при bias от +1% до +5%, а для скоропортящихся товаров - минимизировать MAPE при bias от -1% до -5%
(!) Не забываем, что нужно измерять MAPE и MAE для изменения прибыли, а не продаж. Иногда такую метрику называют WAPE - Weighted average percent error
Вывод:
Используйте метрики, нормированные от 0 до 100%, чтобы их было легко объяснить. Учитывайте стоимость ошибки в большую и меньшую стороны
👍1
#оффтоп
"What one programmer can do in one month, two programmers can do in two months. – Frederick P. Brooks"
Радует, что в сообществе начинают появляться блогпосты о том, что DS должны быть более end-to-end, чтобы приносить value
Unpopular opinion: Data scientist should be more end-to-end
https://eugeneyan.com/writing/end-to-end-data-science/
TL;DR
Фокус на решении изначальной бизнес-проблемы, а не узких задачах про данные/модель/микросервис/.. позволяет:
1. Более глобально понимать бизнес - - > делать более эффективные решения
2. Делать те задачи, которые полезны бизнесу, а не те, которые кажутся полезными с точки зрения ML
3. Снизить число ненужных коммуникаций (DE - DS - ML engineer - ML Ops - РМ) и ускорить решение задачи
4. Повышает шанс довести задачу до конца, т.к. есть конкретный ответственный за неё человек, а не плеяда data-* специалистов
Имхо, абсолютно согласен. Я бы разделял только data-related обязанности и инфраструктурные.
Условно, делать базу данных и инфраструктуру микросервисов для инференса должны архитекторы / software инженеры. А вот все, что связанно непосредственно с обработкой данных и ML - работа data scientist-а
"What one programmer can do in one month, two programmers can do in two months. – Frederick P. Brooks"
Радует, что в сообществе начинают появляться блогпосты о том, что DS должны быть более end-to-end, чтобы приносить value
Unpopular opinion: Data scientist should be more end-to-end
https://eugeneyan.com/writing/end-to-end-data-science/
TL;DR
Фокус на решении изначальной бизнес-проблемы, а не узких задачах про данные/модель/микросервис/.. позволяет:
1. Более глобально понимать бизнес - - > делать более эффективные решения
2. Делать те задачи, которые полезны бизнесу, а не те, которые кажутся полезными с точки зрения ML
3. Снизить число ненужных коммуникаций (DE - DS - ML engineer - ML Ops - РМ) и ускорить решение задачи
4. Повышает шанс довести задачу до конца, т.к. есть конкретный ответственный за неё человек, а не плеяда data-* специалистов
Имхо, абсолютно согласен. Я бы разделял только data-related обязанности и инфраструктурные.
Условно, делать базу данных и инфраструктуру микросервисов для инференса должны архитекторы / software инженеры. А вот все, что связанно непосредственно с обработкой данных и ML - работа data scientist-а
eugeneyan.com
Unpopular Opinion: Data Scientists Should be More End-to-End
Why (and why not) be more end-to-end, how to, and Stitch Fix and Netflix's experience
👌1
Грабли #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
Что ж, мы определились, что 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
Medium
Prediction Intervals in Forecasting: Quantile Loss Function
In most real world prediction problems, the uncertainty in our predictions provides significant value
❤2
Оптимизация промо акций
Часть 3
ML - это не только модели
Хороший подход при построении модели таков:
Строим MVP (базовую модель) - - > тестируем её в бою - - > собираем фидбек/метрики - - > улучшаем
Повторяем цикл несколько раз
Представим, что мы построили MVP с помощью LightGBM и запустили наш ML проект в бой. И отправимся в увлекательное путешествие по граблям ✈️
#pricing #timeseries
Часть 3
ML - это не только модели
Хороший подход при построении модели таков:
Строим MVP (базовую модель) - - > тестируем её в бою - - > собираем фидбек/метрики - - > улучшаем
Повторяем цикл несколько раз
Представим, что мы построили MVP с помощью LightGBM и запустили наш ML проект в бой. И отправимся в увлекательное путешествие по граблям ✈️
#pricing #timeseries
Грабли #1: Иногда модель прогнозирует падение спроса при росте скидки 📉
- "Стоп.. Как такое возможно?" - спросите вы
- "Элементарно" - ответит любое решающее дерево
Вроде бы простейшую логику "при росте скидки растёт спрос" деревьям очень сложно выучить. Деревья в целом очень плохо учат около-линейные зависимости
К счастью, в LightGBM есть параметр monotone_constraints, который позволяет задать ограничение на монотонность по каждой фиче
Пофиксили.
- "Стоп.. Как такое возможно?" - спросите вы
- "Элементарно" - ответит любое решающее дерево
Вроде бы простейшую логику "при росте скидки растёт спрос" деревьям очень сложно выучить. Деревья в целом очень плохо учат около-линейные зависимости
К счастью, в LightGBM есть параметр monotone_constraints, который позволяет задать ограничение на монотонность по каждой фиче
Пофиксили.
Грабли #2: Почему-то модель прогнозирует меньше, чем есть на самом деле.. или проблемы в данных
Несмотря на то, что для большинства категорий мы прогнозируем 55% квантиль, итоговый прогноз в среднем < факта! То есть у нас отрицательный bias. Чтобы разобраться, что случилось, начинаем копаться в данных и видим, что под конец многих акций продажи падаюют в 0, хотя в начале акции они довольно хорошо росли
В ритейле и не только бывают out-of-stock: товар физически заканчивается на полке. Клиенты хотели бы купить больше товаров, но их нет. А нам нужно прогнозировать как раз то, сколько купили бы клиенты, если товаров было бы досатоточно. То есть в среднем таргет в модели < реального прироста продаж
Вариантов решения 2:
1. Если у нас есть данные по out-of-stock (обычно инвентаризация), то мы можем убрать из обучающей выборки те даты, когда товар заканчивался. А лучше еще и пару дней до этого момента
2. Если таких данных нет, то попытаться определить out-of-stock по данным. Для начала можно попробовать простейшие правила вроде:
- Продажи на промо < 1/2 средненедельных продаж без промо
- Продажи на второй неделе промо < 1/4 продаж на первой неделе
Есть шанс, что что-то из этих вариантов сработает
Несмотря на то, что для большинства категорий мы прогнозируем 55% квантиль, итоговый прогноз в среднем < факта! То есть у нас отрицательный bias. Чтобы разобраться, что случилось, начинаем копаться в данных и видим, что под конец многих акций продажи падаюют в 0, хотя в начале акции они довольно хорошо росли
В ритейле и не только бывают out-of-stock: товар физически заканчивается на полке. Клиенты хотели бы купить больше товаров, но их нет. А нам нужно прогнозировать как раз то, сколько купили бы клиенты, если товаров было бы досатоточно. То есть в среднем таргет в модели < реального прироста продаж
Вариантов решения 2:
1. Если у нас есть данные по out-of-stock (обычно инвентаризация), то мы можем убрать из обучающей выборки те даты, когда товар заканчивался. А лучше еще и пару дней до этого момента
2. Если таких данных нет, то попытаться определить out-of-stock по данным. Для начала можно попробовать простейшие правила вроде:
- Продажи на промо < 1/2 средненедельных продаж без промо
- Продажи на второй неделе промо < 1/4 продаж на первой неделе
Есть шанс, что что-то из этих вариантов сработает