Как вы A/B тестируете две версии промпта в production?

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

тестирование промптов|A/B тестирование промптов]] в production — это контролируемый эксперимент, в котором две версии системного промпта (контрольная и экспериментальная) случайным образом назначаются разным группам пользователей. Ключевые элементы: стабильное разделение трафика по user_id, сбор онлайн-метрик (latency, cost, user feedback) и офлайн-метрик (faithfulness, answer relevance через RAGAS), минимальная длительность в 1 неделю для накопления статистической мощности, и применение t-test или bootstrap с порогом p-value < 0.05 для принятия решения о rollout.

1. Зачем A/B тестировать промпты?

Промпты — это субъективный и высокочувствительный компонент LLM-системы. Даже небольшое изменение формулировки может изменить тон, точность, стиль ответа, а значит — повлиять на бизнес-метрики: конверсию, удержание пользователей, стоимость инференса. Без A/B теста невозможно объективно оценить, какая версия лучше, так как:

• Субъективность оценки: разработчик может предпочитать один стиль, а пользователи — другой.
• Неявные эффекты: новый промпт может улучшить faithfulness, но увеличить latency из-за более длинного контекста.
• Бизнес-влияние: изменение промпта может незаметно снизить CTR или retention, что проявится только на большой выборке.

A/B тест даёт статистически обоснованный ответ: «новая версия значимо лучше (или хуже) по ключевым метрикам».

2. Дизайн A/B эксперимента: разделение трафика

Основа A/B теста — случайное назначение пользователей в группы. Для LLM-системы важно, чтобы один и тот же пользователь всегда видел одну и ту же версию промпта (стабильность опыта). Поэтому используют:

• Разделение по user_id (hash-based): берётся хеш от user_id (или session_id), и по модулю 100 (или другого числа) пользователь попадает в группу A или B. Это гарантирует, что при повторных визитах он остаётся в той же группе.
• Случайное назначение при первом запросе: если user_id нет, можно генерировать случайное число при первой сессии и сохранять в cookie/сессии.

Важно: не использовать случайное назначение на каждый запрос — это приведёт к смешению эффектов и нарушению независимости наблюдений.

Рекомендуется хеш от user_id с фиксированным seed'ом для воспроизводимости.

3. Метрики для сравнения промптов

Метрики делятся на онлайн (собираются в production) и офлайн (вычисляются на семпле с помощью LLM-асессора).

Онлайн-метрики

• Latency (время ответа): среднее, p95, p99. Длинный промпт может увеличить время генерации.
• Cost (стоимость): количество токенов на запрос (input + output). Более подробный промпт дороже.
• User feedback: лайки/дизлайки, рейтинг ответа, CTR на ссылки.
• Retention: возвращаемость пользователей (daily/weekly active users).
• Task success rate: доля запросов, где пользователь достиг цели (например, оформление заказа).

Офлайн-метрики (на семпле)

• Faithfulness (фактологическая точность): насколько ответ соответствует предоставленным документам (если RAG). Измеряется с помощью RAGAS или LLM-as-judge.
• Answer relevance: релевантность ответа запросу.
• Toxicity / safety: уровень токсичности или небезопасного контента.
• Conciseness: лаконичность (соотношение полезной информации к длине).

Пример: для RAG-системы можно взять 500 случайных запросов из production, прогнать через обе версии промпта, и посчитать faithfulness через RAGAS. Это даст офлайн-метрику, которая дополнит онлайн-данные.

4. Минимальная длительность и размер выборки

A/B тест должен длиться достаточно долго, чтобы:

• Накопить статистическую мощность (power > 0.8) для обнаружения эффекта заданного размера.
• Учесть недельные циклы (пользователи ведут себя по-разному в будни и выходные).
• Избежать novelty effect (пользователи могут реагировать на новизну, а не на качество).

Минимальная длительность: 1 неделя (7 полных дней). Для высоконагруженных систем может хватить 3-5 дней, если метрики стабильны.

Размер выборки зависит от ожидаемого эффекта. Для малых эффектов (например, +1% в CTR) нужно больше пользователей. Формула для t-test:

n = (Z_alpha/2 + Z_beta)^2 * (2 * sigma^2) / delta^2

где delta — минимальный обнаруживаемый эффект, sigma — стандартное отклонение метрики. На практике используют power analysis с помощью библиотек (statsmodels, scipy).

Пример: если baseline CTR = 5%, ожидаемый lift = 10% (до 5.5%), sigma ≈ 0.22, alpha=0.05, power=0.8, то n ≈ 70 000 пользователей на группу.

5. Статистическая значимость

После сбора данных нужно проверить, что разница между группами не случайна.

• t-test (Стьюдента): для нормально распределённых метрик (latency, cost). Сравнивает средние двух независимых выборок.
• Bootstrap: непараметрический метод, не требует нормальности. Многократно пересэмплирует данные и строит доверительный интервал для разницы средних.
• p-value: порог обычно 0.05. Если p < 0.05, разница статистически значима.
• Multiple testing correction: если метрик много (latency, cost, feedback, faithfulness), нужно применять Bonferroni correction или Benjamini-Hochberg, чтобы избежать ложных срабатываний.

Пример кода (bootstrap):

import numpy as np

def bootstrap_diff(control, treatment, n_iter=10000):
    diffs = []
    for _ in range(n_iter):
        c_sample = np.random.choice(control, size=len(control), replace=True)
        t_sample = np.random.choice(treatment, size=len(treatment), replace=True)
        diffs.append(np.mean(t_sample) - np.mean(c_sample))
    ci_low = np.percentile(diffs, 2.5)
    ci_high = np.percentile(diffs, 97.5)
    return ci_low, ci_high

# Пример: метрика faithfulness (0-1)
control = [0.85, 0.90, 0.88, ...]
treatment = [0.92, 0.91, 0.89, ...]
ci = bootstrap_diff(control, treatment)
if ci[0] > 0:
    print("Treatment significantly better")

6. Практический пайплайн A/B теста

1. Формулировка гипотезы: «Новый промпт повысит faithfulness на 5% без увеличения latency».
2. Дизайн: выбрать метрики, длительность, размер выборки.
3. Имплементация: использовать feature flag (например, LaunchDarkly) для переключения промпта по user_id.
4. Запуск: начать с малого трафика (1-5%), чтобы проверить отсутствие багов.
5. Мониторинг: отслеживать метрики в реальном времени (дашборд), обратить внимание на аномалии.
6. Анализ: после накопления данных — t-test/bootstrap, проверка на multiple testing.
7. Решение: если значимое улучшение — rollout на 100% (постепенно, 25% -> 50% -> 100%). Если ухудшение — откат.
8. Очистка: старую версию промпта удаляют через 2 недели, чтобы избежать случайного использования.

7. Пример кода: симуляция A/B теста

import numpy as np
from scipy import stats

# Симуляция данных: faithfulness (0-1) для двух групп
np.random.seed(42)
n = 1000
control = np.random.beta(10, 2, n)  # среднее ~0.83
treatment = np.random.beta(12, 2, n)  # среднее ~0.86

# t-test
t_stat, p_value = stats.ttest_ind(treatment, control)
print(f"t-statistic: {t_stat:.3f}, p-value: {p_value:.4f}")

# Bootstrap
diffs = []
for _ in range(10000):
    c_sample = np.random.choice(control, size=n, replace=True)
    t_sample = np.random.choice(treatment, size=n, replace=True)
    diffs.append(np.mean(t_sample) - np.mean(c_sample))
ci = np.percentile(diffs, [2.5, 97.5])
print(f"95% CI for difference: [{ci[0]:.4f}, {ci[1]:.4f}]")

if p_value < 0.05:
    print("Significant improvement")
else:
    print("No significant difference")

8. Подводные камни

• Interference (интерференция): если пользователи взаимодействуют друг с другом (например, чат-бот для команды), группы могут влиять друг на друга. Решение: изолировать по workspace/tenant.
• Novelty effect: пользователи могут реагировать на новизну, а не на качество. Решение: продлить тест до 2-3 недель или использовать time-series analysis.
• Drift (смещение): со временем распределение запросов может измениться. Решение: использовать CUPED (контрольные переменные) для снижения дисперсии.
• Simpson's paradox: агрегированные метрики могут показывать обратный эффект по сравнению с сегментами. Решение: стратифицировать анализ по важным когортам (тип запроса, устройство).
• Multiple testing: если проверять 20 метрик, одна может оказаться значимой случайно. Решение: correction (Bonferroni, FDR).

9. A/B тестирование в контексте RAG и Agentic RAG

В RAG-системе промпт влияет на два этапа: retrieval (промпт для переформулировки запроса) и generation (промпт для LLM). A/B тест может быть направлен на:

• Промпт для query rewriting: влияет на качество поиска. Метрики: recall@k, MRR (офлайн), user feedback (онлайн).
• Промпт для генерации ответа: влияет на faithfulness, стиль, длину. Метрики: faithfulness (RAGAS), latency, cost.
• Промпт для агента (Agentic RAG): агент может делать несколько шагов (поиск, вызов API). Промпт влияет на количество шагов, успешность выполнения задачи. Метрики: task success rate, number of tool calls, cost.

Особенность: в Agentic RAG промпт может содержать инструкции по выбору инструментов. A/B тест должен учитывать, что агент может вести себя недетерминированно (разные траектории). Поэтому метрики собираются на уровне сессии, а не отдельного запроса.

10. Инструменты и платформы

• Feature flag системы: LaunchDarkly, Split.io, Flagsmith — позволяют управлять rollout и A/B тестами без деплоя.
• Аналитические платформы: PostHog, Amplitude, Mixpanel — встроенные A/B тесты с дашбордами.
• ML-инструменты: MLflow (эксперименты), Evidently (мониторинг дрифта), RAGAS (офлайн-метрики).
• Статистические библиотеки: scipy.stats, statsmodels, pingouin.

Рекомендация: для production использовать внутреннюю платформу A/B тестирования, если она есть, или связку LaunchDarkly + PostHog + собственный скрипт анализа.

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

Задача: A/B тестирование промпта для суммаризации диалогов поддержки. Есть две версии промпта: старая (контроль) и новая (эксперимент), которая требует более краткого и структурированного ответа.

Инструменты: Python, scipy, numpy, RAGAS (или openai для оценки), синтетические данные.

Шаги:

1. Сгенерировать 2000 синтетических диалогов (например, на основе датасета customer support).
2. Написать две версии промпта (control и treatment).
3. Для каждого диалога получить ответ от LLM (через API) с каждым промптом.
4. Собрать метрики: latency (время ответа), cost (токены), faithfulness (через RAGAS), conciseness (длина ответа).
5. Разделить данные на две группы (по user_id, симулировать 1000 пользователей в каждой).
6. Провести t-test и bootstrap для каждой метрики.
7. Визуализировать распределения и доверительные интервалы.

Ожидаемый результат: отчёт с таблицей метрик, p-value, решением (какой промпт лучше). Например: treatment значимо улучшает conciseness (p<0.001) без потери faithfulness (p=0.23).

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

Навигация

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