Blind A/B eval двух промтов

Тебе нужно сравнить prompt v1 vs prompt v2 по метрике {{metric}} на {{n_cases}} кейсах. «Чувствую что v2 лучше» не годится — нужен blind A/B с статистикой.

1. Зачем blind

Если оценщик (ты, judge-модель, человек) знает какой промт — оценки смещаются:

• Подсознательно подыгрываешь «новому»
• Замечаешь только то что подтверждает гипотезу
• Считаешь спорные кейсы в свою пользу

Blind = оценщик не знает какая версия выдала каждый ответ. Это обязательное условие.

2. Дизайн эксперимента

Шаг 1: фиксируй всё кроме промта

• Модель — одна и та же версия (sonnet-X.Y или opus-X.Y)
• Температура — одна и та же
• Tools — один и тот же набор
• Контекст / system prefix — одинаковый
• Dataset кейсов — заморожен

Если меняешь модель И промт — это два эксперимента, не один.

Шаг 2: прогон

Для каждого кейса c:

• Запусти v1 → ответ A1
• Запусти v2 → ответ A2
• (Опционально) Запусти v1 ещё раз → A1' чтобы оценить шум модели

Сохрани результаты в одну таблицу с анонимными метками:

case_id  variant_id  answer_text  tokens  latency_ms  cost_usd
c001     X           "..."        420     1800        0.012
c001     Y           "..."        510     2100        0.015
c002     X           "..."        380     1700        0.011
c002     Y           "..."        450     1900        0.013

variant_id (X/Y) — рандомизированный mapping к v1/v2, который оценщик не знает. Mapping живёт в отдельном файле, который смотрит только координатор после оценки.

Шаг 3: оценка

Каждую пару (c, X-answer, Y-answer) показываем judge'у в рандомизированном порядке (иногда X слева, иногда справа):

Case: ...
Answer A: ...
Answer B: ...

По метрике "{{metric}}" — какой ответ лучше?
- A значительно лучше
- A немного лучше
- одинаково
- B немного лучше
- B значительно лучше
- + 1-2 строки обоснования

Шаг 4: распознавание

После всех оценок — раскрытие mapping и подсчёт.

3. Judge: Claude vs человек

Гибрид:

• 80-100% кейсов оценивает Claude-judge
• 10-20% случайных + ВСЕ спорные («одинаково» или близкие к одинаково) — человек
• Сравни — есть ли расхождение

Калибровка Claude-judge

Перед использованием:

• 50 кейсов с парами ответов, человеком отмечены winner
• Claude-judge на тех же 50
• Считай Cohen's kappa или согласие в %
• Допустимо: согласие ≥ 0.8 (со «значительно» и «немного» считай за одну категорию направления)
• Если ниже — переписывай судья-промт, не используй

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

Сравнение двух пропорций «v2 лучше» vs «v1 лучше». Минимум:

• Используй knock-out: только кейсы где judge сказал «A лучше» или «B лучше», игнорируй «одинаково»
• Считай долю побед v2: p = wins_v2 / (wins_v1 + wins_v2)
• Для бинарного теста — нужно ≥ 30 «решающих» кейсов, иначе любая разница в шуме
• Простой sign-test (или ширшая формула 2-proportion z-test) даёт p-value
• Принимай v2 только если p < 0.05 И эффект практически значим (например, ≥ 10 п.п.)

Готовая формула на пальцах:

N = wins_v1 + wins_v2
если N < 30: «недостаточно данных, добавь кейсов»
если p_v2 ≥ 0.60 и N ≥ 30: «v2 уверенно лучше»
если 0.45 ≤ p_v2 ≤ 0.55: «разницы нет»
иначе: «v1 лучше» / «нужно больше данных»

Не путай статистическую значимость с практической. p < 0.05 при разнице 51% vs 49% — это статистика говорит «есть тренд», но релизить v2 ради 2% не стоит.

5. Что ещё мерить кроме win-rate

• latency_diff — p50, p95 (v2 может быть «лучше», но в 2 раза медленнее)
• tokens_diff / cost_diff — экономика
• rubric breakdown — где конкретно v2 лучше (полнота? стиль? точность?), а где хуже
• flake rate per variant — стабильность

Решение «релизим v2» — это компромисс по 5 осям, не только по win-rate.

6. Анти-паттерны

• ❌ Cherry-picking 5 примеров где v2 круче — это анекдот, не эксперимент
• ❌ Оценщик видит метку «v1»/«v2» — bias гарантирован
• ❌ Одинаковый порядок A/B во всех кейсах — judge ловит паттерн
• ❌ Менять промт И модель одновременно — не понять что повлияло
• ❌ Прогон один раз — без замера шума модели не отличить улучшение от везения
• ❌ Игнорировать «одинаково» при подсчёте win-rate (это нормально, но обязательно репорти их долю)
• ❌ Маленькая выборка (< 30 решающих) и громкий вывод
• ❌ Judge-промт меняется между прогонами — нельзя сравнивать
• ❌ Релиз на основе p-value без проверки экономики (latency / cost)
• ❌ После раскрытия — «давайте перепрогоним только сомнительные» — это уже не blind

7. Шаблон отчёта

# A/B eval: prompt v1 vs v2

## Setup
- Model: ...
- Dataset: <hash>, N кейсов: {{n_cases}}
- Judge: claude-X.Y / human / hybrid
- Judge prompt: <link>

## Win-rate (knock-out)
- v2 wins: K
- v1 wins: M
- Tie: T
- p_v2 = K/(K+M) = ...
- p-value = ...

## Other metrics
- latency p50: v1 = ..., v2 = ...
- tokens: ...
- cost: ...

## Качественный разбор
- v2 лучше в: ...
- v2 хуже в: ...
- 3 спорных кейса (id, обоснование)

## Решение
- Релиз v2 / отказ / нужно ещё данных
- Обоснование

На выходе

• Mapping-файл (анонимные метки)
• Таблица ответов + таблица оценок
• Калибровка judge (если Claude-judge)
• Отчёт по шаблону с явным «решение + обоснование»