LLM-as-judge: when it works and when it lies

Идея LLM-as-judge проста: одна модель оценивает выход другой по заданному критерию. Насколько этому можно верить — вопрос эмпирический, и на него есть измеренный ответ. В работе «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena» (Zheng et al., 2023) сильный judge (GPT-4) согласился с вердиктами людей более чем в 80% случаев — примерно столько же, сколько люди соглашаются друг с другом. То есть для субъективных свойств — тон, полнота, следование инструкции, полезность — правильно настроенный judge даёт оценку уровня среднего человеческого эксперта, но за секунды и центы.

Два режима работы. Direct scoring: judge получает один ответ и рубрику, выносит вердикт (pass/fail или балл). Подходит для CI-гейтов и мониторинга — оценка каждого ответа независима, датасет можно гонять инкрементально. Pairwise comparison: judge получает два ответа на один вопрос и выбирает лучший (или ничью). Стабильнее для сравнения моделей и промптов между собой, потому что относительное суждение «А лучше Б» проще абсолютного «А тянет на 7/10», но результат — рейтинг, а не порог для гейта.

Чего judge не умеет: надёжно проверять арифметику и вычисления (сам ошибается), свежие факты без предоставленного reference, корректность кода без запуска. Правило: judge оценивает только то, что видно из текста ответа и данного ему контекста. Всё исполняемое проверяйте исполнением, всё фактологическое — reference-ответом в промпте judge.

Judge — это модель со своими систематическими искажениями. Их надо знать поимённо:

• Position bias. В pairwise-режиме judge предпочитает ответ на определённой позиции (чаще первый). В MT-Bench при перестановке ответов местами даже сильные модели меняли вердикт: только GPT-4 удержал консистентность около 65%, слабые судьи — заметно ниже. Митигация: каждую пару прогонять дважды с обменом позиций; расхождение вердиктов считать ничьёй.
• Verbosity bias. Длинный ответ получает больше баллов независимо от содержания. В MT-Bench это проверяли «repetitive list»-атакой: ответ, раздутый повторами, обманывал часть судей. Митигация: явный пункт рубрики «многословие без новой информации — недостаток» и контроль длины как отдельная метрика вне judge.
• Self-enhancement bias. Модель систематически завышает оценки ответам, сгенерированным ею же или моделью того же семейства. Митигация: judge из другого семейства, чем оцениваемая модель (оцениваете GPT — судите Claude, и наоборот).
• Сползание шкалы. На шкале 1–10 судьи кластеризуют оценки вокруг 6–8, различающая способность падает. Митигация: бинарные вердикты с обязательным объяснением или маленькие шкалы с якорями (1 = есть выдуманный факт, 3 = всё подтверждено контекстом).

Общий приём против всех сразу: заставляйте judge сначала письменно разобрать ответ по критериям (chain-of-thought) и только затем выносить вердикт, а при наличии эталона — давайте reference-guided режим: сравнение с эталоном устойчивее свободной оценки.

Самая частая ошибка — принять вердикты judge на веру. Judge — это ещё одна LLM-система, и у неё должен быть собственный эвал: согласие с человеком. Процедура калибровки: возьмите 50–100 кейсов с человеческими бинарными метками из прошлого урока, прогоните judge и постройте confusion matrix против человека. Смотрите не только accuracy: важны TPR (какую долю настоящих fail judge ловит) и TNR (какую долю настоящих pass не бракует зря). Judge, пропускающий 40% реальных дефектов, бесполезен как гейт, даже если общая точность выглядит прилично. Сводная метрика — та же каппа Коэна: κ ≥ 0.8 — judge можно доверить гейт, 0.6–0.8 — рабочий уровень с выборочным человеческим контролем, ниже — рубрика требует переработки.

Что улучшать при низком согласии, по убыванию эффекта. Первое — бинаризация и конкретика рубрики: вместо «оцени качество ответа» — один проверяемый критерий на одну рубрику. Второе — few-shot примеры граничных случаев прямо в промпт judge: пары «этот ответ pass, потому что…» / «этот fail, потому что…» из ваших размеченных данных. Третье — chain-of-thought перед вердиктом. Четвёртое — reference-ответ, если он есть в датасете.

И два эксплуатационных правила: смена модели judge (или мажорное обновление провайдера) — повод перекалиброваться, потому что пороги строгости у моделей разные; и держите постоянный сэмпл человеческого контроля (5–10% вердиктов), чтобы заметить дрейф judge раньше, чем он испортит месяц метрик.

Рабочая рубрика — это один критерий, определение pass и fail и граничные примеры. Шаблон:

Критерий: ответ опирается только на предоставленную политику возврата.
PASS: каждое утверждение о сроках и условиях подтверждается текстом политики;
      при отсутствии информации ответ честно направляет в поддержку.
FAIL: любое условие, срок или исключение, которого нет в политике;
      обещание возврата вне описанных правил.
Сначала перечисли все фактические утверждения ответа и источник каждого,
затем вынеси вердикт PASS или FAIL.

В promptfoo это ассерт llm-rubric, а модель судьи задаётся отдельно от тестируемой — берите другое семейство:

defaultTest:
  options:
    provider: anthropic:claude-sonnet-4-20250514  # judge не из семейства тестируемой модели
tests:
  - vars:
      question: "Можно ли вернуть заказ через 40 дней?"
    assert:
      - type: llm-rubric
        value: "PASS только если ответ верно называет срок 30 дней и не выдумывает исключений; иначе FAIL."

Для RAG-систем не изобретайте рубрики с нуля: Ragas даёт декомпозицию на faithfulness (доля утверждений ответа, подтверждённых контекстом), answer relevancy и context precision/recall — это готовые reference-free метрики с внятной семантикой. Подход G-Eval (Liu et al., 2023) добавляет форму: judge получает критерий, сам разворачивает его в шаги проверки (auto-CoT) и заполняет структурированную форму — на бенчмарках суммаризации это дало лучшую корреляцию с человеком, чем прямые оценки. И считайте экономику: judge удваивает стоимость прогона, поэтому кэшируйте вердикты для неизменённых пар «ответ + рубрика».