LLM as Judge

Суть

Когда нет ground truth (а в агентных задачах его обычно нет), качество измеряют не сравнением со строкой-эталоном, а суждением модели: «насколько ответ точен / полон / в нужном тоне». Судьёй может быть более мощная модель (GPT-4o, Claude) либо более простая — в зависимости от задачи и бюджета.

Две семьи метрик оценки

Reference-based (нужен эталон):

• BLEU — точность совпадения n-грамм, хорошо для перевода.
• ROUGE — recall-ориентированная (ROUGE-1/2/L), для саммаризации.
• BERTScore — семантическое сходство через эмбеддинги, лучше BLEU на длинных текстах.
• (+ METEOR, MoverScore, BLEURT и др. — полный список ссылок в Источниках.)

Reference-free (эталон не нужен):

• LLM-as-Judge — модель оценивает ответ по критериям (бинарно 0/1 или градиентно 1–5).
• G-Eval — оценка через цепочку рассуждений (Chain-of-thought) судьи.
• Task-specific — кастомные метрики: точность извлечения данных, соответствие тону компании, latency, cost.

Принципы (как делать судью надёжным)

• Бинарность лучше градиента — шкалы PASS/FAIL (Да/Нет, 0/1) проще согласовать и между людьми, и между LLM и человеком, чем «оценка 7 из 10».
• Калибровка судьи — модель-судью калибруют на небольшом датасете, размеченном человеком-экспертом, иначе её вердикты смещены.
• Чёткие критерии вместо «общих» — для нишевого домена вместе с экспертом продумывают, что есть «хорошо/плохо», а не берут средневзвешенные метрики.
• CoT + структурный вывод — судья рассуждает по шагам и отдаёт JSON-вердикт (удобно парсить и агрегировать).
• Судья ≠ самооценка — нельзя просить модель оценивать собственный вывод: «агенты уверенно хвалят свою работу, даже посредственную». Судья должен быть внешним (см. Generator Evaluator). Где есть объективная проверка (код, тесты) — она предпочтительнее судьи (детерминизм дешевле и надёжнее).
• Гибридное будущее — LLM Juries (коллегии судей) для сложных случаев; «trust or escalate»: маленькие модели (~3B) берут 80% рутинных оценок, тяжеловесы подключаются при сомнении; кросс-валидация автоматическими метриками (BERTScore) на фактологии.

Биасы LLM-судьи (и LLM Jury)

У судьи есть систематические смещения, которые надо учитывать:

• Verbosity bias (многословность) — судья склонен считать более длинный/детальный ответ лучшим, даже если там «вода» и повторы (путает количество с качеством).
• Positional bias (эффект порядка) — в парном сравнении при прочих равных чаще выбирается ответ, стоящий первым. Решение: всегда рандомизировать порядок ответов перед оценкой.
• Self-enhancement bias (самолюбование) — модель выше оценивает ответы «своей крови» (GPT-5 → ответы GPT-4), чем чужой модели.
• Атака на судью — специально сконструированными суффиксами (Greedy Coordinate Gradient) можно заставить судью принять неверное решение.

Роли судьи: оценка по критериям, оценка по критериям с эталоном (референс в контекст), парное сравнение (выбрать лучший из двух — проще, чем абсолютная оценка в вакууме), суд присяжных (LLM Jury). LLM Jury — комитет из разных моделей (Claude, Gemini, Llama) голосует, результаты усредняются: так обходят self-enhancement bias одного вендора (подход использует Amazon). Это самый популярный приём против предвзятости одной модели.

Связано с

• Agent Evals — судья автоматизирует answer_grounded и метрики качества
• Generator Evaluator — паттерн «генератор + внешний судья», почему самооценке нельзя верить
• DeepEval Agentic Metrics — почти все метрики DeepEval работают через LLM-as-judge
• RAG Metrics — RAGAS использует судью без ground truth

Открытые вопросы

• насколько confidence самого судьи можно доверять без калибровки
• когда reference-based (BERTScore) надёжнее судьи, а когда наоборот