Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агентную обвязку научились улучшать автоматически так, чтобы она реже подгонялась под набор задач, на котором её настраивали. На незнакомых бенчмарках обвязка прибавила до 4,7 пункта; препринт не рецензирован, а числа в нём получили сами авторы. Автоматическую настройку агента теперь можно строить не только вокруг лучшего результата на тестах, но и вокруг переноса изменений и расхода токенов.
Почему агент начинает запоминать задачи
Обвязка агента — это всё вокруг замороженной LLM: системные инструкции, порядок вызова инструментов, память, управление контекстом, обработка ошибок и условия остановки. Она определяет, прочитает ли агент нужный файл, восстановится ли после неудачной команды и сохранит ли результат в требуемом формате.
Автоматическая настройка превращает эту обвязку в редактируемую программу. Модель анализирует неудачные траектории, предлагает изменения, запускает кандидатов на задачах и сохраняет вариант с лучшей оценкой. Затем цикл повторяется.
Проблема возникает из-за многократного использования одного конечного набора. Каждый следующий кандидат опирается на результаты предыдущих проверок, поэтому поиск постепенно учит особенности конкретных заданий, их проверяющих программ и случайных колебаний оценки. Рост результата внутри набора перестаёт означать, что агент действительно стал лучше.
RRSI не запрещает менять отдельные части обвязки. Вместо этого метод ограничивает путь поиска. В начале кандидат может объединять несколько связанных правок, но с каждым раундом допустимое число изменений уменьшается. Так проще установить, какой механизм дал прирост, и сложнее замаскировать под него набор мелких подгонок.
История поиска хранит гипотезу каждой правки, изменённый компонент, разницу в коде, оценку, стоимость и решение о принятии. Отклонённые идеи остаются отрицательным свидетельством. Если поиск застревает на переписывании инструкций, часть бюджета направляют на компоненты, которые он ещё не пробовал менять.
Отбор учитывает утечки, шум и стоимость
До полноценного запуска отдельная модель-критик проверяет разницу между версиями. Она отклоняет правки с названиями задач, конкретными значениями, ответами и логикой, которая относится только к настроечному бенчмарку. Такой кандидат не получает завышенную оценку и не влияет на следующие раунды.
Перед поиском базовую обвязку запускают несколько раз и определяют обычный разброс результата. Кандидат не принимают, если его преимущество укладывается в этот шум или если он незаметно ведёт поиск вниз через последовательность небольших ухудшений.
Рост расхода токенов также должен соответствовать приросту качества. Изменение, которое добавляет длинные рассуждения или новые обращения к модели без измеримой пользы, не проходит отбор. Компоненты, которые перестали помогать, становятся целями для удаления, поэтому сложность не накапливается только потому, что однажды попала в обвязку.
Перенос оказался скромнее настроечного прироста, но устойчивее
Метод проверили на восьми бенчмарках из трёх областей: программирование, работа с документами и инженерное проектирование. В каждой области обвязку меняли на отдельном наборе, а затем без дополнительной настройки переносили на другие задачи с иными инструментами или проверкой.
На наборе, который направлял поиск, максимальный прирост составил 14,1 пункта. На внешних задачах улучшились все проверенные разбиения, а финальная обвязка тратила на 30% меньше токенов основной модели, чем нерегуляризованный поиск. В лучшем сравнении с усреднённым результатом прежних методов преимущество достигло 22,9%.
Эксперимент с удалением частей RRSI показывает разницу между оптимизацией теста и улучшением механизма. Без ограничений система получила самый высокий результат на настроечном наборе, но на внешних задачах вернулась почти к исходной обвязке и стала дороже. Отдельные запуски с Claude и Gemini сохранили тот же рисунок, а найденная обвязка помогла и более слабой модели, которая не участвовала в поиске.
Планы стоит менять на уровне процесса отбора
Работа не означает, что автоматическая эволюция уже заменяет ручную разработку агентов. Она предлагает более строгий контур экспериментов: разделять задачи для поиска и проверки, хранить историю гипотез, проверять правки на утечки и принимать рост стоимости только вместе с измеримым приростом качества.
Для команды, которая уже автоматически переписывает инструкции, инструменты или управление контекстом, главный пересмотр касается критерия успеха. Лучший кандидат на настроечном наборе не должен автоматически становиться новой версией агента. Нужны независимые задачи и отдельные пороги для качества, стабильности и стоимости.
Расход всё равно растёт относительно исходной обвязки: в одном из опытов RRSI требовал 2,42 миллиона токенов на попытку против 1,56 миллиона у базовой версии. Значит, регуляризация сокращает избыточные вычисления, но не превращает улучшение в бесплатное.
Проверка касается обвязок с замороженными весами модели и конечным бюджетом поиска. Результаты получены на задачах с кодом, рабочими документами и инженерным проектированием; они не отвечают на вопрос, как тот же подход поведёт себя при обучении весов, в других агентных архитектурах или в существенно более длинных циклах самоулучшения.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
