Un gruppo di ricercatori della Stanford University ha sviluppato TRACE, un sistema di addestramento progettato per individuare le cause ricorrenti degli errori commessi dagli agenti AI e rafforzare soltanto le capacità che risultano insufficienti. Il metodo evita di sottoporre l’intero modello a un nuovo addestramento generico e costruisce invece ambienti sintetici dedicati ai singoli problemi rilevati durante l’esecuzione delle attività.
TRACE è l’acronimo di Turning Recurrent Agent Failures into Capability-Targeted Training Environments. Il sistema parte dall’idea che molti fallimenti degli agenti non siano eventi casuali e indipendenti, ma conseguenze ripetute di un numero relativamente limitato di capacità mancanti. Un agente può, per esempio, comprendere correttamente una richiesta e conoscere gli strumenti disponibili, ma non riuscire a verificare una condizione preliminare, interpretare una struttura dati o coordinare una sequenza di chiamate.
I normali metodi di fine-tuning tendono a utilizzare grandi raccolte di esempi generali oppure a sottoporre il modello a reinforcement learning direttamente nell’ambiente finale. In entrambi i casi, il sistema deve ricavare implicitamente quale capacità gli manca osservando numerosi successi e fallimenti. Questo procedimento può richiedere molti dati e può portare il modello a memorizzare schemi specifici dell’ambiente di addestramento senza acquisire una competenza sufficientemente generale.
TRACE introduce invece una fase diagnostica prima dell’addestramento. Il sistema confronta le traiettorie nelle quali l’agente ha completato correttamente un compito con quelle terminate in un fallimento. Per traiettoria si intende l’intera sequenza delle operazioni eseguite: ragionamento prodotto, strumenti richiamati, parametri utilizzati, risposte ricevute dall’ambiente e decisione finale.
Il confronto permette di individuare quali capacità compaiono con maggiore frequenza nei percorsi riusciti e risultano invece assenti nei percorsi falliti. Il metodo non considera quindi soltanto l’ultima risposta sbagliata, ma cerca la competenza operativa che avrebbe potuto impedire l’errore.
La pipeline comprende quattro fasi automatizzate. La prima è la selezione delle capacità mancanti. Un agente di programmazione basato su un modello linguistico analizza i risultati del benchmark e propone un insieme iniziale di competenze potenzialmente rilevanti. Altri sottoagenti esaminano poi separatamente ogni coppia composta da una traiettoria e da una capacità candidata.
Ogni caso viene classificato in tre categorie. L’etichetta PRESENT indica che la capacità è stata utilizzata correttamente, LACKING segnala che risulta insufficiente, mentre NA viene applicata quando quella competenza non è pertinente al compito esaminato. Il sistema calcola quindi quanto frequentemente ogni capacità sia richiesta e quale differenza presenti tra esecuzioni riuscite e fallite.
Per essere selezionata, una capacità deve comparire in una quota sufficiente dei casi e deve mostrare una relazione coerente con gli errori. Questa doppia condizione riduce il rischio di addestrare il modello su caratteristiche rare, descritte in modo troppo generico oppure individuate per coincidenza in un numero limitato di esempi.
Nella seconda fase, TRACE genera automaticamente un ambiente sintetico per ciascuna capacità selezionata. Ogni ambiente viene costruito affinché il completamento del compito dipenda soprattutto dalla competenza che deve essere rafforzata. Il modello non viene quindi addestrato su una replica completa del benchmark, ma su esercizi mirati che isolano il comportamento problematico.
Un ambiente dedicato alla verifica delle precondizioni può, per esempio, presentare attività nelle quali un’azione è valida soltanto dopo avere controllato lo stato di un ordine o l’identità del cliente. Un ambiente destinato alla lettura di dati strutturati può richiedere di recuperare informazioni distribuite tra campi differenti, mentre un esercizio sulla corretta invocazione degli strumenti può valutare la scelta della funzione e dei parametri appropriati.
I compiti vengono creati proceduralmente a partire da valori iniziali casuali. La validazione è affidata a regole e algoritmi deterministici, evitando la necessità di etichettare manualmente ogni risposta o di utilizzare un altro modello linguistico come giudice. Questo aspetto riduce i costi della generazione dei dati e rende più chiaro il criterio con cui viene assegnata la ricompensa.
TRACE verifica inoltre che l’ambiente non sia troppo semplice. Il sistema sottopone al modello di base una serie di esecuzioni e misura la percentuale di successo. Se il compito viene risolto con eccessiva facilità, l’ambiente può essere modificato introducendo variazioni superficiali, nomi differenti, elementi irrilevanti o punti di intervento ingannevoli. L’obiettivo è richiedere realmente la capacità scelta anziché consentire la soluzione attraverso una scorciatoia.
La terza fase riguarda l’addestramento. Per ogni capacità viene creato un adattatore LoRA separato. La Low-Rank Adaptation consente di modificare il comportamento del modello aggiungendo una quantità relativamente ridotta di parametri, mentre i pesi principali rimangono congelati.
Gli adattatori vengono addestrati attraverso GRPO, Group Relative Policy Optimization, un algoritmo di reinforcement learning che confronta più risposte generate per lo stesso compito e rafforza quelle che ottengono risultati migliori. La ricompensa proviene dall’ambiente sintetico e misura se l’agente ha applicato correttamente la capacità richiesta.
La separazione tra gli adattatori impedisce che l’addestramento di una competenza modifichi indiscriminatamente tutto il modello. Un adattatore può specializzarsi nella verifica delle precondizioni, un altro nell’interpretazione di dati strutturati e un terzo nella gestione di operazioni articolate su più passaggi.
L’ultima fase combina gli adattatori attraverso una struttura mixture-of-experts. Un sistema di instradamento stabilisce quale specialista utilizzare durante l’inferenza. Il modello può quindi attivare l’adattatore più adatto al problema corrente senza applicare simultaneamente tutte le modifiche.
Il router può operare a livello globale, scegliendo uno specialista per l’intera traiettoria, oppure a livello più granulare. Nell’implementazione descritta dai ricercatori, l’instradamento può avvenire durante i diversi livelli dell’elaborazione e consentire una combinazione ponderata degli adattatori. In questo modo l’agente può passare da una capacità all’altra mentre affronta fasi differenti dello stesso compito.
La struttura è diversa da un tradizionale mixture-of-experts addestrato fin dall’inizio. Gli esperti di TRACE non sono grandi porzioni indipendenti del modello, ma adattatori LoRA relativamente compatti, ciascuno collegato a una capacità individuata attraverso l’analisi degli errori.
I ricercatori hanno valutato il metodo su tre ambienti agentici e su modelli di dimensioni differenti. Uno dei principali test è stato τ²-Bench, un benchmark che simula attività di assistenza clienti nei settori del commercio e del trasporto aereo. L’agente deve dialogare con il cliente, consultare informazioni, applicare politiche e utilizzare strumenti esterni per modificare ordini, prenotazioni o dati.
L’analisi delle traiettorie di τ²-Bench ha mostrato che gran parte dei fallimenti poteva essere collegata a quattro capacità ricorrenti. La prima riguardava il ragionamento sui dati strutturati, necessario per interpretare correttamente informazioni recuperate tramite gli strumenti. La seconda consisteva nell’esecuzione di compiti articolati su più passaggi. L’agente poteva conoscere ogni singola operazione, ma perdere la sequenza corretta o interrompere il processo prima del completamento. La terza capacità era la verifica delle precondizioni. Nei servizi reali molte operazioni possono essere eseguite soltanto quando sono rispettate determinate regole. Un rimborso può richiedere che l’ordine abbia uno specifico stato, mentre una modifica può essere consentita soltanto entro una determinata scadenza. La quarta riguardava l’accuratezza delle chiamate agli strumenti. L’agente doveva scegliere la funzione corretta e compilare i parametri senza omissioni o incongruenze. Un singolo valore sbagliato poteva provocare il fallimento dell’intera attività anche quando la decisione generale risultava corretta.
Applicato a Qwen3-30B-A3B-Instruct, TRACE ha portato il risultato su τ²-Bench dal 32,9% al 48,3%, con un miglioramento di circa 15,4 punti percentuali nell’implementazione pubblicata. Il documento di ricerca riporta un incremento di 15,3 punti rispetto al modello di base, dovuto all’arrotondamento o alla configurazione considerata.
La sperimentazione ha riguardato anche SWE-Bench Verified, uno dei benchmark più utilizzati per valutare gli agenti di sviluppo software. Ogni attività parte da un problema reale prelevato da un progetto open source. Il modello deve analizzare il repository, individuare l’origine del difetto, modificare il codice e produrre una soluzione che superi i test automatici.
Nel lavoro principale, TRACE ha migliorato il risultato del modello di base di 15 punti percentuali Pass@1. La metrica Pass@1 indica la percentuale di problemi risolti correttamente utilizzando il primo tentativo prodotto dall’agente. Il sistema ha inoltre superato SWE-RL, un metodo specifico per l’addestramento su attività di ingegneria del software, di 8,4 punti percentuali. Un’ulteriore applicazione a Qwen3.6-27B ha raggiunto il 73,2% su SWE-Bench Verified, partendo da un valore di riferimento del 68%. In questa configurazione l’aumento è stato quindi di 5,2 punti percentuali. Il repository pubblico contiene gli script, gli ambienti sintetici e le indicazioni necessarie per riprodurre questa specifica esecuzione.
Il risultato del 73,2% colloca un modello open-weight da 27 miliardi di parametri nella stessa fascia di alcuni sistemi di programmazione proprietari di grandi dimensioni. Il confronto deve tuttavia essere interpretato con cautela. I punteggi pubblicati su SWE-Bench possono dipendere dall’infrastruttura agentica, dal limite di tentativi, dagli strumenti disponibili, dalla quantità di calcolo utilizzata e dalla versione esatta del benchmark.
Il risultato non dimostra quindi che Qwen3.6-27B sia complessivamente superiore ai modelli commerciali confrontati in ogni attività di programmazione. Mostra che, nella configurazione sottoposta al benchmark, l’addestramento mirato di TRACE ha consentito a un modello relativamente compatto di raggiungere una percentuale di risoluzione molto elevata.
Uno degli aspetti più rilevanti riguarda l’efficienza dei dati. TRACE ha ottenuto risultati superiori ai metodi GRPO e GEPA utilizzando meno di un quarto delle traiettorie di addestramento. Su τ²-Bench, il metodo ha superato la migliore accuratezza finale raggiunta da GRPO di 10,4 punti e quella di GEPA di 8,6 punti.
La riduzione dei rollout è importante perché la generazione di traiettorie agentiche è costosa. Ogni esecuzione può comprendere numerosi messaggi, chiamate agli strumenti, consultazioni di database e verifiche dell’ambiente. Nei compiti di programmazione può essere necessario caricare repository, eseguire test e avviare ambienti isolati.
Un approccio generico produce molti esempi che non affrontano direttamente il limite principale del modello. TRACE cerca invece di concentrare il calcolo sulle situazioni nelle quali la capacità mancante è indispensabile. L’efficienza deriva quindi non soltanto dall’utilizzo di LoRA, ma anche dalla selezione degli esercizi.
Il metodo può migliorare inoltre la generalizzazione. Se il modello viene addestrato direttamente su problemi simili a quelli del benchmark, può apprendere correlazioni superficiali, formati ricorrenti o procedure legate a un ambiente specifico. Un esercizio costruito per isolare una capacità dovrebbe invece insegnare un comportamento applicabile anche a situazioni differenti.
La distinzione non è assoluta. Gli ambienti sintetici vengono generati a partire dagli errori osservati nel benchmark e rimangono quindi collegati alle sue caratteristiche. Il vantaggio deve essere verificato ogni volta su compiti realmente diversi da quelli usati per la diagnosi e l’addestramento.
TRACE automatizza gran parte della pipeline attraverso agenti di programmazione come Claude Code o Codex. Gli agenti leggono i risultati, propongono le capacità, classificano le traiettorie, producono gli ambienti e ne controllano il funzionamento. Questa automazione rende il sistema adattabile a nuovi benchmark, ma introduce anche una dipendenza dalla qualità del modello utilizzato per costruire il processo di addestramento.
Una diagnosi errata può portare alla selezione di una capacità troppo vaga o non realmente collegata ai fallimenti. Un ambiente generato male può premiare una scorciatoia oppure valutare un comportamento diverso da quello desiderato. Per questa ragione la pipeline utilizza più agenti indipendenti, soglie statistiche, controlli automatici e ripetizioni su diverse esecuzioni.
L’utilizzo di verificatori algoritmici riduce anche il problema dei giudici basati su modelli linguistici. Quando un LLM valuta la risposta di un altro LLM, il risultato può essere influenzato da preferenze stilistiche, errori di interpretazione o somiglianze tra i due sistemi. Nei compiti costruiti da TRACE, la ricompensa può essere legata a condizioni osservabili, come la correttezza di una chiamata, il superamento di un test o il raggiungimento di uno stato preciso.
Il sistema non elimina comunque il costo computazionale dell’addestramento. Il repository raccomanda più GPU per eseguire GRPO su modelli da decine di miliardi di parametri e un’infrastruttura separata per generare i rollout attraverso vLLM. TRACE riduce il numero di esempi necessari, ma richiede l’analisi iniziale, la generazione degli ambienti, l’addestramento di più adattatori e la costruzione del router.
Anche l’aumento del numero di capacità può rendere più complessa la gestione del sistema. Ogni nuovo adattatore deve essere conservato, caricato e selezionato correttamente. Se due capacità sono molto simili o entrano in conflitto, il router potrebbe scegliere lo specialista sbagliato o combinarli in modo inefficace.
Un altro limite riguarda l’evoluzione dell’ambiente. Le cause degli errori possono cambiare dopo un aggiornamento del modello, degli strumenti o delle regole operative. Un adattatore addestrato su una versione precedente potrebbe non essere più utile oppure introdurre comportamenti indesiderati. La procedura di diagnosi dovrebbe quindi essere ripetuta periodicamente.
Questa caratteristica rende TRACE interessante come sistema di miglioramento continuo. Un agente distribuito in un ambiente aziendale può registrare le esecuzioni fallite, confrontarle con quelle riuscite e individuare nuovi gruppi di errori. Il sistema potrebbe quindi creare ambienti sintetici dedicati e produrre adattatori aggiuntivi senza riaddestrare l’intero modello.
In un’applicazione di assistenza clienti, per esempio, un aggiornamento delle politiche potrebbe generare una nuova categoria di errori nella verifica dei requisiti. In un agente software, l’introduzione di un nuovo framework potrebbe evidenziare difficoltà nella configurazione dei test. TRACE permetterebbe di intervenire su questi limiti specifici senza ricostruire l’intero dataset di addestramento.
La capacità di collegare una modifica del modello a una causa osservabile offre anche una maggiore possibilità di controllo. Un normale fine-tuning può migliorare il punteggio complessivo senza rendere chiaro quale comportamento sia cambiato. Con TRACE, ogni adattatore è associato a una capacità descritta, a un ambiente specifico e a un insieme di errori ricorrenti.
Questa tracciabilità può facilitare la valutazione prima della distribuzione. Gli sviluppatori possono misurare separatamente l’effetto di ogni adattatore, verificare se introduce regressioni e disattivarlo quando non è necessario.
Il progetto è stato pubblicato con licenza MIT e comprende il codice per l’analisi delle capacità, la generazione degli ambienti, l’addestramento GRPO e il routing tra gli adattatori. Sono inclusi prompt già configurati per τ²-Bench e SWE-Bench, oltre a modelli generali che possono essere adattati ad altri ambienti.