Рекомендательные системы
Часть 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-кривой, а не площадь под ней!

Модель с другой (зелёной) ROC-кривой имеет ROC-AUC меньше оранжевой, но с точки зрения бизнеса модель с зелёной кривой лучше!

#metrics