Финал курса: как строить судью, которому можно верить, и какие баги у него гарантированно будут.
Не «мнение», а предсказание: фейл / не фейл. Меряется TP/FP/TN/FN, TPR/TNR, confusion matrix — не accuracy.
Ловушка accuracy: 5% фейлов → судья «всегда ок» даёт 95% accuracy и ловит ноль проблем.
Подробно — в глоссарии метрик.
| Способ | Когда | Почему |
|---|---|---|
| Direct scoring | Факты, faithfulness, политика | Ответ либо верен, либо нет |
| Pairwise comparison | Тон, убедительность, когерентность | Стабильнее для субъективного |
| Reference-based | Есть эталонные ответы | Дороже: референсы надо писать |
Источник: Eugene Yan.
Несмотря на баги: сильный судья (GPT-4) совпадает с людьми на >80% — на уровне человек-человек. Это легитимизирует подход при правильной калибровке.
Источник: MT-Bench / Judging LLM-as-a-Judge.
Источники: Hamel judge, Who Validates the Validators?.
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.
Почему так: один критерий (не мультитул), binary (Likert шумит), критика (для error analysis), JSON (парсится кодом), явный запрет стиля/длины (лечит verbosity bias).
Code-based проверка всегда предпочтительнее: JSON-схема, regex, enum, «цифра баланса только из get_balance», account_id == session_id, SQL exec. Судья — только для того, что кодом не выражается.
Экономика: LLM-judge с CoT — деньги и латентность. Не вешай в горячий путь, если можно кодом.
Судья предпочитает длинные ответы — это?
Для фактов лучше скоринг?
Criteria drift — это когда?