Судья-модель для автооценки: где верить, а где проверять

Почему модель-судья ошибается

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

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

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

Средний балл тоже хорошо прячет сбои. Представьте 100 ответов: 90 простых случаев судья оценивает почти без промаха, а в 10 редких системно пропускает опасную ошибку. На графике все выглядит прилично, потому что среднее осталось высоким. Для команды это ловушка: редкие случаи часто и стоят дороже всего.

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

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

Когда автооценке можно верить

Автооценка полезнее всего там, где ответ можно проверить почти по шаблону. Чем меньше места для вкуса и догадок, тем ровнее результат. Если задача сводится к тому, есть ли нужное поле, соблюден ли формат и не вышел ли ответ за лимит, модель-судья обычно справляется нормально.

Самый надежный случай - проверка формы ответа. Вернул ли LLM JSON, есть ли обязательные поля, совпадают ли типы, не пропущен ли атрибут, не превышена ли длина текста. Здесь модель ищет конкретные признаки, а не спорит о смысле.

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

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

На старте обычно хватает трех безопасных применений:

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

Если модель-судья ошибется в таких задачах, команда потеряет время, а не клиента или деньги. Это подходящий режим для первых запусков.

В рабочей системе такой слой часто ставят первым. Если команда гоняет трафик через единый LLM-шлюз, такие проверки удобно автоматизировать рано, а ручной просмотр оставить для спорных задач, где смысл ответа важнее формы. Например, в AI Router можно прогонять несколько моделей через один OpenAI-совместимый эндпоинт и держать одинаковый сценарий проверки без переписывания SDK, кода и промптов.

Когда нужна ручная выборка

Ручная выборка нужна там, где у хорошего ответа нет одной правильной формы. Модель-судья любит шаблонный стиль: коротко, ровно, без спорных деталей. Из-за этого она часто занижает сильный ответ просто потому, что тот написан не так, как ожидала рубрика.

Это особенно заметно в задачах с открытым текстом. Два ответа на жалобу клиента могут быть одинаково полезны, но один звучит мягче, а другой прямее. Человек увидит уместный тон и смысл. Модель нередко выберет тот вариант, который больше похож на примеры из промпта.

Есть случаи, где без людей лучше не обходиться вообще. Это медицинские, правовые и финансовые ответы, где одна неточная фраза меняет смысл. Это проверка фактов, если у вас нет надежного эталона или базы для сверки. Это запросы, где можно случайно раскрыть PII, нарушить внутренние правила или требования закона. И это редкие ошибки с высоким ущербом, даже если они случаются раз в 500 ответов.

Доменные задачи опасны по простой причине: модель-судья может звучать уверенно и все равно пропускать ошибку. В медицинской сводке она не заметит, что совет противоречит симптомам. В банковском ответе может одобрить двусмысленное объяснение отказа. В правовом тексте иногда считает ответ полным, хотя в нем нет нужной оговорки.

С фактами та же история. Если эталона нет, модель начинает оценивать не истинность, а правдоподобие. Для новостей, отраслевых обзоров и кратких рыночных справок этого мало. Человек должен читать хотя бы часть выборки и отдельно смотреть источники, даты, цифры и имена.

Отдельная зона риска - безопасность и комплаенс. Если система работает с заявками, чатами клиентов или внутренними документами, ручная проверка должна смотреть не только на качество ответа, но и на то, не утекли ли ФИО, номер счета, телефон или другие личные данные. Для банков, телекома, госсектора и healthcare это обычная рабочая проверка, а не лишняя осторожность.

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

Как собрать рубрику без размытых формулировок

Модель-судья начинает путаться, когда вы просите ее одним числом оценить все сразу. Формулировка вроде "качество ответа" звучит удобно, но внутри обычно смешаны точность, полнота, стиль, формат и безопасность. Лучше разложить оценку на отдельные критерии и проверять каждый по своей шкале.

Для обычной задачи LLM часто хватает четырех критериев:

• точность фактов;
• выполнение инструкции;
• соблюдение формата;
• безопасность ответа.

Если у вас рабочий сценарий с повышенным риском, критерии стоит привязать к реальным сбоям. Для банковского или медицинского кейса полезно отдельно оценивать утечку PII. Для интеграций через API - соблюдение JSON-схемы. Тогда рубрика перестает оценивать общее впечатление и начинает ловить конкретные ошибки.

Каждому критерию нужна короткая шкала с примерами. Обычно хватает 0, 1 и 2. Больше градаций часто только мешает: и люди, и модель начинают спорить о соседних баллах вместо сути.

Для критерия "соблюдение формата" шкала может быть такой: 0 - ответ не в том формате или ломает парсинг; 1 - формат почти верный, но пропущено поле или есть лишний текст; 2 - ответ полностью проходит проверку. Для "точности фактов" логика похожая: 0 - есть выдумка или прямое противоречие данным; 1 - мелкая неточность без вреда для задачи; 2 - факты совпадают с источником.

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

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

Перед запуском дайте рубрику двум разметчикам на одной и той же выборке. Часто хватает 30-50 ответов. Если люди регулярно расходятся по одному критерию, проблема почти всегда в формулировке шкалы, а не в людях. Исправьте это до запуска автооценки. Иначе модель-судья просто унаследует ту же путаницу.

Как настроить проверку по шагам

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

1. Соберите 100-300 примеров из продукта. Добавьте не только обычные запросы, но и короткие, грязные и спорные.
2. Разметьте часть набора вручную. Для первого прохода часто хватает 30-50 примеров, если их смотрят два человека по одной рубрике.
3. Разберите расхождения между людьми. Если разметчики спорят, причина обычно в расплывчатом критерии.
4. Прогоните тот же набор через модель-судью и сравните оценки по каждому критерию, а не только общий балл.
5. Исправьте рубрику и повторите цикл на новом срезе, а не на тех же примерах.

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

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

Небольшой пример быстро показывает перекос. Допустим, судья ставит высокую оценку кратким резюме звонка, даже если в тексте нет суммы платежа. По общему совпадению с ручной разметкой вы видите 82%. Звучит неплохо. Но по критерию "есть обязательные факты" совпадение падает до 54%. Значит, рубрика слишком мягкая или сам судья не понимает, что пропуск суммы ломает ответ.

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

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

Пример системной ошибки на реальной задаче

Представьте чат поддержки, который отвечает только по базе знаний компании. На обычных вопросах он работает ровно, а ошибки всплывают на запросах с исключениями.

Запрос клиента: "Я уже оплатил заказ. Можно поменять адрес доставки, если посылку передали курьеру?" В базе знаний сказано, что менять адрес можно не всегда. Если заказ уже у внешней службы доставки, нужен новый заказ или отдельное согласование с оператором.

Бот отвечает очень вежливо: "Да, конечно. Я помогу изменить адрес. Обычно это занимает до 2 часов". Ответ звучит хорошо, но он неточный. Бот пообещал действие, которого в правилах может не быть.

Модель-судья часто завышает такой ответ. Она видит вежливый тон, понятную структуру и попытку помочь. Если в рубрике есть только полезность, ясность и тон, судья легко ставит 4,5 из 5. Люди ставят 2 из 5, потому что клиент получил ложное обещание.

Где расходятся люди и судья

На выборке из 200 диалогов расхождение обычно видно сразу. На простых FAQ оценки почти совпадают. На запросах с исключениями разница уже большая.

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

Что менять в рубрике

После такого сбоя команде нужна рубрика, где фактическая точность живет отдельно от вежливости. Обычно помогает несколько прямых правил:

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

После этого ручная выборка уже не выглядит лишней перестраховкой. Для случаев с исключениями лучше смотреть вручную 100% диалогов хотя бы в первые 2-3 недели. Если поток слишком большой, проверяйте минимум 30% таких случаев и держите 10% обычных диалогов как контрольную группу.

Иначе ошибка модели-судьи останется незаметной: бот будет казаться вежливым и полезным, пока поддержка не начнет разбирать жалобы клиентов.

Частые ловушки при запуске

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

Поэтому рубрику лучше держать раздельной. Фактическую точность оценивайте отдельно. Покрытие запроса отдельно. Формат или тон - тоже отдельно, если они действительно важны для задачи. Иначе потом сложно понять, что именно просело после смены модели или промпта.

Вторая ловушка возникает, когда команда проверяет рубрику на одном типе запросов, а потом ждет такой же стабильности везде. На FAQ, суммаризации звонков и юридических черновиках судья ошибается по-разному. Если рубрику проверили только на коротких вопросах поддержки, она легко поплывет на длинных ответах с несколькими условиями и оговорками.

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

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

С версиями часто бывает совсем приземленная проблема. Команда чуть меняет инструкцию судьи, видит рост на 4-5 пунктов и думает, что качество выросло. На деле изменилась шкала. Если вы прогоняете оценки через единый OpenAI-совместимый шлюз, полезно фиксировать не только текст промпта, но и точное имя модели, провайдера и дату смены конфигурации.

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

Что проверить перед запуском

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

Сначала соберите ручную выборку. В нее должны входить не только аккуратные и короткие ответы, но и сложные случаи: спорные запросы, неполные данные, длинный контекст, несколько ограничений сразу. Если команда внедряет LLM в банке, телекоме, госсекторе или healthcare, рискованные кейсы лучше вынести в отдельный набор. Именно там модель-судья чаще всего ошибается с уверенным видом.

Перед запуском полезно проверить несколько вещей:

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

Небольшой тест быстро отрезвляет. Если модель стабильно прощает фактические ошибки, но строго наказывает за тон или формат, вы увидите это уже на первых десятках примеров. Такой перекос лучше поймать до запуска, а не после квартала отчетов.

Если цена ошибки выше, чем выигрыш от скорости, остановите автооценку на этом участке. Вернитесь к рубрике, добавьте примеры, пересоберите ручную выборку и только потом включайте автоматический суд заново. Быстрый запуск сам по себе ничего не дает, если команда потом вручную разгребает неверные оценки.

Что делать дальше

Модель-судья полезна, пока у нее узкая зона ответственности. Оставьте автоматическую проверку для простых задач: формат, обязательные поля, явные нарушения политики, совпадение с эталоном по понятным правилам. Все, что связано со смысловыми нюансами, спорной полнотой ответа или неочевидной пользой для человека, лучше проверять ручной выборкой.

Ручная проверка не обязана быть большой. Часто хватает 30-50 ответов на каждый спорный сценарий, чтобы увидеть повторяющуюся ошибку. Если модель-судья раз за разом ставит высокий балл вежливому, но пустому ответу, проблема уже не в одном промпте, а в самой рубрике или в классе задач.

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

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

Если вы тестируете судью у разных провайдеров, удобно прогонять все через один совместимый интерфейс. В AI Router можно отправлять такие прогоны через один OpenAI-совместимый эндпоинт и не менять SDK, код и промпты при смене модели. Это полезно, когда вы сравниваете несколько кандидатов на одной и той же рубрике и хотите, чтобы различия шли от модели, а не от инфраструктуры.

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