Istniejące systemy autonomicznego doskonalenia osiągają dobre wyniki w zadaniach programistycznych, ale nadal nie wiadomo, czy potrafią ulepszać złożone, długotrwałe procesy AI przypominające rzeczywiste wdrożenia korporacyjne.
Nasze badania nad Meta-Harness wykorzystują autonomiczne samodoskonalenie w procesach wyszukiwania agentowego, głębokich badań i analizy sygnałów, a jednocześnie uwzględniają wymagania przedsiębiorstw: ocenę na danych odłożonych, audytowalność, kontrolę budżetu i zatwierdzanie przez człowieka.
W trzech reprezentatywnych zadaniach Meta-Harness znacznie poprawił wyniki. W przypadku Signal Engine odnotowaliśmy między innymi 84-procentową poprawę wyniku testu na danych odłożonych, a w Agentic Multimodal Retrieval — większą trafność przy 16-krotnie szybszym wykonaniu.
W odróżnieniu od większości wcześniejszych podejść Meta-Harness w miarę możliwości mierzy skuteczność na odłożonych zbiorach danych, aby sprawdzić, czy usprawnienia uogólniają się poza dane użyte podczas optymalizacji.
Wyniki wskazują, że autonomiczne doskonalenie procesów może wyjść poza testy programistyczne i objąć rzeczywiste korporacyjne systemy AI, zapewniając praktyczną drogę do ciągłego ulepszania aplikacji AI.
Najnowsze prace nad autonomicznymi badaniami AI, w tym publikacja Meta-Harness, platforma CORAL oraz projekt karpathy/autoresearch, pokazały, że agenty programistyczne mogą iteracyjnie ulepszać rozwiązanie na podstawie określonej miary oceny. Otwarte pozostaje pytanie, czy metody te sprawdzają się w długotrwałych procesach AI, takich jak agentowe wyszukiwanie multimodalne, w którym agent musi wielokrotnie przeszukiwać multimodalne korpusy dziedzinowe, aby odpowiedzieć na pytanie, lub złożone potoki przetwarzania danych wymagające wielu zależnych kroków, wywołań narzędzi i decyzji dotyczących obsługi wyjątków. Istotniejsze pytanie brzmi: czy poprawa utrzymuje się również na danych, których optymalizator nigdy nie widzi?
Odpowiedzią na to pytanie są nasze prace badawczo-rozwojowe nad Meta-Harness. Wykorzystujemy pomysły z najnowszych badań i dostosowujemy je do potrzeb przedsiębiorstw: oceny na danych odłożonych, ścieżek audytu, limitów kosztów oraz wyraźnego momentu przekazania rozwiązania człowiekowi do przeglądu przed wdrożeniem.
Rozwiązanie przetestowaliśmy w trzech długotrwałych zadaniach wzorowanych na rzeczywistych projektach klientów. Signal Engine monitoruje na żywo strumień wpisów na platformie X dotyczących rynku AI i tworzy ustrukturyzowane raporty o trendach, oparte na wiarygodnych źródłach. Agentic Multimodal Retrieval analizuje zapytania łączące tekst i obrazy, aby zwracać najbardziej trafne strony dokumentów. Głębokie badania koordynują wiele agentów, które przeszukują internet, weryfikują źródła i tworzą obszerne raporty badawcze.
Signal Engine: łączny wynik testu na danych odłożonych wzrósł z 0,456 do 0,841, czyli względnie o 84%. Przy tym samym budżecie CORAL i karpathy/autoresearch nie przekroczyły 0,50.
Agentic Multimodal Retrieval: NDCG@10 na danych odłożonych wzrósł z 0,705 do 0,744, a rzeczywisty czas pojedynczej oceny spadł z 869 s do 54 s. Oznacza to 16-krotne przyspieszenie przy większej trafności.
Głębokie badania: łączny wynik jakości raportu wzrósł z 0,449 do 0,802 dla 10 pytań referencyjnych, podczas gdy rozwiązania bazowe uzyskały około 0,52. W tym zadaniu nie było odłożonego podzbioru, dlatego traktujemy ten wynik wyłącznie jako wynik w obrębie próby.
Efektywność wyszukiwania: dzięki predykcyjnemu ponownemu klasyfikowaniu hipotez Signal Engine osiągnął 91% najlepszego wyniku przebiegu referencyjnego w 3 iteracjach zamiast 20, przy takim samym budżecie oceny.
Większość autonomicznych systemów badawczych optymalizuje i ocenia rozwiązania na tym samym zbiorze danych, przez co nie można stwierdzić, czy wynik się uogólnia. W przypadku Signal Engine i Agentic Multimodal Retrieval stosujemy ścisły podział: zbiór treningowy, na którym można oceniać kandydatów, zbiór rozwojowy do kontroli poprawności oraz odłożony zbiór testowy, którego optymalizator nigdy nie widzi. Każdy podany wynik pochodzi z jednej konkretnej wersji kodu ocenionej na wszystkich podzbiorach. Nigdy nie łączymy więc najlepszego wyniku treningowego jednego kandydata z najlepszym wynikiem testowym innego.
W każdej rundzie otoczenie operacyjne generuje zestaw ustrukturyzowanych hipotez dotyczących zmian w kodzie. Każda hipoteza wskazuje mechanizm, który ma zostać zmieniony, wcześniejszą wersję stanowiącą jej podstawę oraz rodzaj błędu, któremu ma zaradzić. Etap klasyfikacji filtruje zestaw, zanim zostaną przeprowadzone kosztowne oceny. Hipotezy, które przejdą dalej, trafiają do działających równolegle agentów wykonawczych. Korzystają one ze wspólnej bazy wiedzy, ale edytują kod w całkowicie odizolowanych przestrzeniach roboczych, dzięki czemu każdy kandydat jest oceniany uczciwie i niezależnie. Na koniec rundy moduł wykonawczy wybiera jednego zwycięzcę: kandydata z najwyższym wynikiem, który przeszedł również wszystkie kontrole na jawnych podzbiorach danych. Zwycięzca staje się punktem wyjścia kolejnej rundy. Każda próba zapisuje stały zestaw danych w repozytorium dowodów tylko do dopisywania: poprawkę kodu, wyniki dla poszczególnych podzbiorów, dziennik zdarzeń oraz cztery krótkie analizy napisane przez LLM, dotyczące przebiegu, błędów, kosztów i wniosków. Moduł proponujący w kolejnej rundzie odczytuje tę historię, dzięki czemu otoczenie operacyjne wykorzystuje zdobytą wiedzę, zamiast ponownie podążać tymi samymi ślepymi uliczkami.
Trzy zabezpieczenia zapewniają bezpieczne działanie tej pętli. Zasady zakresu ograniczają listę plików, które kandydat może zmieniać, i wycofują wszystkie zmiany poza tym zakresem. Budżety tokenów i czasu rzeczywistego zatrzymują przebieg po przekroczeniu limitu wydatków, a ograniczenia współbieżności utrzymują otoczenie operacyjne w granicach limitów użycia modelu i procesorów GPU. Samo otoczenie operacyjne nigdy też niczego nie wdraża. Tworzy ono sklasyfikowanego i w pełni udokumentowanego kandydata, a inżynier przegląda różnice i decyduje, czy rozwiązanie trafi do środowiska produkcyjnego.
W lokalnym stosie każda runda opisanej wyżej pętli opiera się na pięciu podstawowych mechanizmach inżynieryjnych.
Izolacja przestrzeni roboczych. Jedno drzewo robocze git na każdego kandydata. Odgałęzienia współdzielą bazę obiektów, ale nie swoje pliki. Pozwala to uruchamiać kandydatów równolegle przy niemal stałym wykorzystaniu miejsca na dysku i ułatwia porównywanie ich z aktualnie najlepszą wersją.
Piaskownica wykonawcza. Konfiguracja udostępnia dwa tryby: natywny podproces do szybkich iteracji lub całkowicie odizolowane środowisko wykonawcze. Korpusy są montowane tylko do odczytu, a katalog roboczy każdej próby jest usuwany po jej ocenie. Dzięki temu próba nie może zmienić zbioru danych ani przenieść swojego stanu do następnej próby.
Zasady zakresu. Lista dozwolonych ścieżek zadeklarowana w konfiguracji eksperymentu. Wszystkie zmiany poza tą listą są wycofywane przed oceną próby, a sama próba zostaje oznaczona. Gwarantuje to, że różnice widoczne dla osoby dokonującej przeglądu pozostają w zadeklarowanym zakresie.
Egzekwowanie budżetu. Trzy warstwy: limity tokenów i czasu rzeczywistego dla każdej próby, łączny limit przebiegu oraz ograniczenie współbieżności. Razem zapewniają przewidywalność wydatków i utrzymują otoczenie operacyjne w granicach limitów użycia modelu oraz infrastruktury.
Repozytorium dowodów. Plik JSONL tylko do dopisywania, zawierający poprawkę kodu, wyniki dla poszczególnych podzbiorów, dziennik zdarzeń i cztery analizy napisane przez LLM. Widoki zmaterializowane — tabela wyników, najlepsza wersja i indeks błędów — są odtwarzane po każdej próbie. Kolejne rundy mogą dzięki temu korzystać z wcześniejszej historii, a każdy przebieg pozostaje odtwarzalny bajt po bajcie.
Żaden z tych mechanizmów nie jest opcjonalny. Celem otoczenia operacyjnego jest pozostawienie po zakończeniu przebiegu rozwiązania, które można rzeczywiście zatwierdzić: zwycięskiego kandydata, różnic o ograniczonym zakresie, pełnego rejestru wszystkich prób oraz znanego kosztu. Usunięcie któregokolwiek z pięciu mechanizmów oznacza utratę jednej z tych gwarancji.
We wszystkich trzech eksperymentach stosujemy tę samą strategię hipotez. W każdej iteracji moduł proponujący generuje więcej hipotez, niż pozwala uruchomić budżet: M = 8 kandydatów przy budżecie wysłania K = 4. Osobny moduł klasyfikujący oparty na LLM porządkuje następnie wszystkie 8 propozycji w ramach jednego, trzydziestosekundowego wywołania. Ma przy tym pełny obraz sytuacji: aktualny najlepszy wynik i jego słabe wymiary, analizy błędów z ostatnich prób oraz wszystkie 8 propozycji zestawionych obok siebie. Cztery najlepsze propozycje trafiają do modułu wykonawczego, a każda z nich wymaga od 15 do 30 minut. Pozostałe cztery są odrzucane, zanim wygenerują jakiekolwiek koszty.
Modele bazowe pozostawały niezmienione przez cały czas; otoczenie operacyjne edytowało jedynie otaczający je kod. Signal Engine i Głębokie badania działały na modelu gpt-5.5. Agentic Multimodal Retrieval korzystał z modelu Qwen3.6-35B-A3B o otwartych wagach, udostępnianego lokalnie przez vLLM i połączonego z modułem wyszukiwania obrazów ColQwen3-4B. Takie zestawienie wybrano ze względu na przewidywalne koszty infrastruktury lokalnej.
Poniższy wykres pokazuje zmiany wyników w naszych trzech głównych zadaniach. „Wersja początkowa” to kod wyjściowy napisany przez inżyniera. „Meta-Harness” to najlepsza wersja znaleziona przez Meta-Harness. We wszystkich trzech zadaniach odnotowaliśmy poprawę wyników na odłożonym zbiorze testowym.
Signal Engine został oceniony przez LLM pod względem aktualności, zgodności z faktami, szczegółowości i tonu. Wykorzystano 150 wpisów treningowych z platformy X oraz 150 odłożonych wpisów testowych. W trakcie przebiegu najlepsza wersja poprawiła łączny wynik treningowy z 0,431 do 0,756, a wynik na danych odłożonych z 0,456 do 0,841. Poprawa wynikała ze zmian w samym otoczeniu operacyjnym, a nie tylko z modyfikacji poleceń. Zwycięskie iteracje nauczyły się odfiltrowywać szum z mediów społecznościowych, dodały etapy weryfikacji faktów i wymagały, aby każdy wynik opierał się na jednoznacznych dowodach. Poniższy schemat przedstawia proces iteracyjny.
Historia prób pokazuje, jak te usprawnienia się kumulowały. Wczesna zmiana strukturalna podniosła najlepszy bieżący wynik do 0,625; bardziej szczegółowa obsługa dowodów zwiększyła go do 0,679; a udoskonalona pętla refleksji i kryteriów oceny — do 0,819. Około połowy wszystkich przebiegów kandydatów uzyskało gorsze wyniki lub całkowicie się nie powiodło, ale nie wpłynęło to na tabelę wyników: każde odgałęzienie działało w izolacji, przegrane różnice odrzucano, a błędy zapisywano w repozytorium wniosków, aby kolejny moduł proponujący nie powtarzał tej samej ślepej uliczki.
Co najważniejsze, przez cały przebieg krzywa dla danych odłożonych rosła wraz z krzywą treningową. Sugeruje to, że otoczenie operacyjne rzeczywiście ulepszało proces, zamiast zapamiętywać korpus treningowy. Wyniki na danych odłożonych były nieco wyższe od treningowych, co interpretujemy jako zwykły szum próbkowania między dwoma małymi, rozłącznymi podzbiorami.
Agentic Multimodal Retrieval mierzymy za pomocą NDCG@10 na publicznym podzbiorze Computer Science zbioru ViDoRe V3, obejmującym 20 zapytań treningowych, 10 rozwojowych i 20 odłożonych zapytań testowych. Otoczenie operacyjne podniosło NDCG@10 na danych odłożonych z 0,705 do 0,744, jednocześnie skracając całkowity rzeczywisty czas oceny z 869 sekund do 54 sekund.
Głębokie badania są oceniane przez LLM na podstawie łącznej miary jakości merytorycznej i jakości źródeł, zgodnie z metodą DeepResearch-Eval, dla 10 pytań referencyjnych. Ulepszony kod podniósł średni wynik z 0,449 do 0,802. Zwycięskie zmiany można było łatwo odczytać z różnic w kodzie: dodano wstępny etap planowania, który porównuje podejścia przed uruchomieniem agentów badawczych, oraz końcowy etap przeglądu ukierunkowany na wymiary, w których raporty wcześniej uzyskiwały słabe wyniki. Ponieważ ocena tego zbioru jest kosztowna, a sam zbiór niewielki, nie podzieliliśmy go i traktujemy wynik jako uzyskany w obrębie próby.
Wszystkie trzy metody porównaliśmy przy takim samym budżecie: na tych samych zbiorach danych i modelach bazowych, z takim samym limitem iteracji i taką samą łączną liczbą ocen kandydatów. W zadaniu Signal Engine Meta-Harness osiąga wynik 0,841 w teście na danych odłożonych, podczas gdy oba rozwiązania bazowe pozostają poniżej 0,50. W zadaniu Agentic Multimodal Retrieval nasz zespół uzyskał najwyższy NDCG@10 na danych odłożonych (0,744 wobec 0,700 dla CORAL i 0,738 dla karpathy), a oficjalną ocenę przeprowadza od 12 do 14 razy szybciej: w 54 s wobec 786 s i 650 s. W zadaniu Głębokie badania nasz zespół osiąga 0,802, podczas gdy oba rozwiązania bazowe pozostają w pobliżu 0,52. W całym porównaniu obowiązuje jedno zastrzeżenie: samodzielnie odtworzyliśmy CORAL i karpathy/autoresearch na podstawie opublikowanych opisów, dlatego część różnicy może wynikać z odmiennych implementacji, a nie wyłącznie z samych metod.
Różnicę wyjaśniają cztery decyzje projektowe. Po pierwsze, przed wprowadzeniem jakichkolwiek zmian w kodzie nasz zespół tworzy ustrukturyzowaną specyfikację projektu. Sprzyja to zmianom strukturalnym, takim jak nowe etapy potoku, zamiast drobnych modyfikacji poleceń. Po drugie, uruchamia współbieżne odgałęzienia oparte na wspólnym, aktualnie najlepszym kandydacie. Usprawnienia kumulują się więc szybciej niż w przypadku niezależnych agentów CORAL lub ściśle sekwencyjnej pętli karpathy. Po trzecie, każda próba pozostawia ustrukturyzowane artefakty — wyniki, dzienniki zdarzeń i cztery analizy opracowane przez LLM — które odczytuje kolejny moduł proponujący. Rozwiązania bazowe zachowują jedynie proste dzienniki prób. Po czwarte, sterownik adaptacyjny kieruje moduł proponujący ku eksploracji po zastoju i ku udoskonalaniu po sukcesie. Dodatkowo predykcyjne ponowne klasyfikowanie hipotez odrzuca słabe pomysły, zanim zużyją budżet.
Krzywe dla danych odłożonych pokazują uogólnianie w obrębie dziedziny, a nie transfer między dziedzinami. Nie należy oczekiwać, że proces dostrojony do wyodrębniania sygnałów z rynku AI sprawdzi się w tekstach prawnych lub biomedycznych bez ponownego uruchomienia otoczenia operacyjnego. Otoczenie operacyjne wspina się tylko na wzgórze wyznaczone przez mechanizm oceny, więc wiernie nadmiernie dopasuje się do zaszumionego zbioru treningowego lub źle skalibrowanego arbitra. Przed poważnym przebiegiem zalecamy co najmniej 20 starannie dobranych elementów treningowych i osobny podzbiór rozwojowy. Największym ograniczeniem praktycznym są koszty. Każda ocena ponownie uruchamia cały potok na wszystkich podzbiorach. Sam wybrany kandydat do wyszukiwania zużył około 2,2 miliona tokenów wejściowych, a poważna optymalizacja z użyciem modelu klasy gpt-5.5 kosztuje od kilkuset do nieco ponad tysiąca dolarów na zadanie. Wyniki pochodzą też z pojedynczych przebiegów, a nie z wielokrotnych prób. Dlatego udostępniamy je jako techniczny wpis na blogu, a nie formalne badanie.
Meta-Harness pokazuje, że autonomiczne ulepszanie kodu może być na tyle uporządkowane, aby sprawdzić się w przedsiębiorstwach. Kluczowe elementy to hipotezy strukturalne, predykcyjne filtrowanie wstępne, odizolowana ocena, testy na danych odłożonych wszędzie tam, gdzie pozwalają na to dane, oraz pełna ścieżka audytu każdej zatwierdzonej zmiany. Razem zapewniają zespołowi inżynieryjnemu przewidywalną drogę od działającego potoku początkowego do jego wymiernie lepszej wersji. Właściciel procesu otrzymuje zaś prosty model działania: korzyści z autonomicznej eksploracji zamknięte w ścisłych ramach uwzględniających budżet, z udziałem człowieka przed wdrożeniem jakichkolwiek zmian.