Чек-лист A/B-теста ML-модели: 36 пунктов перед запуском рекомендаций, цен и поиска

A/B-тест ML-модели — это эксперимент, в котором случайная часть пользователей получает решения новой модели, а остальные — текущей, и компания сравнивает бизнес-метрику двух групп. Перед запуском нужно заранее зафиксировать гипотезу, главную метрику, размер выборки и правило остановки, проверить равномерность сплита и договориться, какое решение примут при каждом исходе. Ниже — 36 пунктов по восьми этапам с ответственными и критериями «готово».

Чек-лист подготовлен AIrassvet 21 октября 2026 года для владельцев продукта, руководителей e-commerce и аналитиков, которые выводят в продакшн модели рекомендаций, ранжирования поиска, динамических цен или прогнозов. Он опирается на публикации исследователей экспериментальных платформ Microsoft, Stanford и Criteo. Собственного эксперимента для статьи мы не проводили: числа в примерах взяты из первоисточников или явно помечены как расчёт.

Кратко

Офлайн-точность не гарантирует рост выручки. Решение о выкатке модели принимают по онлайн-эксперименту на реальных пользователях.
Размер выборки считают до старта. По формуле Kohavi и соавторов (2009) для конверсии 5% и чувствительности 5% нужно около 122 тыс. пользователей в каждой группе.
Неравный сплит — главный сигнал брака. В исследовании Microsoft (KDD 2019) несоответствие долей групп (SRM) нашли примерно в 6% экспериментов.
Подглядывание ломает статистику. Если останавливать тест, как только p-value стало меньше 0,05, доля ложных побед растёт.
Решение фиксируют заранее: что делаете при росте, нуле и падении метрики.

Для кого чек-лист и что в него не входит

Чек-лист для команд, которые сравнивают две версии ML-модели или модель с текущим правилом на живом трафике сайта, приложения или каталога: рекомендации, поиск, цены, скидки, прогнозы с прямым влиянием на пользователя. Мы не разбираем офлайн-валидацию модели, многорукие бандиты, байесовский анализ и устройство платформ экспериментов. Как запускать рекомендации целиком, мы описали в статье «Рекомендательная система для интернет-магазина».

Термины. *Контроль (A)* — группа с текущей моделью. *Тест (B)* — группа с новой моделью. *Главная метрика (OEC)* — одна заранее выбранная метрика, по которой принимают решение. *MDE* — минимальный эффект, который тест должен уметь обнаружить. *Мощность* — вероятность заметить эффект, если он есть. *SRM (sample ratio mismatch)* — расхождение фактических долей групп с запланированными. *Guardrail-метрики* — защитные показатели, которые не должны ухудшиться.

Почему офлайн-метрик недостаточно

Модель обычно сначала оценивают на исторических данных: точность прогноза, NDCG, полнота. Но история показывает реакцию пользователей на старые рекомендации, а не на новые. Исследователи Criteo (Gilotte и соавторы, 2018) прямо называют офлайн-оценку предварительным шагом перед онлайн-тестом и показывают, что традиционные контрфактические оценки на их данных не дают удовлетворительного баланса смещения и разброса.

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

Что понадобится до старта

Две готовые версии: текущая модель или правило (контроль) и новая модель, обе работают на одном и том же потоке запросов.
Механизм сплита: платформа экспериментов или собственный сервис, который стабильно относит пользователя к одной группе.
Логи: события показа, клика, покупки, отказа с идентификатором пользователя, группы и версии модели.
Исторические данные за несколько недель для оценки дисперсии метрики и сезонности.
Люди и роли: владелец продукта, аналитик, ML-инженер, разработчик; для цен и скидок — юрист или специалист по рискам.

Чек-лист по этапам

Отмечайте пункт, только когда выполнен критерий «готово». Роли условные: в небольшой команде один человек может закрывать несколько ролей.

Этап 1. Гипотеза и решение

☐ Гипотеза сформулирована в виде «новая модель изменит метрику X у пользователей Y, потому что Z» — *владелец продукта*.
☐ Названо бизнес-решение, которое зависит от результата: выкатить, доработать или отказаться — *владелец продукта*.
☐ Заранее записано, что делаете при росте, нулевом эффекте и падении главной метрики — *владелец продукта, аналитик*.
☐ Офлайн-оценка новой модели не хуже текущей и задокументирована — *ML-инженер*.

Готово, когда: гипотеза и правило решения записаны в паспорт эксперимента до старта.

Этап 2. Метрики

☐ Выбрана одна главная метрика (OEC), связанная с деньгами или удержанием: выручка на пользователя, конверсия, доля успешных поисков — *владелец продукта, аналитик*.
☐ Определены 2–5 guardrail-метрик: скорость ответа, доля ошибок, возвраты, отписки, маржа — *аналитик*.
☐ Для каждой метрики записана формула, единица анализа и источник данных — *аналитик*.
☐ Проверено, что метрика считается одинаково в обеих группах и по тем же логам — *аналитик, разработчик*.
☐ Решено, как учитывать выбросы: например, ограничение экстремальных заказов — *аналитик*.

Готово, когда: формулы метрик согласованы и посчитаны на исторических данных.

Этап 3. Размер выборки и длительность

☐ Оценена дисперсия главной метрики по историческим данным — *аналитик*.
☐ Задан MDE, который имеет смысл для бизнеса, а не «любой рост» — *владелец продукта*.
☐ Рассчитан размер выборки на группу при уровне значимости 5% и мощности не ниже 80% — *аналитик*.
☐ Длительность покрывает минимум один полный недельный цикл и даёт набрать расчётную выборку — *аналитик*.
☐ Если трафика не хватает, рассмотрены метрика с меньшей дисперсией или снижение дисперсии по данным до эксперимента (CUPED) — *аналитик*.

Готово, когда: размер выборки, длительность и дата окончания записаны и не меняются по ходу теста.

Этап 4. Рандомизация и сплит

☐ Выбрана единица рандомизации: пользователь, сессия, магазин, регион — и она совпадает с единицей анализа — *аналитик, разработчик*.
☐ Пользователь стабильно попадает в одну группу при повторных визитах и на разных устройствах, насколько это возможно — *разработчик*.
☐ Боты, сотрудники и тестовые аккаунты исключены одинаково в обеих группах — *разработчик, аналитик*.
☐ Проведён A/A-тест или проверка сплита: группы без изменений не различаются по метрикам — *аналитик*.
☐ Проверено пересечение с другими экспериментами на тех же страницах — *владелец продукта*.

Готово, когда: A/A-проверка не показала значимых различий, доли групп совпадают с планом.

Этап 5. Модель и инфраструктура

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

Готово, когда: нагрузочный прогон пройден, выключатель проверен вручную.

Этап 6. Запуск и мониторинг

☐ Первые часы тест идёт на небольшой доле трафика для проверки ошибок — *разработчик*.
☐ Ежедневно проверяется SRM: фактические доли групп сравниваются с планом статистическим тестом — *аналитик*.
☐ Guardrail-метрики отслеживаются с порогами аварийной остановки — *аналитик, ML-инженер*.
☐ Решение о победе не принимается до окончания расчётного срока, если не используется последовательный метод анализа — *аналитик*.

Готово, когда: тест дошёл до расчётной даты без SRM и без срабатывания guardrail-порогов.

Этап 7. Анализ

☐ Если SRM найден, результаты не интерпретируются до выяснения причины — *аналитик*.
☐ Эффект указан с доверительным интервалом, а не только с p-value — *аналитик*.
☐ Динамика эффекта по дням проверена на эффект новизны: рост в первые дни, который затем исчезает — *аналитик*.
☐ Разрезы по сегментам заданы заранее, а найденные после теста объявлены гипотезами для следующего эксперимента — *аналитик*.

Готово, когда: отчёт содержит эффект, интервал, guardrail-метрики, проверку SRM и ограничения.

Этап 8. Решение и выкатка

☐ Решение принято по правилу из этапа 1, а не по самому удачному разрезу — *владелец продукта*.
☐ Выкатка идёт поэтапно, а небольшая контрольная группа (holdout) остаётся для отслеживания долгосрочного эффекта — *владелец продукта, разработчик*.
☐ Паспорт эксперимента, отчёт и версия модели сохранены в общей базе экспериментов — *аналитик*.
☐ Назначена дата повторной проверки модели на дрейф данных — *ML-инженер*.

Готово, когда: новая версия на всём трафике, отчёт доступен команде, назначен владелец модели.

Как посчитать размер выборки: пример

Kohavi и соавторы (2009) приводят приближённую формулу для уровня значимости 5% и мощности 80% при двух группах равного размера:

n = 16 · σ² / Δ², где *n* — число пользователей в каждой группе, *σ²* — дисперсия главной метрики, *Δ* — абсолютный эффект, который нужно заметить. Для мощности 90% коэффициент 16 заменяют на 21.

Главная метрика	Исходные данные из статьи Kohavi и соавторов	Расчёт	Пользователей в каждой группе
Конверсия в покупку	конверсия 5%, нужно заметить изменение на 5% от неё	16 · 0,05 · 0,95 / (0,05 · 0,05)²	≈ 121 600
Выручка на пользователя	средняя 3,75 $, стандартное отклонение 30 $, изменение на 5%	16 · 30² / (3,75 · 0,05)²	≈ 409 600

Расчёт выполнен AIrassvet по формуле и исходным данным из статьи. Сравнение показывает практический вывод авторов: метрика с меньшей дисперсией, например конверсия вместо выручки, сокращает нужную выборку — по их оценке, в этом примере в 3,3 раза. Второй способ — CUPED: на поисковике Bing метод снижал дисперсию примерно на 50%, то есть давал ту же мощность при половине пользователей или половине длительности (Deng и соавторы, 2013).

Копируемый шаблон паспорта эксперимента

Скопируйте шаблон в базу знаний команды и заполните его до запуска теста.

ПАСПОРТ A/B-ТЕСТА ML-МОДЕЛИ
Название и ID эксперимента:
Владелец продукта / аналитик / ML-инженер:
Гипотеза: новая модель ___ изменит ___ у ___, потому что ___
Контроль (A): модель/правило, версия ___
Тест (B): модель, версия ___, дата обучения ___
Главная метрика (OEC), формула, единица анализа:
Guardrail-метрики и пороги аварийной остановки:
Единица рандомизации и доли групп (например, 50/50):
Исключения из трафика (боты, сотрудники, тестовые аккаунты):
Дисперсия метрики (период оценки):
MDE, уровень значимости, мощность:
Размер выборки на группу:
Дата старта / расчётная дата окончания:
Правило остановки (фиксированный срок или последовательный метод):
Решение при росте / нуле / падении:
Заранее заданные сегменты для анализа:
Результат: эффект, доверительный интервал, SRM-проверка, ограничения:
Принятое решение и дата:

Типовые ошибки

Остановка «по первой значимости». Johari и соавторы (2015) показывают, что обычные p-value и доверительные интервалы становятся ненадёжными, если тест непрерывно мониторят и останавливают по результату; для этого нужны последовательные методы.
Игнорирование SRM. Fabijan и соавторы (KDD 2019) описывают SRM как частый признак проблем с данными: причины — ошибки назначения групп, потеря логов, фильтрация ботов, задержка в одной из версий.
Эффект новизны и привыкания. Kohavi и соавторы (2009) предупреждают: опытные пользователи могут сначала хуже реагировать на изменение навигации, а интерес к новому может временно завышать результат.
Слишком много метрик без главной. Если в отчёте двадцать метрик, хотя бы одна случайно покажет «значимость»; решение принимают по одной заранее выбранной метрике.
Разные логи в группах. Если новая модель логирует события иначе, сравнение метрик бессмысленно — проверяйте это на A/A-тесте.

Когда A/B-тест не подходит

A/B-тест по пользователям не подходит или требует другой схемы в таких случаях:

Мало трафика. Если до расчётной выборки нужны месяцы, сначала сравните модели офлайн, выберите метрику с меньшей дисперсией или тестируйте на более частом событии.
Пользователи влияют друг на друга. В маркетплейсах, такси, доставке новая модель в одной группе может менять предложение для другой; тогда рандомизируют по регионам или по интервалам времени.
Цены и скидки. Разные цены для разных покупателей требуют проверки юристом и внимания к репутационным рискам; часто тестируют по магазинам или регионам. Подробнее о рисках — в статье о динамическом ценообразовании с ИИ.
Редкие решения с большой ценой ошибки. Для кредитных или медицинских решений нужны отдельные процедуры валидации, которые этот чек-лист не заменяет.

Частые вопросы

Сколько должен длиться A/B-тест ML-модели?

Столько, сколько нужно для расчётной выборки, но не меньше полного недельного цикла. Длительность определяют до старта по размеру выборки и трафику: поведение в будни и выходные отличается, а короткий тест может поймать эффект новизны. Kohavi и соавторы (2009) отмечают, что число посетителей растёт примерно линейно со временем эксперимента. Менять срок по ходу теста из-за промежуточных результатов нельзя.

Можно ли сравнить больше двух моделей в одном тесте?

Можно, но каждая дополнительная группа уменьшает трафик на вариант и увеличивает риск случайной «победы». Kohavi и соавторы (2009) приводят более консервативную формулу размера выборки для нескольких вариантов: n = (4rσ/Δ)², где r — число вариантов. На практике сначала отсеивают кандидатов офлайн и выводят в онлайн-тест одну-две лучшие модели.

Что делать, если доли групп не совпадают с планом?

Остановить интерпретацию результатов и искать причину. Расхождение долей (SRM) Fabijan и соавторы связывают с ошибками назначения, потерей или задержкой логов, фильтрацией ботов, перенаправлениями. Пока причина не найдена, метрики групп сравнивать нельзя: даже большой эффект может объясняться тем, что в группы попали разные пользователи. После исправления тест обычно перезапускают.

Нужна ли платформа экспериментов или хватит своего кода?

Для первых тестов хватит своего сервиса сплита и аккуратных логов, если команда проверяет SRM и проводит A/A-тест. Платформа нужна, когда экспериментов становится много: она ведёт реестр, следит за пересечениями и автоматически считает метрики. В обоих случаях важнее дисциплина паспорта эксперимента, чем выбор инструмента.

Как тестировать модель поиска по каталогу?

Так же, как рекомендации, но главной метрикой обычно берут долю поисков с покупкой или добавлением в корзину, а guardrail-метриками — долю пустых выдач и скорость ответа. Единица рандомизации — пользователь, чтобы один человек не видел разные выдачи. Как устроен сам поиск, мы описали в статье об умном поиске для интернет-магазина.

Первоисточники и метод

Kohavi, Longbotham, Sommerfield, Henne. Controlled experiments on the web: survey and practical guide, 2009 — формула размера выборки, пример с конверсией и выручкой, эффекты новизны.
Fabijan и соавторы. Diagnosing Sample Ratio Mismatch in Online Controlled Experiments, KDD 2019 — частота и причины SRM.
Deng, Xu, Kohavi, Walker. Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data (CUPED), WSDM 2013 — снижение дисперсии.
Johari, Pekelis, Walsh. Always Valid Inference: Bringing Sequential Analysis to A/B Testing, 2015 — проблема непрерывного мониторинга.
Gilotte и соавторы. Offline A/B testing for Recommender Systems, 2018 — ограничения офлайн-оценки.
Kohavi, Tang, Xu. Trustworthy Online Controlled Experiments, Cambridge University Press — книга-справочник по экспериментам.

Как составлен чек-лист. Мы разложили рекомендации первоисточников по восьми этапам жизненного цикла эксперимента и для каждого пункта указали роль и проверяемый критерий. Пункты про инфраструктуру ML-модели (версия в логах, запасной вариант, расчёт признаков) — инженерная практика, а не вывод исследований. Ограничения: мы не проверяли чек-лист на собственном эксперименте, а числа из статей относятся к условиям авторов.

Как AIrassvet помогает проверить ML-модель в A/B-тесте

Хорошая модель приносит пользу, только если её эффект измерен честно. На сайте AIrassvet указаны направления, которые закрывают эту задачу:

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

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

Обсудить задачу

Итог: тест решает, а не модель

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

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