Наявні системи автономного вдосконалення продемонстрували високі результати в завданнях програмування, але досі незрозуміло, чи здатні вони покращувати складні довготривалі робочі процеси ШІ, подібні до реальних корпоративних розгортань.
Наше дослідження Meta-Harness застосовує автономне самовдосконалення до агентного пошуку, поглибленого дослідження та аналізу сигналів, водночас додаючи корпоративні вимоги: оцінювання на відкладених даних, можливість аудиту, контроль бюджету й затвердження людиною.
У трьох типових навантаженнях Meta-Harness суттєво підвищив ефективність, зокрема забезпечив покращення результату на відкладеному тесті Signal Engine на 84%, а для агентного мультимодального пошуку — вищу точність за виконання у 16 разів швидше.
На відміну від більшості попередніх підходів, Meta-Harness за можливості вимірює успіх на відкладених наборах даних, щоб з’ясувати, чи узагальнюються покращення за межами даних, використаних під час оптимізації.
Ці результати свідчать, що автономне вдосконалення робочих процесів може вийти за межі тестів із програмування й охопити реальні корпоративні системи ШІ, відкриваючи практичний шлях до безперервного покращення ШІ-застосунків.
Нещодавні дослідження автономної роботи ШІ, зокрема стаття Meta-Harness, фреймворк CORAL і karpathy/autoresearch, показали, що агенти програмування можуть ітеративно вдосконалювати рішення за заданою метрикою оцінювання. Відкритим залишається питання, чи придатні ці методи для довготривалих робочих процесів ШІ — наприклад, агентного мультимодального пошуку, де агент має ітеративно шукати в мультимодальних галузевих корпусах, щоб відповісти на запитання, — або для складних конвеєрів обробки даних із багатьма залежними кроками, викликами інструментів і рішеннями щодо обробки винятків. Глибше питання полягає в тому, чи зберігаються ці здобутки на даних, яких оптимізатор ніколи не бачить.
Наша науково-дослідна робота над Meta-Harness — це відповідь на це питання. Вона запозичує ідеї з нещодавніх досліджень і адаптує їх до потреб бізнесу: оцінювання на відкладених даних, журнали аудиту, обмеження витрат і чітка передача результату рецензенту-людині перед випуском.
Ми протестували її на трьох довготривалих завданнях, змодельованих за прикладами реальної роботи з клієнтами. Signal Engine відстежує потік дописів у X про ринок ШІ в реальному часі та створює структуровані звіти про тенденції з надійними джерелами. Агентний мультимодальний пошук аналізує змішані текстові й графічні запити та повертає найрелевантніші сторінки документів. Поглиблене дослідження координує кількох агентів, які шукають інформацію в інтернеті, перехресно перевіряють джерела та готують розгорнуті дослідницькі звіти.
Signal Engine: сукупна оцінка відкладеного тесту зросла з 0,456 до 0,841, тобто на 84% у відносному вираженні. За однакового бюджету CORAL і karpathy/autoresearch не досягли 0,50.
Агентний мультимодальний пошук: NDCG@10 на відкладених даних зріс із 0,705 до 0,744, а фактичний час кожного оцінювання скоротився з 869 до 54 с. Це у 16 разів швидше й водночас точніше.
Поглиблене дослідження: сукупна оцінка якості звітів зросла з 0,449 до 0,802 на 10 контрольних запитаннях, тоді як базові методи отримали приблизно 0,52. Для цього завдання не було відкладеного розділу, тому результат стосується лише навчальної вибірки.
Ефективність пошуку: завдяки прогнозному переранжуванню гіпотез Signal Engine досяг 91% найкращої оцінки еталонного запуску за 3 ітерації замість 20 з тим самим бюджетом оцінювання.
Більшість систем автономного дослідження оптимізують і оцінюють результат на одному наборі даних, тому неможливо визначити, чи здатен він до узагальнення. Для Signal Engine та агентного мультимодального пошуку ми застосовуємо суворий поділ: навчальний набір, на якому можна оцінювати варіанти; набір для розробки й базових перевірок; а також відкладений тестовий набір, якого оптимізатор ніколи не бачить. Кожен наведений результат отримано для однієї конкретної версії коду, оціненої на всіх розділах. Тому ми ніколи не поєднуємо найкращу навчальну оцінку одного варіанта з найкращою тестовою оцінкою іншого.
У кожному раунді система harness створює набір структурованих гіпотез щодо змін у коді. У кожній гіпотезі зазначено механізм, який пропонується змінити, попередню версію, на якій вона ґрунтується, і тип помилки, який вона має усунути. Етап ранжування фільтрує набір до початку ресурсомістких оцінювань. Відібрані гіпотези передаються паралельним агентам-виконавцям, які користуються спільною базою знань, але редагують код у повністю ізольованих робочих просторах. Завдяки цьому кожен варіант оцінюється об’єктивно й незалежно. Наприкінці раунду виконавець обирає одного переможця — варіант із найвищою оцінкою, який також пройшов усі перевірки на доступних розділах даних. Цей переможець стає основою для наступного раунду. Кожне випробування записує до сховища доказів лише з можливістю доповнення фіксований набір даних: патч коду, оцінки за кожним розділом, журнал подій і чотири короткі аналітичні висновки від LLM щодо перебігу, помилок, вартості та ретроспективи. Генератор пропозицій у наступному раунді перечитує цю історію, тож система harness накопичує здобуті знання, а не знову повторює ті самі безрезультатні спроби.
Три запобіжні механізми гарантують безпечне виконання циклу. Політика області змін обмежує перелік файлів, які може редагувати варіант, і скасовує всі зміни поза ним. Бюджети токенів і часу зупиняють виконання після досягнення встановленої межі витрат, а обмеження паралельності утримують систему harness у межах лімітів запитів моделі та GPU. При цьому система harness ніколи нічого не випускає самостійно. Вона надає повністю задокументований варіант із місцем у рейтингу, а інженер перевіряє різницю у коді й вирішує, чи розгортати його у виробничому середовищі.
У локальному стеку кожен раунд описаного вище циклу спирається на п’ять базових інженерних механізмів.
Ізоляція робочих просторів. Окреме робоче дерево git для кожного варіанта. Форки мають спільну базу об’єктів, але не мають доступу до файлів один одного. Це дає змогу паралельно запускати варіанти з майже незмінними витратами дискового простору та легко порівнювати їх із поточною найкращою версією.
Пісочниця виконання. Конфігурація підтримує два режими: нативний підпроцес для швидких ітерацій або повністю ізольоване середовище виконання. Корпуси монтуються лише для читання, а тимчасовий каталог кожного випробування видаляється після оцінювання. Тому випробування не може змінити набір даних або передати свій стан наступному випробуванню.
Політика області змін. Список дозволених шляхів, визначений у конфігурації експерименту. Усі зміни поза цим списком скасовуються до оцінювання, а випробування позначається відповідним прапорцем. Отже, різниця у коді, яку бачить рецензент, гарантовано залишається в межах визначеної області.
Дотримання бюджету. Три рівні: ліміти токенів і часу для кожного випробування, загальна межа для всього запуску та обмеження паралельності. Разом вони роблять витрати передбачуваними та втримують систему harness у межах лімітів запитів моделі й інфраструктури.
Сховище доказів. JSONL-файл лише з можливістю доповнення, що містить патч коду, оцінки за розділами, журнал подій і чотири аналітичні висновки від LLM. Матеріалізовані подання (таблиця лідерів, найкраща версія та індекс помилок) оновлюються після кожного випробування. Це дає наступним раундам змогу спиратися на попередню історію, водночас зберігаючи побайтову відтворюваність кожного запуску.
Жоден із цих механізмів не є необов’язковим. Мета системи harness — після завершення запуску надати рецензенту те, що справді можна затвердити: варіант-переможець, різницю у коді в чітких межах, повну історію всіх спроб і відому вартість. Якщо прибрати будь-який із п’яти механізмів, одна з цих гарантій зникне.
В усіх трьох експериментах використовується однакова стратегія роботи з гіпотезами. На кожній ітерації генератор створює більше гіпотез, ніж дає змогу перевірити бюджет: M = 8 варіантів за бюджету запуску K = 4. Потім окремий ранжувальник на базі LLM упорядковує всі 8 варіантів за один тридцятисекундний виклик, маючи повну картину: поточну найкращу оцінку та її слабкі складові, аналіз помилок нещодавніх випробувань і всі 8 пропозицій поруч. Чотири найкращі варіанти передаються виконавцю, і кожен із них потребує від 15 до 30 хвилин. Інші чотири відхиляються ще до того, як спричинять будь-які витрати.
Базові моделі залишалися незмінними протягом усього процесу; система harness редагувала лише код навколо них. Signal Engine і поглиблене дослідження працювали на gpt-5.5. Агентний мультимодальний пошук працював на моделі з відкритими вагами Qwen3.6-35B-A3B, локально розгорнутій через vLLM, у парі із засобом пошуку зображень ColQwen3-4B. Це поєднання обрали через передбачувану вартість локальної експлуатації.
На діаграмі нижче показано динаміку оцінок для трьох наших основних завдань. «Початкова версія» — це вихідний код, написаний інженером. «Meta-Harness» — це найкраща версія, знайдена Meta-Harness. На відкладеному тестовому наборі результат покращився для всіх трьох завдань.
Signal Engine оцінював LLM-суддя за актуальністю, фактичною точністю, деталізацією й тоном на 150 навчальних і 150 відкладених тестових дописах. За час запуску найкраща версія підвищила сукупну навчальну оцінку з 0,431 до 0,756, а оцінку на відкладених даних — із 0,456 до 0,841. Покращення забезпечили зміни в самій системі harness, а не лише коригування запитів: успішні ітерації навчилися фільтрувати шум у соцмережах, додали етапи перехресної перевірки фактів і вимагали, щоб кожен результат спирався на явні докази. На схемі нижче показано процес ітерацій.
Історія випробувань показує, як накопичувалися ці покращення. Перша структурна зміна підвищила поточний найкращий результат до 0,625; детальніша робота з доказами — до 0,679; а вдосконалений цикл ретроспективи та критеріїв оцінювання — до 0,819. Приблизно половина запусків варіантів показала гірші результати або завершилася помилкою, але це не вплинуло на таблицю лідерів: кожен форк працював ізольовано, невдалі зміни відкидалися, а помилки записувалися до сховища ретроспектив, щоб наступний генератор не повторював той самий безрезультатний шлях.
Найважливіше те, що протягом запуску крива відкладених даних зростала разом із навчальною кривою. Це свідчить, що система harness удосконалювала робочий процес, а не запам’ятовувала навчальний корпус. Оцінки на відкладених даних були трохи вищими за навчальні. Ми пояснюємо це звичайним шумом вибірки між двома невеликими неперетинними розділами.
Агентний мультимодальний пошук вимірюється за допомогою NDCG@10 на загальнодоступному розділі Computer Science набору ViDoRe V3, сформованому з 20 навчальних, 10 розробницьких і 20 відкладених тестових запитів. Система harness підвищила NDCG@10 на відкладених даних із 0,705 до 0,744, водночас скоротивши загальний фактичний час оцінювання з 869 до 54 секунд.
Поглиблене дослідження оцінюється за сукупним показником змістовної якості та якості джерел, визначеним LLM-суддею відповідно до DeepResearch-Eval, на 10 контрольних запитаннях. Удосконалений код підвищив середній показник із 0,449 до 0,802. Успішні зміни було легко побачити в різниці коду: попередній етап планування для порівняння підходів до запуску дослідницьких агентів і фінальна перевірка, зосереджена на складових, за якими звіти раніше отримували низькі оцінки. Оскільки цей набір малий, а оцінювання дороге, ми не ділили його й вважаємо результат отриманим на навчальній вибірці.
Ми порівняли всі три методи за однакового бюджету: ті самі набори даних, базові моделі, ліміт ітерацій і загальна кількість оцінювань варіантів. У Signal Engine Meta-Harness досягає 0,841 на відкладеному тесті, тоді як обидва базові методи не досягли 0,50. В агентному мультимодальному пошуку наша команда має найвищий NDCG@10 на відкладених даних (0,744 проти 0,700 у CORAL і 0,738 у karpathy) та виконує офіційне оцінювання у 12–14 разів швидше: 54 с проти 786 і 650 с. У поглибленому дослідженні наша команда досягає 0,802, тоді як обидва базові методи залишилися на рівні близько 0,52. Є важливе застереження: ми відтворили CORAL і karpathy/autoresearch за їхніми опублікованими описами, тому частина розриву може бути зумовлена відмінностями реалізації, а не лише самих методів.
Розрив пояснюють чотири проєктні рішення. По-перше, до редагування коду наша команда створює структуровану проєктну специфікацію. Це спрямовує її на структурні зміни, як-от нові етапи конвеєра, а не на коригування запитів. По-друге, вона паралельно запускає форки, що спираються на спільний найкращий варіант, тому покращення накопичуються швидше, ніж у незалежних агентів CORAL або суворо послідовному циклі karpathy. По-третє, кожне випробування залишає структуровані артефакти — оцінки, журнали подій і чотири аналітичні висновки від LLM, — які перечитує наступний генератор пропозицій, тоді як базові методи зберігають лише прості журнали спроб. По-четверте, адаптивний контролер спрямовує генератор до дослідження після застою та до уточнення після успіху, а прогнозне переранжування гіпотез відкидає слабкі ідеї ще до витрачання бюджету.
Криві відкладених даних демонструють узагальнення в межах предметної області, а не перенесення між областями: не слід очікувати, що процес, налаштований для виділення сигналів ринку ШІ, працюватиме так само з юридичними чи біомедичними текстами без повторного запуску системи harness. Система harness також рухається лише в напрямку, заданому оцінювачем, тому сумлінно перенавчиться на зашумленому навчальному наборі або неправильно відкаліброваному судді. Перед серйозним запуском ми рекомендуємо підготувати щонайменше 20 ретельно відібраних навчальних прикладів і окремий розділ для розробки. Вартість — найбільше практичне обмеження. Кожне оцінювання повторно запускає весь конвеєр на всіх розділах; лише вибраний варіант пошуку використав приблизно 2,2 мільйона вхідних токенів, а серйозна оптимізація на моделі класу gpt-5.5 коштує від кількох сотень до трохи більше тисячі доларів на завдання. Нарешті, ці показники отримано за результатами одиничних запусків, а не повторних випробувань. Саме тому ми публікуємо їх у дописі інженерного блогу, а не як формальне дослідження.
Meta-Harness показує, що автономне вдосконалення коду можна зробити достатньо системним для корпоративного використання. Для цього потрібні структурні гіпотези, прогнозна попередня фільтрація, ізольоване оцінювання, тестування на відкладених даних, де це можливо, і повний журнал аудиту для кожної прийнятої зміни. Разом вони дають інженерній команді передбачуваний шлях від робочого початкового конвеєра до версії з вимірювано кращими результатами, а операційному керівнику — просту модель: переваги автономного дослідження в суворих межах із контролем бюджету та обов’язковою участю людини перед випуском.