Привет!

Меня зовут Иван Максимов,
@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

Оптимизация промо-акций.
Часть 1
Зачем понимать ДО начала проекта, что хочет бизнес 💼

Представьте, что вы работаете DS-ом в крупном ритейлере (условно, Дикси/Пятерочка). К вам приходит менеджер и предлагает оптимизировать промо-акции с помощью ML, выбирая оптимальную скидку на каждый товар.

Первым делом нужно узнать:
- Что значит оптимильная скидка (max продаж в шт, выручки, прибыли)
- Как будет использоваться ваша ML модель (Менеджер видит её прогноз и принимает решение, автоматическая устонавка скидки, ...)

Допустим, у вас хороший менеджер, и он сказал, что:
- Оптимальная скидка = max(Прибыли)
- Ваш инструмент будет использовать менеджер для установки скидок. Он подаёт на вход id товара, а ваш инструмент показывает прогнозы прибыли при всех возможных скидках и оптимальную скидку

Так, кажется, что вводные есть, можно формулировать задачу в терминах ML и выбирать метрики!

..но не забыли ли мы кое-что?

#pricing #timeseries

Грабли #1. В каких разрезах нужен прогноз?

Вариантов огромное множество:
> все продажи / по региону / по магазину
> по дням / неделям
> по SKU* / PLU**

При этом почти всегда чем более агрегирован таргет, тем точнее прогноз.

Поговорив с менеджером, вы понимаете, что акции формируются на 1/2 недели (т.к. печатают каталог) на уровне SKU и региона (т.к. есть ограничения логистики)

Также вы узнаете, что акции формируются за 2 недели до их начала, поэтому вам нужен прогноз не на 2 недели вперёд, а на 4. И метрики вы будете изменять на 2-ух последних неделях из 4-ех прогнозируемых

*SKU - все вкусы питьевого йогурта Epica, 3.2%
**PLU - конкретный вкус питьевого йогурта Epica, 3.2%

Вывод:
Важно заранее узнать не только сам таргет (прибыль), но и в каких разрезах необходимо его прогнозировать

Грабли #2: А что прогнозируем в итоге? 📈📉

Прибыль? Заказы? Изменение чего-то из первых двух? Аплифт? Это самые опасные грабли, на которые вы можете наступить. Прогноз не того, что реально нужно бизнесу = 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)

Вывод:
Иногда стоит выходить за рамки: например, поменять таргет

Как вам первая часть про уточнение деталей ДО начала проекта? 🤯

Оптимизация промо-акций
Часть 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

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

Тут начинается интересное:) В большинстве кейсов для ритейла лучше, если товара на полке > чем хотят купить. Пустые полки - самый большой страх. НО в категориях скоропортящихся товаров ситуация ровно обратная, т.к. ритейлер несет существенные потери из-за утилизации испорченных продуктов. +когда клиент видит гнилой банан/помидорку на полке - это не очень хорошо. Поэтому наша 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%, чтобы их было легко объяснить. Учитывайте стоимость ошибки в большую и меньшую стороны

#оффтоп

"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-а

Full stack data scientist

Да-да, писать тесты на данные и ML-модели - это тоже часть вашей работы