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

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

Как вам такое развенчание мифа?)

P.S. Расскажите про это на собеседовании, и пока ваш собеседник в шоке, просите свои 300к/сек 🔥

Сегодня последний день в году, и пора подводить итоги года 🌲

Канал ML4Value 💥
Я очень давно хотел начать публично писать про то, как ML может принести настоящую пользу бизнесу - и в этом году сделал это! Чему я несказанно рад

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

А ещё в планах запуск полноценного курса по ML4Value - сначала мы его оттестим, а ближе к апрелю вы сможете его увидеть:)

Что я понял за этот год 🕵‍♂🧠
1. Самыми полезными курсами в СколТехе были курсы по soft skills (Product design, From idea to startup, negotiation)

Да-да, истории про короткие и быстрые итерации разработки продукта, важности писать краткие итоги встреч на работе и т.д. - действительно важны и "написаны кровью" неудавшихся ML проектов

2. Всегда нужно начинать проект с простой модели статистики "ручной" формулы

Прогнозируете спрос - попробуйте сначала выкатить в продакшн прогноз = факт прошлой недели. И вы удивитесь, сколько сложностей возникнет на вашем пути. А вот когда весь пайплайн выкатки в прод и принесения пользы бизнесу работает - можно и модель улучшить:)

3. Нетворкинг - мощь
В этом году я сходил на 8 встреч по Random Coffee от ODS. На них я узнал невероятно много нового и даже нашёл друга :)

Finally 🎅
Поздравляю всех с наступающим Новым Годом! Кайфуйте от новых знаний и проектов, развивайтеcь и будьте счастливы!)

Что такое персональные/релевантные рекомендации?

Именно этот вопрос у меня периодически возникает. И я часто задаю его менеджерам ☺️

Ведь если мы:
1. Знаем реальные оценки пользователя по каким-то товарам (товары в магазине/фильмы/..)
2. Умеем считать среднюю оценку товара

То из этих 2ух пунктов уже можно делать рекомендации товаров! Зачем тогда мы так сильно топим за матричное разложение (SVD, ALS) и другие модели рек систем?

Во-первых, персонально != только через 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