Новая система оптимизации на основе ИИ превосходит Claude Code и Codex в 2,5 раза при том же вычислительном бюджете.
Бен Диксон
Представьте, что ваша команда разработчиков только что внедрила ИИ-агента для поиска информации во внутренних документах компании и ответов на вопросы сотрудников. В процессе разработки он работает безупречно, но в производственной среде постоянно выдает ошибки или пропускает ключевые ограничения. Исправление этой проблемы редко бывает простым. Требуется утомительный процесс проб и ошибок, включающий одновременную настройку стратегий сегментации, методов поиска и системных подсказок. Поскольку эти настройки взаимосвязаны, становится практически невозможно определить, какая именно корректировка действительно решила проблему.
Для решения этой задачи исследователи из Китайского университета Жэньминь и Microsoft Research представили Arbor — фреймворк, который преобразует исследования и оптимизацию на основе ИИ из последовательности проб и ошибок в кумулятивный процесс обучения. Arbor организует гипотезы, эксперименты и выводы в дерево, которое помогает системе учиться на предыдущих ошибках, чтобы со временем вносить более обоснованные и проверенные улучшения.
В ходе практических испытаний Arbor продемонстрировал более чем в 2,5 раза больший подтвержденный прирост производительности по сравнению со стандартными агентами ИИ-программирования в реальных инженерных задачах при том же объеме ресурсов.
В контексте корпоративного ИИ этот метод напрямую позволяет автоматизировать непрерывное совершенствование сложных инженерных систем, существующих в реальном мире.
Понимание «узкого места» в автономной оптимизации
По мере того, как большие языковые модели и системы искусственного интеллекта становятся все более совершенными, от них ожидается выполнение более сложных операций, таких как автономная оптимизация (АО) программных систем, например, агентных комплексов или алгоритмов обучения моделей.
AO отражает фундаментальный цикл автономных исследований. Агент ИИ начинает работу с исходного изменяемого артефакта, такого как кодовая база машинного обучения или конвейер обработки данных, и конкретной целью. Цель агента — итеративно улучшать этот артефакт посредством экспериментальной обратной связи без пошагового контроля со стороны человека.
Главная проблема автоматизации ИИ часто понимается неправильно. Многие инженерные команды обнаруживают, что простое предоставление программисту больше времени или вычислительных ресурсов для оптимизации кода не приводит к лучшим результатам. «Автоматизация может поддерживать работу ИИ очень долгое время, но цикл — это не то же самое, что прогресс», — сказал соавтор статьи Цзяцзе Цзинь в интервью VentureBeat. «Если цель расплывчата или метрику легко изменить, длительная автоматизация часто просто приводит к «улучшениям» быстрее, чем это кому-либо на самом деле нужно».
Джин объясняет, что для решения сложных задач требуется множество попыток, а в стандартных архитектурах агентов отсутствует критически важная структура данных для поддержания состояния. «Как убедиться, что знания и опыт, полученные в каждой попытке, действительно накапливаются, а не теряются в буфере прокрутки?» — говорит он. Без этой структуры агенты просто повторяют одни и те же ошибки.
Современные агентные системы могут проводить эксперименты в течение многих часов, преследуя четко определенные цели: редактирование кода, запуск инструментов, автономное выполнение тестов. Но они рассматривают каждую попытку изолированно, упуская из виду структурные механизмы, которые позволили бы им накапливать и использовать полученные знания.
Им не хватает способности одновременно отслеживать и сравнивать несколько конкурирующих направлений исследований. Без этого они не могут интерпретировать как успехи, так и неудачи, чтобы переосмыслить свои будущие исследования, что является ключевым механизмом, обеспечивающим кумулятивный характер человеческих исследований.
Агенты общего кодирования обычно используют стенограммы разговоров для запоминания. Поскольку задачи AO охватывают сотни ходов и легко превышают пределы контекстного окна, этим агентам трудно сохранять и повторно использовать фактические данные на протяжении длительных периодов времени. В результате они теряют общую структуру исследовательского процесса и склонны к застреванию на ранних этапах неудач или погоне за нестабильными результатами оценок. Системе необходима структурированная, устойчивая память, которая фиксирует, какие направления были опробованы, какие фактические данные были получены и как каждый результат изменяет пространство будущих гипотез.
Существующие фреймворки также склонны поощрять хакерство и переобучение на основе метрик разработки. Это приводит к созданию иллюзии прогресса без улучшений, которые бы отражались на реальной производительности.
Наконец, универсальные агенты программирования обычно объединяют вызовы своих инструментов в единое общее рабочее дерево. Это архитектурное ограничение не позволяет им проверять параллельные гипотезы в изолированных средах без повреждения основной кодовой базы или сокрытия того, какая именно гипотеза привела к конкретному результату.
Структура Arbor
Arbor решает проблемы адаптивной архитектуры с помощью фреймворка, который автоматизирует долгосрочный цикл исследования, экспериментирования и абстракции, характерный для человеческих исследований. Arbor отделяет стратегическое направление исследований от задач программирования на практическом уровне с помощью двух ключевых компонентов:
Координатор: Долгоживущий агент ИИ, выступающий в роли главного исследователя. Он никогда напрямую не редактирует целевой код. Вместо этого он контролирует общее состояние исследований по оптимизации, анализирует накопленные данные, выдвигает новые гипотезы и направления для изучения, а также решает, что делать с результатами экспериментов.
Исполнительные агенты: Кратковременные, узкоспециализированные агенты искусственного интеллекта. Когда координатор хочет проверить идею, он запускает исполнительного агента и помещает его в изолированную среду, по сути, в новое рабочее дерево Git. Каждому исполнительному агенту передается одна гипотеза. Он реализует назначенную идею, проводит оценки, отлаживает ошибки и сообщает координатору о результатах и созданных артефактах.
Эти два компонента взаимодействуют посредством механизма, который исследователи называют «уточнением дерева гипотез» (HTR). HTR представляет весь исследовательский процесс в виде устойчивого разветвленного дерева, где каждый узел связывает четыре элемента: гипотезу, исполняемый артефакт, полученные фактические данные и обобщенную идею. Это означает, что координатор может одновременно исследовать несколько конкурирующих направлений, не теряя при этом своей позиции.
Координатор строит дерево, размещая общие идеи у корня, в то время как конкретные уточнения разветвляются в виде листьев. Это позволяет Arbor безопасно исследовать несколько конкурирующих гипотез одновременно. Если эксперимент исполнителя терпит неудачу, дерево записывает причину неудачи в виде отрицательного ограничения, гарантируя, что система не будет бесконечно повторять одну и ту же ошибку.
Чтобы понять, почему изоляция в Arbor важна, рассмотрим распространенный корпоративный сценарий: оптимизация конвейера генерации с дополненной информацией (RAG) для внутреннего ИИ-помощника. «Когда вы просите одного агента, такого как Клод Код или Кодекс, „повысить точность“, он, как правило, за один проход меняет множество вещей — разбиение на фрагменты, подсказку, метод поиска», — сказал Джин. Это приводит к путанице изменений, из-за чего невозможно определить, какое именно изменение действительно помогло. Кроме того, это напрямую изменяет репозиторий без изоляции.
Arbor решает эту проблему, рассматривая каждый рычаг как отдельную гипотезу. Разбиение на фрагменты становится одной ветвью, поиск — другой, а запрос — третьей, причём каждый элемент реализуется и оценивается в своём собственном изолированном рабочем дереве Git. «Таким образом, вы получаете чёткую атрибуцию: „разложение ограничений на стороне поиска дало +X; поиск в ширину на самом деле навредил“», — сказал Джин.
Когда исполнитель возвращает отчет, координатор записывает данные в дерево и распространяет полученную информацию вверх к родительским узлам. Это означает, что локальное наблюдение становится обобщенным ограничением, которое формирует будущую генерацию идей координатором.
Чтобы предотвратить манипулирование системой вознаграждений или переобучение на данных разработки, HTR применяет строгий «контроль слияния». Даже если исполнитель сообщает о фантастическом результате разработки, координатор создаст изолированное рабочее дерево для проверки кандидата с помощью отложенного тестового оценщика. Артефакт объединяется с текущим лучшим репозиторием только в том случае, если он явно улучшает результат теста, подтверждая, что прогресс реален.
Arbor в целом подпадает под концепцию «циклического проектирования», популяризированную такими деятелями индустрии, как создатель OpenClaw Питер Штайнбергер и руководитель Claude Code Борис Черни. Идея заключается в том, чтобы выйти за рамки отдельных запросов и разработать итеративные циклы (наблюдение, рассуждение, действие, проверка), которые управляют автономными агентами. Однако, как отмечает Джин, «цикл может заполниться беспорядочными, неотслеживаемыми попытками, и в итоге вы ничего не получите и не сможете восстановить, что изменилось».
Арбор в действии
Исследователи оценили 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 просто быстрее оптимизирует результат в сторону ненадежного результата», — сказал Джин.
Джин считает, что следующий этап развития выйдет за рамки использования отдельных скалярных метрик. «Естественным шагом станет то, что артефакт каждого узла будет нести вектор — точность, задержка, стоимость — вместо одной оценки», — сказал Джин. «Переход от одной скалярной метрики к многоцелевому поиску Парето — это очень естественное расширение структуры».
Подпишитесь, чтобы получать самые свежие новости!
Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.
Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.
Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.
Источник: venturebeat.com
Оцените материал:
