Как ИИ может менять собственный процесс развития через рекурсивное самоулучшение

Современные модели пишут код, запускают тесты, замечают, что что-то упало, и сами вносят правки. Если дать им инструменты, этот цикл можно прокручивать многократно, без чьего-либо участия. А где заканчивается обычная автоматизация и начинается самоулучшение? Недавно я прочла обзор, в котором авторы берут концепцию рекурсивного самоулучшения (Recursive Self-Improvement, RSI) и предлагают шкалу из пяти уровней автономии. В этой статье я хочу поговорить о том, какие из них уже можно увидеть в современных системах.

Для чего понадобилось понятие RSI

Сейчас специалисты вручную решают, что улучшать, собирают под это ресурсы, вносят изменения и проверяют результат. Все это обходится дорого, как и данные для обучения моделей. Например, на подготовку GDPval, набора из 1 320 профессиональных задач для проверки ИИ, авторам понадобилось более 9 тысяч часов. Синтетические данные и обучение с подкреплением снимают часть ручной работы, но взамен нужна инфраструктура, которая самостоятельно формирует и оценивает опыт, а это тоже деньги. Так, постобучение DeepSeek-V3.2 превысило десятую часть затрат на весь претрейн. А когда модель уже запущена, добавляются расходы на правку документации, новые инструменты и контекст. 

Прогресс при этом неравномерный. По индексу HCI математика уже близка к идеальному результату. А вот длинные задачи, где человеку приходится вручную искать и чинить сбои, отстают, и этот труд дорого обходится.

Получается, улучшение модели держится на цепочке дорогостоящих вмешательств. RSI проверяет, можно ли часть этой координации сделать постоянной способностью самой системы. Это автономный замкнутый процесс: система находит собственные ограничения, генерирует и проверяет улучшения, а потом использует новые возможности, чтобы улучшить и сам процесс улучшения. Цикл разложен по ролям. Улучшатель предлагает изменения, стратегия решает, где их искать, верификатор принимает или отклоняет результат. На роль верификатора подойдёт тест, модель вознаграждения, среда или человек. Пока система правит функцию сортировки, объект улучшения — сама функция. А когда система начинает менять способ, которым генерирует кандидатов, объектом становится этот способ. Это и есть рекурсия.

Похожие области уже во многом автоматизированы, но самоулучшением это не считается, поэтому и понадобилась шкала. В непрерывном обучении разработчик задает цель и критерии, в AutoML заранее заданы пространство поиска и оценщики, а агенты обычно работают в рамках одной задачи с неизменными инструментами. Самоулучшением это становится только тогда, когда меняется процедура поиска и оценки и эти изменения переносятся на следующие раунды. Поэтому важно, сложился ли вокруг ИИ устойчивый цикл улучшения и какая часть решений в нем уже перешла от человека к системе. 

Пять уровней RSI

Уровни обозначены как L1–L5, а нулевой, B0, к RSI формально не относится: это точка отсчета. Начну с него. Агент правит код по тестам человека или дорабатывает эссе по рубрике, а все, что он выяснил в процессе, исчезает вместе с контекстом сессии. Сюда относятся Self-Refine, Reflexion и Tree of Thoughts. Между задачами опыт не накапливается, улучшает человек, а самопроверка может закреплять ошибку. Если одна и та же модель отвечает и оценивает, то у обеих стадий будут одни и те же пробелы в знаниях. Тот цикл «создал, проверил, исправил», с которого я начала рассказ, и есть B0.

Стоит системе начать запоминать хотя бы что-то из своих же исправлений, она попадает уже на уровень L1. Принятый результат сохраняется и в дальнейшем используется, хотя человек по-прежнему задает, что улучшать и что считать успехом. В FineWeb-Edu люди формулируют критерий образовательной ценности, а языковая модель размечает по нему веб-корпус. В Meta* система Capacity Efficiency превращает опыт инженеров в навыки для расследования регрессий и чинит их по заранее заданным процедурам: часы ручного разбора сокращаются до минут. Но если задача выходит за рамки предусмотренной процедуры, агент не может изменить ее сам, а ошибка, записанная в состояние системы, переживает задачу.

На уровне L2 система перестает просто запоминать и начинает выбирать. Она сама решает, какую правку попробовать следующей, наблюдает результат, диагностирует, выбирает способ изменения, проверяет и оставляет или откатывает. Цель и критерий приемки при этом остаются внешними. Dropbox с помощью GEPA переписывает запрос, по которому языковая модель оценивает релевантность файлов. ADAS описывает агента как Python-функцию и через метаагента пополняет архив кандидатов. Здесь же появляется и первый серьезный риск: тестовый набор, который адаптивно опрашивают, попадает в зону оптимизации. Системы уже показывали подбор удачного начального значения генератора случайных чисел и попытки вытащить тестовые метки через повторные запросы к оценщику.

На уровне L3 система уже самостоятельно решает, на чем ей дальше нужно учиться. Ее состояние влияет на выбор следующего опыта, и этот опыт меняет состояние, а новое снова влияет на следующий выбор. В Absolute Zero Reasoner одна модель придумывает исполняемые задачи и решает их, а исполнитель кода проверяет и задачи, и решения. VOYAGER в Minecraft выбирает цели по своему состоянию и истории исследований и сохраняет удачное поведение как исполняемые навыки. Если система неточно оценивает сложность задачи или ошибается модель, которая проверяет качество решений, то дальнейшее обучение проводится с искажениями, они оседают в параметрах и памяти и расходятся по раундам. То есть риски тут немалые.

На уровне L4 обратная связь от реальной работы решает, что сохранится в системе, будь то память, навыки, инструменты или код агента. В Metis агент раз за разом находит одно и то же исправление для постраничного API и в итоге собирает из него готовый инструмент. В HarnessDev агент правит свою обвязку по результатам тестовых прогонов, а независимая проверка идет на скрытых задачах. В HDSO кандидат-навык сравнивают с контролем на тех же задачах и добавляют в библиотеку, только если предположение подтвердилось.

На пятом уровне L5 объектом изменения становится уже механизм, который порождает будущие улучшения: улучшатель, оценщик преемников или политика исследований. В STOP улучшатель, программа на Python, берет и оптимизирует собственный исходный код. Его четвертое поколение обошло исходную версию на всех задачах, которые не участвовали в самоулучшении. То есть на новом материале, а не на примерах, под которые система подстраивалась. В Gödel Agent политика решения задач и логика обновления сидят в одной программе, и ошибки передаются по наследству: 14 из 100 запусков на MGSM закончились ниже исходной политики. Red Queen Gödel Machine держит оценщик замороженным внутри эпохи и сравнивает его с независимым эталоном. На отложенных задачах Polyglot это дало 71,7% против 69,9% у конкурента.

Принятые изменения улучшателей и оценщиков действительно могут управлять следующими раундами и частично переноситься между задачами, хотя надёжно ли эффект накапливается от поколения к поколению, пока неясно.

Какие элементы RSI уже используются в ИИ

Самопроверка наглядно показывает границу между уровнями. Self-Refine, Reflexion и Tree of Thoughts остаются на B0, то есть это еще не RSI. Даже когда доработка заметно улучшает ответ, сама система не меняется: рефлексия из Reflexion живет в буфере контекста и исчезает вместе с задачей. Вдобавок самопроверка тормозит сама себя: если модель и отвечает, и оценивает, у обеих стадий одни и те же пробелы. Другое дело «нашел ошибку и исправил» — у Meta* это превращается в навык для расследования регрессий, который работает и в следующих задачах. Это уже первый уровень.

Синтетические данные встречаются сразу на двух уровнях. Microsoft SynthLLM, SynthAgent и NVIDIA Nemotron-4 — это первый уровень. Одна модель генерирует ответы. Модель вознаграждения отфильтровывает их по заданным параметрам, человек определяет, что генерировать и по каким критериям отбирать. На третьем уровне задачи для системы генерируются с учетом того, что она уже знает и умеет на данный момент. Это влияет на выбор следующей задачи, ее решение меняет состояние, а новое состояние снова влияет на то, какую задачу модель получит в дальнейшем.

Такую зависимость хорошо видно в обучении через соревнование систем, где одна часть придумывает задачи, а другая их решает. В Search Self-Play одна модель предлагает задачи, другая их решает, и награда за предложенную задачу зависит от того, насколько хорошо с ней справилась решающая модель. В STP генератор гипотез и модуль доказательств обучаются вместе: гипотезы, которые модулю доказательств даются с трудом, становятся материалом для дальнейшей генерации. В R-Zero «соперник» придумывает задачи без готовых ответов, а «решатель» их решает. Весь этот класс относится к третьему уровню, с оговоркой: согласованность ответов решателя показывает лишь, насколько сложной ему кажется задача, но не то, верно ли она решена. 

От обучения самой модели логично перейти к обучению устройства системы, то есть к метаобучению. На шкале оно встречается чаще остальных направлений. ADAS, AFlow, AgentSquare, GEPA и autoresearch остаются на втором уровне, поскольку ищут лучшую конфигурацию, а цель и критерий приемки задаются извне. На пятом уровне стоят STOP, HyperAgents, Darwin Gödel Machine, Gödel Agent, A-Evolve-Training и Red Queen Gödel Machine. Для Darwin Gödel Machine есть оговорка: правила ведения архива и выбора родителей остаются вне самоизменения. 

Больше всего примеров дает практика, а именно системы, где ИИ действует как агент, который сам планирует шаги, вызывает нужные инструменты и доводит задачу до конца без пошаговых инструкций человека. Сами по себе они пока не дотягивают до настоящего RSI, часто работают внутри одной задачи с неизменной обвязкой. Агент выходит на первый уровень, когда накопленное по итогам работы остается в постоянном состоянии и дальше повторно применяется. В Metis повторяющееся исправление используется как инструмент, который сохраняется после проверки в изолированной среде. В промышленных решениях, например, в OpenAI Harness Engineering перед выпуском инженеры задают замысел продукта и правила проверки, а Codex реализует и проверяет все внутри этих рамок, и это тоже первый уровень.

А как проверить, что система улучшила себя, а не научилась казаться лучше?

Как оценивать изменения, которые система внесла в себя

Конкретные требования зависят от уровня. Для L1 важны надежность исполнения и безопасность сохранения. Ошибка, записанная в состояние, переживет задачу. Для L2 лишние вычисления на поиск легко принять за улучшение алгоритма. Результаты, о которых сообщили сами компании, показывают, что подход в принципе работает. Но независимой проверки не было. Для L3 нужны контрольные эксперименты вроде заморозки входа, по которому механизм выбора опыта видит текущее состояние системы, и разделение корректности, сложности и реальной пользы для обучения. Задача может быть решена правильно, но оказаться бесполезной для дальнейшего обучения. А задача, которая выглядит сложной по косвенным признакам, на деле может оказаться неоднозначной или нечетко сформулированной.

Для L4 риск заключается в сбое устойчивого обновления, когда принятое изменение влияет на множество последующих решений, прежде чем проявится его слабость. Система может вывести неверный урок из шумных данных, применить верный урок не по адресу, пропустить нужное обновление или сохранить новое поведение ценой прежних возможностей. Но по итоговому результату на задачах не видно, какая именно из этих причин сработала. Внешне все они выглядят одинаково, как падение качества. Поэтому каждое изменение нужно отслеживать отдельно: связывать его с данными, которые его вызвали, и смотреть на эффект и на новых задачах, и на тех, что система уже решала раньше. Сюда же относится Library Drift: растущая библиотека навыков ухудшает поиск нужного и тормозит прогресс раньше, чем это станет заметно по оценкам. А слишком агрессивная чистка вредит еще сильнее.

На L5 нужно определить измененный артефакт, записать данные, которые его вызвали, и убедиться, что он действительно был использован в следующем раунде. Исходный и пересмотренный механизмы используют сопоставимых агентов при равных бюджетах, включая цену оценки самих механизмов, а при переносе фиксируют пересмотренный механизм. Так строит проверку HyperAgents: отделяет способность порождать агентов от результата на исходной задаче.

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

Что меняется при переходе к полноценному RSI

Ни на одном из уровней система не получает миссию, границы безопасности, независимую оценку или право последнего слова при важных релизах. Даже на L5, когда система пересматривает политику исследований, смена операционных приоритетов не означает передачи власти над общей миссией. Человек при этом перестает выбирать каждую правку и каждый эксперимент. Вместо этого он проектирует рамки, внутри которых система ищет и проверяет. А из этого вырастает целый набор технических задач.

Начинается все с диагностики: сбой редко показывает, какой компонент надо менять. Неверный ответ может идти от плохих данных, неполного контекста, интерфейса инструмента, модели или оценщика. Показательный случай произошел у Humanlaya. Инструмент извлечения не смог разобрать трехстраничный отсканированный PDF, и проверяющий агент пометил вложение как непригодное. Поправили то, как проверяющий агент принимает решение в таких случаях. После четырех обновлений доля пакетов с ключевыми дефектами упала с 9,0% до 3,7%, а среднее время ручной обработки — с 48 до 27 минут на задачу. Когда адаптируются несколько компонентов, изменение одного может обесценить допущения другого. Поэтому диагноз лучше превращать в проверяемую гипотезу, замораживать компоненты и вести явные записи зависимостей. С сигналом для обучения та же история, что и в L3: опыт может быть валидным, подходящим по сложности и полезным для обучения, и одно не гарантирует другого.

А что делать с уже накопленным состоянием? Само по себе его сохранение еще не значит, что следующие агенты смогут им воспользоваться. Нужный навык может не вызваться вовсе. А может и вызваться, но агент не последует ему как надо. Растущая библиотека к тому же мешает сама себе, это и есть Library Drift. Интересная деталь: способность создавать полезные обновления почти не зависит от мощности базовой модели. А вот способность извлекать пользу из обновленной обвязки зависит от нее нелинейно. Поэтому вкладываться имеет смысл в способность самого агента решать задачи, а не в способность системы, которая эти обновления генерирует. И раз навык, полезный своему автору, может не подойти другому исполнителю, артефакт должен содержать свои свидетельства, условия применимости, зависимости и наблюдаемый эффект.

А как проверять такие артефакты в разных областях? В разработке софта проверка дешевая, но условная, тесты подтверждают только то, что покрыто спецификацией. В здравоохранении результаты запаздывают и смешаны с другими факторами. В физическом мире и в клинике откат программного чекпойнта не отменит последствий, поэтому там проверка должна идти до релиза.

Самое трудное это доверие к эволюции самого механизма. На L5 более сильный решатель может вскрыть слабости оценщика, но замена оценщика делает оценки несравнимыми или поощряет эксплуатацию. Здесь помогает разделение редактируемых внутренних механизмов обратной связи и независимо поддерживаемых критериев приемки, сохранение свидетельств, которые связывают каждую правку механизма с последующими решениями. Но как сохранить независимую оценку при многократном адаптивном доступе, как выявлять согласованные ошибки предлагающего и оценивающего, и как откатывать вредные изменения механизма, не теряя полезный накопленный опыт?

А еще встает вопрос долгой оценки, ресурсов и инфраструктуры. Исходный и пересмотренный механизмы нужно сравнивать при равных суммарных бюджетах, включая стоимость разработки и оценки самих механизмов. И выкладывать полные траектории вместе с отвергнутыми обновлениями и регрессиями. Более быстрое ядро или более долгий прогон без присмотра могут скрывать заметные затраты на генерацию и оценку кандидатов, поддержку инфраструктуры и ревью. 

Доказательство RSI — это не разовые успехи, а повторяющиеся сдвиги в самом механизме, который эти улучшения порождает. Причём такие, где видно, что их вызвало, и которые работают не только на исходной задаче, но и на других.

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

*Meta признана экстремистской организацией на территории РФ.