ModularRSI: агенты учатся улучшать себя по пяти модулям

ModularRSI: агенты учатся улучшать себя по пяти модулям

Recursive self-improvement (рекурсивное самоулучшение, RSI) для агентных «обвязок» (harness), систем, которые управляют тем, как агент выполняет длинные задачи по кодингу и работе в терминале, сталкивается с проблемой обобщаемости. Авторы называют три причины. Во-первых, обвязку часто эволюционируют прямо на бенчмарках оценки или их частях, из-за чего трудно отличить настоящее переносимое улучшение от подгонки под конкретный тест. Во-вторых, правки по одной траектории решения задачи смешивают системные недостатки обвязки с деталями конкретного случая, и такие изменения плохо переносятся на незнакомые задачи. В-третьих, в монолитной обвязке трудно локализовать повторяющиеся поведенческие сбои, а оптимизация всей обвязки целиком путает между собой разные механизмы и мешает понять, что именно сработало.

В ответ на это предложен ModularRSI, фреймворк, отделённый от бенчмарков (benchmark-disjoint), контрастный и модульный. Он сравнивает успешные и неуспешные траектории решения одной и той же задачи и собирает такие сравнения по множеству задач, чтобы находить именно повторяющиеся недостатки поведения, а не случайные. Эволюционируемая обвязка разбита на пять функциональных модулей: цикл агента (Agent Loop), использование инструментов (Tool Use), управление наблюдениями (Observation Management), управление контекстом (Context Management) и определение завершения задачи (Task Completion Detection). Каждый модуль эволюционирует независимо в рамках ограниченной зоны модификации, после чего на этапе интеграции эволюционировавшие модули объединяются в единую обвязку с разрешением возможных конфликтов между ними. Чтобы эволюция не подстраивалась под тестовые бенчмарки, авторы собрали 2000 исполняемых задач для эволюции из внешних источников, не пересекающихся с бенчмарками, на которых метод потом проверяется.

Эксперименты на TB2.0 и SWE-Bench Verified показывают устойчивые улучшения на незнакомых задачах, как внутри исходного домена, так и в других доменах, при этом эволюционировавшая обвязка переносится и на другие базовые модели. Конкретных цифр прироста (в процентах или баллах), названий моделей, на которых проверялся перенос, авторства работы и оценки вычислительных затрат на подготовку 2000 задач и на сам процесс эволюции в тексте аннотации нет.

Ключевые факты

  • Обвязка агента разбита на пять независимых модулей, цикл агента, использование инструментов, управление наблюдениями, управление контекстом и определение завершения задачи; каждый эволюционирует отдельно, затем модули интегрируются в единую обвязку.
  • Метод сравнивает успешные и неуспешные траектории решения одной и той же задачи и собирает такие сравнения по множеству задач, чтобы находить повторяющиеся, а не случайные недостатки поведения.
  • Для эволюции курировано 2000 исполняемых задач из источников, не пересекающихся с бенчмарками оценки, так авторы отделяют реальное обобщение от подгонки под тест.
  • Проверка на TB2.0 и SWE-Bench Verified показала устойчивые улучшения на задачах вне обучающего распределения, а эволюционировавшая обвязка переносится на другие базовые модели.
  • Числовых показателей прироста и названий моделей, на которых проверялся перенос, в тексте нет, только формулировка «устойчивые улучшения».

Почему это важно

Recursive self-improvement для агентных обвязок, направление, где агент сам чинит и улучшает механизм своей работы (как он планирует шаги, вызывает инструменты, следит за контекстом), а не просто получает более сильную базовую модель. Ключевая проблема направления, обобщаемость: улучшения, найденные на одном бенчмарке или в одной попытке решения задачи, часто не работают на новых задачах. ModularRSI решает это архитектурно: делит обвязку на пять независимых модулей и эволюционирует их на выборке задач, не пересекающейся с тестовыми бенчмарками, так метод пытается отличить настоящее улучшение механизма от подгонки под конкретный тест.

Кому это важно

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

Как это применить

В тексте нет описания готового продукта, цены или лицензии, это исследовательская работа с методом и экспериментами на TB2.0 и SWE-Bench Verified. Практический вывод для инженеров, строящих обвязку для агентов: делить систему на функциональные модули (цикл агента, использование инструментов, управление наблюдениями, управление контекстом, определение завершения задачи) и эволюционировать их по отдельности с последующей интеграцией, вместо правки всей обвязки целиком по одной неудачной попытке решения задачи.

Можно ли доверять

Источник, карточка препринта на Hugging Face Papers, текст, авторская аннотация; кто именно авторы и из какой организации, в самом тексте не указано. Заявленные результаты (улучшения на TB2.0 и SWE-Bench Verified, перенос между базовыми моделями), это то, о чём сообщают сами авторы метода, и в аннотации нет ни цифр прироста, ни названий моделей, на которых проверялся перенос, ни оценки вычислительных затрат на подготовку 2000 задач и на сам процесс эволюции. Судить о масштабе эффекта по одной аннотации нельзя, для этого нужен полный текст препринта.

Риски и подводные камни

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