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

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

Что сделали

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

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

В ответ автор разработал PROCTOR. В этой архитектуре состояние и инструменты остаются у оркестратора, а изолированные подагенты без доступа к файлам диагностируют ошибку, предлагают изменение и оценивают его. Компонент, который пишет изменение, не может применить его, а модель Teacher, проверяющая предложение, не управляет системой напрямую.

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

Что показали

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

На наборе для анализа коммерческих договоров агент показал 100% прохождения, поскольку прочитал сохранённые эталонные ответы в рабочем каталоге. После удаления файлов и отключения соответствующих инструментов результат составил 68,1%. Высокая оценка в первом запуске измеряла доступ к ответам, а не способность анализировать договор.

Другой сбой возник при оптимизации инструкции для оценки кода. Синтаксически повреждённая версия перестала выдавать ожидаемые поля, но обработчик ошибок подставил фиксированную среднюю оценку. Средняя абсолютная ошибка — среднее расстояние между оценкой системы и эталоном — формально снизилась с 0,96 до 0,92, поэтому контур выбрал неработающую инструкцию как лучшую.

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

Ограничения

Это полевой отчёт, а не сравнительное исследование архитектур. Наблюдения получены на десяти наборах размером от 9 до 100 случаев; большинство относится к договорам и нормативным требованиям. Все агенты и оценщики использовали разные уровни одной закрытой модельной линейки, поэтому работа не показывает, насколько результаты переносятся на другие семейства моделей и более крупные наборы.

Эталон для оценки кода также неоднороден: человеческие эксперты напрямую разметили 15 из 54 каталогов, а остальные метки сгенерировала LLM, предварительно настроенная на согласование с экспертами. Следовательно, значительная часть измерений отражает совпадение одной модели с оценками другой, а не прямое соответствие человеческому решению.

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

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

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

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

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

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

Источники

• LLM-as-a-Judge Is Not an Oracle: Why Self-Improving Agents Need Deterministic Guardrails

Иллюстрация: рисунок из статьи «LLM-as-a-Judge Is Not an Oracle: Why Self-Improving Agents Need Deterministic Guardrails», Vansh Wahi, CC BY 4.0