LLM-as-a-Judge
Abstract
LLM-as-a-Judge — использование модели для оценки результата по рубрике. Это масштабируемый измерительный инструмент для критериев, которые трудно проверить кодом, но не источник объективной истины.
Когда применять
- стиль, полнота, релевантность и качество объяснения;
- groundedness, если judge получает ответ и evidence;
- предварительная сортировка большого числа результатов;
- сравнение кандидатов при наличии человеческого calibration set.
Exact checks, schema validation, unit tests и проверку существования ссылок выполняй кодом. Judge нужен для оставшейся семантической части.
Форматы
- Pointwise: оценить один ответ по шкале или классам.
- Pairwise: выбрать лучший из двух ответов.
- Reference-based: сравнить с эталоном.
- Rubric-based: проверить несколько независимых критериев.
Надёжный контур
task + candidate + evidence + rubric
↓
judge
↓
score + criterion-level reasons + uncertainty
↓
calibration / threshold / human reviewJudge оценивает; переписывание результата — отдельный optimizer-step. Такое разделение позволяет понять, что именно улучшилось, и не терять исходный кандидат.
Типичные смещения
- position bias: предпочтение ответа из определённой позиции;
- verbosity bias: предпочтение более длинного текста;
- self/family bias: возможное предпочтение похожего стиля или собственной модели;
- reference leakage: копирование формы эталона вместо оценки качества;
- prompt injection: кандидат пытается инструктировать judge;
- inconsistency: изменение оценки при повторе или переформулировке.
Калибровка
- Собери примеры с независимой человеческой разметкой.
- Определи рубрику с наблюдаемыми уровнями, а не словами «хорошо/плохо».
- Проверь порядок кандидатов в pairwise-сравнении в обе стороны.
- Измерь agreement по каждому критерию.
- Разбери false positives и false negatives.
- Зафиксируй версии judge model, prompt и rubric.
- Периодически отправляй случайную выборку человеку.
Не калибруй и не измеряй judge на одном наборе: это скрывает переобучение рубрики.
В production
- не используй один judge как единственную границу безопасности;
- route low-confidence и high-impact случаи человеку;
- храни сырые оценки и причины, а не только итоговый score;
- ограничивай циклы evaluator–optimizer;
- сравнивай стоимость judge с ценностью отфильтрованных ошибок.