Оценка LLM плавает: как откалибровать судью и найти источник дрейфа

Сборка не менялась, а доля успешных ответов упала. Первая реакция — откатить продукт. Но в eval-пайплайне есть не одна, а две вероятностные системы: модель создаёт ответ, затем другая модель его оценивает. Новый ответ, повторное решение судьи, обновлённая рубрика или смена серверной конфигурации способны сдвинуть итоговую метрику без регрессии приложения.

Поэтому задача калибровки — не заставить LLM всегда выдавать одно число. Нужно сделать источник изменения наблюдаемым и не позволить единичному баллу управлять релизом.

У одного балла четыре возможных объяснения

Полная цепочка выглядит так:

text
тестовый пример -> продуктовая LLM -> сохранённый ответ -> LLM-судья -> решение

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

Для диагностики нужны разные режимы:

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

Детерминированная проверка сильнее модельного мнения

LLM-судья не должен решать, валиден ли JSON, существует ли обязательное поле, вызван ли нужный инструмент, совпадает ли сумма или разрешён ли URL. Это проверяется программой и возвращает точную причину отказа.

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

Актуальные рекомендации OpenAI по evals советуют строить тесты под реальную задачу, непрерывно пополнять набор случаев, сверять автоматическую оценку с людьми и предпочитать более ограниченные решения — попарное сравнение или pass/fail. В руководстве по graders отдельно описаны строковые проверки, метрики похожести и модельные судьи. Конкретный API принадлежит OpenAI, но принцип применим к любой системе: используйте самый однозначный измеритель, который отвечает на вопрос.

Практичный контракт оставляет четыре независимых выхода:

1. жёсткий детерминированный отказ;
2. решения по отдельным смысловым критериям;
3. ошибка калибровки или нестабильность судьи;
4. передача спорного случая человеку.

Средний балл 7,3/10 стирает эту информацию: он не сообщает, найден ли фактический дефект или судье просто не понравился стиль.

Судье нужен собственный экзамен

До подключения к CI соберите калибровочный набор:

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

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

Работы об LLM-as-a-Judge показывают, почему нельзя сертифицировать судью только именем модели. Исследование MT-Bench и Chatbot Arena получило высокое согласие с людьми в своей конфигурации, но также зафиксировало смещение по позиции, предпочтение многословия, склонность к собственной модели и ограничения рассуждения. Его процент согласия нельзя переносить на другой домен.

В работе Large Language Models Are Not Fair Evaluators одна перестановка ответов могла изменить рейтинг; авторы проверяли баланс позиций, несколько свидетельств и участие человека. Более позднее систематическое исследование позиционного смещения охватило 12 судей, 22 задачи и более 100 тысяч оценок и показало зависимость эффекта от модели и задачи.

Четыре испытания для каждого контракта судьи

Замороженный ответ

Несколько раз оцените один и тот же сохранённый ответ без изменения рубрики и конфигурации. Храните все решения, а не только среднее. Считайте, как часто меняется pass/fail и на каких критериях разброс максимален.

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

Обратный порядок

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

Контрфактическая форма

Измените длину, заголовки, имя ассистента или уверенный тон, не меняя полезность ответа. Сильный сдвиг балла указывает, что судья измеряет поверхностное предпочтение. Так же обнаруживается grader hacking: продукт учится писать длиннее и «авторитетнее», автоматический балл растёт, а экспертная оценка — нет.

Эталон или исполнимая проверка

Для извлечения данных, grounded Q&A, математики и tool use передайте источник, эталон или результат программы. Объяснение судьи помогает расследованию, но не доказывает вердикт: та же модель способна убедительно обосновать ошибку.

Калибруйте решение, а не среднее число

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

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

Стоимость false accept и false reject различается. Для медицинского ответа опаснее пропустить неподтверждённый совет; для рекламного заголовка может быть дороже отправлять половину потока экспертам. Сначала задайте эту цену, затем выбирайте порог, объём выборки и бюджет повторов. Универсального значения 0,8 или числа запусков нет.

Для CI полезны три решения: pass, fail и review. Непрерывный балл можно хранить для анализа, но он не должен создавать ложную точность.

Фиксированные якоря показывают, кто дрейфует

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

text
текущие ответы продукта -> текущий судья -> сигнал продукта
фиксированные якоря    -> текущий судья -> сигнал судьи

Если продуктовая метрика падает, а якоря стабильны, исследуйте продукт или распределение трафика. Если на якорях судья стал строже, сначала проверяйте модель судьи, рубрику, примеры, парсер и backend. Когда обе линии шумят, честный вывод — измерительная система пока не годится для блокировки.

Препринт 2026 года Who Drifted: the System or the Judge? формализует такой подход: фиксированный набор с человеческими метками измеряет разрыв «судья–человек» отдельно от основного мониторинга. Опубликованные там показатели обнаружения и стоимости относятся к эксперименту, а не гарантируют ваш результат. Переносимая идея в другом: изменение продукта не может изменить уже сохранённый якорный ответ, а изменение судьи — может изменить его оценку.

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

Релизный порог должен уметь остановиться

Порядок проверки важнее одной формулы:

text
1. Прошли ли все детерминированные контракты?
2. Остался ли судья в допустимом диапазоне на якорях?
3. Стабильны ли повторные оценки замороженных ответов?
4. Превышает ли разница версий обычный разброс?
5. Сосредоточена ли проблема в критичных сегментах?
6. Нужен ли спорным случаям эксперт?

Из этого получаются четыре состояния:

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

Нулевая температура не закрывает расследование. Инфраструктура, модельный alias, шаблон промпта, результат инструмента и парсер могут измениться. Исторический пример OpenAI о воспроизводимости с seed и system fingerprint говорил лишь о «в основном одинаковых» ответах на поддерживаемых тогда preview-моделях и прямо не гарантировал детерминизм. Не переносите это обещание на любой современный API.

Версионируйте модель судьи, рубрику, примеры, схему ответа, парсер и политику агрегации. Логируйте доступные request ID, параметры и backend fingerprint. Эти данные помогают объяснить различие; они не превращают вероятностную систему в unit-тест.

Что делать, когда метрика уже изменилась

1. Сверьте версии датасета, продукта, судьи, рубрики, примеров, парсера и агрегации.
2. Проверьте детерминированные отказы отдельно от смысловых оценок.
3. Повторно оцените сохранённые ответы, не генерируя их заново.
4. Посмотрите на человеческий якорный набор.
5. Разбейте изменение по задаче, языку, длине, риску и источнику трафика.
6. Повторите тест порядка или поверхностной формы для затронутого критерия.
7. Отдайте спорные критичные случаи на слепую экспертную проверку.
8. Меняйте решение о релизе только после того, как одна гипотеза получила отличающее её доказательство.

Надёжный LLM-судья не обещает всегда одинаковое число. Он имеет измеренную повторяемость, версию контракта, связь с экспертной политикой и независимую якорную линию. Возможность ответить «данных недостаточно, нужна проверка» делает такой eval сильнее, а не слабее.