Как доверительный интервал для LLM меняет выбор модели

Переходить на новую LLM только потому, что она набрала 78% вместо 74%, опасно. Эти четыре процентных пункта могут описывать реальный выигрыш, а могут быть обычным шумом конкретного тестового набора. Пока команда не построила интервал для разницы, число в таблице отвечает лишь на один вопрос: кто оказался впереди в этом прогоне.

В оценке моделей я чаще вижу не плохую статистику, а ее отсутствие. Команда бережно собирает сто примеров, запускает несколько кандидатов, выбирает верхнюю строку и начинает миграцию. Через месяц выясняется, что преимущество исчезает на другом наборе, в другом языке или при реальной нагрузке. Доверительный интервал не делает решение автоматическим, но он отделяет наблюдаемую разницу от решения, которое можно защищать перед продуктом, безопасностью и финансами.

Разница в баллах еще не доказывает превосходство

Одиночный балл на бенчмарке является оценкой, а не свойством модели. Если модель A решила 156 из 200 заданий, а модель B решила 148, разница составляет 4 процентных пункта. Но 200 заданий не являются всей будущей работой системы. Это выборка из более широкого множества запросов, документов, пользователей и пограничных случаев.

На другом разумном наборе заданий A могла бы выиграть на 1 пункт, проиграть на 2 или выиграть на 7. Доверительный интервал показывает диапазон таких правдоподобных значений для средней разницы при принятой статистической модели. Он не превращает неопределенность в ноль, а заставляет показать ее рядом с красивым числом.

Самая частая ошибка состоит в сравнении двух независимых процентов. Один и тот же кейс должен пройти через обе модели. Тогда вы видите не только общие успехи, но и структуру расхождений:

• обе модели справились;
• обе ошиблись;
• A справилась, B нет;
• B справилась, A нет.

Большинство наборов содержит много первых двух типов. Они почти не помогают выбрать победителя. Решение несут последние два типа, то есть задания, на которых кандидаты действительно разошлись.

Если A и B решили одинаковое число задач, но A выигрывает сложные юридические запросы, а B выигрывает простые классификации, усредненный балл также может скрыть то, что важно бизнесу. Сначала определите единицу решения: один запрос, один документ, один диалог или один кейс клиента. Потом стройте сравнение на этой единице.

Доверительный интервал описывает метод, а не вероятность для готового диапазона

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

Это различие не академическая придирка. Неверная фраза "у нас 95% вероятности, что A лучше" создает ложную уверенность в решении. Корректнее сказать так: "по этому протоколу 95% интервал разницы лежит от X до Y". Если ноль находится внутри, данные совместимы как с выигрышем A, так и с выигрышем B.

Справочник NIST/SEMATECH Engineering Statistics Handbook задает интервал среднего как среднее плюс-минус критическое значение t, умноженное на стандартную ошибку. Он также прямо связывает ширину интервала с двумя вещами: размером выборки и стандартным отклонением наблюдений. Для LLM это переводится без мистики: больше независимых и релевантных кейсов сужают интервал, а неоднородные ответы, спорная разметка и нестабильная генерация его расширяют.

Интервал не отвечает на вопрос "нравится ли нам эта модель". Он отвечает на более узкий вопрос: какие средние различия по заранее определенной метрике согласуются с тем, что мы увидели на тесте. Решение о смене модели требует добавить порог пользы, стоимость миграции и запреты, которые нельзя компенсировать средним баллом.

Парное сравнение сохраняет информацию о каждом задании

Для бинарной метрики, например "ответ прошел проверку или нет", создайте для каждого задания разность:

d_i =  1, если A прошла, а B не прошла
d_i = -1, если B прошла, а A не прошла
d_i =  0, если результат одинаков

Среднее d_i равно разнице долей успеха A и B. Парный расчет лучше независимого сравнения процентов, потому что одинаковая сложность задания вычитается из разницы. Очень трудный договор и очень легкий FAQ не раздувают ошибку только потому, что оба попали в набор.

Ниже минимальный пример, который можно положить рядом с выгрузкой результатов. В нем 34 кейса выиграла A, 26 выиграла B, на 140 кейсах исход совпал.

import numpy as np
from scipy import stats

# +1: A выиграла кейс, -1: B выиграла, 0: ничья
wins = np.array([1] * 34 + [-1] * 26 + [0] * 140)
n = len(wins)
mean_diff = wins.mean()
se = wins.std(ddof=1) / np.sqrt(n)
t_crit = stats.t.ppf(0.975, df=n - 1)
low, high = mean_diff - t_crit * se, mean_diff + t_crit * se

print(f"Разница: {mean_diff:.2%}")
print(f"95% ДИ: [{low:.2%}, {high:.2%}]")

Вывод имеет такой вид:

Разница: 4.00%
95% ДИ: [-3.64%, 11.64%]

В таблице A выглядит лучше: 78% против 74%. Однако интервал включает и проигрыш 3,64 пункта, и выигрыш 11,64 пункта. Формулировка "A лучше" здесь не выдерживает проверки. Правильная формулировка: на этом наборе A показала оценку преимущества 4 пункта, но данных недостаточно, чтобы надежно отделить ее от B.

Не заменяйте парный расчет двумя отдельными интервалами для accuracy и не сравнивайте, пересекаются ли они. Пересечение отдельных интервалов не является корректным критерием для интервала их разности. Считайте разницу на уровне задания сразу.

Размер набора помогает медленнее, чем ждут от него

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

Возьмем тот же профиль различий, но на 2 000 кейсах: A выиграла 340, B выиграла 260, еще 1 400 дали одинаковый исход. Оценка разницы осталась 4 пункта. Стандартная ошибка упала примерно с 3,87 до 1,22 пункта, а 95% интервал стал равен примерно [1,60%, 6,40%]. Теперь ноль не входит в диапазон.

Это не повод автоматически собирать 2 000 строк. Если все они являются почти одинаковыми вариантами одного шаблона, фактической новой информации мало. Тысяча перефразированных запросов к одному и тому же полю анкеты не равна тысяче независимых пользовательских задач.

Проверьте, не прячутся ли в наборе кластеры:

• несколько запросов из одного документа;
• серия сообщений одного диалога;
• шаблоны одного клиента или одного продукта;
• варианты одного и того же промпта;
• сгенерированные синтетические кейсы с общим источником.

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

Разброс ответов часто важнее среднего балла

Две оценки 80% могут требовать совершенно разного объема проверки. Если почти все задания дают одинаковый исход для обеих моделей, а различия возникают на нескольких стабильных кейсах, интервал может быстро сузиться. Если модели постоянно меняются местами на задачах разной сложности, неопределенность останется высокой даже при неплохом среднем результате.

В бинарном парном сравнении разброс создают именно ненулевые d_i. Когда A выигрывает 40 кейсов, B 0, а остальные 160 совпадают, преимущество выглядит устойчивее, чем при 80 победах A и 40 победах B, хотя оба сценария могут дать похожую разницу по процентам. Во втором случае кандидаты расходятся чаще, и часть расхождений работает против A.

Для шкалы качества, например от 1 до 5, ситуация еще сложнее. Один разметчик может поставить 4 вместо 3 за полноту объяснения, другой поставит 2 за опасную фактическую ошибку. Среднее скрывает природу расхождения. Храните исходные оценки по модели, заданию и разметчику. Тогда можно проверить, являются ли колебания свойством моделей, особенностью задания или разногласием людей.

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

Повторные вызовы не увеличивают набор автоматически

Температура, семплирование, изменения у провайдера и нестабильный LLM-судья добавляют еще один слой разброса. Если вы сделали пять вызовов модели на одном вопросе, вы получили пять наблюдений генерации, но не пять независимых пользовательских задач.

Плохой прием выглядит так: команда запускает 100 заданий по 10 раз, получает 1 000 строк и строит интервал, считая все строки независимыми. Интервал получается очень узким, потому что расчет вообразил 1 000 разных задач. На деле тест все еще охватывает 100 задач, и ответы внутри каждой группы связаны.

Есть два рабочих варианта. Для большинства продуктов достаточно заранее установить число повторов, посчитать среднюю оценку каждой модели внутри задания, а затем сравнивать эти средние попарно по заданиям. Если разброс генерации сам является предметом решения, используйте иерархический бутстреп: сначала выбирайте задания с возвращением, затем внутри выбранных заданий выбирайте повторы с возвращением.

Фиксированный seed помогает отладить расхождение, но не должен скрывать нестабильность. Если продукт работает при температуре 0,7, оценка на температуре 0 не описывает его работу. Заморозьте параметры вызова до эксперимента: модель, версия, системный промпт, температура, лимит токенов, инструменты, схема ответа и правило ретраев.

Бутстреп нужен для метрик, которые не любят простые формулы

Парный t-интервал хорош для средней разницы, особенно когда заданий достаточно и распределение средних ведет себя спокойно. Но в LLM-оценке часто встречаются F1, win rate по судье, средняя стоимость с тяжелым хвостом, ранговые метрики и сложные правила агрегации. Для них удобнее парный бутстреп.

Алгоритм простой. Вы много раз выбираете из исходного набора столько же заданий с возвращением, каждый раз считаете разницу метрик A и B, а затем берете 2,5-й и 97,5-й процентили получившегося распределения. Важно выбирать индексы заданий один раз для обеих моделей. Если бутстрепить кандидатов независимо, вы ломаете парность и теряете точность.

import numpy as np

rng = np.random.default_rng(42)
# score_a и score_b содержат метрику для одного и того же задания
score_a = np.array([...])
score_b = np.array([...])

boot = []
for _ in range(10_000):
    idx = rng.integers(0, len(score_a), len(score_a))
    boot.append(score_a[idx].mean() - score_b[idx].mean())

low, high = np.quantile(boot, [0.025, 0.975])
print(low, high)

Подставлять mean() можно только для средней метрики по заданиям. Для F1 сначала пересчитайте F1 на выбранных индексах, а потом добавьте разницу в boot. Для диалогов передавайте в процедуру целый диалог, а не отдельную реплику. Бутстреп не исправляет плохой тестовый набор, но он честно отражает форму неопределенности, которую дает выбранная метрика.

Статистическая значимость не равна полезности для бизнеса

Ноль вне интервала означает, что данные плохо согласуются с отсутствием средней разницы при вашем протоколе. Это не означает, что выигрыш оправдывает миграцию. На 20 000 запросов можно получить статистически убедительное преимущество в 0,2 пункта, которое не окупит смену маршрутизации, переобучение команды и повторную приемку безопасности.

До запуска эксперимента задайте минимальный practically useful effect, то есть порог полезной разницы. Допустим, новая модель оправдывает переход только при снижении доли ошибок минимум на 2 пункта. Тогда решение звучит не как "интервал выше нуля", а как "нижняя граница интервала выше 2 пунктов". Если диапазон [0,8%, 3,7%], A, вероятно, лучше, но у вас нет оснований обещать нужный эффект.

Иногда задача обратная. Новая модель дешевле или быстрее, и вы готовы принять небольшое ухудшение качества, но не больше 1 пункта. Тогда задайте границу нехуже: нижняя граница разницы качества A минус B должна быть выше -1 пункта. После этого отдельно проверяйте, дает ли экономия достаточно денег или задержки. Не прячьте компромисс за единым рейтингом.

Для систем с обязательными требованиями среднее качество вообще не является главным арбитром. Если модель иногда раскрывает персональные данные, нарушает обязательный формат или создает недопустимый ответ в чувствительном сценарии, ей нужен отдельный стоп-критерий. Интервал вокруг общей оценки не отменяет этот запрет.

Лучший кандидат на том же наборе почти всегда выглядит лучше, чем он есть

Если команда прогнала 15 моделей, 30 вариантов системного промпта и несколько судей, а потом объявила победителем максимальную строку, она провела отбор по шуму. Даже одинаковые кандидаты дадут случайного лидера. Чем больше попыток, тем выше шанс выбрать удачное отклонение, а не настоящий эффект.

Не пытайтесь чинить это красивой p-value после факта. Разделите работу на три части. На наборе разработки ищите промпт, схему инструментов и короткий список кандидатов. На валидационном наборе фиксируйте конфигурацию и отсеивайте явных аутсайдеров. Нетронутый holdout оставьте для одного финального сравнения заранее ограниченного списка.

Судью тоже нужно фиксировать. Если LLM-судья оценивает один и тот же ответ по-разному или предпочитает стиль одной модели, добавьте человеческую проверку на выборке спорных и критичных кейсов. Полезно измерить согласие между разметчиками, но не делайте из коэффициента согласия декоративное число. Просмотрите конкретные разногласия и перепишите рубрику там, где люди оценивают разные свойства ответа.

Решение о смене модели должно пережить разрезы данных

Средний интервал по всему набору полезен, но он редко достаточен для продакшена. Разбейте результаты на срезы, которые соответствуют риску: русский и казахский языки, типы документов, короткие и длинные контексты, отраслевые термины, запросы с инструментами, чувствительные случаи. Не ожидайте, что каждый срез даст узкий интервал. Маленькие срезы честно покажут, где данных не хватает.

Не собирайте десятки срезов ради цветной панели. Каждый разрез должен отвечать на конкретную угрозу. Если медицинский поток составляет малую долю трафика, но ошибка там дорога, ему нужен собственный набор и собственный порог. Общий выигрыш не компенсирует регрессию в этом потоке.

Для команд, которые держат LLM-трафик через единый API-шлюз, удобно сохранять в оценочном журнале идентификатор модели, версию промпта, параметры вызова, срез и решение разметчика. AI Router может помочь с единым маршрутом запросов и аудит-логами, но статистическое решение все равно принимает ваш протокол, а не шлюз.

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

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