A/B тестування ML-моделей: як порівняти без ризику для бізнесу

## Чому A/B тестування ML-моделей складніше, ніж A/B тест кнопки Класичне A/B тестування UI-елементів відносно просте: 50% користувачів бачать варіант A, 50% — варіант B, через тиждень порівнюємо конверсію. Для ML-моделей все значно складніше з кількох причин. По-перше, **feedback delay**. Якщо ви тестуєте модель прогнозування відтоку клієнтів, результат рішення (відтік або ні) ви побачите через тижні або місяці. Класичний A/B тест з коротким вікном не покаже реального ефекту. По-друге, **interference between users**. Рекомендаційна система для одного користувача впливає на наявність товару для іншого. Рандомізація на рівні користувача не усуває цю залежність. По-третє, **model drift в часі**. За час тесту стара модель може погіршитись через data drift, а нова — ні, або навпаки. Це забруднює порівняння. ## Shadow Mode: нульовий ризик для порівняння Shadow mode (тіньовий режим) — найбезпечніший спосіб тестування нової моделі. Логіка проста: нова модель отримує ті самі вхідні дані, що й production-модель, але її відповідь **не показується користувачеві і не впливає на рішення**. Натомість вона логується і порівнюється з відповіддю production-моделі постфактум. Що дає shadow mode: - Оцінка латентності нової моделі під реальним навантаженням - Порівняння розподілу передбачень (чи немає systematic bias?) - Виявлення граничних випадків, де моделі суттєво розходяться - Перевірка інфраструктури деплойменту без ризику для користувачів Shadow mode не замінює A/B тест — він не показує бізнес-метрики. Але дозволяє відфільтрувати явно проблемні моделі до того, як вони торкнуться реальних користувачів. ## Canary Release: поступове розгортання Canary release — це стратегія, при якій нова модель спочатку отримує малий відсоток трафіку (1–5%), і цей відсоток поступово зростає за умови відсутності деградації метрик. Типова схема для ML-моделі: 1. Деплой нової моделі, направлення 1% трафіку 2. Моніторинг 24–48 годин: технічні метрики (латентність, error rate) + бізнес-метрики (конверсія, відмови) 3. Якщо все добре — збільшення до 5%, потім до 20%, 50%, 100% 4. При будь-якій деградації — автоматичний rollback до попередньої версії Ключовий момент: **автоматичний rollback**. Canary без автоматичного відкату — це canary без парашута. Визначте порогові значення метрик заздалегідь і налаштуйте автоматичне спрацювання. ## Multi-Armed Bandits: динамічна оптимізація Класичний A/B тест фіксує розподіл трафіку на весь час експерименту — навіть якщо одна версія явно краща. Multi-armed bandit (MAB) вирішує цю проблему: він динамічно перерозподіляє трафік на користь варіанту, що показує кращий результат, одночасно продовжуючи досліджувати альтернативи. Найпопулярніший алгоритм — **Thompson Sampling**: система постійно оновлює ймовірнісну оцінку кожного варіанту і вибирає, куди направити наступний запит, пропорційно до ймовірності того, що цей варіант є найкращим. MAB ідеально підходить для: - Рекомендаційних систем, де потрібна швидка адаптація - Ситуацій з обмеженим часом на тест (рекламні кампанії, акції) - Задач з чітким online reward сигналом (клік, покупка) MAB менш підходить для: - Задач з delayed feedback (відтік, LTV) - Ситуацій, де потрібна статистично значуща різниця для рішення ## Статистична значущість: скільки чекати Найпоширеніша помилка в A/B тестуванні — зупинка тесту при першому значущому результаті (p < 0.05). Це призводить до хибно позитивних висновків. Правильний підхід: визначте **sample size заздалегідь** на основі: - Очікуваного ефекту (Minimum Detectable Effect, MDE) - Статистичної потужності тесту (зазвичай 80%) - Рівня значущості (alpha = 0.05) Для e-commerce з базовою конверсією 3% і MDE 10% відносного покращення (тобто 3.3%) при alpha=0.05 і power=0.8 потрібно близько 50 000 користувачів на варіант. Калькулятори sample size (Evans, Optimizely) допоможуть порахувати це без глибоких знань статистики. **Правило:** завжди визначте зупиночний критерій до початку тесту. Не дивіться на p-value щодня — зафіксуйте дату завершення і дотримуйтесь її.