LLM-судьи

LLM-судьи как измерительные приборы​

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

Примеры применения:

• оценка точности и связности резюме относительно эталона
• проверка того, что сгенерированный ответ опирается на найденный контекст и не содержит неподтверждённых утверждений
• попарное сравнение вариантов ответа для выбора более качественного
• классификация вывода модели как безопасного/небезопасного или прошедшего/не прошедшего проверку по явным критериям
• регрессионная оценка по системе критериев на эталонных наборах данных в конвейерах CI/CD
• оценка корректности шага рабочего процесса: соответствовало ли каждое извлечение данных или обращение к инструменту заданному контракту?

LLM лучше различают явно заданные варианты или критерии, чем проводят открытую оценку. Вместо «это хорошо?» выбирай классификацию, попарное сравнение или оценку по именованным критериям. См. рекомендации OpenAI по оценке.

Судья — один из нескольких инструментов​

Генеративный судья редко бывает самым достоверным из доступных инструментов. Детерминированная проверка, специально обученный критик или типизированная модель принятия решений — классификатор, которому передают состояние и объявленные вопросы, а он возвращает откалиброванные вероятности вместо текста, — обычно дают более веское основание для того же суждения. Такой интерфейс задала Jev (TypeSafe System One); Clef от Cloudflare и открытое семейство Kev предоставляют тот же API и допускают самостоятельное размещение. В главе «Планирование» разобран выбор между ними.

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

Самые достоверные проверки встречаются реже всего, и с ростом доступности достоверность падает.¹ Специально обученный критик и типизированная модель принятия решений стоят выше генеративного судьи везде, где применимы. Критик читает тот же текст, но оценивает его по усвоенным предпочтениям: дообученные критики планирования на 4B и 8B параметров повысили долю решённых задач у шести более крупных агентов программирования на 16,0% и 14,4% на SWE-Bench Verified и снизили стоимость обработки одного примера GPT-OSS-20B с $0,07 до $0,03.² Типизированная модель принятия решений отвечает на объявленные вопросы откалиброванной вероятностью вместо текста.³ В главе «Валидация» все методы распределены по четырём классам.

Возможности любого судьи ограничивают два факта о валидности. Доля точных совпадений завышает способности генеративного судьи: на MT-Bench коэффициент каппа Коэна ниже на 33–41 пункт, а места судей в рейтинге меняются вплоть до 14 позиций между бенчмарками.⁴ Коллегии судей, использующие общие свидетельства, разделяют и слепые зоны: голосование разных моделей на общих данных одобрило 62,9% небезопасных предложений против 22,9% после добавления независимого источника.⁵

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

Шум неизбежен — учитывай его при проектировании​

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

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

Проектируй критерии так, чтобы минимизировать смещение, а шум учитывай повторными измерениями:

• Атомарные критерии. Разделяй фактическую обоснованность, выполнение контракта, полноту, краткость и безопасность на отдельные оси. Единую интегральную оценку качества невозможно ни проверить, ни целенаправленно улучшить.
• Требуй свидетельства. Возвращай результат по каждому критерию со ссылками на соответствующее требование, источник, дифф или трассу. Голая оценка — шум, выдаваемый за сигнал.
• Калибруй по людям. Сравнивай вердикты с репрезентативным набором примеров, размеченных людьми. Расхождение может выявить неоднозначные критерии, слабого судью или область, где автоматизация неуместна.
• Контролируй позиционное смещение. При попарной оценке случайно меняй порядок кандидатов и проверяй оба порядка. Используй другое семейство моделей, чем у генератора, чтобы уменьшить предпочтение собственных результатов. Укажи в критериях игнорировать длину и формат, если они сами не являются критериями.
• Для утверждений с высокой требуемой точностью используй несколько независимых судей. Один вызов LLM на одной модели может дать противоположный вердикт при повторном запуске. Когда важна точность, выполняй N независимых вызовов: разные семейства моделей, температуры или повторные вызовы с одной конфигурацией, — и объединяй результаты голосованием большинства. Это тот же шаблон «создай независимых кандидатов и оцени их по независимым свидетельствам» из главы «Рычаги надёжности». Отслеживай согласованность между вызовами: частые расхождения указывают на неоднозначную систему критериев.

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

Версионируй и контролируй свой прибор​

Фиксируй версии модели-судьи, критериев и промпта как версии измерительного оборудования. Перекалибровывай систему при изменении любого компонента и периодически передавай выборку вердиктов людям на проверку. Разреши результат needs_review вместо принудительного вердикта: направляй человеку случаи с низкой уверенностью, серьёзными последствиями или противоречивыми свидетельствами.

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

Главное​

• LLM-судьи — измерительные приборы, а не арбитры. Они заполняют промежуток между детерминированными проверками и ручным ревью и полезны, когда человек не может проверить каждый артефакт.
• Это один из нескольких инструментов. Детерминированная проверка, обученный критик или типизированная модель принятия решений достовернее везде, где способны выразить то же суждение. Выбирай наименее сложный инструмент, достоверности которого достаточно для обоснования утверждения.
• Шум неизбежен, со смещением можно работать. Создавай атомарные критерии с подтверждающими свидетельствами; калибруй по человеческой разметке; случайно меняй порядок для борьбы с позиционным смещением. Считай повторные измерения способом оценить шум, а не недостатком.
• Используй выборку ради точности. Когда последствия ошибочного принятия велики, запускай несколько независимых судей из разных семейств моделей и объединяй вердикты голосованием большинства.
• Версионируй прибор. Фиксируй модель-судью, критерии и промпт; перекалибровывай при изменениях; разрешай needs_review вместо принудительного вердикта.

Примечания​

1. Wan et al. (2026), No Free Checker: A Survey of Verifiers for Robot Policies — для примерно 150 верификаторов четырёх семейств (человек, правила и формальные методы, обученные, встроенные в модель) «достоверность падает с ростом доступности». Обзор посвящён политикам роботов; этот порядок — принцип, а не измерение для агентов программирования. ↩

2. Gandhi et al. (2026), Steer, Don't Solve: Training Small Critic Models for Large Code Agents — дообученные критики планирования на 4B и 8B параметров повышают долю решённых задач шести более крупных агентов программирования на 16,0% и 14,4% на SWE-Bench Verified и снижают стоимость инференса GPT-OSS-20B на один пример с $0,07 до $0,03. ↩

3. TypeSafe AI (2026), System One — состояние и типизированные вопросы дают откалиброванные вероятности через выбор, score и noul, без сгенерированного текста; Cloudflare (2026), Clef — тот же интерфейс на Workers AI (@cf/cloudflare/clef, $0,24 за миллион входных токенов); Kev (2026), kev — семейство под Apache-2.0 от 0,8B до 27B параметров с тем же API и точностью в пределах одного пункта от Jev на отложенных источниках. ↩

4. Norman et al. (2026), Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias — «снижение оценки при переходе от точного совпадения к каппе Коэна универсально (33–41 п. п. на MT-Bench)», а позиции судей меняются вплоть до 14 мест между бенчмарками. ↩

5. Zheng et al. (2026), Engineering Reliable Commit Gates for Agentic AI: Cost-Aware Verification Portfolios under Common-Mode Data Failures — «голосование разных моделей на общих свидетельствах одобряет 62,9% небезопасных предложений против 22,9% при наличии независимого источника». ↩