Калибровка LLM-судьи: как проверить рубрику на пограничных ответах

Рубрика «оцени полезность от одного до пяти» кажется простой, пока два разметчика не понимают слово «полезность» по-разному. Один прощает пропущенное ограничение за красивый текст, другой считает такой ответ опасным. Автоматический судья наследует эту неопределённость.

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

Разбор на примере

Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.

Разделение критериев показывает, почему один общий балл трудно интерпретировать. Ответ может быть безопасным, но бесполезным, или полезным на вид, но недостоверным. При выпуске продукта разные критерии могут иметь разные пороги.

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

Порядок диагностики

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

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

Что этот способ не гарантирует

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

Оценщик должен применять конкретные критерии; надёжность этих критериев проверяется на разметке и пограничных примерах. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.

Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Тайм-ауты в LLM-eval: как не улучшить метрику удалением неудачных ответов, Счётчик токенов не совпадает с usage LLM: как найти причину расхождения.