Во-первых, персонально != только через ML

Если у вас бизнес, в котором юзер покупает один и тот же товар регулярно, то прекрасная персональная рекомендация - это рекомендовать то, что юзер уже покупал. Поверьте, такую "модель" рекомендаций очень сложно побить

Конечно же в бизнесе, где юзер покупает товар только 1 раз (фильмы, продажа бытовой техники и т.п.) это не сработает

Во-вторых, мы сильно недооцениваем модель "рекомендуй самое популярное". У которой есть ещё куча вариаций вроде "самое популярное в каждой категории"

На самом деле во многих сервисах (в том же Нетфликс!) есть разделы вроде "Популярное", "Смотрят сейчас", "Новинки", которые строятся безо всякой персонализации! Но при этом эти рекомендации релевантный очень многим пользователям просто потому что они популярны

Даже классическая модель ALS предполагает обучение формулы:
y = b_i + b_u + emb_i * emb_u

То есть да, предсказания получаются при перемножении эмбеддингов emb_i * emb_u, но почему-то все забывают про bias товара bi

А ведь может оказаться, что b_i >> emb_i * emb_u, и тогда по сути именно b_i будет влиять на рекомендации

Но все же модели рек систем (ALS, LightFM,...) позволяют:
- делать персональные рекомендации и повышать покрытие базы товаров. То есть рекомендуем не 0.01% самых популярных всем, а 30% товаров
- Позволяет учесть текущие интересы пользователя (условно через поиск ближайших соседей к последнему посту с лайком)
- Ранжировать те же популярные товары персонально

Поэтому они полезны :) Но они - не панацея

В общем, персональные/релеваньные рекомендации - это не всегда ML и не всегда персонально 🙃

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

В следующих постах поговорим про то, какие сложности возникают когда мы следуем стратегии "рекомендуем популярное"

И конечно обсудим, как с ними можно справиться!

Как и обещал, сегодня напишу про то, что скрывается за "да просто отсортируй товары по популярности, делов на 30 минут!"

Обычно продакты / менеджеры, предлагая сортировку "по популярности", не договаривают несколько вещей:

1. Популярные товары должны приносить прибыль
А это не всегда так. Например, один из самых популярных товаров в продуктовых ритейлерах - бананы - обычно продают себе в убыток

Так что "сортировка по популярности" должна учитывать суммарную прибыль, которую приносит товар

#recsys

2. В сортировке не должно быть "нежелательных" товаров

Обычно самый очевидный и самый сложный пункт. Отсортируйте товары по популярности в Ашане - как думаете, что будет на 1ом месте? Хлеб, молоко, бананы? А вот и нет - пакет. Но согласитесь, рекомендовать пакеты глупо?

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

Поэтому нужно помнить про Black list товаров/категорий

3. Товары в сортировке должны быть разнообразными

Если вы выполнили первые 2 пункта, то это вас не спасёт от того, что топ-20 позиций в сортировке займёт хлеб. Может, хлеб и популярен, и действительно является хорошей рекомендаций, но не 20 же штук 😝

Обычно, чтобы такого не было, товары не сортируют по популярности, а сэмплируют с вероятностью пропорциональной популярности - проверено, работает

UPD: как верно подметили в комментариях, иногда похожие товары в одной ленте рекомендаций - это хорошо. Например, когда юзер ищет брюки, а вы ему рекомендуете топ-10 популярных брюк. Есть и другие кейсы)

4. Всё пункты выше касаются и более умных / ML сортировок - помните про эти "очевидные" пункты всегда!

*В своей карьере я видел ml-модели, которые рекомендовали пакеты в ритейле. Поверьте, таких замечательных ML-метрик и даже продуктовых метрик в А/В я больше никогда не видел

**это к вопросу выбора адекватных метрик 😜
О чем и пойдёт речь на следующей неделе!)

Как вам такие "очевидные" советы в сортировке по популярности?

P.S. Хоть они и очевидные, но я сплошь и рядом вижу косяки в таких кейсах (да и сам иногда их совершаю)

Кстати про рекомендацию пакетов. В ODS сейчас увидел пост, где одному известному члену сообщества посчитали его любимый товар - им оказался пакет 😅

Как вы понимаете, считали просто по популярности, и забыли убрать "особые" товары и категории

Долго думал, как уместить рассказ о метриках в небольшой пост, но не смог придумать. Поэтому про них будет что-то более масштабное (пост на Хабр или целый вебинар) чуть позже

А сегодня будет немного необычный формат - попробуем сделать reverse engineering ML проекта!) И конечно подумать, как его улучшить, чтобы он принес больше пользы - поехали 🚂

Начнём с классики: ML для пополнения товаров на полке из статьи

Задача звучит примерно так:
В течение дня товары на полке в магазине заканчиваются. Но товар есть на складе магазина. Как бы нам научиться определять, что товар заканчивается, и вовремя принести доп единицы товара со склада?

Бизнес польза вполне очевидна:
Мы повышаем доступность товара —> повышаем продажи

Ограничения:
Данных по остаткам (кол-ву товара на полке) у нас нет. Есть только данные по продажам на кассе

Как решали в статье:
Мне очень понравилось, что ребята честно написали как провалилась тяжёлая артиллерия с LightGBM (почитайте подробности в статье - оно того стоит), и в итоге они остановились на очень простом подходе:

1. Спрос на товар имеет распределение Пуассона
2. Давайте по истории оценим его параметр mu = среднее
3. Зная закон распределения и его параметр mu, мы можем считать вероятность того, что товар был продан <= k раз
4. Если до 14 часов для фактического кол-ва продаж такая вероятность < 1%

P(кол-во продаж <= фактические продажи до 14:00) < 1%

, считаем, что товар закончился (поэтому у него так мало продаж) и его нужно пополнить на полке

В итоге в статье говорят, что в 58% случаев такой подход действительно выявляет, что товара на полке нет. При этом случайная модель выявляла бы такие товары лишь в 5% случаев

Какие плюсы в подходе ребят я вижу:
- Просто. А простая модель - то, что нужно для MVP
- Легко масштабируется
- Показывает впечатляющее качество

Но есть и минусы:
- Написали про точность (precision) в 58%, но ничего не сказали про recall. Наверняка в магазине есть товары, которые всегда заканчиваются к 14:00 (горячий хлеб, пирожки, салаты). Вполне может оказаться так, что модель классно определяет именно эти товары (условно 10% от всех Stock-out), а оставшиеся вообще не определяет
- Порог вероятности в 1% тоже выглядит немного подозрительно и наводит на мысль о низком recall
- Как я понял, А/В теста не было
- Время пополнения со склада в 14:00 выглядит как бизнес правило. Возможно, получится сильно все улучшить просто делая пополнение условно и в 14:00, и в 18:00

После опроса выше я крепко задумался, а почему, собственно, все ритейлеры не внедряют систему мониторинга остатков на складе + учёт данных с касс = знание об остатках на полках?

А вместо этого компании внедряют очень дорогой computer vision для детекции stock-out на полке, и стартапы в этой сфере растут как на дрожжах (примеры 1, 2, 3). Поговорил с несколькими дата саентистами из индустрии и узнал, что главная проблема - лаг в поступлении данных с касс. И он может быть не несколько минут, а скорее 6+ часов! Понятное дело, что с таким лагом наш подход не работает

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

Да, кстати, все DS-ы из индустрии, с которыми я говорил, согласились, что риал-тайм данные с касс + мониторинг остатков - пожалуй, самый простой и дешёвый (!) способ очень точно знать стоки на полках, если:
- у ритейлера уже есть система мониторинга стоков на складе
- данные с касс льются с небольшим лагом

Сегодня речь пойдёт о рейтинге. Вроде бы обыденная привычная вещь: все мы видели рейтинги фильмов на Netflix или Кинопоиске, рейтинг товаров в том же М.Видео, рейтинг ресторанов, да и вообще рейтинги везде. Но как они получаются и зачем нужны?

Первая мысль - ну, клиенты ставят оценки от 1 до 5, они усредняются и получается рейтинг, что сложного-то?

С одной стороны, да. С другой, рейтинг должен:
1. Быть честным
2. Помогать потребителям делать выбор
3. Мотивировать продавцов товаров/услуг их улучшать

Допустим, один отель получил средний рейтинг 5.0 от 6 человек. А другой - 4.6, но от 1 000 человек. Честен ли такой рейтинг? Очевидно нет: пройдёт время, больше людей оценит первый отель, и скорее всего его рейтинг снизится. Ну и очевидно, что рейтинги из примера выше скорее мешают пользователям выбирать между отелями

А теперь представьте себя на месте владельца отеля с рейтингом 4.6: у него есть очевидный вопрос "Как мне улучшить мой рейтинг?". Ведь от рейтинга зависит то, сколько клиентов и прибыли у него будет

Например, Booking решает эти 3 сложности с рейтингом с помощью достаточно необычного ML подхода. Сначала эксперты вручную ставят рейтинг части отелей. Затем Booking обучает 4 lightgbm моделей, которые прогнозируют P(рейтинг > k), k=1,...4

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

Booking сортирует ленту в том числе по рецтингу - этим он помогает клиентам выбирать отели

А потом с помощью shap векторов Booking объясняет отелям, почему их рейтинг именно такой, и рекомендует, как его улучшить. Выглядит довольно просто, элегантно и эффективно - все как я люблю 😋

Кстати, рекомендации по улучшению рейтинга выглядят вот так: владельцу отеля вполне понятно, что нужно делать

Ну а если вам понравилась тема про рейтинги, то подробности подхода Booking вы можете почитать здесь. Поставьте палец вверх, и в следующих постах я расскажу ещё много крутых вещей про рейтинги:)

https://nplus1.ru/news/2021/05/26/citing-nonreplicable-publications

Недавно наткнулся на статью о том, что "Статьи с невозпроизводимыми результатами цитруются чаще"

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

Ещё более забавно то, что кто-то перевёл заголовок статьи на русский как "невоспроизводимость научных статей только увеличивает их цитируемость"

Переводчики этого рисерча сами допускают одну из логических ошибок. Вы наверняка её знаете: "Correlation does not imply causality". Авторы нашли некую корреляцию между воспроизводимостью результатов и цитируемостью. И написали в статье именно о корреляции. Намеренно снижая воспроизаодимость результатов, вы конечно же не повысите цитируемость статьи:)

Но переводчики рисерча недосмотрели / решили сделать более кликбейтный заголовок. Грустно.