Почему модель-оценщик пропускает ошибки в траектории агента

В препринте, который не проходил рецензирования, Hadi Mohammadi из Utrecht University сравнил способы оценки LLM-агентов, работающих с инструментами. По замерам автора, проверка только итогового ответа пропустила больше половины ошибок, которые не изменили видимый пользователю результат. Работа важна командам, которые используют модель-оценщик как контроль качества, условие выпуска или источник сигнала для обучения агента.

Что сделали

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

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

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

Сравнение охватывало программные правила, модель-оценщик, видящую только запрос и ответ, пошаговые оценщики на Qwen2.5:14b и llama3.1:8b, а также голосование нескольких запусков Qwen. Инструменты оценивали по полноте — доле обнаруженных ошибок, точности локализации шага, правильности типа ошибки, ложным срабатываниям, времени работы и калибровке. Калибровка показывает, насколько заявленная моделью уверенность соответствует её фактической точности.

Что показали

Модель, получавшая только запрос и финальный ответ, обнаружила 45% скрытых ошибок против 84% явных. При этом она назвала ошибочными 33% правильных траекторий. Общая полнота маскировала этот разрыв: итоговый ответ действительно содержал признаки явного сбоя, но ничего не говорил о нарушении процесса, если требуемый результат всё же был достигнут.

Оценщик на той же модели, получавший полную последовательность действий, довёл полноту на скрытых ошибках до 77% и не пометил ошибочной ни одной чистой траектории. Он также почти всегда правильно находил шаг сбоя и лучше согласовывал уверенность с фактической точностью. Цена такого контроля по замерам автора — примерно 3× больше времени на одну траекторию.

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

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

Ограничения

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

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

Сравнение ограничено локальными Qwen и Llama. В работе нет замеров более крупных моделей, внешних API и оценщиков, специально обученных на траекториях конкретного продукта. Результаты также получены в одной среде генерации и не оценивают разброс между версиями моделей, инфраструктурой запуска и наборами рабочих сценариев. Заявленная уверенность одиночных оценщиков бралась из их собственного ответа, а не из независимой вероятностной модели.

Что это значит

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

Практическая схема контроля должна разделять несколько задач:

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

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

Источники

• trajectory-judge: What Outcome-Only LLM Judges Miss on Agent Trajectories

Иллюстрация: рисунок из статьи «trajectory-judge: What Outcome-Only LLM Judges Miss on Agent Trajectories», Hadi Mohammadi, CC BY 4.0