Как мы не обожглись на быстрых ML-экспериментах: опыт с 10% аудитории, холиварами с аналитиками и «лампой для лишая»

Каждый новый A/B-тест у нас занимал 3–4 недели. За это время ML-команда успевала придумать ещё несколько гипотез, аналитики — устать, а продакты — начать спорить, можно ли вообще продолжать эксперимент, если метрики уже неделю летят вниз.

В какой-то момент стало понятно: такими темпами мы просто тонем в очереди гипотез.

Тогда у нас появились быстрые эксперименты — короткие тесты на маленькой аудитории, которые помогают за несколько дней понять, что гипотеза, скорее всего, плохая, и не тратить на неё ещё месяц.

Меня зовут Лера Катеринчик, я старший продакт-менеджер в команде рекомендаций. Мы делаем ML-модели, которые пытаются угадать, что пользователь захочет следующим.

Я не гуру и не «лидер мнений». Я обычный продакт, который работает с ML-инженерами, аналитиками и живёт в тех же процессах и бардаке, что и многие продуктовые команды.

Хочу рассказать, как мы используем быстрые эксперименты, где они работают, где нет и с какими проблемами мы столкнулись.

Проблема: очередь гипотез и споры «стопать или не стопать»

Раньше процесс выглядел довольно стандартно:

1. ML-команда делает новую версию модели.

2. Проверяет её на офлайн-метриках на исторических данных.

3. Отдаёт на внутреннее тестирование.

4. Запускаем полноценный A/B-эксперимент на 3–4 недели.

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

Часть команды, в первую очередь аналитики, говорит: эксперимент нельзя останавливать раньше времени. И это абсолютно обоснованная позиция — если дёргать тест посреди процесса, можно сломать статистику, получить некорректные результаты и принять неправильное решение. Поэтому аналитики настаивают на том, чтобы строго соблюдать правила проведения экспериментов и заранее согласованные сроки.

Другая часть команды смотрит на это более прагматично: метрики уже падают, мы прямо сейчас теряем деньги и пользовательский опыт ^[1], зачем продолжать ещё две недели?

Каждый такой спор отнимал много времени, сил и внимания ^[2] у команды.

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

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

Мы решили попробовать.

Что такое быстрый эксперимент

В нашем понимании быстрый эксперимент — это:

• маленькая аудитория (примерно 10% пользователей, которых можно делить на ещё более маленькие группы, до 2,5%),

• короткий срок (около 3-7 дней),

• смотрим не на точные значения метрик, а на направление,

• не считаем статистическую значимость и не проводим полноценный дизайн эксперимента с расчётом периода теста в рамках классического подхода с фиксированным горизонтом. 

Главная идея — не доказать, что гипотеза хорошая, а быстро понять, что она плохая. Если за несколько дней метрики заметно падают, гипотеза отваливается. Мы не тратим на неё ещё 3-4 недели большого эксперимента.

Если метрики не падают, это ещё не значит, что гипотеза хорошая. Это значит, что её можно нести в полноценный A/B-тест.

Я обычно объясняю это странной метафорой:сравниваю с лампой для проверки лишая у котов. Если светится, то с высокой долей вероятности это лишай.  Если не светится — это не гарантия, что всё хорошо, нужно дальше проверять.

С быстрыми экспериментами примерно так же:

• если всё плохо — это видно быстро;

• если вроде нормально — это ещё ничего не гарантирует.

Почему три дня

Мы просто внутри команды договорились, что будем смотреть примерно три дня.

Логика ^[3] такая:

• первый день шумный — тест может стартовать в середине дня;

• второй день — фактически одна нормальная точка;

• на третий день уже начинает быть видно направление.

Нам важно не точное значение метрики, а куда идёт линия — вверх или вниз.

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

Какие гипотезы мы так проверяем

Мы не все гипотезы гоняем через быстрые эксперименты. Обычно это такие случаи:

1. Рискованные гипотезы
   Когда есть вероятность сильно уронить метрики и страшно сразу запускать на большую аудиторию.

2. Конкурирующие гипотезы
   Когда несколько идей претендуют на одно место, и нужно понять, какую тестировать первой.

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

Сами гипотезы предлагают продакты, бизнес, ML-команда.

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

Как это устроено технически (и где начинаются споры)

Сам быстрый эксперимент запускается примерно так же, как обычный A/B-тест. Самая сложная часть — договориться про аудиторию.

Чтобы быстрые эксперименты вообще можно было проводить, нужно держать часть аудитории свободной. У нас обсуждался вариант — всегда оставлять около 10% аудитории под быстрые тесты. То есть большие эксперименты идут на 90%, а 10% остаются свободными. И вот тут начались споры с аналитиками.

Аналитики говорят: “Если вы забираете 10% аудитории, вы уменьшаете чувствительность метрик и увеличиваете срок больших экспериментов. Может быть, не нужно держать их постоянно свободными?” 

А я говорю: “А если гипотеза появится через неделю после запуска большого эксперимента, когда уже заняли все 100% аудитории? Нам тогда ждать месяц?”

Пока идеального решения нет. Мы обсуждали вариант просто попробовать держать 10% и потом посмотреть, насколько они реально используются. Если окажется, что они почти всегда простаивают — значит, инструмент не нужен. Если используются регулярно, значит, всё было не зря.

Как проходит быстрый эксперимент по шагам

Сейчас процесс примерно такой:

1. Появляется гипотеза — от продакта, бизнеса или ML-команды.

2. ML-инженеры делают новую версию модели. Обычно это занимает от одного до трёх дней. Сначала модель проверяют на оффлайн-метриках — то есть смотрят, стала ли она лучше угадывать действия пользователя на исторических данных. Если сильно упрощать: у нас есть информация о том, что пользователь в итоге купил, и модель должна поставить этот товар выше в рекомендациях. Если она начала делать это точнее — значит, модель, скорее всего, улучшилась.

3. После этого модель проходит внутренний тест — проверяем, что технически ничего не сломалось.

4. Затем идёт внешний тест: несколько продактов и аналитиков вручную смотрят результаты и проверяют, не выглядит ли выдача странно или «кринжово».

5. После этого запускаем быстрый эксперимент на 10% аудитории на 3 дня.

6. Смотрим графики метрик и оцениваем направление изменений.

7. Если метрики заметно падают — гипотеза умирает на этом этапе.

8. Если сильной просадки нет — обсуждаем, стоит ли запускать полноценный A/B-тест.

Альфа-тестирование на сотрудниках для быстрых экспериментов мы не делаем — это слишком долго для такого формата.

Где мы фиксируем результаты (спойлер: не очень системно)

Честно говоря, здесь у нас пока хаос. Нет единого места, где фиксируются все быстрые эксперименты. Иногда пишем в задачи, иногда что-то попадает в историю изменений блоков, иногда остаётся только в презентации с итогами месяца. Это отдельная продуктовая боль ^[4]: ты договариваешься, что команда будет вести документацию, потом отвлекаешься на другие процессы — и документация перестаёт вестись. Сейчас мы стараемся все же вести change log по каждому рекомендательному месту со всеми тестами и изменениями, но получится ли удержаться в этой системе, пока не знаю.

Ошибки и риски

Быстрые эксперименты могут обмануть

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

Какие ошибки мы сделали в начале

• Не оставляли аудиторию под быстрые эксперименты.

• Не договаривались заранее с аналитиками о разборе результатов.

• Не уточняли метрики перед запуском.

Был случай: запускали тест с разнообразием, а метрику разнообразия не включили. Смотрели на конверсии и защитные метрики, но ключевую метрику забыли. В итоге эксперимент было сложно интерпретировать. Поэтому теперь стараемся заранее договориться, на какие метрики смотрим.

Где быстрые эксперименты не подходят

Есть ситуации, где этот инструмент почти бесполезен:

• Удержание, возвращаемость и отток пользователей. За три дня пользователь просто не успевает изменить своё долгосрочное поведение ^[5], поэтому такие метрики невозможно нормально оценить на коротком промежутке. 

• Продукты, где фича разрабатывается очень долго. Если на реализацию гипотезы уходит много времени и ресурсов, то стоимость ошибки ^[6] становится слишком высокой. Есть риск преждевременно отклонить гипотезу на быстром эксперименте, хотя на полноценном тесте она могла бы показать хороший результат.

• Гипотезы с репутационными или юридическими рисками. Обычно сама подготовка и согласование таких изменений занимают больше времени, чем полноценный A/B-тест. Плюс последствия ошибки здесь могут быть слишком серьёзными, чтобы проверять что-то в ускоренном режиме.

• Молодые продукты с маленькой аудиторией и нестабильными метриками. В таких условиях слишком много шума в данных, и на коротком промежутке можно просто не увидеть реальное направление изменений.

Что изменилось после внедрения

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

Но уже видно несколько эффектов:

• уменьшилось количество гипотез, которые идут в большой тест;

• стало меньше споров, чью гипотезу тестировать первой;

• кажется, что мы в целом стали быстрее двигаться.

По моим ощущениям, быстрые эксперименты особенно полезны:

• в ML-продуктах, где новую модель можно сделать за несколько дней;

• в продуктах с гибким интерфейсом, где можно быстро менять порядок блоков и смотреть реакцию ^[7] пользователей.

Если команда хочет попробовать, я бы начала так:

1. Собрать продакта, аналитика и ML-команду и обсудить, зачем это нужно и какие риски, какой будет процесс и кто за что будет отвечать в нем (обратите внимание: особенно важно обсудить зоны ответственности).

2. Обсудить это со стейкхолдерами.

3. Попробовать сделать тестовый период и посмотреть, есть ли от этого польза.

Вывод

Быстрые эксперименты —  это инструмент, который помогает быстрее отсеивать плохие гипотезы. Он не заменяет A/B-тесты, не гарантирует успех, не решает все проблемы и требует договорённостей с аналитиками и командой. Но в нашем случае он помог уменьшить очередь экспериментов, сократить количество споров и быстрее принимать решения по гипотезам. Возможно, и в вашей команде этот инструмент будет полезен? Я считаю, что попробовать точно стоит.