Gli attuali sistemi di miglioramento autonomo hanno ottenuto risultati notevoli nelle attività di programmazione, ma non è ancora chiaro se possano migliorare workflow IA complessi e di lunga durata, simili alle implementazioni aziendali reali.
La nostra ricerca su Meta-Harness applica l’auto-miglioramento autonomo ai workflow di recupero agentico, deep research e intelligence dei segnali, integrando requisiti aziendali come valutazioni su dati riservati, verificabilità, controlli del budget e approvazione umana.
Nei tre carichi di lavoro rappresentativi, Meta-Harness ha migliorato notevolmente le prestazioni, con un aumento dell’84% nei test su dati riservati per Signal Engine e una maggiore precisione con un’esecuzione 16 volte più veloce per Agentic Multimodal Retrieval.
A differenza della maggior parte degli approcci precedenti, ove possibile Meta-Harness misura il successo su set di dati riservati, per verificare se i miglioramenti si generalizzano oltre i dati usati durante l’ottimizzazione.
Questi risultati indicano che il miglioramento autonomo dei workflow può andare oltre i benchmark di programmazione e raggiungere i sistemi IA aziendali reali, offrendo un percorso concreto verso applicazioni IA in continuo miglioramento.
I recenti lavori sulla ricerca autonoma nell’IA, tra cui l’articolo su Meta-Harness, il framework CORAL e karpathy/autoresearch, hanno dimostrato che gli agenti di programmazione possono migliorare iterativamente una soluzione sulla base di una metrica di valutazione. Resta da capire se questi metodi siano applicabili ai workflow IA di lunga durata, come il recupero multimodale agentico, in cui un agente deve cercare iterativamente in corpora di settore multimodali per rispondere a una domanda, oppure a pipeline complesse di elaborazione dei dati che richiedono numerosi passaggi dipendenti, chiamate a strumenti e decisioni sulla gestione delle eccezioni. La questione più profonda è se i miglioramenti reggano su dati che l’ottimizzatore non vede mai.
La nostra attività di ricerca e sviluppo su Meta-Harness risponde a questa domanda. Riprende le idee della ricerca recente e le adatta alle esigenze aziendali: valutazioni su dati riservati, tracciabilità delle verifiche, tetti di spesa e un chiaro passaggio a un revisore umano prima di qualsiasi distribuzione.
L’abbiamo testata su tre attività di lunga durata basate su lavori reali per i clienti. Signal Engine monitora un flusso in tempo reale di post su X relativi al mercato dell’IA e produce report strutturati sulle tendenze, corredati di fonti attendibili. Agentic Multimodal Retrieval ragiona su query miste di testo e immagini per restituire le pagine più pertinenti dei documenti. Deep research coordina più agenti per cercare sul web, verificare le fonti e redigere report di ricerca approfonditi.
Signal Engine: punteggio composito nel test riservato da 0,456 a 0,841, con un aumento relativo dell’84%. CORAL e karpathy/autoresearch sono rimasti sotto 0,50 con lo stesso budget.
Agentic Multimodal Retrieval: NDCG@10 sul set riservato da 0,705 a 0,744, con un calo del tempo effettivo per valutazione da 869 a 54 secondi. Un aumento di velocità di 16 volte, con maggiore precisione.
Deep research: punteggio composito della qualità dei report da 0,449 a 0,802 su 10 domande di riferimento, contro circa 0,52 per le baseline. Questa attività non prevedeva una partizione riservata, quindi consideriamo il dato valido solo all’interno del campione.
Efficienza della ricerca: con il riclassificatore predittivo delle ipotesi, Signal Engine ha raggiunto il 91% del miglior punteggio dell’esecuzione di riferimento in 3 iterazioni anziché 20, a parità di budget di valutazione.
La maggior parte dei sistemi di ricerca autonoma ottimizza e valuta sullo stesso set di dati, rendendo impossibile stabilire se il risultato si generalizzi. Per Signal Engine e Agentic Multimodal Retrieval imponiamo una separazione rigorosa: un set di addestramento su cui valutare i candidati, un set di sviluppo per i controlli di coerenza e un set di test riservato che l’ottimizzatore non vede mai. Ogni risultato riportato deriva da una specifica versione del codice valutata su tutte le partizioni: non combiniamo mai il miglior punteggio di addestramento di un candidato con il miglior punteggio di test di un altro.
A ogni ciclo, l’infrastruttura genera un gruppo di ipotesi strutturate per modificare il codice. Ogni ipotesi indica il meccanismo da modificare, la versione precedente su cui si basa e la modalità di errore a cui mira. Una fase di classificazione filtra il gruppo prima di sostenere il costo delle valutazioni più onerose. Le ipotesi selezionate passano ad agenti esecutori paralleli che condividono una base di conoscenze comune, ma modificano il codice in aree di lavoro completamente isolate. Ogni candidato viene così valutato in modo equo e indipendente. Al termine del ciclo, il sistema promuove un vincitore: il candidato con il punteggio più alto che ha anche superato tutti i controlli sulle partizioni visibili. Il vincitore diventa la base di frontiera per il ciclo successivo. Ogni prova scrive un pacchetto fisso in un archivio delle evidenze in sola aggiunta: patch del codice, punteggi per partizione, registro degli eventi e quattro brevi analisi scritte da un LLM su traccia, errori, costi e riflessioni. Il proponente del ciclo successivo rilegge questa cronologia: è così che l’infrastruttura consolida quanto appreso, invece di ripercorrere gli stessi vicoli ciechi.
Tre misure di protezione consentono di eseguire il ciclo in sicurezza. Una policy di ambito limita i file che un candidato può modificare e annulla qualsiasi modifica esterna. I budget di token e tempo effettivo interrompono l’esecuzione quando la spesa supera il limite, mentre i vincoli di concorrenza mantengono l’infrastruttura entro i limiti di utilizzo di modello e GPU. Inoltre, l’infrastruttura non distribuisce mai nulla autonomamente. Produce un candidato classificato e documentato integralmente; un tecnico esamina il diff e decide se portarlo in produzione.
In uno stack locale, cinque elementi tecnici fondamentali sostengono ogni ciclo descritto sopra.
Isolamento dell’area di lavoro. Una worktree Git per ogni candidato. I fork condividono un database di oggetti, ma mai i rispettivi file. I candidati possono quindi essere eseguiti in parallelo con un costo su disco quasi costante, mentre il confronto con l’attuale versione di frontiera diventa immediato.
Sandbox di esecuzione. Due modalità configurabili: sottoprocesso nativo per iterazioni rapide oppure ambiente di esecuzione completamente isolato. I corpora vengono montati in sola lettura e la directory temporanea di ogni prova viene eliminata dopo la valutazione. Di conseguenza, una prova non può modificare il set di dati né trasferire il proprio stato alla successiva.
Policy di ambito. Un elenco di percorsi consentiti dichiarato nella configurazione dell’esperimento. Prima della valutazione vengono annullate tutte le modifiche esterne all’elenco e la prova viene contrassegnata. Il diff presentato al revisore resta quindi sempre entro l’ambito dichiarato.
Applicazione dei limiti di budget. Tre livelli: limiti di token e tempo effettivo per prova, un tetto complessivo per esecuzione e un limite di concorrenza. Insieme rendono prevedibile la spesa e mantengono l’infrastruttura entro i limiti di utilizzo del modello e dell’infrastruttura tecnica.
Archivio delle evidenze. Un file JSONL in sola aggiunta contenente patch del codice, punteggi per partizione, registro degli eventi e quattro analisi scritte da un LLM. Le viste materializzate (classifica, frontiera e indice degli errori) vengono rigenerate dopo ogni prova. I cicli successivi possono così sfruttare la cronologia precedente, mantenendo ogni esecuzione riproducibile byte per byte.
Nessuno di questi elementi è facoltativo. Lo scopo dell’infrastruttura è offrire al revisore, al termine dell’esecuzione, qualcosa che possa davvero approvare: un candidato vincente, un diff circoscritto, un registro completo dei tentativi e un costo noto. Eliminando uno dei cinque elementi, viene meno una di queste garanzie.
Tutti e tre gli esperimenti adottano la stessa strategia per le ipotesi. A ogni iterazione, il proponente genera più ipotesi di quante il budget consenta di eseguire: M = 8 candidati per un budget di invio K = 4. Un classificatore LLM separato ordina quindi tutti e 8 con un’unica chiamata di trenta secondi, avendo a disposizione il quadro completo: il miglior punteggio corrente e i suoi aspetti più deboli, le analisi degli errori delle prove recenti e tutte le 8 proposte affiancate. I primi 4 passano all’esecutore, con un costo di 15-30 minuti ciascuno. Gli altri 4 vengono scartati prima di consumare risorse.
I modelli sottostanti sono rimasti invariati per l’intera durata; l’infrastruttura ha modificato solo il codice circostante. Signal Engine e deep research sono stati eseguiti su gpt-5.5. Agentic Multimodal Retrieval è stato eseguito sul modello open-weight Qwen3.6-35B-A3B, distribuito localmente tramite vLLM e abbinato al sistema di recupero di immagini ColQwen3-4B: una combinazione scelta per la prevedibilità dei costi on-premise.
Il grafico seguente mostra l’andamento dei punteggi per le nostre tre attività principali. “Seed” indica il codice iniziale scritto da un tecnico. “Meta-Harness” indica la migliore versione individuata da Meta-Harness. Nel set di test riservato osserviamo un miglioramento delle prestazioni in tutte e tre le attività.
Signal Engine è stato valutato da un LLM in termini di attualità, accuratezza fattuale, granularità e tono, usando 150 tweet di addestramento e 150 tweet di test riservati. Nel corso dell’esecuzione, la versione migliore ha portato il punteggio composito di addestramento da 0,431 a 0,756 e quello sul set riservato da 0,456 a 0,841. I miglioramenti sono derivati da modifiche all’infrastruttura stessa, non solo da ritocchi ai prompt: le iterazioni vincenti hanno imparato a filtrare il rumore dei social media, aggiunto passaggi di verifica incrociata dei fatti e imposto a ogni output di basarsi su evidenze esplicite. Il diagramma seguente illustra il processo di iterazione.
La cronologia delle prove mostra come si sono accumulati questi miglioramenti. Una prima modifica strutturale ha portato il miglior risultato progressivo a 0,625; una gestione più granulare delle evidenze lo ha innalzato a 0,679; infine, un ciclo perfezionato di riflessione e criteri di valutazione lo ha portato a 0,819. Circa metà delle esecuzioni candidate ha ottenuto risultati inferiori o è fallita del tutto, senza però compromettere la classifica: ogni fork è stato eseguito in isolamento, i diff perdenti sono stati scartati e gli errori registrati nell’archivio delle riflessioni, affinché il proponente successivo non ripetesse lo stesso vicolo cieco.
Soprattutto, durante l’intera esecuzione la curva del set riservato è cresciuta insieme a quella di addestramento. Ciò indica che l’infrastruttura stava migliorando il workflow, anziché memorizzare il corpus di addestramento. I punteggi sul set riservato erano leggermente superiori a quelli di addestramento, un risultato che interpretiamo come normale rumore di campionamento tra due partizioni piccole e distinte.
Agentic Multimodal Retrieval viene misurato con NDCG@10 sulla partizione pubblica Computer Science di ViDoRe V3, organizzata in 20 query di addestramento, 10 di sviluppo e 20 di test riservate. L’infrastruttura ha portato l’NDCG@10 sul set riservato da 0,705 a 0,744, riducendo al contempo il tempo effettivo totale della valutazione da 869 a 54 secondi.
Deep research viene valutato, su 10 domande di riferimento, tramite un punteggio composito assegnato da un LLM alla qualità dei contenuti e dei riferimenti, secondo DeepResearch-Eval. Il codice migliorato ha innalzato la media da 0,449 a 0,802. Le modifiche vincenti erano immediatamente riconoscibili nel diff: una fase iniziale di pianificazione per confrontare gli approcci prima di attivare gli agenti di ricerca e una fase finale di revisione mirata agli aspetti in cui i report avevano storicamente ottenuto punteggi bassi. Poiché questo set è piccolo e costoso da valutare, non lo abbiamo suddiviso e consideriamo il risultato valido all’interno del campione.
Abbiamo confrontato i tre metodi con lo stesso budget: stessi set di dati, stessi modelli sottostanti, stesso limite di iterazioni e stesso numero totale di valutazioni dei candidati. Su Signal Engine, Meta-Harness raggiunge 0,841 nel test riservato, mentre entrambe le baseline rimangono sotto 0,50. Su Agentic Multimodal Retrieval, il nostro team ottiene il miglior NDCG@10 sul set riservato (0,744, contro 0,700 di CORAL e 0,738 di karpathy) ed esegue la valutazione ufficiale da dodici a quattordici volte più velocemente: 54 secondi contro 786 e 650. Su deep research, il nostro team raggiunge 0,802, mentre entrambe le baseline rimangono intorno a 0,52. Va tenuta presente un’avvertenza: abbiamo reimplementato CORAL e karpathy/autoresearch in base alle descrizioni pubblicate, quindi parte del divario potrebbe dipendere da differenze di implementazione, non solo di metodo.
Il divario è riconducibile a quattro scelte progettuali. Primo: il nostro team genera una specifica progettuale strutturata prima di modificare il codice, privilegiando così cambiamenti strutturali, come nuove fasi della pipeline, anziché semplici ritocchi ai prompt. Secondo: esegue fork concorrenti ancorati a un candidato di frontiera condiviso, quindi i miglioramenti si accumulano più rapidamente rispetto agli agenti indipendenti di CORAL o al ciclo strettamente sequenziale di karpathy. Terzo: ogni prova produce elementi strutturati (punteggi, registri degli eventi e quattro analisi redatte da un LLM) che il proponente successivo rilegge, mentre le baseline conservano soltanto registri non strutturati dei tentativi. Quarto: un controller adattivo spinge il proponente verso l’esplorazione dopo una fase di stallo e verso il perfezionamento dopo un successo; un riclassificatore predittivo delle ipotesi elimina inoltre le idee deboli prima che consumino budget.
Le curve dei set riservati dimostrano la generalizzazione all’interno dello stesso dominio, non il trasferimento tra domini: non ci si può aspettare che un workflow ottimizzato per estrarre segnali dal mercato dell’IA funzioni altrettanto bene su testi giuridici o biomedici senza rieseguire l’infrastruttura. L’infrastruttura migliora inoltre solo rispetto all’obiettivo definito dal valutatore: un set di addestramento rumoroso o un giudice mal calibrato verrà quindi sovra-adattato fedelmente. Prima di un’esecuzione importante consigliamo almeno 20 elementi di addestramento ben selezionati e una partizione di sviluppo separata. Il costo è il principale vincolo pratico. Ogni valutazione riesegue l’intera pipeline su tutte le partizioni; il solo candidato di recupero selezionato ha consumato circa 2,2 milioni di token di input e un’ottimizzazione sostanziale su un modello di classe gpt-5.5 costa da qualche centinaio a poche migliaia di dollari per attività. Infine, questi dati derivano da singole esecuzioni e non da prove ripetute: per questo li condividiamo in un articolo tecnico del blog anziché in uno studio formale.
Meta-Harness dimostra che il miglioramento autonomo del codice può essere reso sufficientemente rigoroso per l’uso aziendale. Gli elementi essenziali sono ipotesi strutturali, prefiltraggio predittivo, valutazioni isolate, test su dati riservati ove possibile e una tracciabilità completa delle verifiche per ogni modifica promossa. Insieme, questi elementi offrono al team tecnico un percorso prevedibile da una pipeline iniziale funzionante a una versione sensibilmente migliore. Per i responsabili operativi, il modello è semplice: i vantaggi dell’esplorazione autonoma entro un quadro rigoroso e attento al budget, con una persona coinvolta prima di qualsiasi distribuzione.