Налаштування A/B-тестування ML-моделей у продакшені

A/B-тестування ML: де ламається продакшен

Найчастіша картина: нову версію моделі випускають у продакшен повністю, одним релізом, поверх старої. Порівнювати нема з чим — попередня версія вже не отримує трафік, а офлайн-оцінка на відкладеній вибірці показує одне, тоді як жива система живе за іншими правилами. Суперечка про те, чи стало краще, вирішується не вимірюванням, а тим, хто гучніше наполягає.

Розбіжність метрик майже завжди походить зі зміщення вибірки. Відкладена вибірка зібрана на минулих даних, а живий трафік змінюється: приходять нові сегменти, змінюється частка користувачів з історією, інакше поводяться рідкісні запити.

Контроль якості моделі за однією середньою цифрою це приховує — метрика зросла загалом, а на цільовому сегменті просіла.

Робоча схема — часткове A/B-тестування ML на живому трафіку: частина запитів іде на нову версію, частина залишається на контрольній. Користувач закріплюється за гілкою на всю сесію, інакше порівняння версій моделі розмивається перемиканнями.

Тіньовий режим і канарковий випуск дають те саме вимірювання без ризику: тіньова копія рахує відповіді, не впливаючи на видачу, а канаркова частка зростає в міру підтвердження метрик.

Тоді випуск моделі в продакшен спирається на вимірювання, а не на думку: видно приріст на цільовому сегменті та ціну — затримку й частку відмов. Як це закривається на практиці — нижче.

Що дає кероване порівняння моделей на потоці

Цикл перевірки гіпотез прискорюється

Раніше нова версія моделі чекала найближчого релізу, а результат оцінювали за непрямими ознаками та скаргами. Тепер трафік ділиться на групи прямо в робочому контурі, і час до оцінки результату вимірюється днями, а не тижнями. За той самий період команда встигає перевірити більше гіпотез і швидше закриває тупикові гілки.

Порівняння груп користувачів замість суперечок

Обидві версії отримують зіставні потоки запитів, а поведінка аудиторії порівнюється за заздалегідь узгодженими зрізами. Це прибирає аргумент «мені здається, нова модель відповідає краще»: рішення спирається на різницю між групами, а не на враження від кількох показових прикладів.

Єдина метрика якості

Шкала фіксується до старту — частка успішно закритих сценаріїв, точність відповіді на контрольному наборі, глибина взаємодії. Одна метрика на всі ітерації дозволяє порівнювати версії між собою й бачити, який крок дав приріст, а який створив лише видимість роботи.

Частка програшних випусків падає

Поки порівняння йде на частині аудиторії, помилка проявляється до того, як зачепить усіх. Слабка версія знімається з потоку й не доходить до повного релізу — клас відмов, коли «покращення» непомітно погіршувало якість, зникає з процесу.

Формати розгортання: тіньовий режим, канарковий, повний A/B

Вибір режиму розгортання — це насамперед вибір ціни помилки. Тіньовий прогін її не створює, канарковий випуск обмежує її часткою трафіку в тесті, а повний A/B-тест ставить на кін усю аудиторію.

Різниця між форматами — не в «просунутості», а в тому, які обмеження ви готові прийняти: доступність даних, термін спостереження й вимоги до відкату.

На практиці формати не конкурують, а вишиковуються в ланцюжок: тіньовий прогін відсікає явні відмови, канарковий випуск перевіряє стійкість під живим навантаженням, повний A/B-тест відповідає на питання про приріст.

Ключова умова переходу на наступний крок — єдиний набір метрик у всіх режимах і робочий відкат на попередню версію на кожному з них. Інакше результати непорівнювані, і рішення про розгортання доведеться приймати на око.

Як це виглядає на живому потоці, ми розбирали в Розборі розгортання рекомендаційної моделі — там же видно, чому після тіньового прогону контроль на частці трафіку все одно обов’язковий.

Етапи впровадження: від аудиту даних до передачі контуру

Впровадження A/B-тестування моделей — це не встановлення бібліотеки, а послідовність, де кожен крок спирається на попередній. Пропущений аудит даних залишає схему експерименту без опори, і висновки потім нічим захистити. Порядок роботи в нас такий.

1. Аудит даних. Дивимося, які події логуються, з якою затримкою доходять, де губиться частка результатів і чи є історичний зріз для офлайн-прогону. Без цього не можна ні порахувати метрику, ні оцінити термін тесту.
2. Схема експерименту. Фіксуємо основну метрику, метрики-обмежувачі, гіпотезу, мінімальний помітний ефект і критерії зупинки — до старту, а не після першого погляду на цифри.
3. Розбиття на групи. Розподіляємо за ідентифікатором користувача, а не за запитом: інакше одна людина потрапляє в обидві групи й порівняння розмивається. До запуску перевіряємо баланс груп за зрізом історії.
4. Налаштування контуру. Налаштовуємо маршрутизацію частки трафіку й логування версії моделі разом із рішенням. Кожен показ має пов’язуватися з результатом, інакше розбір розбіжностей упирається в здогадки.
5. Перевірка на пілоті. Запускаємо на малій частці трафіку й дивимося технічні помилки, час відповіді, дрейф вхідних даних. Розширюємо лише після того, як контур поводиться стабільно.
6. Передача контуру. Віддаємо регламент запуску нових версій, дашборд, доступи й порядок зупинки експерименту. Команда замовника веде наступний тест сама.

Конфігурації, схеми й регламенти експерименту

Експеримент керований, коли все, що визначає його поведінку, лежить у файлах і регламентах, а не в голові інженера.

Нижче — мінімальний комплект, який залишається в замовника разом із робочим контуром: за ним прогін можна повторити, зупинити або відкотити без участі нашої команди.

• Конфігурація експерименту — частки трафіку між контролем і варіантами, горизонт спостереження, мінімальний розмір вибірки, критерій дострокової зупинки й правило визнання переможця.
• Карта метрик — одна цільова з напрямом зміни, захисні метрики, які не повинні просісти, і розбивка за сегментами, де ефект може відрізнятися.
• Схема потоків трафіку — як запит потрапляє у варіант, де фіксується розподіл і хто відповідає за те, що той самий користувач залишається у своїй групі.
• Правила доступу до даних — хто і на якій підставі бачить сирі події, де лежать знеособлені зрізи, як перевірна розмітка відокремлена від навчальної вибірки.
• Документація контуру — склад сервісів, залежності, точки стикування зі сховищем і моніторингом, порядок штатного запуску й зупинки.
• Регламент відкату — тригери (просідання захисної метрики, зростання відмов, розбіжність розподілу), відповідальний, час до повернення на контроль і порядок розбору.
• Журнал прогонів — гіпотеза, версія моделі, період, результат, рішення про розгортання та його автор.

Кожен пункт — робочий артефакт: його читають під час передачі зміни й під час розбору інциденту, а не лише на прийманні. Комплект оновлюється разом із контуром — інакше за пару ітерацій документація розходиться з реальністю, і відкат перетворюється на ручну археологію.

Кейс: як ми прибрали розбіжності між версіями моделі

Що було на вході

Замовник — сервіс із моделлю ранжування в продакшені. Команда випускала нову версію раз на два тижні й щоразу отримувала спірний результат: на одному сегменті модель вигравала, на іншому програвала, а рішення приймалося за середнім по всьому трафіку.

Частка відмов на нових версіях трималася на рівні 6–8%, а на розбір однієї гіпотези йшло близько трьох тижнів — ефект встигав застаріти раніше, ніж тест закривався.

Що змінили

Ми розвели два різні питання: «модель справді краща?» і «трафік поділено чесно?».

З’явилася стратифікація потоку за ключовими сегментами, фіксація випадковості розбиття, тіньовий прогін нової версії на всьому трафіку до того, як її побачить частина користувачів, і захисні метрики — час відповіді й частка порожніх видач — з автоматичною зупинкою тесту при просіданні.

Критерій зупинки задавався заздалегідь, тому рішення про розгортання перестало залежати від того, хто гучніше наполягає.

Що стало

Частка відмов на нових версіях знизилася з 6–8% до 2%, а розкид ефекту між сегментами став видимий до розгортання, а не після. Час від гіпотези до рішення скоротився з трьох тижнів до шести днів.

Стійкість перевіряли повторними прогонами: знак ефекту збігався у дев’яти запусках із десяти, тоді як раніше результат змінювався від запуску до запуску.

Підхід не винайдений нами — стратифікація груп і захисні метрики докладно розібрані в матеріалах Microsoft Research щодо побудови платформ експериментів, ми адаптували їх під масштаб і структуру даних замовника.

Чим A/B-тестування ML відрізняється від канаркового релізу

A/B-тестування ML відповідає на питання «чи стало краще», канарковий реліз — «чи не зламалося». Перший порівнює версії моделі за користувацькою метрикою, другий страхує випуск від регресу.

Канарковий етап із порогами за помилками пропустить модель, яка працює стабільно, але втрачає конверсію.

Різниця починається з одиниці спостереження. Канарковий реліз оперує екземплярами сервісу й частками трафіку — йому достатньо агрегатів за хвилини.

В A/B-тестуванні ML одиниця — користувач або сесія, закріплена за групою: якщо той самий трафік іде в обидві гілки, виникає зміщення вибірки, і ефект моделі не відокремлюється від ефекту аудиторії.

Рішення за результатом тесту теж приймається по-різному. Канарковий реліз закривається автоматикою: вихід за пороги за відмовами й затримками дає відкат, інакше частка розширюється.

A/B-тестування ML потребує заздалегідь вибраної метрики, розрахунку потужності й вікна спостереження — зазвичай тижнів, щоб уловити тижневий цикл поведінки.

Обмеження за даними розходяться: на слабкому потоці A/B-тестування ML не набирає потужності, а канарковий реліз стартує на малій частці й статистики не накопичує.

На практиці їх поєднують — спочатку канарковий етап, потім A/B на решті аудиторії; метрики обох етапів тримаємо в одному трекері експериментів, наприклад у MLflow.

Питання за даними, метриками й інфраструктурою тестів

Сумніви навколо тестів повторюються: чи можна вірити різниці між групами, що робити із затримкою розмітки й чи варто розгортати власний контур експериментів. Нижче — короткі відповіді на те, що найчастіше виринає на етапі оцінки.

Мітки приходять із затримкою — тесту можна вірити?

Так, якщо вікно спостереження узгоджене з горизонтом дозрівання мітки. Обидві групи рахуємо в одному вікні й перераховуємо підсумок після його закриття, а не за першими днями, де частина подій ще не доїхала.

Чи потрібен окремий контур експериментів?

Зазвичай ні: якщо розділення трафіку, логування показів і розрахунок метрик уже працюють, до них додається версія моделі та ознака групи. Свій контур розгортаємо, коли рішення потрібно ухвалювати швидше, ніж дозволяє поточна аналітика.

Як досягти зіставності груп?

Ділимо за стійким ідентифікатором користувача, а не за сесією чи окремим запитом, і до старту звіряємо групи за ключовими зрізами. Інакше різниця у складі трафіку читається як ефект моделі.

Обговоримо задачу: зберемо план експерименту під ваш потік

Щоб план експерименту був реалістичним, а не загальним, потрібні вхідні дані з вашого боку. Достатньо описати поточний потік запитів, продуктові метрики й обмеження — решту уточнимо в листуванні, а спірні місця закриємо гіпотезами й окремо позначимо в плані.

• Як рішення приймається зараз: одна модель на весь трафік, ручні правила чи попередній експеримент — і що саме в ньому не спрацювало.
• Яка частка трафіку може піти під тест і де точки входу: сервіс онлайн-запитів, черга, пакетний перерахунок за розкладом.
• Метрика успіху в двох шарах: бізнес-показник (конверсія, частка скасувань, час обробки) і технічна точність моделі з розкидом за сегментами.
• За який термін потрібен висновок — дні чи тижні — і чи можна розтягнути тест, якщо для значущого результату не вистачає подій.
• Що є за даними: логи минулих версій, розмічена вибірка, доступ до сховища й поля, які не можна вивантажувати назовні.
• Вимоги до відкату: за який час потрібно повернути попередню модель і хто ухвалює рішення про зупинку експерименту.
• Хто з боку замовника погоджує метрики й доступи — один відповідальний чи кілька команд.

У відповідь повернемо оцінку обсягу робіт, порядок робіт за етапами, схему розбиття трафіку, критерії зупинки й відкату. Опишіть задачу — зберемо план під ваш потік і назвемо терміни.