Как делать A/B тестирование промптов в production?

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

тестирование промптов|A/B тестирование промптов]] в production — это контролируемый эксперимент, в котором две или более версии промпта одновременно показываются разным сегментам пользователей, чтобы объективно сравнить их по бизнес-метрикам (качество ответа, задержка, стоимость, пользовательская обратная связь). Ключевые элементы: стабильная сегментация трафика (обычно по хэшу user_id), мониторинг метрик в реальном времени и статистический анализ (t-test или bootstrap) для выявления значимых различий. Победившая версия раскатывается постепенно на весь трафик.

1. Зачем нужно A/B тестирование промптов

Промпты — это программный интерфейс к LLM. Каждое изменение (добавление примера, изменение инструкции, перестановка контекста) может непредсказуемо повлиять на поведение модели.

• Проблема «На глаз» нельзя оценить, стал ли ответ лучше, потому что LLM стохастична, а восприятие качества субъективно.
• Решение A/B тест — объективный эксперимент, где одна группа пользователей получает старый промпт (control), другая — новый (treatment), и мы сравниваем метрики.

Термин A/B тестирование (A/B testing) — рандомизированный эксперимент с двумя (или более) вариантами, в котором фиксируется различие только по одному фактору — промпту.

2. Сегментация (разделение трафика)

Чтобы результаты были чистыми, одного и того же пользователя нельзя переключать между версиями каждый запрос. Нужна стабильная сегментация.

2.1 Способы сегментации

Рекомендация хэш по user_id (или session_id для неавторизованных). Это даёт sticky assignment — пользователь всегда видит ту же версию.

import hashlib

def assign_variant(user_id: str, variants: list = ["control", "treatment"]) -> str:
    hash_int = int(hashlib.md5(user_id.encode()).hexdigest(), 16)
    bucket = hash_int % 100
    # 50% control, 50% treatment
    if bucket < 50:
        return variants[0]
    else:
        return variants[1]

3. Варианты промптов (Control vs Treatment)

В простейшем случае — две версии. Но может быть несколько (A/B/C), если нужно сравнить несколько идей.

• Control (v1): текущий production-промпт.
• Treatment (v2, v3 …): изменённые версии (добавлен шаблон ответа, пример, инструкция быть кратким и т.п.).

Важно: менять только одну переменную, иначе вы не поймёте, что именно повлияло на метрику.

4. Метрики: что измерять

Без метрик A/B тест бессмыслен. Делим метрики на онлайн (производственные) и оффлайн (автоматические оценки без пользователя).

4.1 Основные метрики

Пример: для чат-бота поддержки — основная метрика доля успешных решений (success rate). Для генеративного поиска — faithfulness и click-through rate на найденные документы.

4.2 Инструменты сбора

• Логирование: каждое поколение LLM пишется в БД (ClickHouse, BigQuery) с variant, user_id, metrics.
• Платформы LangSmith, MLflow, Weights & Biases позволяют настроить трекинг.

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

Нельзя просто сравнить средние — нужно убедиться, что разница не случайна.

5.1 Гипотеза

• H0 (нулевая): метрика для control и treatment не отличается.
• H1 (альтернативная): разница есть.

5.2 Методы

5.3 Размер выборки

• Длительность минимум 1-2 недели (чтобы покрыть недельные циклы).
• Количество пользователей зависит от размера эффекта. Используйте power analysis (например, statsmodels).
  • Обычно: несколько тысяч пользователей на вариант для малых эффектов (1-5% улучшения).

Пример bootstrap на Python

import numpy as np

def bootstrap_diff(control, treatment, n_bootstrap=10000):
    # разница средних
    observed_diff = np.mean(treatment) - np.mean(control)
    # объединённая выборка
    combined = np.concatenate([control, treatment])
    n_c, n_t = len(control), len(treatment)
    boot_diffs = []
    for _ in range(n_bootstrap):
        sample_c = np.random.choice(combined, size=n_c, replace=True)
        sample_t = np.random.choice(combined, size=n_t, replace=True)
        boot_diffs.append(np.mean(sample_t) - np.mean(sample_c))
    # 95% доверительный интервал
    ci_low, ci_high = np.percentile(boot_diffs, [2.5, 97.5])
    return observed_diff, (ci_low, ci_high)

Если 0 не входит в 95% CI → разница статистически значима при α=0.05.

5.4 Множественное тестирование

Если сравниваете несколько вариантов (v2, v3) с control, применяйте поправку Бонферрони или Benjamini-Hochberg.

6. Принятие решения и Rollout

6.1 Критерии победы

• Статистическая значимость (p-value < 0.05 или 0 не входит в 95% CI).
• Практическая значимость (эффект > минимального полезного эффекта, например, +2% success rate).
• Отсутствие ухудшения по другим ключевым метрикам (например, faithfulness не упала).

6.2 Постепенная раскатка

1. Shadow mode – новый промпт работает параллельно, но не влияет на ответ (только мониторинг метрик, нет пользователей).
2. Canary (5-10% трафика) – небольшой процент, следим за аномалиями.
3. Gradual rollout – увеличиваем долю победившего варианта (20%, 50%, 100%).
4. Full rollout – 100% трафика на новый промпт.

При обнаружении регрессии — автоматический откат на control.

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

• Интерференция пользователи из разных вариантов могут влиять друг на друга (например, контент создаётся одним вариантом, потребляется другим). Решение: сегментировать по пользователю, а не запросу.
• Novelty effect в начале пользователь может реагировать на новый формат лучше просто из-за новизны. Ждите минимум неделю.
• Day-of-week effect запуск в пятницу может дать искажение из-за выходных. Синхронизируйте время запуска.
• Confounding если одновременно меняется что-то ещё (другая модель, кэш), разницу не приписать промпту. Изолируйте эксперимент.
• Недостаточная статистическая мощность запуск на малой выборке ведёт к ложноотрицательным результатам.

8. Пример полного флоу

# 1. Определить вариант
variant = assign_variant(user_id)

# 2. Сформировать промпт
if variant == "control":
    prompt = build_prompt_v1(query, context)
else:
    prompt = build_prompt_v2(query, context)

# 3. Запросить LLM
start = time.time()
answer = llm.generate(prompt)
latency = time.time() - start

# 4. Посчитать токены
cost = estimate_cost(prompt, answer)

# 5. Оценить faithfulness (в отдельном пайплайне)
faithfulness = evaluate_faithfulness(answer, context)

# 6. Сохранить лог
log_to_db(user_id, variant, query, answer, latency, cost, faithfulness)

# 7. Еженедельно запустить статистику
results = run_experiment_analysis()
if results.significant and results.effect > threshold:
    rollout_treatment()

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

Задача A/B тест двух версий промпта для генерации краткого содержания статьи (summary) в новостном дайджесте.

Инструменты Python, LangChain, FastAPI (для эмуляции сервера), SQLite (логи), bootstrap (scipy для статистики).

Шаги:

1. Создайте функцию assign_variant(user_id), которая хэширует id и возвращает "v1" или "v2".
2. Напишите два промпта: v1 — просто "Суммируй статью", v2 — "Суммируй в 2-3 предложениях, выдели ключевые цифры".
3. Сымитируйте 1000 пользователей (можно сгенерировать случайные user_id).
4. Для каждого пользователя сгенерируйте запрос на сумму (например, случайная статья из датасета CNN/DailyMail).
5. Запишите в БД: user_id, variant, время ответа, количество токенов, оценка faithfulness (можно использовать LLM-as-judge GPT-4).
6. Сравните метрики между v1 и v2: bootstrap для latency и faithfulness.
7. Сделайте вывод: какой вариант значимо лучше по какой метрике.

Ожидаемый результат Вы увидите, что v2 может дать меньшую latency и больший faithfulness, но стоит проверить, не потерялась ли важная информация (оценить recall ключевых фактов).

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

Навигация

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