Чек лист перед началом ML-проекта

1. Спроси "А зачем?" перед тем, как бежать делать проект. И уточни, что хочет в итоге получить менеджер/бизнес

2. Проверь, достаточно ли:
-- данных
-- вычислительных мощностей
-- времени у ds-специалистов

3. Представь, как пошагово ты будешь решать проблему через ML. Не получается? Возможно, решения через ML не существует

4. Представь, что модель уже готова. Подумай, что ещё нужно сделать (бизнес-ограничения, катить в продакшн, получить согласования,..)

5. А в самом лучшем случае, сколько денег это нам принесёт? Сравни свою оценку доп. денег с оценкой менеджера

6. Что и где может пойти не так? Если рисков слишком много, то, может, пока и не стоит начинать?

Рекомендательные системы
Часть 2
Грабли #1: А достаточно ли данных?

На первый взгляд, ответить можно за пару минут: вспомнить, что у нас пишутся данные по онлайн и оффлайн продажам уже 2 года и все, но.. Нет

1. Есть ли привязка юзера к покупке?

Данные по продажам, может и записываются. Но вопрос в том, пишется ли в каком-то виде id-шник юзера в заказе

В ритейле это, как правило, либо логин (~онлайн id) для онлайн покупок, либо id карты лояльности для оффлайн. Обидно будет, если только у 3% юзеров есть такие id-шники

2. Есть ли данные по скидкам?

Мы ведь хотим давать персональные скидки в рекомендациях. Будет непросто это сделать без данных о том, когда, на какой товар и какая скидка была

В моей практике далеко не у всех компаний были такие данные. Были кейсы, когда историю промо вели понедельно в csv..

Если вдруг данных нет, то можно попробовать восстановить размер скидки из истории цен. Например, сравнивать цену товара в неделю week_t со средней ценой товара за week_{t-3} - week_{t-1}. Но на это вам стоит заложить сразу +2-3 недели: в таких алгоритмах много подводных камней

3. А e-mail-ы то есть?

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

Если вдруг email-ов нет, то можно:
- Рассылать рекомендации ещё и через смс (вдруг телефоны есть)
- Делать push up уведомления в приложении / на сайте
- Печатать персональные скидки на чеке (так делает ритейлеры Виктория, Перекрёсток)
- Начать бесплатно раздавать карты лояльности с регистрацией через e-mail / cмс. Так со временем мы получим привязку юзера к заказу
- Стимулировать онлайн-покупки. Например, М.Видео даёт скидку в 3% на любую покупку онлайн. Это происходит в том числе, чтобы потом направить всю мощь персонализации на юзера

Рекомендательные системы
Часть 2
Грабли #2: А как это будет выглядеть? 🙈 vs 😍

Юзеру все равно, используете ли вы под капотом набор эвристик или SOTA. Ему важно, чтобы продукт:
-- Выполнял его базовую потребность (купить новый холодильник да подешевле)
-- Был визуально приятен
-- Был удобен

Ваша моделька прямиком с KDD2020 будет бесполезной, если у рекомендуемого товара нет фото, описания или цены

Идеальный loss и метрики не помогут, если вы будете писать название товара также как в базе данных (СТИРАЛ.МАШ. BOSH 13К сер.17)

Никто не купит больше товаров, если не откроет письмо из-за его неудачного заголовка

Если вы будете рекомендовать пакеты / подарочные упаковки и прочие очень популярные, но далеко не ключевые товары в вашем магазине (а все мы помним, что recsys зачастую имеют bias в сторону популярных товаров), то ваши бизнес-оунер и юзеры не будут рады

Не ждите отклика на e-mail рассылки, если вы забыли про часовые пояса в России и разослали всем письма в 20:00 по Мск.. или в 2 ночи по Хабаровскому времени

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

Делайте ML-продукты, а не ML-модели

Рекомендательные системы
Часть 2
Грабли #3: Заработаем ли мы больше денег?

Почему-то про эффективность самих ML-проектов никто не говорит. А стоит. Прикинем (очень грубая оценка) до начала проекта, сколько доп денег мы получим в лучшем случае

Пусть мы узнали, что:
>> актуальные e-mail-ы есть у 20% юзеров
>> Маркетинг готов давать в среднем 10% скидку. В лучшем кейсе мы вообще не даём скидки (0%) и все идеально. То есть в прибыльности с 1 продажи мы нисколько не теряем
>> В лучшем случае конверсия из e-mail в покупку будет около 3%. Да-да, это ещё очень хорошо

Прикинем прирост прибыли в лучшем случае. Пусть прибыль от продаж сейчас = Х

Х * 0.2 * (1.0 - 0.0) * 0.03 = 0.006 * Х

Или прирост прибыли в 0.6%. Как-то не круто

Я знаю довольно много историй, когда люди понимали, что ML проект приносит мало денег уже когда он сделан. Не надо так 😞


Что же делать с нашим проектом? Сразу сворачиваем?..

На самом деле, нет

Я тут вижу 2 способа повысить прибыль:

Способ 1

E-mail есть всего у 20% юзеров. Можно подумать, как рассылать сообщения остальным

- Уведомления в приложении
- Уведомления на сайте при онлайн покупке
- Физическая бумажка с персональной скидкой на следующую покупку, которую вы выдаёте на кассе
- Есть и другие способы 😉

Такими мерами можно увеличить покрытие с 20% до 80% юзеров. Итого, наш прирост прибыли станет в 4 раза больше:
0.6 * 4 = 2.4%

Способ 2
Попробовать увеличить средний чек, давая скидку. Причём давать такую скидку, которая увеличивает прибыль от продажи 1 товара.

Условно, дать скидку 5% и увеличить средний чек на 15%. Вы же помните акции вроде "Скидка 5% при покупке от Х руб"? Вот на это они и расчитаны:)

Тогда при средней прибыли с продажи в 30% получим прирост:

(30%-5%) * (1 + 0.15) - 30% = +4.5% прибыли

Вывод
Посчитайте экономику проекта до его начала. Иногда вы с удивлением обнаружите, что ML приносит мало денег. Тогда вы сможете заранее придумать, что поменять, чтобы это исправить

​​#разбор
Недавно я дал своим студентам задачу рекомендовать 5 товаров, оптимизируя такую метрику с ограничениями:

money_precision@5 = SUM(price_i * relevant_flag_i) / SUM(price_i * recommended_flag_i),

Рекомендуем хотя бы 1 дорогой товар (price_i > 7$)


При этом средняя цена товара в датасете ~2$. В общем, решил имитировать максимизацию выручки от рекомендации (метрика отражает выручку + ограничение заставляет рекомендовать хотя бы 1 дорогой товар) 💰💰

Интересно, что без ограничения метрика достаточно легко достигает 25%. Но как только применяем ограничение - падает до 10-12%

Как вы думаете, почему? И что такое падение может означать с точки зрения бизнеса? Напишите свои идеи в комментарии

А в следующих постах мы подробнее разберём этот кейс. Оказывается, на нем можно объяснить очень много о value рекомендательных систем для бизнеса

#разбор
Для начала давайте разберем метрику из поста выше:

money_precision@5 = SUM(price_i * relevant_flag_i) / SUM(price_i * recommended_flag_i),

Рекомендуем хотя бы 1 дорогой товар (price_i > 7$)


Пусть товар дороже 7$ стоит ровно 7$ и пусть его точно никто не купит

р - средняя цена рекомендованного товара

Х (от 0 до 5) - кол-во купленных среди рекомендованных, тогда

р*Х / (7 + р*4) > 0.2
Х > 0.8 + 1.4 / р
precision@5 = X/5 > 0.2 + 0.28/p

Как видите, зависимость от цены (р) НЕ линейная. Очень выгодно рекомендовать дорогие товары с точки зрения метрики

При p = 1 вам нужно угадать аж 2.2 товара из 5 (это соответствует precision@5 = 44%!. Что почти невозможно)

При р = 3 - около 1.26 из 5 (precision@5 =25%)
При р = 5 - около 1.1 из 5 (precision@5 = 22%)

Ситуация очень похожа на реальность: лучше продать 1 товар по цене 5$, чем 2 по цене 1$

Вывод
Всегда учитывайте деньги в метрике

Но как же оптимизировать money_precision@5?

На самом деле из поста выше можно получить, что:

money_precision@5 = precision@5 - 0.28/p

Если мы прогнозируем вероятность покупки товара (~precision@5), то нам просто нужно завысить вес ошибки для дорогих товаров пропорционально 0.28/р. Для этого можно взять вес ошибки, например как е^(alpha * p)

Кстати, в рекомендательных системах часто точно также взвешивают наблюдения по давности взаимодействия. Чтобы давнее взаимодействие юзера с товаром имело меньший вес, чем новое

Вывод
Приближение loss функции к реальности можно добиться за счёт взвешивания наблюдений (sample_weight)

Mind the weights 👍

В канале давно не было постов: предновогоднее выкатывание проектов в прод сказывается:) Исправляюсь

Рекомендательные системы
Грабли #4: А как оптимизировать нестандартные бизнес-метрики?

Иногда бизнес-метрика не является функцией от вероятности покупки/клика (что мы обычно прогнозируем). Условная соц сеть хочет увеличить среднюю длину сессии, ритейлер - частотность покупок, а логистическая компания - уменьшить время доставки. Что же делать в таких случаях?

Возможный ответ до ужаса очевиден: сделать бизнес метрику функцией от того, что вы предсказываете!

На эту тему есть прекрасное выступление про "умную ленту vk": попроще и посложнее с causal inference

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

1. Представим, что вы можете предсказывать вероятность N действий пользователя p(x_i), x_i = {просмотр, покупка, лайк, выход из приложения,...} .

2. При этом ваша целевая метрика y_i = длина сессии.

3. Тогда можно построить линейную регрессию:
y_i = alpha_1*p(x_1) + alpha_2*p(x_2) +...

После оценки её параметров alpha_i, вы можете легко получать прогноз бизнес метрики, исходя из прогнозов вероятностей действий пользователя p(х_i)!

Вопрос только в том, как собрать обучающую выборку?

Вы можете разделить выших юзеров на условные 5 000 групп. Случайно насэмплировать 5 000 наборов alpha_i. И, ранжируя посты по y_i из формулы

y_i = alpha_1*p(x_1) + alpha_2*p(x_2) +...

Показать вашим юзерам 5 000 разных сортировок. В итоге, вы получите наборы y: {alpha_i}

И по ним вполне можно получить оптимальные параметры линейной регрессии

Вуаля, вы великолепны! Теперь у вас есть формула, превращающая предсказания кликов, лайков и прочего в длину сессии

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

Используйте всю мощь функций! И превратит ваши ML-прогнозы в бизнес-метрики

На опрос выше ответы разделились примерно поровну между "с ROC-AUC = 85%" и "Нельзя однозначно выбрать". Давайте разбираться 😀

#metrics

Правильные ответ - нельзя однозначно выбрать. Исчерпывающее обьяснение можно найти в статье. И меня очень радует, что так много подписчиков канала ответили верно!)

TL;DR
Все зависит от:
1) Баланса классов
2) Стоимости ошибок False Positive (FP) и False Negative (FN)

Да, популярный миф про то, что ROC-AUC подходит для несбалансированных классов тоже ложь⚡️

С точки зрения бизнеса ошибки FP и FN стоят по-разному. Стоимость ошибок и вероятность их совершить (доли классов) формируют кривую безразличия - кривая, вдоль которой бизнесу все комбинации False Positive rate и True Positive rate одинаково ценны

Вся прелесть в том, что такие кривые можно нарисовать прямо на графике ROC-кривой!

P.S. Таких кривых бесконечное множество и они получаются сдвигом по вертикали относительно друг друга. Чем кривая выше, тем бизнес более счастлив

Возможная кривая безразличия для нашей задачи. Касание самой высокой кривой безразличия с ROC-кривой определяет оптимальный трешхолд с точки зрения баланса разных типов ошибок. На графике касание происходит в точке (1,1), что соответствует порогу 0%

То есть модель, которая всегда предсказывает класс 0 с точки зрения бизнеса лучше, чем текущая ML-модель с любым порогом принятия решения, кроме 0%

Теперь самое главное - как определить наклон этой кривой?

Есть формула:

s = r_n * c_n / r_p * c_p,

r_i - доля класса i
c_i - стоимость неверной классификации класса i

То есть на самом деле, решающее значение играет форма Roc-кривой, а не площадь под ней!