Исследователи Google предложили RRSI для ограничения заучивания тестов самоулучшающимися ИИ-агентами: метод повышает результаты на невиданных бенчмарках и снижает расход токенов во время работы.

Исследователи Google предложили метод улучшения ИИ-агентов, не позволяющий им переобучаться на задачах, использованных для оптимизации. Подход получил название Regularized Recursive Self-Improvement of Agent Harnesses, или RRSI, и направлен на проблему, которая становится серьезнее по мере того, как системы автоматически переписывают собственные промпты, рабочие процессы, инструменты и логику памяти.
Согласно исследовательской статье, описанной The Decoder, RRSI улучшил результаты на ранее невиданных бенчмарках максимум на 4,7 балла и использовал примерно на 30% меньше токенов во время работы, чем нерегуляризованный метод оптимизации. Заявленные улучшения достигаются за счет изменения оболочки агента вокруг замороженной модели, а не обновления весов модели.
Многие производственные ИИ-агенты состоят из фиксированной языковой модели, окруженной оболочкой агента: промпты, вызовы инструментов, правила рабочих процессов, системы памяти, поведение при восстановлении и обработка вывода определяют, как работает модель. Оболочка может решать, проверяет ли агент файл перед редактированием, повторяет ли попытку после ошибки и как структурирует итоговый ответ.
Исследователи Google Cloud AI Research и университетские партнеры изучают способы автоматизации улучшений этого слоя. В типичном цикле рекурсивного самоулучшения языковая модель предлагает изменения оболочки, оценивает их на наборе задач и использует результаты для генерации следующих изменений.
Риск заключается в том, что многократная оптимизация на небольшой коллекции тестов может сделать агента лучше именно на этих тестах, не повышая его общие способности. Система может выучить специфические для бенчмарка шаблоны, выбрать изменения, успешные случайно, или накопить ненужную сложность, которая повышает измеряемый балл, но увеличивает стоимость и хрупкость.
Это важно, поскольку ИИ-агентов часто оценивают на ограниченных наборах задач, тогда как предполагаемые среды их применения гораздо менее предсказуемы. Оболочка, хорошо работающая со знакомыми процессами, может отказать при изменении структуры файлов, инструкций, инструментов или целей пользователя.
RRSI вводит ограничения в двух точках процесса оптимизации. При создании кандидатов на изменения он ограничивает количество независимых правок, которые можно объединить в одно предложение. Со временем допустимое число правок уменьшается, переводя процесс от масштабного редизайна к более точечным изменениям.
Система также записывает предыдущие попытки, помогая не исследовать повторно изменения, которые уже оказались неудачными. Когда прогресс останавливается, она направляет эксперименты к участкам оболочки, которые еще не изучались.
Отдельный критик оценивает предлагаемые изменения до их окончательного применения. Он отклоняет ревизии, которые, по-видимому, жестко встраивают названия задач, решения или другое поведение, специфичное для бенчмарка. RRSI также требует наблюдаемого прироста производительности перед принятием изменений, повышающих вычислительные затраты, и удаляет компоненты, которые больше не приносят пользы.
В совокупности эти правила должны отдавать предпочтение небольшим, объяснимым улучшениям, переносящимся на новые задачи, а не агрессивным изменениям, максимизирующим узкий тестовый показатель. Метод оставляет оболочку редактируемой, но ограничивает скорость и свободу ее самостоятельной переписи.
Исследователи протестировали RRSI на восьми бенчмарках, охватывающих программирование, офисную работу агентов и инженерное проектирование. Базовая модель, обозначенная в отчете как Claude Opus 4.8, оставалась замороженной. В сравнение вошли неизмененная базовая оболочка и еще четыре метода оптимизации.
Представленные исследователями результаты показывают компромисс. RRSI дал прирост до 14,1 балла на задачах, использованных во время оптимизации, но более важным оказался результат на пяти невиданных бенчмарках, где максимальное улучшение достигло 4,7 балла. Согласно статье, о которой сообщил The Decoder, оболочка RRSI не уступила базовой линии ни в одной из этих невиданных оценок.
Сообщается, что другие подходы хорошо работали на обучающих задачах, но хуже переносились на новые. Два метода оказались ниже базовой линии на новых задачах. RRSI показал наименьшее улучшение на обучающем наборе среди проверенных вариантов; исследователи трактуют это как свидетельство того, что метод жертвует специализацией на бенчмарке ради более широкой генерализации.
Результат по токенам также важен для команд, эксплуатирующих агентов в масштабе. Оптимизированная система RRSI использовала примерно на 30% меньше токенов, чем нерегуляризованная версия, и требовала меньше шагов среди оптимизированных оболочек. Однако исходная базовая система оставалась более экономичной, поэтому регуляризация не сделала всю систему дешевле каждого из альтернативных вариантов.
Это результаты исследований, а не независимые производственные бенчмарки. Показатели производительности являются утверждениями по итогам оценки исследователей, а имеющиеся свидетельства не показывают, как метод поведет себя на более широких распределениях задач, других моделях или реальных корпоративных нагрузках.
Для разработчиков эта работа предполагает, что улучшение агента должно включать больше, чем максимизацию показателя на отладочном бенчмарке. Наборы оценки должны содержать задачи, которых процесс оптимизации никогда не видит. Иначе самоулучшающаяся система может вознаграждать себя за изучение теста, а не за улучшение базового рабочего процесса.
Конструкция RRSI также указывает на операционные меры контроля рекурсивного самоулучшения. Команды могут ограничивать количество одновременных изменений, вести историю неудачных экспериментов, требовать обоснования затрат для более дорогих процессов и блокировать правки, явно связанные с конкретными тестовыми случаями. Это может упростить аудит и откат автоматической оптимизации оболочки.
Подход особенно важен для корпоративного ИИ, где стоимость токенов, предсказуемое поведение и надежность в разнообразных внутренних процессах не менее важны, чем пиковые баллы на бенчмарках. Оболочка, обобщающаяся на незнакомые документы или процедуры, может быть полезнее той, что получает более высокий балл на фиксированном наборе демонстраций.
Работа не решает более широкие вопросы безопасности и управления, связанные с агентами, меняющими собственную операционную логику. RRSI ограничивает изменения оболочки, но имеющиеся свидетельства не показывают, способны ли его критики надежно обнаруживать все формы скрытого поведения, специфичного для бенчмарка. Метод также не рассматривает системы, в которых веса модели меняются во время оптимизации.
Тем не менее заявленный перенос между моделями примечателен. Сообщается, что оболочка для программирования, найденная с помощью Gemini 3.5 Flash, повысила точность более слабой Gemini 3.1 Flash Lite с 11,2 до 14,6 балла без изменения второй модели. Это указывает, что некоторые улучшения рабочих процессов могут переноситься между моделями с разными возможностями, хотя результат получен в том же исследовательском отчете и требует более широкой проверки.
Первым сигналом станет независимое воспроизведение RRSI на дополнительных моделях и семействах задач. Результаты следует сравнивать на отложенных задачах, скрытых и от оптимизатора оболочки, и от его критика.
Исследователям и продуктовым командам также следует проверить, сохраняет ли метод эффективность, когда после развертывания меняются инструменты, промпты, хранилища памяти и распределения данных. Важны будут и измерения стоимости: заявленное сокращение токенов на 30% относится к нерегуляризованной оптимизированной системе, а не обязательно к тщательно разработанной базовой линии.
Еще один открытый вопрос — могут ли аналогичные средства контроля управлять агентами, обновляющими веса модели, а не только окружающую оболочку. Текущее исследование посвящено замороженным моделям и оставляет за рамками более значимую форму самоулучшения.
RRSI решает практическую проблему нынешней гонки агентов: команды могут автоматизировать поиск лучших рабочих процессов быстрее, чем определить, обобщаются ли эти процессы. Поэтому его главный вклад носит методологический характер. Метод рассматривает производительность на невиданных задачах и вычислительную стоимость как ключевые ограничения, а не полагается на один показатель оптимизации.
Исследование не доказывает, что рекурсивное самоулучшение готово к развертыванию без надзора. Но оно дает разработчикам более ясный принцип: агент должен заслужить право стать сложнее, продемонстрировав надежные улучшения за пределами тестов, породивших это изменение.