Сегодня речь пойдёт о рейтинге. Вроде бы обыденная привычная вещь: все мы видели рейтинги фильмов на 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

Сегодня речь пойдёт про А/В платформы. И почему это не только про стат тесты

Думаю, многие видели статью "Hidden technical debt in ML systems" с её знаменитой картинкой

Вкратце статья о том, что мало построить ML-модели и показать SOTA качество. Нужно ещё и построить инфраструктуру вокруг модели, иначе все рискует обернуться полным провалом. Ведь изменение в логгировании данных, высокая нагрузка в проде и множество других вещей может сделать самую прекрасную модель совершенно бесполезной

Вышла статья в далёком 2015 году. На мой взгляд из 2021 года, там явно не хватает блока "А/В testing". Этот блок тянет на ещё одну статью, которую я бы назвал "Hidden technical debt in A/B testing systems"

Hidden technical debt in ML A/B testing systems

Часть 1. Разделение пользователей на группы

Почему-то все думают, что это самый простой этап: "Делим случайно и все дела"! Но на самом деле, это одно из самых сложных и спорных мест во всех А/В платформах

Опустим очень сложные кейсы, когда пользователи (наблюдения) зависят друг от друга. Как например, в логистике или соц сетях. Или кейс с оффлайн А/В тестированием, когда наблюдений мало и они очень разные: например, тесты над оффлайн магазинами

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

Пусть вы проводите одновременно 2 теста на изменение в дизайне на главной странице. Очевидно, они влияют друг на друга - хорошо бы сделать так, чтобы эти тесты проводились на разных пользователях. Такой подход довольно популярен и называется двойным солированием. Упрощенно, вы сначала делите пользователей случайно с random_seed=Х (солью) условно на 100 групп. Группы 1-50 попадают в первый тест, а группы 51-100 - во второй. А потом внутри каждого теста делите пользователей второй раз с random_seed=Y (солью) на тест и контроль. При этом не стоит забывать, что у каждого теста должна быть своя вторая соль

Неплохо, мы смогли развести 2 влияющих друг на друга теста! Но тут нас подстерегает вторая проблема: если разводить все тесты, то у нас будет очень мало экспериментального пространства. Если 1 тест занимает в среднем 10 из 100 групп, то одновременно мы можем запускать всего 10 тестов - грустно😥

Тут нам может помочь подход со слоями от Гугла. Идея весьма проста: давайте разделим наше приложение на "слои". Внутри одного слоя эксперименты считаем зависимыми и разводим их = пользователи не пересекаются. А вот между слоями считаем эксперименты независимыми - пользователь может попасть сразу в N экспериментов в разных слоях. Слой - обычно логически отдельный кусок приложения (главная страница, поиск, экран оплаты заказа и т.д). Вуаля, мы только что смогли проводить не 10 параллельных экспериментов, а 10 * N, где N - число слоев

Я описал лишь пару сложностей и варианты их решения. Когда мы строили свою А/В платформу v1.0 в Delivery Club, таких неочевидных моментов было гораздо больше! Со времени написания статьи произошло множество улучшений в платформе. Но на мой взгляд, до сих пор одной из крупнейших побед остается именно корректное разделение пользователей на группы. Помните, что это, пожалуй, ключевой шаг, и начинайте делать А/В тесты в своей компании именно с него 😉

#ab

Как выбрать метрики?

Часть 2. Выбор метрик в А/В

В идеальном мире для дизайна А/В нужно взять 3 вида метрик:
- Приемочные (обычно 1-3) = те, по прокрасу которых мы принимаем решение об успехе эксперимента
- Контрольные = те, по которым мы понимаем, что ничего не сломалось. Ожидаемое поведение - нет стат значимых изменений
- Барьерные = если покрасились в красный, то тест неудачный не смотри ни на что. Обычно это какие-то крупные метрики всего бизнеса вроде ARPU

Во-первых, достаточно сложно обьяснить такое разделение менеджерам: стандартная проблема - хочется в "примемочные" запихнуть штук 20 метрик. А потом увидеть, что покрасилась конверсия из "одной кнопки в другую" и решить, что тест успешен

Во-вторых, очень сложно выбрать 1-3 приемочных метрики даже если вы аналитик, который все прекрасно понимает. Бизнес - довольно многогранная штука, его состояние тяжело аггрегировать всего 1-3 размерностями. Но это делать нужно! Иначе вы рискуете в приемочные метрики отправить кучу скоррелированных метрик + не забывайте про поправки на множественность. С ними есть мой любимый парадокс: если в тесте 1 метрика, то она стат значима, а если 10, то с поправками на множественность та же метрика уже НЕ стат значима

В-третьих, даже если вы договорились на 1-3 приемочные метрики, то внезапно может оказаться, что тест нужно крутить 3 месяца. Обычно тут как между Сциллой и Харибдой: либо метрика явно влияет на бизнес (как конверсия из захода в приложение в заказ), либо она достаточно чувствительная = держим тест 2 недели, а не 3 месяца. И как выбрать хорошую прокси метрику к вашей целевой - это целая наука

Так что цените ваших аналитиков, которые помогают выбрать правильные метрики, и прислушивайтесь к ним!)

#ab

Зачем нужен продакт менеджер в ML-проектах?
Много кто спрашивал в комментариях к прошлым постам об этом. Поэтому решил сделать отдельный пост на эту тему

Вообще, ML product manager - довольно редкий человек на рынке, особенно в России. И я очень рад, что мне с такими продактами удалось поработать. Сразу оговорюсь, что я в основном встречал продакт менеджеров, которые выполняют сразу 2 роли: продакта и проджекта (то есть формируют видение продукта и помогают вести проект) - дальше речь пойдет именно о таких людях. Итак, что же делает ML product manager?

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

Пример
Классика: вы оптимизировали в рекомендациях кол-во кликов (оно даже и в А/В выросло!), но что-то бизнес не очень рад: ведь заказы упали

2. Собирает всех вовлеченных в проект
Если вы думаете, что "все вовлеченные" - это data scientist, data engineer и еще пара data-***, то вы глубоко ошибаетесь)
Внезапно, практически на любой ML-проект нужны:
- Классические бэк/фронт разработчики
- UX-рисерчеры, чтобы хотя бы на макетах финального продукта (спойлер: это НЕ ml-модель) понять, нужно ли пользователям именно это
- Дизайнеры, чтобы нарисовать эти макеты и финальный продукт
- Аналитики, которые помогут найти "слабые места" в продукте, где будет больше всего выхлопа от ML
- Список может продолжиться еще дальше

Примеры
Согласитесь, будет неприятно узнать на этапе выкатки в прод, что бэкенд разработчики были не в курсе всего происходящего, и что бэкенд не способен сейчас поддерживать ваше ML-решение?

Или что ваше мега-решение по рекомендациям фильмов с precision@5 = 90% (что вы и оптимизировали) вдруг окажется не слишком хорошим, потому что дизайнеры нарисовали карточку рекомендаций с всего 2 фильмами вместо ожидаемых вами 5?

3. Помогает формировать гипотезы ДО начала разработки
Как же много ML-моделей не доходит до прода, потому что оказываются ненужными конечному пользователю. Поэтому важно собрать всех вместе и понять, на какие метрики мы должны влияеть (продакт), в какие точки продукта стоит приложить усилия (тут помогут аналитики), каким должен быть дизайн и еще бы проверить это все хотя бы на UX-макетах

Пример
Непопсовая классика: вы вырастили конверсию из показа блока "Похожие товары" в заказ на 20%! Ну круто же! Но этими рекомендациями пользуются <1% пользователей, потому что они расположены на далеееком и никому неизвестном экране приложения

4. Помогает формировать бэклог "широкой" команды проекта
Не нуждается в представлении, поэтому сразу:

Пример
Сформировать бэклог всех вовлеченных супер важно, иначе вы можете выкатить свой мега крутой ML-микросервис, но бэк сможет с ним интегрироваться через 2 месяца, а фронты отрисовать - через 3

5. И еще бесконечно много вещей!
Цените ваших продактов - они решают миллион маленьких сложностей, о которы вы даже не догадываетесь. Неплохой список таких сложностей/рисков можно почитать вот тут

Badass data scientist
Этот пост начинался как список того, без чего точно не стоит приступать к любой ds-задаче. Но в итоге превратился в список для badass data scientist - но иногда лучше действительно им побыть:)

1. Не делай задачу, пока нет ее четкого описания
Навеяно просмотром десятков курсов, кагглом и ютуб-разбором бизнес задач. Почему-то все в них говорят что-то вроде: "К нам пришел бизнес-заказчик и попросил решить такую задачу: кому отправлять e-mail со скидкой 20%, чтобы минимизировать отток пользователей? Мы готовы тратить на удержание пользователя не более Х руб, стоимость смс - Y руб, общий бюджет - Z рублей. Будет круто, если сократим отток с 12% до 7%"

В реальности это же совсем не так! Обычно бизнес хочет "повысить эффективность скидок". Хорошо, если еще накидывает варианты реализации: предотвращать отток, реактивировать спящих клиентов, повышать чек существующих и т д. Но, как правило, из первого описания задачи вообще не понятно, что от вас хотят, и что такое "успех" в решении задачи

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

2. Не делай задачу, пока нет четкого критерия "успеха"
Это должна быть одна (максимум две) метрики + их ожидаемый прирост + сроки

Иначе можно легко и стат значимо (!) повысить конверсию "из кнопки Х в кнопку Y" на 0.001% за полгода. Но вряд ли это можно назвать успехом

3. Не делай задачу, если сомневаешься в ее бизнес-эффекте
ML - довольно дорогостоящая для внедрения штука: сервера, время дата саентистов и других вовлеченных в проект. Если вы сомневаетесь, что действительно сможете улучшить бизнес - не делайте это

4. Не делай задачу от бизнеса, пока нет одного ответственного за нее от бизнеса
Иначе рискуешь делать непонятно что, непонятно к каким срокам. И не факт, что это потом решат внедрять в бизнес-процесс

Но не стоит уходить и в другую крайность, которая описана в этой статье
Вроде бы все это очевидные вещи, но об них все мы очень часто спотыкаемся 😏