A/B tests and statistical significance

Модель A показала 87% на вашем датасете, модель B — 84%. B хуже? Посчитаем. Стандартная ошибка доли при n = 100 кейсов:

SEM = sqrt(p(1−p)/n) = sqrt(0.87 × 0.13 / 100) ≈ 0.034
95% CI: 0.87 ± 1.96 × 0.034 = [0.80; 0.94]

Интервалы A [0.80; 0.94] и B [0.77; 0.91] перекрываются почти целиком: разница в 3 п.п. на 100 кейсах неотличима от шума. Именно это — центральный тезис работы Anthropic «Adding Error Bars to Evals» (Miller, 2024): eval score — это выборочное среднее по вопросам, случайная величина, и репортовать её без стандартной ошибки — статистическая небрежность, из-за которой команды «улучшают» и «ухудшают» системы внутри полосы шума.

Откуда берётся дисперсия. Первый источник — выбор вопросов: ваш датасет — выборка из бесконечной популяции возможных входов, и на другой выборке число было бы другим; это главный член, и он есть даже при полностью детерминированной модели. Второй — стохастика генерации: при temperature > 0 повторный прогон того же набора даёт другой результат. Третий — нестабильность judge: его вердикты тоже флуктуируют. Минимальная гигиена отчёта: рядом с каждым числом — n, SEM и доверительный интервал; рядом с каждым сравнением — оценка разности с её интервалом, а не два голых процента.

Ключевое преимущество эвалов перед классическими A/B на пользователях: обе системы можно прогнать на одних и тех же вопросах. Парный дизайн вычитает общую сложность вопросов, и дисперсия разности резко падает — различия детектируются на выборках в разы меньших, чем в непарном сравнении.

Для бинарных исходов парный критерий — тест McNemar. Считаются только расхождения: b — кейсы, где A прошла, а B нет; c — где B прошла, а A нет (совпадающие исходы не информативны):

χ² = (b − c)² / (b + c)

При χ² > 3.84 различие значимо на уровне 0.05. Если b + c < 25, используйте точный биномиальный тест вместо χ²-аппроксимации. Интуиция прозрачна: если из 20 расхождений 15 в пользу A — это сигнал; если 11 против 9 — монетка.

Универсальная альтернатива — бутстрап: 10 000 раз ресэмплируйте кейсы с возвращением, на каждом ресэмпле считайте разность метрик A и B; перцентили 2.5 и 97.5 полученного распределения — это 95% CI разности. Если ноль вне интервала — различие значимо. Бутстрап не требует предположений о распределении и работает для любых метрик — среднего балла judge, латентности, $/задачу, — поэтому это разумный дефолт для eval-репортов. Десять строк кода на numpy, секунды вычислений.

Обратная задача: сколько кейсов нужно, чтобы заметить различие? Грубая формула для сравнения двух долей: n ≈ 16 · p(1−p) / δ², где δ — минимальная разница, которую хотите ловить (при α = 0.05 и мощности 80%). Отличить 85% от 90% (δ = 0.05): n ≈ 16 · 0.875 · 0.125 / 0.0025 ≈ 700 кейсов на группу в непарном дизайне. Парный дизайн сокращает требование в разы (насколько — зависит от корреляции исходов), но порядок величин отрезвляет: golden set из 100 кейсов надёжно ловит только крупные регрессии, в 5–10 п.п. Это нормально для CI-гейта, но «модель B лучше на 2 п.п.» по такому набору — не вывод, а гипотеза, требующая большего сета.

Вторая ловушка — множественные сравнения. Вы смотрите pass rate по 20 сегментам: при пороге p < 0.05 один «значимый» сегмент ожидается чисто случайно. Поправка Бонферрони — делить порог на число сравнений (0.05/20 = 0.0025) — консервативна, но честна. Правило попроще: сегментные различия из разведочного анализа — это гипотезы; подтверждайте их на свежих данных, а не тем же прогоном.

Третья — p-hacking собственными руками: перепрогонять флейкующий эвал, «пока не позеленеет», выбирать из пяти прогонов лучший, останавливать сбор данных при достижении нужного p. Всё это законные с виду действия, инфлирующие ложные открытия. Дисциплина: план анализа до прогона (метрика, критерий, порог, n) и фиксированное число прогонов.

Провайдер выпустил новую модель, она дешевле и «по бенчмаркам лучше». Процедура миграции, собирающая весь курс воедино. Шаг 1 — offline: полный golden set, парный дизайн, бутстрап CI разности, McNemar по бинарным исходам, разбивка по сегментам с поправкой на множественность. Отдельно — ручной разбор перевернувшихся кейсов: новые fail важнее среднего, потому что это конкретные сценарии, которые вы сломаете пользователям. Шаг 2 — guardrail-метрики, которые не входят в pass rate: латентность (p50/p95), стоимость на запрос, refusal rate (доля отказов отвечать), длина ответов. Последняя коварна: новая модель может «улучшить» judge-скоры чистой многословностью — вспомните verbosity bias.

Шаг 3 — канарейка: 5–10% живого трафика на новую модель, онлайн-скоринг обоих плеч калиброванным judge, сравнение операционных метрик, автоматический откат при деградации. Offline-эвал не видит распределения реальных входов сегодняшнего дня — канарейка закрывает этот разрыв. Шаг 4 — полный rollout с сохранением мониторинга.

Два железных правила. Не меняйте модель и промпт одновременно: если качество изменилось, вы не узнаете, что именно сработало; мигрируйте на старом промпте, потом адаптируйте промпт отдельным изменением через тот же контур. И держите возможность отката горячей: пиновка версии модели в конфиге, а не «latest», — иначе провайдер сделает rollout за вас, без вашего эвала.