LLM-судья и статистика оценок

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

LLM-as-a-judge — второй модель, которая оценивает ответ по критериям. Он дешёвый, быстрый и масштабируется на датасет, который человек не разметит за разумное время. Именно поэтому его легко переоценить.

Судья полезен для:

• первичной сортировки и отсева явных провалов;
• проверок стиля, тона и структуры;
• оценки по рубрике, где критерии сформулированы словами;
• группировки типовых ошибок и составления сводки.

Судья плох как единственный источник истины для:

• фактической корректности;
• безопасности и устойчивости к обходу политик;
• тонкой корректности кода;
• любых adversarial-задач, где оцениваемый текст может влиять на оценщика.

Смещения, которые труднее заметить, чем человеческие

• Позиция. В парном сравнении выигрывает вариант, стоящий первым.
• Длина. Более подробный ответ кажется более правильным.
• Самопредпочтение. Модель выше оценивает ответы, похожие на её собственные.
• Согласие с формулировкой. Уверенный и вежливый текст получает балл выше.

Из-за этого судью нельзя использовать «как есть» после смены модели или промпта: калибровка сдвигается вместе с оценщиком.

Рубрика вместо оценки «1–10»

Числовая оценка без критериев воспроизводится плохо: один прогон ставит 7, другой 8, и разница ничего не значит. Работает разложение на проверяемые пункты с бинарным решением.

{
  "criteria": [
    {"id": "answers_question", "question": "Ответ отвечает на заданный вопрос?", "pass": true},
    {"id": "grounded", "question": "Все утверждения подтверждены контекстом?", "pass": false, "evidence": "абзац 3"},
    {"id": "actionable", "question": "Есть конкретный следующий шаг?", "pass": true}
  ],
  "verdict": "fail",
  "reason": "Утверждение о сроках возврата не подтверждено контекстом"
}

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

Калибровка по людям

Судья годится, если его оценки совпадают с человеческими на представительной выборке. Процедура:

1. Взять 40–100 примеров, включая пограничные и провальные.
2. Разметить их людьми независимо, с теми же критериями.
3. Посчитать согласие: долю совпадений и ранг-корреляцию для парных сравнений.
4. Зафиксировать порог, ниже которого судье нельзя доверять рутинные решения.
5. Повторять калибровку после смены модели-судьи или рубрики.

Ориентир из практики: судью уровня Opus 4.1 сверили с людьми на 40 транскриптах и получили корреляцию Спирмена 0.86. Этого достаточно, чтобы сортировать и подсвечивать проблемы, но не чтобы выносить окончательный вердикт. Судья остаётся фильтром, финальное решение — за человеком.

pass^k против pass@k

Поведение модели вероятностное, поэтому один запуск — не измерение.

• pass@k — задача решена хотя бы в одном из k прогонов. Метрика исследовательская: показывает, что решение в принципе достижимо.
• pass^k — задача решена во всех k прогонах. Метрика продуктовая: пользователь не получает k попыток, он получает одну.

Для user-facing проверок нужен именно pass^k. Если агент проходит задачу в трёх случаях из пяти, пользователь увидит провал в 40% обращений, а pass@5 покажет 100%.

Доверительный интервал вместо процента

Тот же eval сегодня даёт 85%, завтра 80% — это нормальный разброс, а не деградация. Решение принимается не по голому проценту, а по интервалу и проверке значимости разницы.

// Интервал Уилсона для доли успехов: устойчивее нормального приближения
// на малых выборках и долях, близких к 0 или 1.
export function wilsonInterval(successes, total, z = 1.96) {
  const p = successes / total;
  const denominator = 1 + (z * z) / total;
  const centre = p + (z * z) / (2 * total);
  const margin = z * Math.sqrt((p * (1 - p)) / total + (z * z) / (4 * total * total));
  return {
    low: (centre - margin) / denominator,
    high: (centre + margin) / denominator,
  };
}

// 68 из 100 — «85%» с интервалом примерно 76–91%:
console.log(wilsonInterval(68, 100));

Практические выводы:

• Считайте интервал. На 20 кейсах разница 80% против 90% почти наверняка незначима.
• Не смешивайте кластеры. Несколько запросов одного пользователя коррелированы; дисперсия занижается, и разброс нужно учитывать отдельно — кластерные ошибки могут увеличивать дисперсию втрое.
• Сравнивайте на одном датасете. Разные наборы дают разные проценты независимо от качества.
• Планируйте объём. Для обнаружения разницы в 5 п.п. нужны сотни кейсов, а не десятки.

Тест формулировки

Определение хорошо сформулированной задачи: два эксперта, глядя на один и тот же ответ, независимо выносят одинаковый вердикт pass/fail. Если вердикты расходятся, проблема в формулировке задачи, а не в оцениваемой системе: критерий неоднозначен, эталон неполон или задача допускает несколько правильных решений.

Проверяйте это до масштабирования: неоднозначные кейсы портят и человеческую, и автоматическую разметку.

Что проверить в проекте

• Есть ли рубрика. Общая оценка «качество 1–10» не воспроизводима.
• Сверялся ли судья с людьми. Без калибровки его числа — мнение модели о модели.
• Используется ли pass^k для пользовательских сценариев. pass@k завышает надёжность.
• Считается ли интервал. Иначе шум принимается за улучшение.
• Пересматривается ли калибровка после смены модели. Судья и объект оценки меняются вместе.

Материалы и источники

• Evals: что должен знать каждый AI-инженер в 2026 — Артем Тарасов, LLM-as-judge и статистическая честность
• Anthropic: Demystifying evals for AI agents — pass^k, критерий двух экспертов
• Anthropic: A statistical approach to model evaluations — интервалы и кластерные ошибки
• Anthropic: Bloom — калибровка судьи и Spearman 0.86
• Hugging Face: LLM Evaluation Guidebook — смещения судьи