Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Ошибочный JSON-вызов инструмента можно чинить по одному полю, не заставляя модель заново писать весь объект. В препринте, который не прошёл рецензирование, авторы сами получили для ContractRL больше успешных по смыслу исправлений, при этом ответ занимал 34,4 выходного токена против 137,2 у полной перегенерации. Для продуктовой команды это переносит основную работу с промпта на контракт: какие поля разрешено менять, сколько попыток дать модели и когда запретить выполнение.
Как контракт ограничивает каждый шаг ремонта
Полная перегенерация создаёт лишний риск: модель может исправить ошибочное поле, но заодно изменить аргументы, которые уже были верны и определяли намерение пользователя. ContractRL сохраняет исходный объект и предлагает локальный патч в формате JSON Patch по RFC 6902.
На каждом шаге модель видит текущий JSON, тип ошибки от проверяющего компонента, путь к проблемному полю, неизменяемую историю предыдущих действий и оставшийся бюджет. В ответ она выбирает патч, повторную попытку или отказ от ремонта.
До применения патча маска действий отбрасывает операции с неверным синтаксисом, недоступными путями и защищёнными полями. Она также запрещает некорректные источники для переноса или копирования и не пропускает патч, который превышает бюджет операций.
Допустимый патч получает детерминированный валидатор. Он проверяет схему и связи между полями, а при ошибке возвращает новый типизированный отчёт. Не прошедший проверку объект не попадает к инструменту, но попытка расходует бюджет; в основном протоколе модель могла предложить не более двух патчей.
Каждый патч, ответ валидатора, число попыток и изменения посторонних полей записываются в неизменяемый журнал. Эталонный объект и оценка смысла присоединяются только после фиксации журнала, поэтому модель не получает правильный ответ через контур проверки.
Обучение с подкреплением сравнивает несколько завершённых эпизодов ремонта. Награда поощряет вызов, который выполняет нужную задачу, и штрафует лишние изменения, повторы, расход токенов и запрещённые действия. Так модель учится не только выбирать патч, но и останавливаться, когда безопасного исправления нет.
Основное сравнение проводили на 192 случаях для каждого запуска и повторяли с пятью начальными значениями генератора случайных чисел. Отдельный экран BFCL включал 64 однополевые ошибки с заранее подготовленными патчами: он проверял валидатор и журнал, а не способность модели самостоятельно ремонтировать вызовы. Дополнительная проверка охватывала вложенные поля, массивы, несколько операций, откат и запрет изменения защищённых путей.
Локальные патчи реже меняли смысл вызова
Семантический успех означает, что исправленный вызов не просто соответствует схеме, а выполняет задуманное действие. При одинаковом наборе входных сведений ContractRL достиг 93,62% такого успеха, Patch-SFT — 90,76%, а полная перегенерация — 91,48%. Разница с Patch-SFT в отдельном парном сравнении была статистически значимой.
Преимущество проявилось и в сохранении уже правильных данных. Среднее число побочных изменений составило 0,0169 у ContractRL против 0,1876 у полной перегенерации. Под побочным изменением авторы считали затронутый конечный путь JSON, который не относился к исправляемому полю.
Удаление маски действий, истории ремонта, обученного решения об остановке или штрафа за побочные изменения ухудшало результат. Это указывает, что эффект даёт весь контур, а не только короткий формат ответа.
Типизированная обратная связь тоже помогала, однако контрольный опыт убирал целый блок проверки сразу. Поэтому работа подтверждает пользу сведений от валидатора, но не позволяет приписать весь выигрыш отдельно коду ошибки, указателю на поле или истории попыток.
Границы метода проходят по качеству контракта. Неверный указатель, повреждённый отчёт валидатора и ошибки сразу в нескольких полях оставались источниками сбоев. Маска может запретить опасное действие, но не способна восстановить намерение, которого нет в доступных модели данных.
Планы стоит менять на уровне контура исполнения
Работа не требует менять основную модель, которая создаёт вызов инструмента. Она предлагает добавить отдельный этап между первым отклонением JSON и повторным обращением к инструменту. Такой этап особенно уместен, когда большинство вызовов почти правильные, а изменение уже верных аргументов может вызвать побочный эффект.
Минимальный контур состоит из детерминированного валидатора, списка неизменяемых путей, ограниченного словаря патчей, бюджета попыток и явного отказа. После каждого действия система заново проверяет весь контракт и только затем разрешает выполнение. Журнал должен хранить исходный объект, патч, ответ валидатора и решение о передаче вызова инструменту.
Начинать внедрение разумно в теневом режиме на собственных ошибочных вызовах. Сравнивать нужно не только соответствие схеме, но и сохранение смысла, число затронутых полей, повторные попытки и расход токенов. Полная перегенерация остаётся полезной для исходного создания объекта и случаев, где ошибку нельзя локализовать.
Проверки проходили в детерминированной песочнице и на заданных семействах повреждений. Поэтому результаты поддерживают архитектуру защищённого ремонта, но не обосновывают автоматический повтор операций во внешних сервисах без их собственных разрешений, контроля побочных эффектов и наблюдения за выполнением.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
