A/B-тестирование ML моделей

В 2012 году один A/B-тест в Microsoft (Bing) принёс 100 миллионов долларов годового дохода - просто за счёт изменения оттенка цвета ссылки. Но неправильные эксперименты обходятся ещё дороже: Netflix однажды потерял миллионы, раскатив модель, которая прошла все offline-тесты, но провалилась на реальных пользователях. Между offline-метриками и реальным поведением пользователей лежит пропасть, и A/B-тестирование - единственный мост через неё.

• **Поисковые системы (Google, Bing, Yandex)** - ежегодно проводят десятки тысяч A/B-тестов и экспериментов с interleaving для оценки изменений в ранжировании: каждое обновление алгоритма поиска проходит через многоуровневую воронку offline -> interleaving -> A/B -> gradual rollout
• **Рекомендательные системы (Netflix, Spotify, YouTube)** - используют multi-armed bandit для оптимизации контента на главной странице: Thompson Sampling динамически перераспределяет показы между вариантами обложек, заголовков и рекомендаций, минимизируя потери на неэффективных вариантах
• **E-commerce (Amazon, Booking, Ozon)** - A/B-тестируют модели ценообразования, ранжирования товаров и персонализации: каждый эксперимент сопровождается расчётом sample size, мониторингом guardrail-метрик и коррекцией на множественные сравнения (Bonferroni/FDR)

Предварительные знания

• Search & Ranking

От полевых опытов Фишера до онлайн контролируемых экспериментов

Статистический каркас A/B-тестирования идёт от Рональда Фишера, который в 1920-х и 1930-х разработал рандомизированные контролируемые эксперименты, работая над сельскохозяйственными опытами в Ротамстеде. Его книга 1935 года The Design of Experiments закрепила рандомизацию, повторность и нулевую гипотезу как основы корректного причинного вывода, те самые идеи, что и сегодня оправдывают деление пользователей на контрольную и тестовую группы. Десятилетия спустя веб превратил эти идеи в ежедневную инженерную практику. В 2000-х Рон Кохави, работая в Microsoft, а раньше в Amazon, продвигал онлайн контролируемые эксперименты в интернет-масштабе, выстраивая инфраструктуру и методологию, позволявшие компаниям прогонять тысячи A/B-тестов одновременно. Кохави документировал неожиданные результаты: как крошечные изменения интерфейса двигали выручку на миллионы и как команды регулярно переоценивают собственные идеи. Его работа сделала эксперименты ключевой компетенцией современных продуктовых и ML-команд, где каждая модель ранжирования или изменение рекомендаций выкатывается за контролируемым экспериментом.

Online Evaluation

Модель обучена, метрики на тестовом наборе хорошие - accuracy 95%, NDCG@10 улучшился на 3%. Кажется, пора деплоить. Но вот проблема: **offline метрики и online метрики часто расходятся**. Модель, которая лучше по AUC на тестовой выборке, может ухудшить CTR на реальных пользователях. Причина - offline датасет отражает прошлое, а пользовательское поведение меняется. Кроме того, offline метрики не учитывают латентность ответа, визуальное расположение элементов и контекст взаимодействия.

Поэтому в production ML-системах используют три уровня метрик. **Business-метрики** - то, ради чего существует продукт: доход, количество подписок, время в приложении. **Product-метрики** - промежуточные: CTR, конверсия, глубина просмотра. **Guardrail-метрики** - ограничения, которые нельзя нарушать: latency (время ответа), crash rate, отток пользователей. Новая модель может улучшить CTR, но если при этом latency вырос с 50ms до 500ms, эксперимент провален.

**Три уровня метрик для online-экспериментов:** **Business-метрики** (Overall Evaluation Criteria): - Доход на пользователя (Revenue per User) - Количество покупок / подписок - Retention (возврат пользователей) **Product-метрики** (прямые индикаторы): - CTR (Click-Through Rate) - Конверсия (Conversion Rate) - Среднее время сессии - Количество действий на сессию **Guardrail-метрики** (не должны ухудшиться): - Latency (p50, p95, p99) - Error rate / crash rate - Churn rate (отток) - Unsubscribe rate Если guardrail нарушен - эксперимент останавливают, даже если business-метрики улучшились.

Ключевой принцип A/B-тестирования - **рандомизация**: пользователи случайным образом распределяются между вариантами, и каждый пользователь видит только один вариант на протяжении всего эксперимента. Детерминистическое хеширование (hash от user_id) гарантирует, что один и тот же пользователь всегда попадает в одну группу. Без этого результаты будут зашумлены: пользователь увидит разные модели в разных сессиях и его поведение нельзя будет корректно атрибутировать.

**Network effect и SUTVA:** A/B-тест предполагает SUTVA (Stable Unit Treatment Value Assumption) - результат одного пользователя не зависит от того, в какой группе другие пользователи. Но в соцсетях это нарушается: если друг пользователя из treatment-группы делится контентом, найденным новым алгоритмом, это влияет на пользователя из control-группы. Решения: cluster-based randomization (рандомизация по кластерам друзей), geo-based experiments (разные города/регионы), или switchback experiments (чередование вариантов по времени).

Interleaving

Классический A/B-тест для ранжирования имеет фундаментальную проблему: **он очень медленный**. Пользователь видит результаты только одной модели, и разница между моделями может быть меньше, чем разница между самими пользователями. Чтобы обнаружить 1% улучшение CTR, может потребоваться миллион пользователей и 2 недели эксперимента. **Interleaving** решает эту проблему: вместо того чтобы показывать каждому пользователю результаты только одной модели, мы смешиваем результаты двух моделей в один список и смотрим, на результаты какой модели пользователь кликает чаще.

Самый популярный метод interleaving - **Team Draft**. Аналогия: две модели - это капитаны команд на школьном уроке физкультуры. Они по очереди «выбирают» результаты в общий список. Модель 1 ставит свой лучший результат первой, затем модель 2 ставит свой лучший (если он ещё не выбран), и так далее. Пользователь видит объединённый список и не знает, какой результат от какой модели. По кликам определяется победитель.

**Почему interleaving чувствительнее A/B-теста в 10-100 раз?** В A/B-тесте мы сравниваем **между пользователями**: - Пользователь X (control): CTR = 3.2% - Пользователь Y (treatment): CTR = 3.5% - Разница 0.3%, но дисперсия между пользователями огромная (от 0% до 20%+) В interleaving мы сравниваем **внутри одного пользователя**: - Тот же пользователь видит результаты обеих моделей - Его предпочтения, контекст, время - одинаковы для обеих - Дисперсия драматически ниже Это paired comparison - как в медицине: давать одному пациенту оба препарата (в разное время) точнее, чем давать разным пациентам разные препараты. Но interleaving работает только для **задач ранжирования** (поиск, рекомендации), где результаты можно перемешать.

У interleaving есть ограничения. Он подходит только для **задач ранжирования**, где результаты двух моделей можно смешать в один список. Для задач вроде ценообразования, UI-изменений или чат-ботов interleaving не применим. Кроме того, interleaving хорошо определяет **какая модель лучше**, но плохо измеряет **насколько** она лучше (эффект в абсолютных числах). Поэтому на практике interleaving используют для быстрого скрининга моделей-кандидатов, а финальное решение о раскатке принимают по полноценному A/B-тесту.

Multi-Armed Bandit

Классический A/B-тест имеет неприятное свойство: пока эксперимент идёт, половина трафика направляется на заведомо худший вариант. Если новая модель лучше, мы теряем деньги на control-группе. Если хуже - теряем на treatment-группе. **Multi-Armed Bandit (MAB)** решает эту проблему: вместо фиксированного split 50/50 он динамически перераспределяет трафик в сторону лучшего варианта, одновременно продолжая собирать данные о худшем. Это компромисс между **exploitation** (использовать лучшее известное) и **exploration** (исследовать неизвестное).

Название «multi-armed bandit» (многорукий бандит) - метафора из теории вероятностей. Аналогия - ряд игровых автоматов (one-armed bandits) с разными вероятностями выигрыша. Эти вероятности неизвестны заранее. На каждом шаге выбирается один автомат и получается награда. Цель - максимизировать суммарный выигрыш. Если всё время играть на одном автомате - возможно, лучший упускается. Если пробовать все подряд - расход на плохие. Нужен баланс.

**Три основных стратегии MAB:** **Epsilon-Greedy:** - С вероятностью (1 - epsilon): выбираем лучший вариант (exploit) - С вероятностью epsilon: выбираем случайный вариант (explore) - Просто, но не адаптивно - epsilon фиксирован **UCB (Upper Confidence Bound):** - Для каждого варианта вычисляем: средний reward + бонус за неопределённость - Редко выбираемые варианты получают больший бонус - Детерминистический - нет случайности в выборе **Thompson Sampling:** - Для каждого варианта поддерживаем распределение вероятности - Сэмплируем из каждого распределения, выбираем максимальный - По мере накопления данных распределения сужаются - Часто лучшая стратегия на практике

**Когда использовать MAB, а когда A/B-тест?** MAB оптимален, когда цена ошибки высока в реальном времени (реклама, ценообразование, рекомендации), когда вариантов много (десятки заголовков email-рассылки), или когда нужен быстрый результат. A/B-тест лучше, когда важна **статистическая строгость**: MAB не даёт чистых p-values и confidence intervals, потому что распределение трафика менялось во время эксперимента. Если нужно доказать стейкхолдерам, что модель B лучше модели A с 95% уверенностью - применяется A/B-тест.

Статистическая значимость

Запущен A/B-тест. Через неделю результат: CTR control-группы 3.2%, CTR treatment-группы 3.4%. Разница 0.2 процентных пункта. Вопрос: это реальное улучшение или случайное колебание? **Статистическая значимость** - формальный способ ответить на этот вопрос. Формулируется **нулевая гипотеза** (H0): "разницы между моделями нет, наблюдаемая разница - случайность". Затем вычисляется **p-value** - вероятность получить такую или большую разницу, если нулевая гипотеза верна.

Прежде чем запускать эксперимент, нужно определить **необходимый размер выборки**. Слишком маленькая выборка - и реальное улучшение не обнаружится (low statistical power). Слишком большая - напрасная трата трафика и времени. Расчёт размера выборки зависит от трёх параметров: **Minimum Detectable Effect (MDE)** - какую минимальную разницу нужно обнаружить, **significance level (alpha)** - порог p-value (обычно 0.05), и **statistical power (1 - beta)** - вероятность обнаружить эффект, если он есть (обычно 0.80).

**Multiple Testing Problem (проблема множественных сравнений):** При тестировании 20 метрик одновременно с alpha = 0.05 вероятность получить хотя бы один ложный положительный результат: 1 - (1 - 0.05)^20 = 64%! **Bonferroni correction** - самый простой способ: alpha_adjusted = alpha / n_tests. - 20 метрик: alpha_adjusted = 0.05 / 20 = 0.0025 - Каждая метрика должна пройти порог 0.0025, а не 0.05 Bonferroni консервативен (может упустить реальные эффекты). Альтернативы: - **Benjamini-Hochberg (FDR)** - контролирует долю ложных открытий, менее консервативен - **Sequential testing (mSPRT)** - позволяет проверять результаты на любом этапе без штрафа На практике в ML-экспериментах обычно есть 1-2 primary metric (с полным alpha) и 5-10 secondary metrics (с Bonferroni или FDR correction).

Наконец, критически важно различать **статистическую значимость** и **практическую значимость**. Результат может быть статистически значимым (p < 0.05), но практически бесполезным. Если CTR вырос с 3.000% до 3.005%, p-value может быть мизерным при миллионах наблюдений, но прирост в 0.005 процентных пункта не оправдывает затраты на деплой и поддержку новой модели. Всегда оценивайте **абсолютный размер эффекта** и его влияние на бизнес, а не только p-value.

Итоги

• **Online evaluation:** offline метрики (AUC, NDCG) часто расходятся с online-результатами - production-оценка требует бизнес-метрик (CTR, доход), product-метрик (конверсия) и guardrail-метрик (latency, error rate), которые нельзя нарушать
• **Interleaving:** для задач ранжирования в 10-100 раз чувствительнее A/B-теста, потому что сравнивает модели внутри одного пользователя (paired comparison), устраняя inter-user variance - идеален для быстрого скрининга моделей-кандидатов
• **Multi-Armed Bandit:** вместо фиксированного 50/50 split динамически перераспределяет трафик в сторону лучшего варианта через Thompson Sampling - баланс exploration/exploitation минимизирует потери, но не даёт строгих p-values
• **Статистическая значимость:** p-value - это вероятность данных при нулевой гипотезе, не вероятность что модель лучше; при большом sample size даже мизерная разница даёт p < 0.05, поэтому всегда оценивайте практическую значимость - как тот оттенок ссылки в Bing, который оказался на 100 миллионов долларов значимым

Связанные темы

A/B-тестирование ML-моделей связывает мониторинг production-систем с процессом принятия решений о раскатке:

• ML Monitoring — Мониторинг - это непрерывное наблюдение за моделью после раскатки, а A/B-тест - разовое сравнение перед раскаткой. Guardrail-метрики из A/B-теста становятся метриками мониторинга в production. Если мониторинг показывает деградацию - запускаем новый эксперимент
• Search & Ranking — Interleaving - основной метод быстрой оценки моделей ранжирования. Метрики вроде NDCG@10 служат offline-фильтром, но финальное решение о раскатке нового ранжирования всегда принимается по результатам online-экспериментов с реальными пользователями

Вопросы для размышления

• Почему компании уровня Google и Microsoft проводят десятки тысяч A/B-тестов в год, а не доверяют offline-метрикам? Какие факторы реального мира не может поймать тестовый датасет?
• В каких ситуациях multi-armed bandit может дать худший результат, чем классический A/B-тест? Подсказка: учесть нестационарность и delayed rewards.
• Если p-value = 0.001, но абсолютная разница CTR составляет 0.01 процентных пункта - стоит ли раскатывать модель? Как формализовать понятие 'практическая значимость'?

Связанные уроки

• ml-47-model-monitoring — Метрики мониторинга питают A/B-решения
• ml-52-search-ranking — Изменения ранжирования валидируются A/B-тестами
• ml-05-evaluation — Офлайн-метрики дополняют онлайн-тесты
• stat-05-hypothesis — A/B-тест - это проверка гипотез
• stat-19-multiple-testing — Множество метрик требует поправки