LLM-as-judge: как мы оцениваем качество промптов автоматически
2025-12-15 · Елена Козлова
LLM-as-judge
Ручная разметка — дорогой, медленный и шумный процесс. Когда eval-сет разросся до 3000 примеров, мы перестали успевать ревьюить релизы и пошли в сторону LLM-as-judge. За два года накопили опыт, делимся честно.
Что такое judge-модель
Это LLM, которая читает пару (prompt, output) и возвращает оценку: от binary «correct / incorrect» до числового score 1–5 с объяснением. В ряде задач — попарное сравнение двух outputs.
Форматы, которые мы пробовали
| Формат | Точность (Cohen's kappa с людьми) | Применение |
|---|---|---|
| Binary «correct / incorrect» | 0.71 | Extraction, classification |
| Likert 1–5 | 0.58 | Generation quality |
| Pairwise «A лучше B / равно / B лучше» | 0.77 | A/B prompt testing |
| Rubric-based (multi-dim) | 0.68 | Complex outputs |
Pairwise — стабильно самый надёжный. Likert больше всего шумит.
Ключевые наблюдения
1. Judge должен быть не той же модели, что генерация. Иначе systematic bias — модель склонна одобрять свои же ответы. Мы используем Opus для судейства output'ов Sonnet/Haiku.
2. Rubric обязателен. «Оцени качество от 1 до 5» даёт 0.3 kappa. «Оцени по четырём критериям: точность, полнота, формат, стиль; каждому по шкале 1–3» даёт 0.65.
3. Calibration через golden set. Заведите 200 примеров с человеческими лейблами. Прогоняйте judge через них раз в неделю — следите, что kappa не деградирует.
Пример промпта
JUDGE_PROMPT = """Ты — оценщик качества ответов LLM. Даны задача, ожидаемый ответ (reference) и ответ модели.
Оцени ответ модели по 4 критериям (каждый от 1 до 3):
- accuracy: насколько фактически правилен
- completeness: покрыты ли все части запроса
- format: соответствует ли формату (JSON/markdown/plain)
- style: уместен ли тон
Task: {task}
Reference: {reference}
Model output: {output}
Верни JSON: {{"accuracy": n, "completeness": n, "format": n, "style": n, "reason": "..."}}"""
Где judge проваливается
- Редкие категории. На классах с <50 примерами kappa падает в 2 раза. Руками.
- Длинные outputs (>2k токенов). Модель теряет часть критериев.
- Задачи, где ответ «почти правильный». Judge часто ставит 3/3, человек — 2/3.
- Контекстно-зависимые нюансы. Сленг, корпоративная терминология, региональные правила.
Процесс в PromptLayer Hub
Релиз промпта v17 → судья прогоняет его на eval-сете (3000 запросов, ~25 минут, $18 на Opus) → если aggregate score упал более чем на 2 пункта против v16, release блокируется и улетает на human review. В 83% случаев решение judge совпадает с финальным решением человека.
Вывод
LLM-as-judge — не замена людям, а первичный фильтр, который резко сокращает объём ручной работы. Подход окупается почти сразу: мы перешли от «ревью релиза за 2 дня» к «ревью за 45 минут + автосигнал на деградации».
← Ко всем постам