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. Не делай задачу от бизнеса, пока нет одного ответственного за нее от бизнеса
Иначе рискуешь делать непонятно что, непонятно к каким срокам. И не факт, что это потом решат внедрять в бизнес-процесс

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

О ценности культуры А/В тестирования и не только

Думаю многие слышали, что в компании хорошо бы внедрять MLOPS, единый feature store, code review и многие другие "правила хорошей работы с данными и моделями"

При этом про "правила хорошего А/В" говорят не так активно. Сегодня я покажу, сколько может стоить "маленькая ошибка" при проведении А/В теста

Представьте, что Junior аналитик решил задизайнить А/В тест. Он знает про классический А/В эксперимент из учебника с Т-статистикой (что уже неплохо на самом деле!)

Но продакты просят его сделать А/В/С тест и сравнить там всего 2 метрики - конверсию и средний чек. При этом хотят быть "очень уверенными" в результатах
(Да-да, это то же самое, когда хотят 100% точность классификации)

Junior решил полностью последовать их просьбе ("мы ведь совсем капельку поменяем параметры А/В теста!") и выбрал:
alpha=1% (для уверенности)
power=90% (для уверенности-2)
кол-во групп = 3
кол-во метрик = 2

Напомню, что базовый кейс из учебника - это:
alpha=5%
power=80%
кол-во групп = 2
кол-во метрик = 1

#ab

Долго ли, коротко ли, но наконец я возобновил выступления на конференциях!) Ближайшая будет уже во вторник в 20:00

Там я буду рассказывать про ускорение А/В тестов - приходите, буду очень рад увидеть вас среди зрителей :)

Наткнулся на годную статью про UltraGCN (Ultra Graph Convolutional neural Networks)

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

Что интересного в статье
В статье показано, что UltraGCN - это, по сути, ALS с другим лоссом, который накладывает регуляризацию на основе информации из графов связей пользователи-товары и товары-товары

То есть можно просто учить перемножение двух векторов (примерно как в ALS), но с другим лоссом - и вы уже получите новомодную SOTA модель из графовых нейронок! Это же просто🔥

Мои мысли
Я сделал еще пару выводов из этой статьи:
1. Зачастую важен совсем не тот алгоритм/модель, которым вы решаете задачу. А важно правильно выбрать, какую задачу вы решаете (~лосс). На практике я видел этому очень много подтверждений
2. К сожалению, очень мало рисерчей / образовательного контента про лоссы / метрики / задачи в data science

Поэтому решил, что пару слудеющих постов я напишу о лоссах и метрикам в ML-моделях. И каким образом их "правильно" подбирать под каждую ML-задачу. Как говорится, "Stay tuned" 💪

Метрики ML-моделей регрессии

Часть 1. Простые метрики регрессии: RMSE, MAE

RMSE и MAE - пожалуй, самые простые и самые неверно используемые метрики, оторые я видел

Обычно в лекциях по DS про эти метрики говорят следующее: Лучше использовать MAE, чем RMSE, при скошенных распределениях таргета с длинным хвостом, так как MAE меньше штрафует за большие ошибки в прогнозе

Кажется, что что и есть формула успеха, но нет 😉

#metrics

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

Распределение таргета не имеет значение. Важно только распределение ошибок (y_true - y_pred) модели

Во-вторых, MAE и правда меньше штрафует за большие ошибки прогноза. Но тут важно понимать, какой бизнес смысл за этим стоит

MAE - прогнозирует медиану
RMSE - среднее

В-третьих,
Мы прогнозируем среднее обычно для тех случаев, когда оно используется для расчета E(*)

Например,
E(выручка) = цена * E(спрос)

Поэтому в задачах оптимизации цен, промо и т д обычно прогнозируют среднее --> используют RMSE
*да, еще используют poisson/tweedie loss, но об том в следующих частях:)

Мы прогнозируем медиану (MAE loss) или любой другой квантиль (quantile loss), когда речь заходит о разной цене ошибки прогноза в бОльшую и меньшую стороны

Например, при прогнозе спроса для закупки товаров обычно (не всегда) лучше спрогнозировать чуть больше факта - закупить чуть больше товаров. Поэтому тут можно использовать, условно квантильный лосс и прогнозировать, например, 60-й квантиль

Кстати, обратите внимание, в одной задаче (оптимизация цен, промо) я предлагал использовать RMSE, а для того же прогноза спроса в другой задаче (закупка товаров) - квантильный лосс

В целом, лосс-функцию нужно выбирать исходя из задачи, а не формы распределения таргета