Esamos autonominio tobulinimo sistemos pasiekė gerų rezultatų atlikdamos programavimo užduotis, tačiau vis dar neaišku, ar jos gali gerinti sudėtingas, ilgalaikes DI darbo eigas, panašias į realiai įmonėse diegiamas sistemas.
Mūsų „Meta-Harness“ tyrime autonominis savęs tobulinimas taikomas agentinės paieškos, giliojo tyrimo ir signalų analizės darbo eigoms, kartu įtraukiant įmonėms svarbius reikalavimus: vertinimą pagal atidėtus duomenis, audituojamumą, biudžeto kontrolę ir žmogaus patvirtinimą.
Atliekant tris tipinius darbo krūvius, „Meta-Harness“ gerokai pagerino rezultatus: „Signal Engine“ atidėto testo našumas padidėjo 84 %, o agentinė multimodalinė paieška tapo tikslesnė ir buvo vykdoma 16 kartų greičiau.
Kitaip nei daugumoje ankstesnių metodų, „Meta-Harness“, kai tik įmanoma, sėkmę matuoja pagal atidėtus duomenų rinkinius, kad būtų galima įvertinti, ar patobulinimai pritaikomi ne tik optimizuojant naudotiems duomenims.
Šie rezultatai rodo, kad autonominis darbo eigų tobulinimas gali peržengti programavimo etaloninių testų ribas ir būti taikomas realioms įmonių DI sistemoms, suteikdamas praktišką būdą nuolat gerinti DI programas.
Naujausi autonominių DI tyrimų darbai, įskaitant straipsnį „Meta-Harness“, sistemą CORAL ir „karpathy/autoresearch“, parodė, kad programavimo agentai, turėdami vertinimo metriką, gali iteratyviai gerinti sprendimą. Vis dar neatsakyta, ar šiuos metodus galima pritaikyti ilgalaikėms DI darbo eigoms, pavyzdžiui, agentinei multimodalinei paieškai, kai agentas turi iteratyviai ieškoti įvairiarūšiuose specializuotuose tekstynuose, kad atsakytų į klausimą, arba sudėtingiems duomenų apdorojimo procesams, kuriems reikia daug tarpusavyje priklausomų veiksmų, įrankių iškvietimų ir sprendimų dėl išimčių tvarkymo. Svarbesnis klausimas – ar pagerėjimas išlieka vertinant pagal optimizavimo moduliui niekada nerodytus duomenis.
Mūsų „Meta-Harness“ mokslinių tyrimų ir plėtros projektas yra atsakymas į šį klausimą. Jame naujausių tyrimų idėjos pritaikomos įmonių poreikiams: vertinimui pagal atidėtus duomenis, audito sekoms, sąnaudų riboms ir aiškiam perdavimui žmogui peržiūrėti prieš ką nors išleidžiant į gamybinę aplinką.
Sistemą išbandėme atlikdami tris ilgalaikes užduotis, sukurtas pagal realius klientų projektus. „Signal Engine“ stebi tiesioginį įrašų apie DI rinką srautą platformoje X ir rengia struktūrizuotas, patikimais šaltiniais pagrįstas tendencijų ataskaitas. Agentinė multimodalinė paieška analizuoja mišrias teksto ir vaizdų užklausas, kad pateiktų aktualiausius dokumentų puslapius. Gilusis tyrimas koordinuoja kelis agentus, kad šie ieškotų internete, kryžmiškai tikrintų šaltinius ir rengtų išsamias tyrimų ataskaitas.
„Signal Engine“: atidėto testo sudėtinis įvertis pakilo nuo 0,456 iki 0,841, t. y. santykinai 84 %. Naudojant tą patį biudžetą, CORAL ir „karpathy/autoresearch“ rezultatai nesiekė 0,50.
Agentinė multimodalinė paieška: atidėto testo NDCG@10 pakilo nuo 0,705 iki 0,744, o vieno vertinimo faktinis laikas sutrumpėjo nuo 869 iki 54 sek. Taigi pasiektas didesnis tikslumas ir 16 kartų spartesnis vykdymas.
Gilusis tyrimas: 10 kontrolinių klausimų ataskaitų kokybės sudėtinis įvertis pakilo nuo 0,449 iki 0,802, o bazinių metodų rezultatas siekė apie 0,52. Šiai užduočiai nebuvo atidėtos duomenų dalies, todėl šį rezultatą laikome galiojančiu tik imties viduje.
Paieškos efektyvumas: taikant prognozuojamą hipotezių perrikiavimą, „Signal Engine“ per 3, o ne 20 iteracijų pasiekė 91 % geriausio kontrolinio proceso įverčio, naudodama tą patį vertinimo biudžetą.
Dauguma autonominių tyrimų sistemų optimizuojamos ir vertinamos pagal tą patį duomenų rinkinį, todėl neįmanoma nustatyti, ar rezultatą galima apibendrinti. „Signal Engine“ ir agentinei multimodalinei paieškai taikome griežtą skaidymą: mokymo rinkinį, pagal kurį galima vertinti variantus, kūrimo rinkinį pagrįstumo patikroms ir atidėtą testo rinkinį, kurio optimizavimo modulis niekada nemato. Kiekvienas pateikiamas rezultatas gautas vertinant vieną konkrečią kodo versiją pagal visas duomenų dalis, todėl niekada nejungiame geriausio vieno varianto mokymo įverčio su geriausiu kito varianto testo įverčiu.
Per kiekvieną etapą infrastruktūra sugeneruoja struktūrizuotų hipotezių, kaip keisti kodą, rinkinį. Kiekvienoje hipotezėje įvardijamas keistinas mechanizmas, ankstesnė versija, kuria remiamasi, ir šalinamas trikties pobūdis. Prieš skiriant išteklių brangiems vertinimams, rinkinys išfiltruojamas reitingavimo etape. Atrinktos hipotezės perduodamos lygiagrečiai dirbantiems agentams. Jie naudojasi bendra žinių baze, tačiau kodą redaguoja visiškai izoliuotose darbo erdvėse, todėl kiekvienas variantas vertinamas sąžiningai ir nepriklausomai. Etapo pabaigoje vykdyklė išrenka vieną laimėtoją – daugiausia taškų surinkusį variantą, kuris taip pat sėkmingai įveikė visas matomų duomenų dalių patikras. Šis laimėtojas tampa pagrindu kitam etapui. Po kiekvieno bandymo į tik papildomą įrodymų saugyklą įrašomas nekintamas rinkinys: kodo pataisa, kiekvienos duomenų dalies įverčiai, įvykių žurnalas ir keturios trumpos LLM parengtos analizės apie vykdymo eigą, klaidas, sąnaudas bei įžvalgas. Kito etapo siūlymo modulis perskaito šią istoriją, todėl infrastruktūra kaupia įgytas žinias, užuot vėl kartojusi tuos pačius neperspektyvius bandymus.
Trys apsaugos priemonės užtikrina saugų ciklo vykdymą. Aprėpties taisyklės riboja, kuriuos failus variantas gali keisti, o visus aprėpties neatitinkančius pakeitimus atšaukia. Žetonų ir vykdymo laiko biudžetai sustabdo procesą sąnaudoms pasiekus ribą, o lygiagretumo apribojimai neleidžia infrastruktūrai viršyti modelio ir GPU užklausų dažnio ribų. Be to, pati infrastruktūra nieko neišleidžia į gamybinę aplinką. Ji pateikia reitinguotą ir išsamiai dokumentuotą variantą, o inžinierius peržiūri skirtumus ir nusprendžia, ar diegti jį gamybinėje aplinkoje.
Vietiniame technologijų rinkinyje kiekvieną aprašyto ciklo etapą palaiko penki inžineriniai elementai.
Darbo erdvių izoliavimas. Kiekvienam variantui skiriamas atskiras „git worktree“. Atšakos naudojasi bendra objektų duomenų baze, bet niekada – viena kitos failais. Todėl variantus galima vykdyti lygiagrečiai beveik nedidinant disko sąnaudų ir labai lengva palyginti jų skirtumus su dabartine geriausia versija.
Vykdymo smėlio dėžė. Konfigūracija leidžia rinktis vieną iš dviejų režimų: savąjį poprocesį sparčioms iteracijoms arba visiškai izoliuotą vykdymo aplinką. Tekstynai prijungiami tik skaitymo režimu, o kiekvieno bandymo laikinasis katalogas po vertinimo pašalinamas. Todėl bandymas negali pakeisti duomenų rinkinio ar perduoti būsenos kitam bandymui.
Aprėpties taisyklės. Eksperimento konfigūracijoje nurodytas leidžiamų kelių sąrašas. Prieš vertinant bandymą visi už šio sąrašo ribų atlikti pakeitimai atšaukiami, o bandymas pažymimas. Taip užtikrinama, kad peržiūrėtojui rodomi skirtumai neperžengtų nustatytos aprėpties.
Biudžeto apribojimų taikymas. Taikomi trys lygiai: kiekvieno bandymo žetonų ir vykdymo laiko ribos, bendra vieno proceso riba bei lygiagretumo apribojimas. Kartu jie užtikrina prognozuojamas sąnaudas ir neleidžia infrastruktūrai viršyti modelio bei techninės infrastruktūros užklausų dažnio ribų.
Įrodymų saugykla. Tik papildomas JSONL failas su kodo pataisa, kiekvienos duomenų dalies įverčiais, įvykių žurnalu ir keturiomis LLM parengtomis analizėmis. Po kiekvieno bandymo iš naujo sugeneruojami materializuoti rodiniai (rezultatų lentelė, geriausia versija ir trikčių indeksas), todėl tolesni etapai gali remtis ankstesne istorija, o kiekvieną procesą galima atkurti tiksliai iki paskutinio baito.
Nė vienas iš šių elementų nėra pasirenkamas. Infrastruktūros paskirtis – proceso pabaigoje pateikti peržiūrėtojui tai, ką jis iš tiesų gali patvirtinti: laimėjusį variantą, aprėptimi apribotus skirtumus, išsamų visų bandymų įrašą ir žinomas sąnaudas. Pašalinus bet kurį iš šių penkių elementų, viena iš garantijų išnyksta.
Visuose trijuose eksperimentuose taikoma ta pati hipotezių strategija. Per kiekvieną iteraciją siūlymo modulis sugeneruoja daugiau hipotezių, nei leidžia įvykdyti biudžetas: M = 8 variantai, kai vykdymo biudžetas K = 4. Tada atskiras LLM reitingavimo modulis per vieną trisdešimties sekundžių iškvietimą surikiuoja visus 8 variantus, matydamas visą kontekstą: dabartinį geriausią įvertį ir silpnąsias jo sritis, naujausių bandymų trikčių analizes ir visus 8 pasiūlymus greta. 4 geriausi variantai perduodami vykdymo moduliui; kiekvienam jų skiriama 15–30 minučių. Kiti 4 atmetami dar nepatyrus jokių sąnaudų.
Pagrindiniai modeliai visą laiką liko nepakitę – infrastruktūra redagavo tik juos supantį kodą. „Signal Engine“ ir gilusis tyrimas buvo vykdomi naudojant gpt-5.5. Agentinė multimodalinė paieška buvo vykdoma naudojant atvirų svorių Qwen3.6-35B-A3B, vietoje teikiamą per vLLM ir susietą su vaizdų paieškos modeliu ColQwen3-4B. Šis derinys pasirinktas dėl prognozuojamų vietinio diegimo sąnaudų.
Toliau pateiktoje diagramoje parodyta, kaip keitėsi trijų pagrindinių užduočių įverčiai. „Pradinis variantas“ – žmogaus inžinieriaus parašytas pradinis kodas. „Meta-Harness“ – geriausia „Meta-Harness“ rasta versija. Visų trijų užduočių našumas pagal atidėto testo rinkinį pagerėjo.
„Signal Engine“ vertino LLM teisėjas pagal aktualumą, faktinį tikslumą, detalumą ir toną, naudodamas 150 mokymo bei 150 atidėto testo įrašų platformoje X. Per visą procesą geriausios versijos mokymo sudėtinis įvertis pakilo nuo 0,431 iki 0,756, o atidėto testo įvertis – nuo 0,456 iki 0,841. Rezultatai pagerėjo pakeitus ne vien užklausas, bet ir pačią infrastruktūrą: laimėjusiose iteracijose išmokta filtruoti socialinių tinklų triukšmą, pridėti kryžminio faktų tikrinimo veiksmai ir pareikalauta kiekvieną rezultatą pagrįsti aiškiais įrodymais. Toliau pateiktoje schemoje parodytas iteracijų procesas.
Bandymų istorija rodo, kaip šie pagerėjimai kaupėsi. Ankstyvas struktūrinis pakeitimas pakėlė geriausią einamąjį įvertį iki 0,625, detalesnis įrodymų tvarkymas – iki 0,679, o patobulintas įžvalgų ir vertinimo kriterijų ciklas – iki 0,819. Maždaug pusės visų variantų rezultatai buvo prastesni arba bandymai visiškai nepavyko, tačiau tai neužteršė rezultatų lentelės: kiekviena atšaka buvo vykdoma izoliuotai, pralaimėjusių variantų skirtumai pašalinti, o triktys įrašytos į įžvalgų saugyklą, kad kitas siūlymo modulis nekartotų to paties neperspektyvaus bandymo.
Svarbiausia, kad per visą procesą atidėto testo kreivė kilo kartu su mokymo kreive. Tai leidžia manyti, kad infrastruktūra gerino darbo eigą, o ne įsiminė mokymo tekstyną. Atidėto testo įverčiai buvo šiek tiek aukštesni už mokymo įverčius. Tai laikome įprastu imties triukšmu tarp dviejų mažų, nepersidengiančių duomenų dalių.
Agentinė multimodalinė paieška matuojama pagal NDCG@10 viešojo „ViDoRe V3 Computer Science“ rinkinio dalyje, suskirstytoje į 20 mokymo, 10 kūrimo ir 20 atidėto testo užklausų. Infrastruktūra padidino atidėto testo NDCG@10 nuo 0,705 iki 0,744 ir kartu sutrumpino bendrą faktinį vertinimo laiką nuo 869 iki 54 sekundžių.
Gilusis tyrimas vertinamas pagal LLM teisėjo nustatomą turinio ir šaltinių kokybės sudėtinį įvertį, remiantis „DeepResearch-Eval“ metodika ir naudojant 10 kontrolinių klausimų. Patobulintas kodas padidino vidurkį nuo 0,449 iki 0,802. Laimėjusius pakeitimus buvo lengva pastebėti skirtumų rodinyje: tai pradinis planavimo etapas, kuriame metodai palyginami prieš siunčiant tyrimų agentus, ir galutinės peržiūros etapas, skirtas sritims, kuriose ataskaitų rezultatai anksčiau būdavo prasti. Kadangi šis rinkinys mažas ir jį vertinti brangu, jo neskaidėme, todėl rezultatą laikome galiojančiu tik imties viduje.
Visus tris metodus palyginome taikydami tą patį biudžetą: tuos pačius duomenų rinkinius ir pagrindinius modelius, tą pačią iteracijų ribą bei tiek pat bendrų variantų vertinimų. „Signal Engine“ užduotyje „Meta-Harness“ atidėto testo įvertis pasiekė 0,841, o abiejų bazinių metodų rezultatai nesiekė 0,50. Agentinės multimodalinės paieškos užduotyje mūsų komanda pasiekė aukščiausią atidėto testo NDCG@10 (0,744, palyginti su 0,700 CORAL ir 0,738 „karpathy“) ir oficialų vertinimą atliko 12–14 kartų greičiau: per 54 sek., palyginti su 786 ir 650 sek. Giliojo tyrimo užduotyje mūsų komanda pasiekė 0,802, o abiejų bazinių metodų rezultatai liko ties maždaug 0,52. Visiems rezultatams taikoma viena išlyga: CORAL ir „karpathy/autoresearch“ atkūrėme pagal paskelbtus jų aprašus, todėl dalį skirtumo galėjo lemti ne vien metodai, bet ir įgyvendinimo ypatumai.
Šį atotrūkį paaiškina keturi projektavimo sprendimai. Pirma, prieš redaguodama kodą mūsų komanda parengia struktūrizuotą projekto specifikaciją, todėl daugiau dėmesio skiria struktūriniams pakeitimams, pavyzdžiui, naujiems procesų etapams, o ne užklausų koregavimui. Antra, ji vienu metu vykdo atšakas, paremtas bendru geriausiu variantu, todėl patobulinimai kaupiami greičiau nei naudojant nepriklausomus CORAL agentus ar griežtai nuoseklų „karpathy“ ciklą. Trečia, po kiekvieno bandymo lieka struktūrizuoti artefaktai – įverčiai, įvykių žurnalai ir keturios LLM parengtos analizės, kurias perskaito kitas siūlymo modulis, o baziniuose metoduose saugomi tik paprasti bandymų žurnalai. Ketvirta, po sąstingio prisitaikantis valdiklis nukreipia siūlymo modulį į paiešką, o po sėkmės – į tobulinimą. Be to, taikomas prognozuojamas hipotezių perrikiavimas, kad silpnos idėjos būtų atmestos dar prieš joms eikvojant biudžetą.
Atidėto testo kreivės rodo apibendrinimą toje pačioje srityje, o ne perkėlimą tarp sričių: nereikėtų tikėtis, kad DI rinkos signalams išgauti pritaikyta darbo eiga be pakartotinio infrastruktūros vykdymo taip pat gerai veiks su teisiniais ar biomedicininiais tekstais. Infrastruktūra optimizuoja tik pagal vertintojo apibrėžtą tikslą, todėl bus tiksliai persimokyta ir pagal triukšmingą mokymo rinkinį ar netinkamai sukalibruotą teisėją. Prieš rimtą procesą rekomenduojame turėti bent 20 kruopščiai atrinktų mokymo elementų ir atskirą kūrimo duomenų dalį. Didžiausias praktinis apribojimas – sąnaudos. Per kiekvieną vertinimą visas procesas iš naujo vykdomas su visomis duomenų dalimis; vien pasirinktas paieškos variantas sunaudojo apie 2,2 mln. įvesties žetonų, o rimtas optimizavimas naudojant gpt-5.5 klasės modelį vienai užduočiai kainuoja nuo kelių šimtų iki kiek daugiau nei tūkstančio JAV dolerių. Galiausiai šie skaičiai gauti iš pavienių procesų, o ne pakartotinių bandymų, todėl jais dalijamės inžineriniame tinklaraščio įraše, o ne oficialiame tyrime.
„Meta-Harness“ rodo, kad autonominį kodo tobulinimą galima paversti pakankamai metodišku, kad jis tiktų įmonėms. Tam reikia struktūrinių hipotezių, prognozuojamo pirminio filtravimo, izoliuoto vertinimo, testavimo pagal atidėtus duomenis, kai tik jie tai leidžia, ir išsamios kiekvieno priimto pakeitimo audito sekos. Kartu šie elementai suteikia inžinierių komandai prognozuojamą kelią nuo veikiančio pradinio proceso iki išmatuojamai geresnio, o veiklos vadovui – paprastą modelį: autonominės paieškos naudą griežtoje, į biudžetą atsižvelgiančioje sistemoje, kurioje prieš ką nors išleidžiant į gamybinę aplinką dalyvauja žmogus.