Перейти к основному содержимому

Судья — это компонент: версионирование пайплайнов LLM-as-Judge как любой другой зависимости

LLM-as-judge заслуживает доверия только тогда, когда модель-судья, промпт, рубрика и параметры декодирования зафиксированы и покрыты регрессионными тестами как полноценный артефакт.

Макросъёмка печатной платы с замысловатыми дорожками и компонентами, символизирующая версионируемые зависимости.

Тихий режим отказа

Когда вендор выпускает новый чекпоинт модели-судьи, выдаваемые ею оценки меняются. Тестируемая система не изменилась, но метрика изменилась. В большинстве схем оценки это смещение приписывается агенту, а не оценщику. Это тихий режим отказа LLM-as-judge: измерительный инструмент дрейфует, а дашборд сообщает об этом как об изменении измеряемого объекта.

Проблема усугубляется тем, что дрейф рубрики невидим. Промпт судьи накапливает правки со временем: здесь уточняющее предложение, там новый граничный случай. Нет ни диффа, ни владельца, ни теста. Число меняется, а причина — нет. К тому моменту, когда кто-то спрашивает, почему метрика сместилась, судья уже молча переоценил всю историю.

Что содержит спецификация судьи

Судья — это не модель. Это кортеж: идентификатор модели и хеш чекпоинта, температура и top-p декодирования, системный промпт, текст рубрики, few-shot примеры и схема вывода. Каждый элемент влияет на вердикт. Измените любой из них — и оценки изменятся.

Относитесь к этому кортежу как к записи в lock-файле. Запуск судьи без разрешаемой спецификации — это не измерение, а мнение. Спецификацию следует хранить вместе с версией набора для оценки и коммитом агента, который тестируется. Это делает каждую оценку воспроизводимой, а каждое сравнение — осмысленным.

На практике спецификация судьи может выглядеть так:

judge_spec:
  model: "vendor/model-name"
  checkpoint: "sha256:abc123..."
  temperature: 0.0
  top_p: 1.0
  system_prompt: |
    You are a strict evaluator. Score the response on a scale of 1-5 for correctness.
  rubric: |
    Correctness: 5 = fully correct, 3 = partially correct, 1 = incorrect.
  exemplars:
    - input: "What is 2+2?"
      output: "4"
      score: 5
    - input: "What is 2+2?"
      output: "5"
      score: 1
  output_schema:
    type: object
    properties:
      score: { type: integer, minimum: 1, maximum: 5 }
      reasoning: { type: string }

Close-up of a modern building facade with red steel beams in geometric patterns against a blue sky

Компромисс — это накладные расходы. Фиксация и версионирование каждого судьи добавляют трения в экспериментирование. Но альтернатива — метрика, которой нельзя доверять, а это хуже, чем отсутствие метрики вообще.

Калибровка по человеческим меткам

Судья — это прокси для человеческого суждения. Чтобы понять, насколько хорош этот прокси, нужен фиксированный набор якорных примеров с человеческими метками. Это небольшой набор примеров, по которым люди согласились относительно правильного вердикта. Прежде чем доверять любому последующему сравнению, сообщайте о согласии судьи на этом якорном наборе.

Согласие следует отслеживать по каждому измерению рубрики, а не как единую агрегированную точность. Судья может соглашаться с людьми в 90% случаев по корректности, но только в 60% по тону. Агрегирование это скрывает. Отслеживание по измерениям показывает, где судья слаб и где необходимо человеческое ревью.

Помечайте измерения с низким согласием и направляйте их на человеческое ревью, а не на автоматические гейты. Это форма активного обучения: судья сообщает вам, где он не уверен, и вы тратите человеческие усилия именно там. Компромисс в том, что человеческое ревью медленное и дорогое, поэтому вы не можете делать его везде. Якорный набор должен быть небольшим и стабильным, а правило маршрутизации — явным.

Регрессионные тесты для оценщика

Судья — это код. У него должны быть тесты. Самые базовые — это заведомо хорошие и заведомо плохие траектории с ожидаемыми вердиктами. Если изменение судьи переворHigh voltage power line and insulators against a clear blue skyators-fe71ad-47747d.jpg) Server rack closeup

Состязательные случаи не менее важны: многословные, но неверные ответы, лаконичные, но верные ответы, отказы и выводы, состоящие только из вызовов инструментов. Они проверяют, чувствителен ли судья к поверхностной форме, а не к сути. Судья, который оценивает многословный неверный ответ выше лаконичного верного, измеряет не то, что вы думаете.

Стабильность оценок — ещё один тест. Повторная оценка одной и той же траектории не должна отклоняться сверх объявленного допуска. Если судья недетерминирован, эта дисперсия является частью ошибки измерения и должна быть указана. Судья, дающий разные оценки на идентичных входах, — ненадёжный инструмент.

Компромисс здесь — поддержка тестов. Каждый новый граничный случай становится тестом. Но цена сломанного судьи — испорченная история оценок, которую гораздо дороже восстановить.

Расхождение между судьями как сигнал

Запуск двух судей из разных семейств моделей на выборке может локализовать неоднозначный язык рубрики. Когда они расходятся, это часто происходит потому, что рубрика неясна, а не потому, что один из судей неправ. Расхождение — это отчёт о дефекте рубрики, а не ничья, которую нужно усреднить.

Публикуйте уровень расхождения рядом с оценкой, чтобы читатели знали погрешность. Оценка 4,2 при уровне расхождения 30% сильно отличается от оценки 4,2 при уровне расхождения 2%. Первое говорит о том, что рубрика требует доработки; второе — о том, что судьи согласованы.

Компромисс — это стоимость: запуск двух судей удваивает инференс. Но информация о качестве рубрики часто того стоит, особенно во время разработки рубрики.

Заключение

LLM-as-judge — мощная техника, но она надёжна ровно настолько, насколько надёжно её слабейшее звено. Зафиксируйте модель, промпт, рубрику и параметры декодирования. Версионируйте их, как любую другую зависимость. Покройте оценщика регрессионными тестами. Калибруйте по человеческим меткам. Относитесь к расхождению между судьями как к сигналу, а не шуму. Когда судья — это компонент, оценка становится измерением.

ПоделитьсяXLinkedInПостоянная ссылка4 мин чтения

Связанное чтение

На какие вопросы это отвечает

What is a judge specification?

A judge specification is the tuple of model identifier and checkpoint hash, decoding parameters, system prompt, rubric text, few-shot exemplars, and output schema that defines a judge. It should be versioned like a lockfile entry.

How do you regression-test a judge?

Use known-good and known-bad trajectories with expected verdicts, adversarial cases, and score stability checks. A judge change that flips these tests fails CI.

Why track judge agreement per rubric dimension?

Aggregate accuracy hides weak dimensions. Per-dimension agreement reveals where the judge is unreliable and should route to human review.

What does cross-judge disagreement indicate?

Disagreement between judges from different families often indicates ambiguous rubric language. It is a rubric defect report, not a tie to be averaged away.