Как вы проводите A/B тест метрик качества (не бизнес-метрик)?

Краткий тезис

A/B тест метрик качества — это сравнение двух версий оценочного пайплайна (eval pipeline), а не бизнес-показателей. Цель — проверить, что новая метрика (или способ её расчёта) лучше согласуется с человеческими суждениями, менее смещена и более стабильна. Ключевые метрики для такого теста: Cohen's Kappa (согласие с человеком), consistency (воспроизводимость) и bias (систематическое отклонение). Это критически важно для автоматизации оценки RAG-систем, когда мы заменяем дорогой ручной eval на автоматический.

1. Термин: A/B тест метрик качества

A/B тест (сплит-тест) — это эксперимент, в котором две группы (контрольная A и экспериментальная B) сравниваются по заранее определённым показателям. В контексте метрик качества мы сравниваем не две версии продукта, а два способа измерения.

Метрики качества (quality metrics) — это показатели, оценивающие, насколько хорошо работает система с точки зрения точности, полноты, релевантности и т.д. В RAG это, например, faithfulness (фактологическая точность), answer relevance (релевантность ответа), context precision (точность контекста]]).

Бизнес-метрики (business metrics) — это показатели, связанные с доходами, удержанием пользователей, конверсией. Например, DAU (Daily Active Users), retention rate, conversion rate.

Ключевое отличие: A/B тест метрик качества проверяет, насколько хорошо наш инструмент оценки (например, LLM-as-a-judge) измеряет то, что нужно. Мы не спрашиваем «какая версия продукта лучше?», а спрашиваем «какая версия eval-пайплайна точнее?».

2. Зачем проводить A/B тест метрик качества?

Основная причина — автоматизация оценки. Ручная оценка (human evaluation) точна, но дорога и медленна. Автоматические метрики (например, на основе LLM) быстры, но могут быть смещены или нестабильны. A/B тест позволяет:

• Валидировать новую метрику: убедиться, что она не хуже старой (или лучше).
• Выбрать лучший промпт для LLM-as-a-judge.
• Сравнить разные модели-оценщики: GPT-4 vs. Llama 3 vs. специализированная модель.
• Обнаружить систематические ошибки: например, что новая метрика занижает оценки для длинных ответов.

Без такого теста вы рискуете внедрить метрику, которая «шумит» или даёт ложные сигналы, что приведёт к неправильным решениям по улучшению RAG-системы.

3. Этапы проведения A/B теста метрик качества

3.1. Подготовка датасета с золотым стандартом

Золотой стандарт (gold standard) — это размеченный вручную датасет, где для каждого запроса известна «идеальная» оценка от человека-эксперта. Это эталон, с которым мы сравниваем автоматические метрики.

Требования к датасету

• Репрезентативность: запросы должны покрывать все типичные сценарии (простые, сложные, с неоднозначностями).
• Размер: минимум 100-200 примеров для статистической значимости.
• Независимость: каждый пример оценивается минимум двумя аннотаторами для расчёта inter-annotator agreement (согласия между аннотаторами).

Пример структуры датасета

3.2. Определение метрик сравнения

Мы сравниваем не сами метрики качества (они — объект теста), а их согласие с человеком. Основные метрики для A/B теста:

Cohen's Kappa — ключевая метрика. Она штрафует за случайные совпадения. Например, если метрика всегда ставит «5», а человек тоже часто ставит «5», Kappa будет низкой, потому что совпадения случайны.

3.3. Разделение на группы

Мы не делим пользователей, а делим примеры из датасета на две группы:

• Группа A (контроль): текущая версия eval-пайплайна (например, старая метрика или старый промпт).
• Группа B (эксперимент): новая версия (например, новая метрика или новый промпт).

Важно: каждый пример оценивается обеими группами, чтобы избежать влияния состава выборки. Это парный тест (paired test).

3.4. Запуск и сбор данных

Запускаем оба пайплайна на одном и том же датасете. Получаем две таблицы оценок:

Группа A (старая метрика):

Группа B (новая метрика):

3.5. Статистический анализ

Для каждой группы считаем метрики сравнения (Cohen's Kappa, bias, consistency). Затем проверяем, значимо ли различие.

Инструменты

• scipy.stats для расчёта Kappa и корреляций.
• Bootstrap для доверительных интервалов.

Пример кода на Python

import numpy as np
from sklearn.metrics import cohen_kappa_score
from scipy.stats import bootstrap

# Оценки человека и двух метрик
human = [5, 5, 3, 4, 2, 5, 4, 3]
metric_a = [4, 5, 2, 4, 2, 5, 4, 3]
metric_b = [5, 5, 3, 4, 3, 5, 4, 4]

# Cohen's Kappa
kappa_a = cohen_kappa_score(human, metric_a, weights='quadratic')
kappa_b = cohen_kappa_score(human, metric_b, weights='quadratic')
print(f"Kappa A: {kappa_a:.3f}, Kappa B: {kappa_b:.3f}")

# Bootstrap для доверительных интервалов
def kappa_func(data):
    h, m = data
    return cohen_kappa_score(h, m, weights='quadratic')

ci_a = bootstrap((human, metric_a), kappa_func, n_resamples=1000, confidence_level=0.95)
ci_b = bootstrap((human, metric_b), kappa_func, n_resamples=1000, confidence_level=0.95)
print(f"95% CI A: {ci_a.confidence_interval}")
print(f"95% CI B: {ci_b.confidence_interval}")

Интерпретация

• Если доверительные интервалы не пересекаются — различие статистически значимо.
• Если пересекаются — нужен более мощный тест (например, permutation test).

3.6. Принятие решения

Выбираем метрику с:

• Более высоким Cohen's Kappa (лучшее согласие с человеком).
• Bias, близким к нулю (нет систематического смещения).
• Низкой variability (стабильность при повторных замерах).

Пример решения

4. Типичные ошибки в A/B тесте метрик качества

4.1. Использование непарного теста

Если вы сравниваете две метрики на разных наборах данных, вы не можете контролировать влияние состава выборки. Всегда используйте один и тот же датасет для обеих групп.

4.2. Игнорирование случайного согласия

Cohen's Kappa учитывает, что часть совпадений может быть случайной. Простая accuracy может быть высокой, даже если метрика «угадывает» (например, ставит всегда среднюю оценку).

4.3. Недостаточный размер выборки

Для статистической значимости нужно минимум 100-200 примеров. Меньше — высок риск ложноположительного результата.

4.4. Смещение в золотом стандарте

Если аннотаторы не согласны друг с другом (низкий inter-annotator agreement), то и метрика не сможет с ними согласиться. Проверяйте согласие между людьми перед началом теста.

5. Расширенные метрики для A/B теста

5.1. Matthews Correlation Coefficient (MCC)

Для бинарных метрик (правильно/неправильно) MCC лучше, чем accuracy, так как учитывает все четыре категории confusion matrix.

Формула

MCC = (TP*TN - FP*FN) / sqrt((TP+FP)*(TP+FN)*(TN+FP)*(TN+FN))

5.2. Fleiss' Kappa

Обобщение Cohen's Kappa для более чем двух оценщиков. Полезно, если у вас несколько аннотаторов.

5.3. Conditional Kappa

Kappa, рассчитанная отдельно для разных подгрупп (например, для коротких и длинных ответов). Позволяет обнаружить, где метрика работает хуже.

6. Инструменты для A/B теста метрик качества

7. Пет-проект для закрепления

Задача Создать A/B тест для сравнения двух промптов LLM-as-a-judge для метрики faithfulness (фактологическая точность ответа RAG-системы).

Инструменты

• Python, pandas, scikit-learn, scipy
• OpenAI API (или локальная LLM)
• Датасет с ручными оценками (можно взять из RAGAS или создать свой)

Шаги:

1. Соберите датасет: 100 пар (запрос, контекст, ответ) с ручными оценками faithfulness (1-5).
2. Определите две версии промпта: версия A (краткий промпт) и версия B (подробный промпт с примерами).
3. Запустите обе версии на датасете, получите оценки.
4. Рассчитайте Cohen's Kappa для каждой версии против человека.
5. Проверьте bias: средняя разница между оценкой метрики и человека.
6. Проверьте consistency: запустите каждую версию 3 раза на одном и том же примере, посчитайте std.
7. Сделайте вывод: какая версия лучше?

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

• Таблица с метриками для обеих версий.
• График распределения bias (гистограмма разниц).
• Решение: выбрать версию B, если её Kappa > 0.7 и bias < 0.2.

8. Связь с другими вопросами

9. Навигация

• Предыдущий: 348
• Следующий: 350
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 348
• Следующий: 350
• Индекс: 00. Индекс разборов