Arbor: Новый ИИ-фреймворк для эффективной оптимизации сложных систем

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

Решение от Arbor

Для решения этой задачи исследователи из Народного университета Китая и Microsoft Research представили Arbor — фреймворк, который превращает ИИ-driven исследования и оптимизацию из последовательности проб и ошибок в кумулятивный процесс обучения. Arbor организует гипотезы, эксперименты и полученные знания в структуру дерева, помогая системе учиться на предыдущих неудачах и со временем вносить более продуманные, проверенные улучшения.

В ходе практических испытаний Arbor продемонстрировал более чем в 2,5 раза больший подтверждаемый прирост производительности по сравнению со стандартными ИИ-агентами-кодировщиками в реальных инженерных задачах, используя при этом тот же объем ресурсов.

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

Проблема автономной оптимизации

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

АО представляет собой базовый цикл автономных исследований. ИИ-агент начинает работу с исходного изменяемого артефакта, такого как база кода машинного обучения или конвейер обработки данных, и конкретной цели. Задача агента — итеративно улучшать этот артефакт на основе экспериментальной обратной связи без пошагового контроля человека.

Основная проблема АО часто недооценивается. Многие инженерные команды замечают, что простое предоставление агенту-кодировщику большего времени или вычислительных ресурсов для оптимизации кодовой базы не приводит к лучшим результатам. По словам Цзяцзе Цзиня, соавтора исследования, в интервью VentureBeat, «Автоматизация может поддерживать работу ИИ очень долго, но цикл не равен прогрессу. Если цель расплывчата или метрика легко поддается ‘взлому’, долгосрочная автоматизация часто лишь быстрее генерирует ‘улучшения’, которые на самом деле никому не нужны.»

Цзинь поясняет, что сложные задачи требуют множества попыток для успешного решения, и стандартным архитектурам агентов не хватает критически важной структуры данных для поддержания состояния. «Как обеспечить, чтобы понимание и опыт каждой попытки действительно накапливались, а не терялись в буфере прокрутки?» — задается вопросом Цзинь. Без такой структуры агенты просто повторяют одни и те же ошибки.

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

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

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

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

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

Фреймворк Arbor

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

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

Эти два компонента взаимодействуют через механизм, который исследователи называют «Уточнением дерева гипотез» (HTR). HTR представляет весь исследовательский процесс как постоянное, ветвящееся дерево, где каждый узел связывает четыре элемента: гипотезу, исполняемый артефакт, полученные фактические данные и извлеченное знание. Это означает, что координатор может одновременно исследовать несколько конкурирующих направлений, не теряя контекста.

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

Чтобы понять важность изоляции в Arbor, рассмотрим распространенный корпоративный сценарий: оптимизацию конвейера генерации с дополненным извлечением (RAG) для внутреннего ИИ-помощника. RAG — это подход, при котором языковая модель получает дополнительную информацию из внешних источников для генерации более точных и релевантных ответов. «Когда одного агента, такого как Claude Code или Codex, просят ‘повысить точность’, он обычно изменяет множество параметров за один проход — стратегии фрагментации, промпт, метод извлечения,» — отметил Цзинь. Это переплетает изменения, делая невозможным определить, что именно помогло, и напрямую изменяет репозиторий без изоляции.

Arbor решает эту проблему, рассматривая каждый управляющий элемент как отдельную гипотезу. Фрагментация становится одной ветвью, извлечение — другой, а промпт — третьей; каждая из них реализуется и оценивается в собственной изолированной рабочей копии Git. «Таким образом, обеспечивается четкая атрибуция: ‘декомпозиция ограничений на стороне извлечения дала +X; поиск в ширину фактически навредил’,» — пояснил Цзинь.

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

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

Arbor в целом подпадает под концепцию «циклической инженерии», популяризированную такими деятелями отрасли, как создатель OpenClaw Питер Штейнбергер и руководитель Claude Code Борис Черни. Идея состоит в том, чтобы выйти за рамки простых промптов и разрабатывать итеративные циклы (наблюдение, рассуждение, действие, проверка), которые управляют автономными агентами. Однако, как отмечает Цзинь: «Цикл может заполниться беспорядочными, неотслеживаемыми попытками, и в итоге у вас не будет никаких результатов и способа восстановить, что изменилось.»

Arbor в действии

Исследователи оценили Arbor на наборе задач автономной оптимизации, разработанном на основе реальных исследовательских сценариев и бенчмарка по машинному обучению MLE-Bench Lite. Набор задач АО включал области ИИ-разработки, такие как обучение моделей, проектирование управляющих оболочек и синтез данных.

В качестве базовых моделей для координатора и агентов-исполнителей исследователи использовали Claude Opus 4.6, GPT-5.5 и Gemini-3-Flash. Arbor был протестирован в сравнении с сильнейшими агентами-кодировщиками, Codex и Claude Code. Arbor и контрольные системы получали одинаковые ресурсы. Для задач MLE-Bench Lite Arbor также сравнивался с передовыми агентскими исследовательскими системами, такими как AI-Scientist, ML-Master и AIDE.

Arbor неизменно превосходил контрольные системы. Он достиг лучшего результата на независимых тестовых данных по всем задачам, продемонстрировав более чем в 2,5 раза больший средний относительный прирост по сравнению с Codex и Claude Code. В задаче BrowseComp, связанной с оптимизацией поискового агента, Arbor повысил точность системы на независимых данных с базовых 45,33% до 67,67%. В то время как Codex и Claude Code застопорились на 50% и 53,33% соответственно. В MLE-Bench Lite, при использовании GPT-5.5, Arbor показал лучший результат среди всех протестированных систем.

Arbor оказался устойчивым к переобучению. Например, в ходе экспериментов с задачей Terminal-Bench 2.0 Claude Code достиг высокого балла 75 на этапе разработки, но его показатель снизился до 71 на независимых данных. Arbor имел более низкий балл 72,22 на этапе разработки, но достиг самого высокого балла на независимых данных — 77,36, что подтверждает применимость его результатов в реальных условиях.

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

Внедрение Arbor: оптимальные области применения и скрытые затраты

Для руководителей инженерных команд, планирующих интегрировать Arbor в свой существующий технологический стек, фреймворк разработан для работы поверх существующих рабочих процессов Git, а не для их замены. «Его выходные данные — это обычная ветка Git, которую можно напрямую проверять с помощью существующих инструментов для ревью кода, CI и человеческой оценки,» — пояснил Цзинь. Только проверенные улучшения объединяются в основную ветку для каждого запуска, оставляя основной репозиторий нетронутым до тех пор, пока разработчик вручную не решит продвинуть код.

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

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

И наоборот, командам следует избегать использования Arbor для задач, критичных к задержкам в реальном времени, очевидных исправлений в одну строку или когда базовая метрика оценки является ошибочной. Потолок качества всего запуска строго ограничен качеством оценочной системы. «Если метрика ненадежна, Arbor просто быстрее оптимизирует систему к ненадежному результату,» — предупредил Цзинь.

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

Твитнуть