Рекурсивное самосовершенствование в ИИ-агентах: что на самом деле показывают эксперименты

Сейчас уже стало обычной практикой просить агента для программирования исправить баг в вашем приложении: он открывает файлы, редактирует несколько строк и запускает набор тестов. Если заменить инструкцию на «улучшите программное обеспечение, которое вы используете для выполнения этой работы», целью становится сам агент: как он находит файлы, какие инструменты использует, как восстанавливается после неудачной попытки и может ли получившаяся версия способствовать дальнейшему улучшению. Именно этот последний вопрос лежит в основе концепции рекурсивного самосовершенствования (RSI). В этой статье разграничиваются самомодификация и настоящее самосовершенствование, рассматриваются основные эксперименты и их результаты, а также приводится набор вопросов и простая схема эксперимента для самостоятельной оценки подобных утверждений.

Самомодификация, самосовершенствование и рекурсия

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

• Самомодификация: происходит изменение какой-либо части системы.
• Самосовершенствование: это изменение приносит измеримую пользу.
• Рекурсивное самосовершенствование: новая способность укрепляет ту самую структуру, которая обеспечивает последующие улучшения.

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

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

Машина Гёделя: докажите пользу перед изменениями

Машина Гёделя, предложенная Юргеном Шмидхубером, представляет собой классическую математическую модель. Система может переписать любую часть своего собственного программного обеспечения, включая компонент, отвечающий за поиск доказательств, но только после того, как она докажет, что такая переписка повышает ожидаемую пользу в рамках заданных целей и предположений.

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

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

ОСТАНОВИТЬСЯ: использование улучшителя для самого себя

Самообучающийся оптимизатор (STOP) начинается с так называемого «улучшателя» — программы, которая обращается к языковой модели с просьбой предложить и оценить возможные улучшения для других программ. Затем «улучшатель» применяется к собственному исходному коду, а обновленная версия используется в следующем раунде для получения дальнейших улучшений.

Примечательным выводом является то, что поведение этого цикла различается в зависимости от используемой модели. При использовании GPT-4 средние показатели эффективности улучшались с каждой итерацией; при использовании GPT-3.5 и Mixtral они снижались. Поскольку основная языковая модель не меняется, авторы четко указывают, что их работа не является полноценным примером RSI.

Урок для практиков прост: итеративное выполнение процесса не гарантирует прогресса. Слабый метод улучшения, применяемый к самому себе, может так же легко усугублять собственные ошибки при каждой итерации.

Агент Гёделя: переписывание собственной логики агента

Gödel Agent позволяет языковой модели изменять логику рассуждений и код поведения агента во время выполнения. Оценка проводится по таким критериям, как понимание прочитанного, математика и ответы на вопросы на основе знаний; оптимизация выполняется на наборе данных для проверки, а результаты работы агента измеряются на отдельном тестовом наборе, что является правильным способом избежать адаптации к условиям теста.

Цифры, приведенные в заголовках, требуют тщательного анализа, поскольку различные варианты тестируются в разных условиях. В рамках MGSM Meta Agent Search показывает точность 53,4%, а ограниченная версия на основе Gödel — 64,2%, причем это сравнение проводится между аналогичными вариантами. Нев ограниченная версия без использования Gödel достигает 90,6%, но она работает в других ограничениях и не должна рассматриваться как следующий этап в том же сравнении.

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

SICA: агент для программирования, редактирующий собственную базу кода

Самосовершенствующийся агент для программирования (SICA) делает этот вопрос более конкретным. Агент модифицирует собственный код, и каждая новая версия оценивается по степени эффективности решения задач, времени, затрачиваемому на это, и связанным с этим затратам.

При выполнении 50 случайно выбранных задач, взятых из SWE-bench Verified, эффективность выросла с 17% в первой итерации до пика в 53% на 14-й итерации, а в последней итерации она составила 51%. Другими словами, улучшения не были монотонными. Авторы оценивают, что 15 итераций обошлись примерно в 7 000 долларов из-за использования API.

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

Всё это не делает результаты тривиальными, но переход от 17% до 53% не означает, что общий уровень интеллекта системы почти утроился. Измерялась была производительность на одном конкретном наборе задач в рамках одного временного лимита, и большая часть улучшений — это именно то, что человек-инженер мог бы добавить в набор инструментов кодирующего агента.

Машина Дарвина-Гёделя: архив вместо одной строки

Машина Дарвина-Гёделя (DGM) отказывается от идеи единой цепочки версий. Она хранит архив вариантов агентов и позволяет новым ветвям развиваться из любого из них. Вариант, который сегодня имеет более низкий рейтинг, всё ещё может стать предком более позднего, более полезного изменения, что и составляет основу эволюционного принципа, заключённого в названии.

Согласно статье версии v3, отмечается увеличение показателей с 20% до 50% при оценке на подмножестве SWE-bench и с 14,2% до 30,7% на полном тестовом наборе Polyglot. В исследовании также проводятся эксперименты по переносу знаний с использованием других моделей и тестовых наборов, которые не использовались во время разработки. Эти результаты указывают на то, что часть улучшений может быть применима и к задачам, отличным от тех, над которыми работали, хотя они и не демонстрируют общего улучшения во всех областях. Как и в других работах, связанных с агентами, базовые модели остаются неизменными; эволюционирует только программное обеспечение агентов вокруг них.

Стоимость также является важным фактором. Авторы оценивают стоимость одной запуска алгоритма DGM на тестовой платформе SWE-bench примерно в 22 000 долларов, тогда как стоимость каждого запуска базовых решений составляет около 10 000 долларов. Поэтому эксперименты, направленные на выявление вклада отдельных компонентов, не позволяют полностью ответить на вопрос о том, сможет ли DGM сохранить преимущество при равном бюджете.

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

Когда меняются веса или алгоритмы улучшения

Эксперименты с кодами агентов — это не весь спектр исследований. SEAL (Self-Adapting Language Models) изучает модели, которые сами генерируют данные для дальнейшей настройки и инструкции по обновлению, включая указания относительно того, как следует осуществлять адаптацию. Обучение с использованием этих самогенерированных инструкций приводит к стабильным изменениям в весах модели, поэтому исследования самосовершенствования явно не ограничиваются лишь созданием структур для агентов. Тем не менее сам факт изменения весов сам по себе ничего не говорит о возможности бесконечного или ускоряющегося прогресса.

Hyperagents устраняет другое ограничение. Он объединяет агента, выполняющего задачу, и мета-агента, который его редактирует, в одну программу для редактирования, так что сам механизм, обеспечивающий будущие улучшения, может быть изменён. Авторы отмечают, что некоторые из этих улучшений мета-уровня передаются между разными областями задач и накапливаются с каждым запуском. Все эти исследования переводят дискуссию из плоскости «Может ли ИИ редактировать собственный код?» в плоскость «Насколько он может улучшить процесс собственного развития?»

Четыре вопроса к любому утверждению о «улучшении»

Когда кривая самосовершенствования идёт вверх, стоит спросить, что именно улучшилось.

В чём именно улучшение?

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

В чем проявляется преимущество?

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

Какая версия лучше?

Архив, сохраняющий лучший результат, будет показывать рост значения «лучшего результата на данный момент», даже если большинство новых кандидатов хуже. Следует анализировать распределение кандидатов, а не только максимальное значение.

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

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

Эти вопросы не предназначены для того, чтобы отрицать прогресс. Они помогают точно определить, что такое прогресс, чтобы его можно было распознать.

Эксперимент по самосовершенствованию, который вы можете провести

Реалистичным стартовым пунктом для индивидуального разработчика или небольшой команды является не открытие всей системы для самостоятельной модификации, а выбор одного узкоспециализированного инструмента разработки и строгое ограничение его возможностей. В качестве примера возьмем инструмент для генерации тестов для Java-кодбазы:

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

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

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

Отслеживайте весь набор кандидатов, а не только текущий лучший вариант, чтобы можно было увидеть, улучшаются ли кандидаты в целом.

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

Лучшие агенты — это не взрыв интеллекта

Может ли ИИ разрабатывать лучший ИИ? В приведённых выше экспериментах — да, в определённом смысле: системы ИИ помогли создать более способных агентов, и некоторые из них применили этот процесс к собственному программному обеспечению. Однако они не показали цепочку улучшений, которая бы ускорялась с каждой итерацией, обобщалась на разные области и работала независимо от решений человека-разработчика. Отвергать эти исследования как «просто инжиниринг подсказок» — значит упускать реальные результаты; называть их началом взрыва интеллекта — значит преувеличивать их значение.

Основные выводы

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

Одних лишь итераций недостаточно для прогресса: технология STOP улучшалась с использованием одной модели, но ухудшалась при использовании других.

Многие зафиксированные улучшения (SICA, DGM) обусловлены более совершенными инструментами для работы с замороженными моделями на конкретных тестовых заданиях, при этом возникают значительные затраты.

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

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