# Конспект 3/3 — LLM-as-judge: теория, баги, калибровка (15 минут)

Глубокий разбор тяжёлого блока из `AI-SD-TOPICS.md` §7. Цель: после чтения уметь **на доске** объяснить, почему accuracy судьи врёт, назвать три типа скоринга и известные баги судей.

---

## 1. Что такое LLM-as-judge

LLM-as-judge (он же LLM-evaluator) — это LLM, который оценивает ответ другого LLM.

Зачем он нужен: задачи становятся открытыми (пересказ, диалог, творчество), и старые метрики — n-gram, similarity, gold reference — перестают отличать хороший ответ от плохого.[41]

Людей звать дорого и медленно. LLM может оценить сотни ответов за минуты.

Но: судья — тоже LLM. Он наследует все баги оцениваемых LLM. Кто проверит судью?[60]

## 2. Ключевая идея: судья — это классификатор

Не думай про судью как про «мнение». Думай как про классификатор, который предсказывает: фейл / не фейл.

Классификатор меряется через TP/FP/TN/FN.

**TP (true positive)** — фейл реально был, судья поймал.

**FP (false positive)** — фейла не было, судья ложно зарубил.

**TN (true negative)** — всё ок, судья пропустил.

**FN (false negative)** — фейл был, судья пропустил.

Две главные метрики судьи:

**TPR (recall)** — из всех реальных фейлов сколько поймано: `TP / (TP + FN)`.

**TNR** — из всех реально-хороших сколько не зарублено ложно: `TN / (TN + FP)`.

**Почему accuracy судьи врёт (главный тезис ролика Hamel и всей литературы):**

Допустим, фейлов в проде 5%. Судья, который всегда говорит «ок»:

- accuracy = 95% (потому что 95% случаев он прав по умолчанию);
- TPR = 0% (не поймал ни одного фейла);
- TNR = 100% (ничего не зарубил ложно).

Ты думаешь «судья отличный — 95% accuracy». На деле он бесполезен: все реальные проблемы проходят мимо.[41][50]

**Вывод: судью меряют TPR/TNR на holdout против человеческой разметки, а не accuracy.**

## 3. Три способа скоринга судьёй

Eugene Yan выделяет три подхода, они не взаимозаменяемы:[41]

**1. Direct scoring** — оценить один ответ без альтернативы.

Когда: объективные вещи — faithfulness, политика, токсичность. Ответ либо верен, либо нет.

**2. Pairwise comparison** — «какой из двух ответов лучше по критерию X».

Когда: субъективное — тон, убедительность, когерентность. Исследования: pairwise стабильнее direct scoring для субъективного, меньше расхождение с людьми.

Не годится для фактов: «ответ верен или нет» не имеет смысла «вернее другого».

**3. Reference-based** — сравнить ответ с эталонным (gold reference).

Когда: есть качественные референсы. Дороже: референсы надо писать.

## 4. Известные баги судей (назвать на собеседовании)

Из MT-Bench paper (Zheng et al., 2023):[53]

**Position bias** — судья предпочитает ответ на позиции A или B независимо от содержания. Лечится: swap позиций и усреднение.

**Verbosity bias** — судья предпочитает более длинные ответы. Известный пример: GPT-4 дал alpaca-7b средний балл 4.7/5 за многословие, а люди — 2.9/5.[41]

**Self-enhancement bias** — судья предпочитает ответы, похожие на свои собственные.

**Limited reasoning** — судья хуже на сложных математических/логических задачах.

Несмотря на баги: сильный LLM-судья (GPT-4) совпадает с людьми на >80% — на уровне согласия человек-человек. Это легитимизирует подход при правильной калибровке.[53]

## 5. Калибровка судьи: пошаговый протокол

По Hamel и Eugene Yan:[68][41]

1. Собери 30–80 примеров и разметь людьми (идеально — домен-эксперт, «benevolent dictator»).
2. Прогони судью на этих примерах.
3. Посчитай TPR/TNR и confusion matrix.
4. Если TPR низкий — критерий слишком узкий или промпт невнятный.
5. Если FP высокий — критерий слишком жёсткий, ложно рубит хорошее.
6. Few-shot — только из train-части разметки, holdout не трогать.
7. Перекалибровка регулярно: **criteria drift**.

**Criteria drift** — феномен из работы Shreya Shankar «Who Validates the Validators?»: «критерии нужны, чтобы оценивать выходы, но оценка выходов помогает определить критерии».[60]

Проще: ты смотришь на новые ответы, понимаешь «а вот это мы не учли», и критерии меняются. Это нормально, но требует, чтобы судья перекалибровывался, а не жил с прошлогодним промптом.

## 6. Как измерить согласие судьи с человеком

Два семейства метрик:[41]

**Classification-метрики** (для binary-задач): precision/recall судьи на разметке. Лучший выбор — потому что переводится в продакшн-поведение: «сколько реальных фейлов мы пропустим».

**Correlation-метрики** (для рангов и шкал):

- **Cohen's κ** — согласие двух райтеров с поправкой на случайность. 0.41–0.60 = moderate. Консервативная.
- **Kendall's τ / Spearman's ρ** — согласие ранжирований. Не учитывают шанс-согласие, потому обычно выше и оптимистичнее.

Eugene Yan скептичен к correlation-метрикам: они не показывают поведение в проде («какой recall на плохих ответах?»). Поэтому советует заставлять судью возвращать **binary**, а не шкалы.[41]

## 7. Промпт-скелет судьи

```
You are grading ONE criterion: <name>.
PASS if and only if: <observable rule>.
FAIL if: <counterexamples>.
Reply JSON: {"verdict": "PASS"|"FAIL", "critique": "..."}.
Do not score style, length, or politeness unless they violate the rule.
```

Почему так:

- **один критерий** — судья-«мультитул» размывает внимание;[68]
- **binary** — Likert 1–5 шумит: разница 3 vs 4 невоспроизводима;[50]
- **критика** — даёт материал для error analysis;
- **JSON** — парсится кодом без LLM;
- **явный запрет стиля/длины** — лечит verbosity bias.

## 8. Когда судья — не нужен

Code-based проверка всегда предпочтительнее, если её можно написать:

- JSON-схема, regex, enum;
- «цифра баланса только из get_balance»;
- account_id == session_id;
- SQL исполнился.

Судья — только для того, что кодом не выражается: тон, полнота, «опирается на политику», tool efficiency.[68]

Экономика: LLM-judge с CoT — это деньги и латентность. Не вешай его в горячий путь, если можно кодом.[50]

## 9. Инструменты, где это уже реализовано

- **Promptfoo** — open-source CLI: матричные сравнения промптов, red-teaming, CI, свои метрики и судьи.[59]
- **Braintrust** — eval-first платформа: датасеты, эксперименты, сравнение промптов, autoevals.[44]
- **LangSmith** — трейсинг + оффлайн/онлайн eval, тесная интеграция с LangChain.[66]
- **Langfuse** — self-hosted open-source альтернатива: трейсы + eval + мониторинг, для команд с требованиями к данным.[67]
- **Ragas** — метрики faithfulness/context recall/relevancy на LLM-суждениях.[35]

Фраза на собеседовании: «Промпт — это код: версия в Git, eval в CI. Harness — Promptfoo/Braintrust, наблюдаемость — Langfuse/Phoenix».

---

## Ссылки по теме

- [MT-Bench / Judging LLM-as-a-Judge (arxiv 2306.05685)](https://arxiv.org/abs/2306.05685) — position/verbosity/self-enhancement баги, >80% согласия с людьми[53]
- [Eugene Yan — Evaluating LLM-Evaluators](https://eugeneyan.com/writing/llm-evaluators/) — direct vs pairwise vs reference, correlation vs classification, баги судей[41]
- [Shreya Shankar — Who Validates the Validators? (arxiv 2404.12272)](https://arxiv.org/abs/2404.12272) — criteria drift, EvalGen, «люди определяют критерии, глядя на выходы»[60]
- [Hamel — Creating a LLM-as-a-Judge That Drives Business Results](https://hamel.dev/blog/posts/llm-judge/) — пошагово: domain expert, dataset, pass/fail с critique, калибровка[68]
- [Hamel — LLM Evals FAQ](https://hamel.dev/blog/posts/evals-faq/) — почему binary, когда judge не нужен, CI vs prod[50]
- [Promptfoo docs](https://promptfoo.dev/docs/) — open-source eval CLI, red-teaming, матрицы[59]
- [Braintrust docs](https://www.braintrust.dev/docs) — eval-first платформа, workflow Instrument→Observe→Annotate→Evaluate→Deploy[44]
- [LangSmith evaluation](https://docs.langchain.com/langsmith/evaluation) — трейсинг + eval в экосистеме LangChain[66]
- [Langfuse](https://langfuse.com/) — self-hosted observability + eval[67]
- [Ragas metrics](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/) — faithfulness, context recall, relevancy[35]

## Мини-словарь к конспекту

**Holdout** — часть разметки, которую не показывали при настройке судьи; на ней меряют честные TPR/TNR.

**Few-shot** — примеры в промпте судьи, показывающие ожидаемое поведение.

**Confusion matrix** — таблица TP/FP/TN/FN по предсказаниям классификатора.

**Criteria drift** — изменение критериев оценки по мере просмотра новых выходов.[60]

**Benevolent dictator** — один ответственный домен-эксперт, который ставит финальные метки, чтобы не было разнобоя.[50]

**Rubric** — описание, за что ставить PASS/FAIL.

**CoT (chain-of-thought)** — «подумай вслух перед ответом»; у судей улучшает точность, но дороже.

**LLM-evaluator / judge / grader** — синонимы: LLM, оценивающий ответы.

**Red-teaming** — автоматизированный поиск уязвимостей и джейлбрейков (в Promptfoo).[59]

**Autoevals** — готовые пресеты судей у Braintrust (factuality, relevance и др.).[44]

## Sources

[35] https://docs.ragas.io/en/stable/concepts/metrics/available_metrics
[41] https://eugeneyan.com/writing/llm-evaluators
[44] https://www.braintrust.dev/docs
[50] https://hamel.dev/blog/posts/evals-faq
[53] https://arxiv.org/abs/2306.05685
[59] https://promptfoo.dev/docs
[60] https://arxiv.org/abs/2404.12272
[66] https://docs.langchain.com/langsmith/evaluation
[67] https://langfuse.com
[68] https://hamel.dev/blog/posts/llm-judge