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

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

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

Відмінності ML A/B від класичного A/B

У класичному A/B користувачі випадково розподіляються між групами один раз. У ML A/B додаткові складності:

• Novelty effect: користувачі реагують на новизну, яка не пов'язана з якістю моделі
• Long-term effects: рекомендаційні системи впливають на довгострокову поведінку, не помітну в короткостроковому тесті
• Carryover effects: ефект від попереднього передбачення впливає на поточну поведінку
• Network effects: у колаборативних системах поведінка одного користувача впливає на інших

Архітектура A/B для ML

Рівні розподілу трафіку:

1. User-level split — один і той самий користувач завжди отримує одну версію моделі. Підходить для персоналізації, рекомендацій.

2. Request-level split — кожен запит випадково надсилається до однієї з версій. Підходить для stateless сервісів (пошук, ціноутворення).

3. Cohort-based split - розбивка по сегментах користувачів. Важливо задля забезпечення балансу по демографічним характеристикам.

Роутинг трафіку:

import hashlib

def get_model_version(user_id: str, experiment_id: str) -> str:
    # Детерминированное хэширование для стабильного назначения
    hash_key = f"{experiment_id}:{user_id}"
    hash_value = int(hashlib.md5(hash_key.encode()).hexdigest(), 16)
    bucket = hash_value % 100  # 0-99

    if bucket < 50:  # 50% трафика
        return "model_v2"
    else:
        return "model_v1_control"

Інструменти

Nginx / Envoy — маршрутизація на рівні інфраструктури за заголовками або вагами.

Seldon Core / KServe — Kubernetes-native інференс із вбудованим A/B:

apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
spec:
  predictors:
    - name: control
      traffic: 70
      graph:
        name: model-v1
    - name: treatment
      traffic: 30
      graph:
        name: model-v2

Feature flags (LaunchDarkly, Unleash) — для гнучкого управління експериментами без деплою.

Статистична методологія

Метрики для ML A/B:

• Primary metric: бізнес-метрика (конверсія, ARPU, retention)
• Guardrail metrics: latency, error rate – не повинні деградувати
• Secondary metrics: proxy-показники (CTR, engagement)

Розмір вибірки та потужність тесту:

Для виявлення ефекту розміром 2% при baseline конверсії 5%, рівні значущості α=0.05 і потужності 80%, потрібно ~15000 користувачів групу. Перед запуском використовуйте калькулятор потужності (scipy.stats.norm або онлайн-інструменти).

Зупинка тесту:

• Не зупиняйте тест раніше запланованого терміну через ранні результати (проблема peek)
• Мінімальна тривалість: 1-2 тижні для обліку денних та тижневих патернів
• Використовуйте Sequential testing (e-values), якщо потрібно приймати рішення раніше

Аналіз результатів

from scipy import stats

control_conversions = [0, 1, 0, 1, ...]  # 0/1 для каждого пользователя
treatment_conversions = [0, 1, 1, 0, ...]

# t-тест для непрерывных метрик
t_stat, p_value = stats.ttest_ind(control_conversions, treatment_conversions)

# Chi-squared для бинарных метрик
from scipy.stats import chi2_contingency
contingency = [[control_success, control_fail],
               [treatment_success, treatment_fail]]
chi2, p_value, dof, expected = chi2_contingency(contingency)

print(f"Relative lift: {(treatment_rate - control_rate) / control_rate:.2%}")
print(f"P-value: {p_value:.4f}")
print(f"Statistically significant: {p_value < 0.05}")

Правильно налаштований A/B-тест дозволяє приймати рішення про депло моделі не на основі інтуїції, а на основі даних з вимірним рівнем впевненості.