ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать A/B тест для RAG

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

Разработать и провести A/B эксперимент для оценки влияния модификации RAG пайплайна на качество ответов. В эксперименте 50% пользовательских запросов направляется на контрольную версию (baseline), а 50% — на экспериментальную версию (treatment). Эксперимент длится 2 недели, после чего проводится статистический анализ для выявления значимых различий по заданным метрикам. Ключевой результат: получить статистически значимый вывод о превосходстве или эквивалентности treatment версии по сравнению с control.

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

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

1. Создаём синтетический датасет запросов (например, 5000 вопросов по документации продукта) с известными ground truth ответами.
2. Разворачиваем control версию (использовать готовый open-source RAG, например, langchain_chatbot).
3. Модифицируем treatment: заменяем FAISS на Milvus с иным алгоритмом, добавляем CohereRerank.
4. Записываем ответы обеих версий в .csv с колонками: query_id, version, response, latency, ground_truth, rouge-l, faithfulness.
5. Эмулируем временные метки на 2 недели (равномерно распределённые).

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

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

Этап 1: Подготовка данных и определение метрик (2 дня)

Действия

1. Собрать/сгенерировать датасет из не менее 5000 пользовательских запросов (каждый с ground truth ответом).
   • Если нет реальных данных: использовать датасет RAG-QA (например, wikiQA), сгенерировать запросы через text-davinci-003.
2. Определить две метрики для сравнения:
   • Primary ROUGE-L (точность совпадения ответов).
   • Secondary: средняя латентность ответа (сек).
   • Дополнительно: Faithfulness (есть оценка галлюцинаций).
3. Реализовать функции вычисления метрик:

   def compute_rouge_l(reference, hypothesis) -> float:
       from rouge_score import rouge_scorer
       scorer = rouge_scorer.RougeScorer(['rougeL'])
       return scorer.score(reference, hypothesis)['rougeL'].fmeasure
   

4. Создать таблицу experiment_log для записи результатов:
   • id, query, version (control/treatment), response, latency, rouge_l, timestamp.

Ожидаемый результат этапа Датасет запросов, функции метрик, схема логирования.

Этап 2: Реализация A/B инфраструктуры (2 дня)

Действия

1. Разработать модуль router для направления каждого запроса случайным образом (без смещения):

   import random
   def assign_version():
       return "control" if random.random() < 0.5 else "treatment"
   

2. Реализовать обработчик запроса:
   • Получает запрос → фиксирует query_id → определяет версию → вызывает соответствующий RAG pipeline → логирует response, latency, version.
3. Интегрировать логирование в MLflow:
   • Запуск эксперимента rag_ab_test_01.
   • Логировать параметры версий (retriever, reranker, prompt).
   • Для каждого запроса: mlflow.log_metric только по окончании всего эксперимента (чтобы не замедлять).
4. Написать юнит-тесты для router (проверка 50/50, отсутствие детерминизма, корректность вызова пайплайнов).

Ожидаемый результат этапа Код A/B системы, готовый к развёртыванию, с доказанной корректностью распределения.

Этап 3: Проведение эксперимента (2 недели в симуляции — 0.5 дня)

Действия

1. Запустить скрипт run_experiment.py, который последовательно подаёт все запросы из датасета с «задержкой» (например, time.sleep(0.01) для имитации времени обработки).
2. Для каждого запроса записывать в CSV/MLflow метрики.
3. По окончании собрать полный лог.
4. Проверить визуально распределение запросов между версиями (должно быть ~50/50).

Ожидаемый результат этапа Лог эксперимента с 5000+ записей, каждая содержит version, rouge_l, latency.

Этап 4: Статистический анализ (1.5 дня)

Действия

1. Загрузить данные эксперимента в DataFrame.
2. Проверить нормальность распределения метрик (Shapiro-Wilk). Если не нормальное — использовать непараметрический тест Манна-Уитни.
3. Выполнить двухвыборочный t-test (или U-test) для первичной метрики rouge_l:

   from scipy import stats
   control = df[df['version']=='control']['rouge_l']
   treatment = df[df['version']=='treatment']['rouge_l']
   t_stat, p_value = stats.ttest_ind(control, treatment)
   

4. Вычислить effect size (Cohen's d).
5. Применить коррекцию Бонферрони, если анализируем несколько метрик (например, 2 метрики → α = 0.025).
6. Построить bootstrap-распределение разности средних (1000 итераций) для доверительного интервала 95%.
7. Визуализировать: boxplot, гистограммы, плотность.

Ожидаемый результат этапа Отчёт с p-value, effect size, доверительным интервалом, выводом о значимости различий.

Этап 5: Интерпретация и формирование вывода (1 день)

Действия

1. Если p-value < α (с учётом коррекции) → различие статистически значимо. Определить, какая версия лучше.
2. Если p-value ≥ α → нельзя отвергнуть нулевую гипотезу. Дополнительно проверить мощность теста (post-hoc power analysis).
3. Задокументировать возможные причины (размер выборки, дисперсия, смещение). Принять решение: оставить control, заменить на treatment, или продлить тест.
4. Подготовить итоговый отчёт (Markdown/PDF) с таблицами, графиками, выводами и рекомендациями.

Ожидаемый результат этапа Заключение о статистической значимости изменений, приложенный код, артефакты (p-value, доверительный интервал, графики).

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

• Разработан и задокументирован A/B тест с чётким разделением control/treatment (50/50).
• Эксперимент выполнен на наборе из не менее 5000 запросов (реальных или синтетических).
• Получен лог с полями: query_id, version, response, rouge_l, latency, timestamp.
• Проведён статистический тест (t-test или непараметрический) с коррекцией на множественность.
• Вычислены и представлены: p-value, effect size, 95% доверительный интервал разницы средних.
• Построены визуализации (boxplot, bootstrap distribution).
• Сделан вывод о значимости различий (или их отсутствии) и дана рекомендация.
• Код выложен в репозиторий с инструкцией по воспроизведению.
• Время выполнения эксперимента (симуляция) не превышает 1 час.
• Отчёт включает обсуждение возможных искажений (confounding factors).

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

• Файл ab_test_report.pdf с описанием дизайна, результатов статистических тестов и выводами.
• Репозиторий с кодом: router.py, run_experiment.py, analyse.py, config.yaml.
• Артефакты MLflow (если использовались) с логами метрик.
• Дополнительно: bootstrap_plot.png, boxplot_versions.png.

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

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

Примечание: в реальных условиях A/B тест длится 2 недели, но кодовая подготовка занимает ~5-6 дней. Для первого раза рекомендуется симуляция для отработки методологии.

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

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

• Я корректно настроил рандомизацию 50/50 и проверил её на тестовых данных.
• Я выбрал primary метрику до анализа, чтобы избежать p-value hacking.
• Я проверил предположения статистического теста (нормальность, равенство дисперсий).
• Я применил коррекцию на множественное сравнение, если используется вторичная метрика.
• Я убедился, что лог содержит достаточно информации для воспроизведения анализа (версии, метки времени, метрики).
• Я задокументировал все гиперпараметры treatment версии (модель, chunk size, prompt).
• Я не полагаюсь только на p-value, но и оценил effect size и доверительный интервал.
• Я протестировал воспроизводимость эксперимента на изолированном окружении (docker/conda).
• Я добавил обработку возможных аномалий (отсутствующие значения, выбросы).