Как и обещал, сегодня напишу про то, что скрывается за "да просто отсортируй товары по популярности, делов на 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". Авторы нашли некую корреляцию между воспроизводимостью результатов и цитируемостью. И написали в статье именно о корреляции. Намеренно снижая воспроизаодимость результатов, вы конечно же не повысите цитируемость статьи:)

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

Но к чему я все это:

Когда вы как аналитик/DS показываете результаты своего рисерча (сравнения средних / коэффициенты линейной регрессии /..) бизнес-заказчику, то внимательно следите за разницей Correlation VS causality

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

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

Будьте осторожны 📈📉❗️

Около полугода назад я стал тимлидом команд персонализации и А/В в Delivery Club. И примерно с тех пор почти не было новых постов в канале 🙂

За это время произошло много интересного: мы запустили несколько крупных проектов, наняли крутых ребят (это заслуживает отдельного поста), я вновь был студентом, а ещё научился совершенно неожиданным для себя вещам

Кажется, настало время возобновить посты и поделиться этим интереснейшим опытом с вами!)

И для начала небольшое резюме того, что я понял за эти полгода:

1. Вдруг осознал, что на своем опыте смог проследить, зачем действительно нужны все best practice в техническом плане ⚙️
За 2 года в деливери мы прошли крутое путешествие от PostgreSQL --> python + jenkins --> metabase до всех современных buzzwords: зоопарк apache, poetry, docker, автотесты, микросервисная архитектура, Golang и много всего еще! Прямо на моих глазах поменялась бОльшая часть технического стека. И самое главное - я четко понимаю, почему и зачем мы его меняли

Если вкратце, то best practice в долгосрочной перспективе сильно упрощают жизнь и позволяют в целом масштабировать data science в компании. 1 DS может и в ноутбуке крутить ML, а вот 10 DS уже должны обзавестить всеми best practices

2. Agile работает
Спринты, планирование, задачи в jira, документация в конфлюенс и все-все и правда делает вашу жизнь проще и эффективнее в среднесрочной перспективе. Но сначала будет немного больно

3. Планировать нужно
Еще раз убедился, что лучше потратить 2 недели на брейншторм и планирование DS проекта, чем потом 2 месяца менять все на ходу

4. 💪Сильный продакт в DS проекте - ваш главный друг и залог успеха проекта
Одна и та же ML-модель (в моем случае recsys) может выглядеть и влиять на пользователя совершенно по-разному. Это очень сильно зависит от того, как ее результаты будут представлены пользователям

5. Вокруг очень много крутых ребят, у которых есть чему поучиться
Даже если вы Ян Лекун в ML, то всегда можно научиться хорошим практикам кода у разработчиков, продуктовому видению у менеджеров, пониманию метрик у аналитиков

Hidden technical debt in ML systems