Уявіть, що ваша інженерна команда розгорнула ШІ-агента для пошуку по внутрішніх документах компанії та відповіді на запитання співробітників. Під час розробки він працює бездоганно, але в продакшені стабільно видає неправдиву інформацію (“галюцинує”) або ігнорує ключові обмеження. Виправлення цього рідко буває простим патчем. Це вимагає виснажливого процесу проб і помилок, одночасного налаштування стратегій розбиття даних (chunking), методів пошуку (retrieval) та системних підказок (system prompts). Оскільки ці налаштування взаємопов’язані, стає майже неможливо визначити, яке саме коригування принесло результат.
Щоб вирішити цю проблему, дослідники з Університету Женьмінь (Китай) та Microsoft Research представили Arbor – фреймворк, який перетворює дослідження та оптимізацію керовані ШІ з послідовності спроб і помилок на процес кумулятивного навчання. Arbor організовує гіпотези, експерименти та висновки у дерево, що допомагає системі вчитися на попередніх невдачах для здійснення розумніших, верифікованих покращень з часом.
У практичних тестах Arbor забезпечив більш ніж 2,5-кратне збільшення верифікованої продуктивності порівняно зі стандартними ШІ-агентами для кодування під час виконання реальних інженерних завдань, працюючи за однакових бюджетних обмежень.
Для корпоративного ШІ ця техніка безпосередньо транслюється в автоматизацію безперервного вдосконалення складних реальних інженерних систем.
Розуміння вузьких місць в автономній оптимізації
Зі зростанням можливостей великих мовних моделей та систем ШІ очікується, що вони будуть виконувати складніші операції, такі як автономна оптимізація (AO) програмних систем, наприклад, агентських фреймворків або алгоритмів навчання моделей.
AO охоплює фундаментальний цикл автономних досліджень. ШІ-агент починає з початкового змінної сутності, як-от кодова база машинного навчання або конвеєр даних, та конкретної мети. Мета агента – ітеративно покращувати цю сутність за допомогою експериментального зворотного зв’язку без покрокового людського нагляду.
Основна проблема AO часто невірно розуміється. Багато інженерних команд виявляють, що просте надання агенту для кодування більшого часу чи обчислювальних ресурсів для оптимізації кодової бази не призводить до кращих результатів. “Автоматизація може забезпечити роботу ШІ протягом дуже тривалого часу – але цикл не є прогресом,” – заявив VentureBeat Цзяцзе Цзінь, співавтор статті. “Якщо мета розпливчаста, або метрика легко обходиться, довготривала автоматизація часто просто генерує “покращення” швидше, які насправді нікому не потрібні”.
Цзінь пояснює, що складні завдання вимагають багатьох спроб для правильного виконання, а стандартні архітектури агентів не мають критично важливої структури даних для підтримки стану. “Як забезпечити, щоб розуміння та досвід від кожної спроби насправді накопичувалися, а не губилися в буфері прокрутки?” – запитав він. Без цієї структури агенти просто повторюють ті самі помилки.
Сучасні агентські системи можуть виконувати експерименти протягом багатьох годин для добре визначених цілей: редагування коду, виклик інструментів, автоматичне виконання тестів. Але вони розглядають кожну спробу ізольовано, втрачаючи структурні механізми, які б дозволили їм накопичувати знання та діяти на основі того, що вони вивчили.
Їм бракує здатності одночасно підтримувати та порівнювати кілька конкуруючих напрямків досліджень. Без цього вони не можуть інтерпретувати як успіхи, так і невдачі, щоб переформувати своє майбутнє дослідження, що є ключовим механізмом, який робить людські дослідження кумулятивними.
Загальні агенти для кодування зазвичай використовують витяги з розмов як свою пам’ять. Оскільки завдання AO охоплюють сотні кроків і легко перевищують ліміти контекстного вікна, ці агенти мають труднощі зі збереженням та повторним використанням фактичних доказів протягом тривалої історії. В результаті вони втрачають загальну структуру дослідницького процесу і схильні зупинятися на ранніх невдачах або переслідувати “шумні” коливання в оцінках. Системі потрібна структурована, надійна пам’ять, яка записує, які напрямки були спробовані, які фактичні докази були отримані, і як кожен результат змінює простір майбутніх гіпотез.
Існуючі фреймворки також схильні до “зламу винагород” (reward hacking) та перенавчання на метриках розробки. Це створює ілюзію прогресу, не забезпечуючи при цьому покращень, які передаються на реальну продуктивність.
Нарешті, універсальні агенти для кодування зазвичай ланцюжково зв’язують свої виклики інструментів на одному спільному робочому дереві. Це архітектурне обмеження заважає їм тестувати паралельні гіпотези в ізольованих середовищах, не пошкоджуючи основну кодову базу або не приховуючи, яка саме гіпотеза спричинила конкретний результат.
Фреймворк Arbor
Arbor вирішує проблеми AO за допомогою фреймворку, який автоматизує довгостроковий цикл дослідження, експериментування та абстракції, що характеризує людські дослідження. Arbor розділяє стратегічне керівництво дослідженнями від завдань кодування на нижчому рівні за допомогою двох ключових компонентів:
Координатор (The coordinator): Довготривалий ШІ-агент, який діє як головний дослідник. Він ніколи не редагує цільову кодову базу безпосередньо. Натомість він керує загальним станом оптимізаційних досліджень, спостерігає за накопиченими доказами, формує нові гіпотези та напрямки для дослідження, і вирішує, що робити з результатами експериментів.
Виконавці (Executors): Короткотривалі, високо сфокусовані ШІ-агенти. Коли координатор хоче перевірити ідею, він створює виконавця та розміщує його в ізольованому середовищі, по суті, в новому робочому дереві Git. Кожному виконавцю передається одна гіпотеза. Він реалізує призначену ідею, проводить оцінки, налагоджує помилки та повідомляє координатору про результати та створені артефакти.
Ці два компоненти співпрацюють через механізм, який дослідники називають “Вдосконалення дерева гіпотез” (Hypothesis Tree Refinement – HTR). HTR представляє весь дослідницький процес як стійке, розгалужене дерево, де кожен вузол пов’язує чотири елементи: гіпотезу, виконуваний артефакт, отримані фактичні докази та дистильований висновок. Це означає, що координатор може досліджувати кілька конкуруючих напрямків одночасно, не втрачаючи своєї позиції.
Координатор будує дерево, розміщуючи широкі ідеї ближче до кореня, тоді як конкретні уточнення розгалужуються як листя. Це дозволяє Arbor безпечно досліджувати кілька конкуруючих гіпотез одночасно. Якщо експеримент виконавця зазнає невдачі, дерево записує причину невдачі як негативне обмеження, гарантуючи, що система не буде нескінченно повторювати ту саму помилку.
Щоб зрозуміти важливість ізоляції Arbor, розглянемо поширений корпоративний сценарій: оптимізація конвеєра Retrieval-Augmented Generation (RAG) для внутрішнього помічника ШІ. “Коли ви просите одного агента, як Claude Code або Codex, ‘покращити точність’, він, як правило, змінює купу речей за один прохід – розбиття (chunking), підказку (prompt), метод пошуку (retrieval),” – каже Цзінь. Це заплутує зміни, роблячи неможливим визначення того, яка саме з них допомогла. Це також безпосередньо мутує репозиторій без ізоляції.
Arbor вирішує це, розглядаючи кожен важіль як окрему гіпотезу. Chunking стає однією гілкою, retrieval – іншою, а prompt – третьою, кожна реалізується та оцінюється у власному ізольованому робочому дереві Git. “Таким чином, ви отримуєте чисте атрибутування: ‘декомпозиція обмежень на стороні пошуку дала +X; пошук у ширину насправді нашкодив,'” – зазначає Цзінь.
Коли виконавець повертає звіт, координатор записує докази в дерево та поширює висновок вгору до батьківських вузлів. Це означає, що локальне спостереження стає узагальненим обмеженням, яке формує генерацію майбутніх ідей координатором.
Щоб запобігти “зламу винагород” або перенавчанню на даних розробки, HTR впроваджує суворий “шлюз злиття” (merge gate). Навіть якщо виконавець повідомляє про фантастичний результат розробки, координатор запустить ізольоване робоче дерево для тестування кандидата проти відкладеного тестового оцінювача. Артефакт зливається в поточний найкращий “стовбур” (trunk) тільки тоді, коли він демонструє покращення тестового показника, підтверджуючи, що прогрес є реальним.
Arbor загалом підпадає під концепцію “інженерії циклів” (loop engineering), популяризованої такими промисловими діячами, як творець OpenClaw Пітер Стайнбергер та керівник Claude Code Борис Черний. Ідея полягає в тому, щоб вийти за межі одиночних запитів і розробити ітеративні цикли (спостерігай, міркуй, дій, перевіряй), які керують автономними агентами. Однак, як зазначає Цзінь, “Цикл може заповнитися безладними, невідстежуваними спробами, і в підсумку ви не матимете, що показати, і жодного способу реконструювати, що змінилося”.
Arbor в дії
Дослідники оцінили Arbor на наборі завдань автономної оптимізації, створеному на основі реальних дослідницьких середовищ та бенчмарку машинного навчання MLE-Bench Lite. Набір AO включав завдання з різних галузей розробки ШІ, зокрема навчання моделей, інженерії агентських фреймворків та синтезу даних.
Дослідники використовували різні базові моделі для агентів координатора та виконавців, включаючи 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 просто швидше оптимізуватиме до ненадіжного результату,” – застерігає Цзінь.
Цзінь бачить наступну еволюцію, що виходить за рамки одиночних скалярних метрик. “Природною еволюцією є те, щоб артефакт кожного вузла містив вектор – точність, затримка, вартість – замість єдиного показника,” – каже Цзінь. “Перехід від єдиного скаляра до багатоцільового пошуку Парето є дуже природним розширенням фреймворку”.
Як захиститися (Порада CryptoDom): Ця розробка стосується оптимізації ШІ-систем, а не прямої кібербезпеки. Однак, для загального захисту від потенційних вразливостей, які можуть виникнути через складні ШІ-системи (наприклад, у майбутньому), завжди використовуйте надійні, унікальні паролі та вмикайте двофакторну автентифікацію (2FA) для всіх ваших онлайн-акаунтів. Регулярно оновлюйте програмне забезпечення та будьте обережні з підозрілими електронними листами чи посиланнями, що можуть призвести до фішингових атак.
За даними порталу: venturebeat.com