Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Ревьюер LLM-агента может исправлять ошибки и одновременно портить уже верные решения: итог зависит не только от качества модели, но и от того, какие изменения система разрешает ей применять. В нерецензированном препринте Fuad Ali, где все числа получены самим автором, проверяемое правило допуска сохранило правильные решения лучше, чем безусловная замена. Для продуктовой архитектуры это означает, что второй вызов модели сам по себе не создаёт надёжный контроль.
Как отделили рекомендацию от права её применить
В эксперименте первый агент выбирал один вариант из семи. Он должен был сначала выполнить защищённое требование — например, уложиться в бюджет или обеспечить минимальный охват группы, — а затем выбрать лучший допустимый вариант по общей пользе.
Предложение первого агента могло быть правильным, нарушать защищённое требование или выполнять его, но уступать другому допустимому варианту. Ревьюер видел исходную задачу и предложение, после чего выдавал структурированную запись с оценкой нарушения и рекомендуемой заменой.
При широких полномочиях любая корректно оформленная рекомендация становилась итоговым решением. Правило допуска по доказательству разрешало замену только тогда, когда запись ревьюера механически подтверждала две вещи: исходный вариант нарушает защищённое требование, а новый вариант его выполняет. Простого заявления модели было недостаточно.
Ключевая деталь эксперимента — одну и ту же рекомендацию применяли по двум правилам. Поэтому различие в результате создавал не новый ответ модели, а только область её полномочий. Такое сравнение отделяет способность найти ошибку от права переписать решение.
Проверка охватывала Qwen3-8B и Mistral-Small-24B-Instruct-2501, запущенные локально, а также два синтетических набора по 96 заданий: выбор пространственной политики и перенос портфеля проектов. Варианты представляли собой структурированные таблицы с заранее вычислимым правильным ответом. Работа поэтому проверяет механизм на дискретных задачах, а не поведение открытых агентов, внешние инструменты или модели из коммерческих API.
Право на замену определило, какие ошибки дошли до результата
В пространственных задачах широкое правило испортило 85 из 96 правильных предложений у каждой модели. Допуск по доказательству оставил такие предложения без изменений, потому что ревьюер не мог подтвердить нарушение защищённого требования.
За эту защиту пришлось заплатить сокращением области исправлений. Если предложение соблюдало обязательное требование, но не было лучшим по общей пользе, правило запрещало ревьюеру улучшить его. На портфельных задачах широкие полномочия заметно чаще находили оптимальный вариант, поэтому универсального победителя по качеству итогового решения не получилось.
Отдельный опыт добавил ревьюеру явный выбор: сохранить решение, заменить его или передать выше. На 48 задачах Qwen сохранил все правильные предложения и отказался от всех улучшений, которые касались только общей пользы. Mistral, напротив, заменил каждое правильное предложение; при этом среди допустимых, но неоптимальных вариантов он находил точный оптимум в 62,5% случаев. Ни одна модель не выбрала передачу выше.
Одинаковое меню действий породило противоположные стратегии. Для Qwen оно стало консервативным запретом на вмешательство, а для Mistral — почти постоянным разрешением на замену. Значит, команда не может считать кнопку «сохранить» или «передать выше» самостоятельной защитой: модель ещё должна научиться пользоваться ею в нужных состояниях.
На предложениях, которые модели генерировали сами, часто встречалась другая проблема: они слишком усердно оптимизировали защищённое требование и не находили лучший вариант среди допустимых. Это увеличивало пользу широкого ревью, но одновременно оставляло ему возможность испортить редкие правильные ответы. Итог зависел от того, какие исходные состояния преобладали у конкретной модели.
Что менять в архитектуре агентной системы
Работа меняет планы команд, у которых есть формализуемые обязательные условия: лимиты бюджета, права доступа, требования к происхождению данных, минимальный охват или другие проверяемые инварианты. В таких системах ревьюер не должен напрямую исполнять любую предложенную замену. Между его ответом и действием нужен детерминированный слой авторизации.
- Разделить совет и полномочие. Ревьюер формирует рекомендацию и доказательство, а обычный код решает, может ли рекомендация изменить состояние системы.
- Проверять узкое утверждение. Сертификат должен подтверждать конкретное нарушение и допустимость исправления. Он не обязан доказывать, что модель рассуждала правильно во всём остальном.
- Развести обязательные и желательные улучшения. Нарушение проверяемого правила можно исправлять автоматически. Замену ради качества, стоимости или общей пользы безопаснее отправлять другому ревьюеру, человеку или более дорогому процессу проверки.
- Измерять переходы между состояниями. Общая точность ревьюера скрывает главное: как часто он сохраняет правильное решение, исправляет нарушение и портит допустимый результат.
Если критерий нельзя проверить механически, такой допуск теряет основу: код не отличит доказательство от уверенного текста модели. Тогда работа не предлагает готовой защиты, но оставляет полезное требование к испытаниям — отдельно проверять качество рекомендаций, интерфейс действий и правила, по которым рекомендации получают силу.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
