Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Локальную правку инструкций для LLM-агента нельзя сохранять только потому, что она исправила один сбой: после объединения с другими правками она может нарушить дальнейшее выполнение. В препринте команды Amazon метод RIPPLE дал прирост доли процессов, прошедших проверку, до 23,1%, хотя работа не рецензирована, а замеры выполнили сами авторы. Для команд это превращает обновление промпта из набора независимых исправлений в последовательную сборку с повторной проверкой каждого изменения.
Почему место правки не ограничивает её эффект
Работа рассматривает агентов, которые создают исполняемые процессы в JSON. Такой результат должен соответствовать схеме, правильно связывать шаги, использовать актуальные идентификаторы ресурсов и проходить проверку внешнего сервиса. Правдоподобный ответ здесь бесполезен, если его нельзя выполнить.
Модель при этом остаётся замороженной: команда не меняет её веса, инструменты и среду выполнения. Меняется политика агента — набор инструкций, который определяет, как он понимает запрос, планирует действия, вызывает инструменты, редактирует результат и исправляет ошибки.
Политику заранее делят на смысловые сегменты. Исправление ошибки при вызове инструмента можно добавить только в соответствующий сегмент, не переписывая весь промпт. Такую правку проще проверить, откатить и связать с конкретным сбоем.
Но локальной остаётся только запись в промпте, а не её последствия. Новое правило может изменить вызовы инструментов, выбор ресурсов, структуру процесса и реакцию на ошибку проверки. Две полезные по отдельности инструкции также могут противоречить друг другу после объединения.
Поэтому RIPPLE разделяет два решения. Сначала он определяет, где исправить политику. Затем отдельно проверяет, безопасно ли сохранять исправление поверх уже принятых изменений.
Как RIPPLE выбирает и сохраняет правку
На каждом учебном задании агент выполняет три независимых прогона. Система оценивает, прошёл ли результат внешнюю проверку, реализует ли он требуемую логику, не вышло ли редактирование за заданные границы и сколько ресурсов потребовало выполнение.
Для разбора RIPPLE выбирает задания, на которых результаты сильнее всего различаются между прогонами. Из каждого такого задания он берёт худшую траекторию: журнал действий, созданный процесс, ответы инструментов и сообщение проверяющего сервиса.
Сбой классифицируют детерминированные правила, а не ещё один вызов LLM. Они различают, например, пропущенное уточнение, неправильный порядок инструментов, нарушение схемы, неудачное исправление после проверки, лишние изменения и незавершённый результат. Если один ранний сбой породил несколько симптомов, основным считают причинно более ранний.
Каждому классу ошибки соответствует сегмент промпта и ограниченная правка из версионируемой библиотеки. RIPPLE не просит модель свободно переписать инструкции: он добавляет заранее определённый фрагмент в назначенное место. Благодаря идентификатору правки получившуюся политику можно просмотреть и откатить.
Все кандидаты сначала запускают от одной и той же версии политики в начале итерации. Это позволяет сравнить их изолированный вклад: правки, которые не улучшают совокупную оценку, отсеиваются, а остальные получают порядок по размеру выигрыша.
После этого начинается повторная проверка. Первый кандидат запускают поверх текущей политики; если он проходит условия по общей оценке и корректности процесса, его принимают. Следующий кандидат проверяют уже вместе с принятой правкой. Базовая линия сдвигается после каждого решения, поэтому тест соответствует версии политики, в которой изменение действительно останется.
Корректность проверяют отдельно от совокупной оценки. Иначе улучшение доли успешно проверенных процессов или сокращение лишних действий могло бы скрыть ухудшение требуемой логики. Повторные прогоны здесь служат эмпирическим фильтром, а не гарантией для любого будущего запроса.
Когда схема меняет планы разработки
Метод проверяли на синтетическом отложенном наборе Flow-HO с 39 заданиями по созданию и изменению процессов. Основные эксперименты провели с Claude Haiku 4.5, а перенос подхода — с Gemma 12B и Ministral 14B. Модели, интерфейсы инструментов и среда оставались неизменными.
Самый наглядный результат связан не с итоговой средней оценкой, а с одной отклонённой правкой. Она ограничивала поиск ресурсов только новыми ссылками и выглядела полезной отдельно. После четырёх ранее принятых изменений доля процессов, прошедших проверку, упала с 35,4% до нуля: старые идентификаторы из повреждённого входа начали попадать в итоговый процесс.
Для агента с внешней проверкой работа предлагает практическую архитектуру контура улучшений. Промпт стоит делить по этапам поведения, ошибки связывать с наблюдаемыми признаками в журнале, исправления хранить как небольшие версионируемые патчи, а каждый патч проверять поверх текущей сборки, а не исходного промпта.
Схема особенно применима там, где агент создаёт JSON, конфигурации инфраструктуры или автоматизации для сервисов и результат можно проверить программно. Если команда уже редактирует общий промпт после отдельных инцидентов, главный пересмотр плана касается критерия сохранения: успешный локальный тест недостаточен без повторного прогона всей накопленной политики.
Flow-HO остаётся синтетическим набором, поэтому работа показывает механизм взаимодействия правок в контролируемой среде, а не готовую оценку для производственных процессов. Перед внедрением понадобится собственный набор повторной проверки, который отражает реальные типы процессов, инструменты и правила корректности продукта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
