ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить A/B тестирование агентов

1. Цель задачи

Научиться проектировать и проводить A/B‑эксперимент для двух версий AI‑агента (control и treatment) в production‑подобном окружении. Эксперимент длится 2 недели, трафик делится 50/50. Ключевой результат — получение статистически значимого вывода о превосходстве или эквивалентности одной из версий по выбранным метрикам.

Ключевой результат Статистически значимый (p-value < 0.05) ответ на вопрос: «Улучшила ли новая версия агента выбранную бизнес‑метрику относительно текущей?» с документированным дизайном эксперимента и анализом.

2. Исходные данные

Если нет реального инструмента — симулируем:

1. Создать простого AI‑агента на LangChain (control), отвечающего на вопросы по документации.
2. Сделать модифицированную версию (treatment), например, с другим промптом или другой LLM (GPT‑4o mini vs GPT‑4o).
3. Написать скрипт, который генерирует 1000+ синтетических запросов из шаблонов с разными интентами.
4. Реализовать балансировщик в Python: random_split(user_id) — по хешу от user_id распределяет запросы 50/50.
5. Записать логи и метрики в CSV (latency, response length, user feedback — если есть).

3. Технологический стек

4. Этапы выполнения

Этап 1: Дизайн эксперимента (2–4 часа)

Действия

1. Сформулировать гипотезу

   • H0: Treatment не отличается от Control по метрике.
   • H1: Treatment лучше/хуже Control (двусторонняя или односторонняя).
   • Пример: «Изменение промпта повышает долю успешных завершений диалога с 70% до 75%».

2. Определить primary метрику (одну, ключевую) и secondary метрики.

   • Primary: Success rate, Average response score, Task completion rate.
   • Secondary: Latency p95, Cost per request, User satisfaction score (если есть).

3. Оценить необходимый размер выборки (sample size)

   • Использовать statsmodels.stats.power.tt_ind_solve_power или онлайн‑калькулятор.
   • Входные: α = 0.05, power = 0.8, effect size (Cohen’s d) из пилота.
   • Если пилота нет — принять effect size = 0.2 (small) и посчитать:

     from statsmodels.stats.power import TTestIndPower
     analysis = TTestIndPower()
     n = analysis.solve_power(effect_size=0.2, power=0.8, alpha=0.05, ratio=1.0)
     print(int(n))  # ~ 393 на группу
     

   • С учётом 2 недель и ожидаемого трафика (например, 100 запросов/день → 1400) выборка достаточна.

4. Спланировать сплит

   • Использовать стабильный хеш от user_id → версия.
   • Обеспечить, что один пользователь всегда попадает в одну группу.

5. Задокументировать дизайн эксперимента в markdown:

   • Гипотеза, метрика, размер выборки, длительность, критерий остановки (не останавливать раньше срока, если нет очевидного вреда).

Ожидаемый результат этапа Документ «Design Document A/B Test Agent v1 vs v2», содержащий все пункты дизайна.

Этап 2: Подготовка инфраструктуры (4–6 часов)

Действия

1. Развернуть две версии агента

   • Docker‑контейнеры с API (FastAPI / Flask).
   • Control — на порту 8001, Treatment — на порту 8002.

2. Написать middleware для сплита трафика

   REQUEST_SPLIT = {0: "control", 1: "treatment"}
   
   def get_version(user_id: str) -> str:
       hash_val = int(hashlib.md5(user_id.encode()).hexdigest(), 16)
       return REQUEST_SPLIT[hash_val % 2]
   
   # В эндпоинте:
   version = get_version(request.user_id)
   if version == "control":
       response = await call_control_agent(...)
   else:
       response = await call_treatment_agent(...)
   

3. Настроить логирование

   • Каждый запрос пишет JSON‑строку с полями:
     timestamp, user_id, version, request_text, response_text, latency_ms, token_count, success_flag
   • Логи складываются в файл или отправляются в Loki.

4. Настроить мониторинг метрик

   • Экспорт метрик в Prometheus: ab_requests_total{version="control/treatment"}, ab_latency_seconds_bucket{version=...}, ab_success_total{version=...}.
   • Grafana dashboard с двумя панелями (control vs treatment) для primary метрики.

5. Провести smoke‑тест

   • Отправить 10–20 тестовых запросов, проверить, что сплит работает и логи пишутся.

Ожидаемый результат этапа Запущенный API с двумя версиями, работающий сплит, логи, мониторинг.

Этап 3: Запуск эксперимента и сбор данных (2 недели + 1 час на запуск)

Действия

1. Запустить эксперимент

   • Направить реальный (или синтетический) трафик на балансировщик.
   • При синтетике: скрипт, который отправляет запросы с разными user_id каждые N секунд.

2. Ежедневно проверять

   • Нет ли дисбаланса в количестве запросов между группами (должно быть ≈50/50).
   • Нет ли технических ошибок (5xx, таймауты).
   • Не превышен ли порог ухудшения secondary метрик (например, latency > 200% от control).

3. Не «подглядывать» p-value ежедневно (peeking) — ждать конца эксперимента.

   • Можно смотреть только агрегированные метрики, не проводя тест.

4. Зафиксировать момент окончания (через 14 дней ровно). Остановить приём запросов или переключить весь трафик на победившую версию (только после анализа).

Ожидаемый результат этапа Собранный датасет из логов за 14 дней (минимум 1000 записей на группу).

Этап 4: Статистический анализ (2–4 часа)

Действия

1. Загрузить данные

   import pandas as pd
   df = pd.read_json('logs_ab_test.jsonl', lines=True)
   control = df[df['version'] == 'control']
   treatment = df[df['version'] == 'treatment']
   

2. Проверить assumption (предпосылки)

   • Нормальность распределения primary метрики (Shapiro‑Wilk или Q‑Q plot). Если нет — использовать непараметрический тест (Mann‑Whitney).
   • Однородность дисперсий (Levene test).

3. Выполнить тест

   from scipy.stats import ttest_ind, mannwhitneyu
   t_stat, p_value = ttest_ind(control['success_flag'], treatment['success_flag'], equal_var=False)
   # или
   u_stat, p_value = mannwhitneyu(control['success_flag'], treatment['success_flag'])
   

4. Рассчитать effect size

   • Cohen’s d, разница пропорций, 95% доверительный интервал.

5. Интерпретировать результат

   • Если p < 0.05: отвергаем H0, версия с лучшим средним — победитель.
   • Если p ≥ 0.05: нет статистически значимого различия.
   • Дополнительно: анализ secondary метрик, проверка на неоднородность эффекта (подгруппы).

6. Написать отчёт

   • Включить: гипотеза, дизайн, выборка, результаты теста, графики (boxplot, trend), выводы и рекомендации.

Ожидаемый результат этапа Отчёт «A/B Test Results Agent v1 vs v2» с p-value, эффектом и решением.

Этап 5: Принятие решения и документирование (1 час)

Действия

1. Принять решение

   • Внедрить treatment, если он значимо лучше.
   • Откатить, если хуже (или нет разницы).
   • Если treatment хуже по secondary метрике — не внедрять.

2. Зафиксировать выводы

   • Заполнить шаблон post‑experiment review: что сработало, что нет, какие уроки.

3. Обновить код агента (если принято внедрить treatment) и деплоить.

Ожидаемый результат этапа Решение о внедрении/откате, обновлённый код (опционально).

5. Критерии приемки (Definition of Done)

• Дизайн эксперимента задокументирован (гипотеза, метрика, sample size, длительность).
• Реализован стабильный сплит трафика 50/50 (на основе user_id).
• Логирование каждого запроса с версией, метриками latency/tokens/success.
• Мониторинг primary метрики в real‑time (Grafana).
• Эксперимент проведён непрерывно в течение 14 дней (или симуляция с запланированными запросами).
• Статистический тест выполнен корректно (с проверкой предпосылок).
• Получен p-value и effect size.
• Написан отчёт с выводами и рекомендациями.
• Решение о внедрении/откате принято и аргументировано.

6. Ожидаемый результат

Основной артефакт Отчёт об A/B тестировании агентов в формате Markdown/PDF, содержащий:

• Дизайн эксперимента (гипотеза, метрики, sample size).
• Графики сравнения (boxplot распределения метрики по группам, cumulative average).
• Результаты статистического теста (p-value, effect size, доверительный интервал).
• Заключение: какая версия победила и почему.

Дополнительные артефакты

• Код балансировщика и логирования.
• Dockerfile для двух версий агента.
• Логи эксперимента (JSONL).
• Prometheus/Grafana конфиги (опционально).

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: Если используется симуляция синтетическим трафиком, время сбора можно сократить до 1–2 часов, запустив скрипт в ускоренном режиме. Но для реалистичности рекомендуется 2 недели с реальным (или эмулированным) потоком.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я сформулировал чёткую гипотезу и выбрал primary метрику до начала эксперимента.
• Я проверил, что сплит трафика стабильный (один пользователь → одна версия).
• Я убедился, что выбранный размер выборки достаточен для обнаружения ожидаемого эффекта (power ≥ 0.8).
• Я настроил логирование всех запросов с метаданными (версия, latency, success).
• Я заранее определил критерии досрочной остановки эксперимента (например, если latency treatment > 3x control).
• Я не смотрел p-value до окончания эксперимента (или использовал sequential testing).
• Я проверил предпосылки статистического теста (нормальность, гомоскедастичность) и выбрал правильный тест.
• Я задокументировал все шаги и результаты в отчёте.
• Я принял обоснованное решение на основе статистики и бизнес‑контекста.