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

## Чому A/B тестування ML-моделей складніше, ніж тестування UI A/B тестування в продуктових командах — стандартна практика. Ви показуєте варіант A 50% користувачів, варіант B — іншим 50%, чекаєте статистично значимого результату і обираєте переможця. Просто. З ML-моделями все складніше. По-перше, модель — це не просто візуальна зміна: вона може впливати на критичні бізнес-рішення. По-друге, ML-моделі мають latency характеристики, які треба враховувати при routing. По-третє, модель може вести себе погано на підгрупах даних, навіть якщо загальна метрика покращилася. У цій статті розберемо повний цикл безпечного A/B тестування ML-моделей. ## Передумови: чому потрібно тестувати Типова ситуація: команда навчила нову версію моделі, offline-метрики покращились (accuracy +3%, AUC +0.02). Чи можна одразу деплоїти в production? Категорично ні. **Причини:** - Offline-метрики ≠ бізнес-метрики. Модель може мати кращий AUC, але гірше конвертувати в реальних умовах - Distribution shift: тестова вибірка не точно відображає production-дані - Latency regression: нова модель може бути точнішою, але повільнішою, і це вб'є UX - Edge cases: на підгрупах (нові користувачі, нові регіони, рідкісні SKU) нова модель може деградувати ## Метод 1: Shadow Mode (тіньовий режим) ### Як працює У shadow mode нова модель отримує той самий трафік, що й production, але її передбачення не використовуються в реальних рішеннях. Обидві моделі отримують однакові вхідні дані, обидві повертають відповідь, але production-модель «виграє» і її відповідь іде до клієнта. Відповідь shadow-моделі логується для аналізу. **Схема:** Запит → [Production Model] → Відповідь до клієнта ↘ [Shadow Model] → Лог (без впливу на клієнта) ### Що аналізувати в shadow mode - **Розбіжності у передбаченнях:** де моделі дають різні відповіді? Які випадки? - **Latency нової моделі:** чи вкладається в SLA? - **Ресурсоспоживання:** CPU/GPU/memory нової моделі - **Помилки і exceptions:** чи є нові класи помилок? ### Коли достатньо shadow mode Shadow mode не дає бізнес-метрик (бо нова модель не впливає на реальні рішення). Але він ідеальний для: - Валідації, що нова модель не крашиться на production-даних - Оцінки latency і ресурсів - Порівняння розподілів передбачень (чи не відрізняються кардинально?) **Тривалість shadow mode:** зазвичай 24–72 години для збору достатньої вибірки. ## Метод 2: Canary Deployment ### Як працює Canary deployment — поступове збільшення частки трафіку до нової моделі. Починаємо з 1–5%, спостерігаємо метрики, якщо все ок — збільшуємо до 10%, 25%, 50%, 100%. **Графік canary rollout:** - День 1: 1% трафіку → нова модель - День 2: 5% трафіку (якщо немає аномалій) - День 4: 20% трафіку - День 7: 50% трафіку - День 10: 100% трафіку ### Автоматизований canary із rollback Ключова перевага — автоматичний rollback при перевищенні порогів: # Псевдокод логіки canary controller if error_rate > 0.01: # 1% помилок trigger_rollback() elif p99_latency > 500: # 500ms P99 latency trigger_rollback() elif conversion_rate_drop > 0.05: # 5% падіння конверсії trigger_rollback() else: increase_canary_traffic(step=0.05) **Інструменти для canary:** Argo Rollouts, Flagger (для Kubernetes), AWS App Mesh, Istio. ## Метод 3: Traffic Splitting (класичний A/B тест) ### Коли використовувати Traffic splitting — класичний A/B тест, де ви одночасно направляєте різні частки трафіку на різні моделі. На відміну від canary, немає поступового збільшення — розбиття фіксоване на час тесту. **Переваги:** - Чіткий статистичний фреймворк - Обидві моделі отримують однакові умови одночасно - Можна тестувати кілька варіантів (A/B/C) **Використовувати коли:** - Ви хочете порівняти дві кардинально різні архітектури - Потрібен формальний статистичний тест - Є бізнес-метрика, яку можна виміряти напряму ### Вимоги для коректного A/B тесту ML **1. Відсутність network effects.** Якщо дії одного користувача впливають на досвід іншого (соціальні мережі, маркетплейси) — класичний A/B тест дає зміщені результати. Потрібне кластерне розбиття. **2. Стабільний assignment.** Один і той самий користувач має завжди потрапляти в одну групу. Randomization на рівні user_id, а не session_id. **3. Novelty effect.** Нова модель може тимчасово показувати кращі метрики просто тому, що «нова». Запускайте тест мінімум 2 тижні. **4. Достатній розмір вибірки.** Розрахуйте необхідний розмір вибірки до початку тесту (power analysis). При ефекті 2% і alpha=0.05 — потрібні тисячі спостережень. ## Метод 4: Multi-Armed Bandit як альтернатива ### Чим відрізняється від класичного A/B Класичний A/B тест оптимізує для статистичного висновку. Multi-Armed Bandit (MAB) оптимізує для мінімізації regret — тобто ви «підтягуєте» трафік до кращої моделі автоматично, не чекаючи кінця тесту. **Epsilon-Greedy стратегія:** з імовірністю epsilon — exploration (рівномірний розподіл між моделями), з імовірністю 1-epsilon — exploitation (увесь трафік до поточного лідера). **Коли використовувати MAB:** - Бізнес-метрику можна вимірювати одразу (не з затримкою) - Цінність мінімізації regret вища, ніж статистичної строгості - Тест може тривати довго **Коли уникати MAB:** - Потрібен формальний статистичний висновок - Є seasonality (різні дні дають різні патерни) ## Моніторинг під час тесту ### Guardrail метрики Паралельно з цільовою метрикою (конверсія, клік) відстежуйте guardrail метрики — ті, що не мають погіршитися: - Error rate (API 5xx) - P99 latency - Сесійна тривалість - Показник відмов Якщо будь-яка guardrail метрика перевищує поріг — автоматичний rollback незалежно від стану цільової метрики. ### Сегментний аналіз Загальна метрика може виглядати добре, а на конкретних сегментах — деградувати: - Нові vs поверненні користувачі - Мобайл vs десктоп - Різні географічні регіони - Різні категорії продуктів Обов'язково аналізуйте ключові сегменти перед оголошенням переможця. ## Від тесту до production: checklist Перед оголошенням переможця перевірте: - Досягнуто статистичної значимості (p < 0.05, power > 0.8)? - Тест тривав достатньо (мінімум 2 повних бізнес-цикли)? - Перевірено всі ключові сегменти? - Guardrail метрики в нормі? - Latency і ресурсоспоживання прийнятні? - Є план rollback після повного деплою? A/B тестування ML-моделей — це не overhead, а страхування від дорогих помилок в production. При правильній організації один тест може запобігти інциденту, що коштуватиме в рази більше, ніж усі витрати на тестування.