Vai al contenuto
AI.info

The Pulse

I ricercatori di Google introducono vincoli all’auto-miglioramento degli agenti

Uno studio pubblicato il 21 settembre da ricercatori affiliati a Google Cloud AI Research descrive un metodo per limitare il modo in cui gli agenti di IA modificano le proprie istruzioni operative e il modo in cui vengono selezionate tali m

I ricercatori di Google introducono vincoli all’auto-miglioramento degli agenti

AI.info Team · Scritto con l’IA ·

Gli agenti il cui harness può evolvere possono ottenere punteggi migliori nei benchmark, ma apprendere modifiche che non funzionano al di fuori dei compiti usati per metterli a punto. Uno studio pubblicato il 21 settembre da ricercatori affiliati a Google Cloud AI Research propone una contromisura: vincolare il modo in cui gli agenti modificano le proprie istruzioni operative e il modo in cui tali modifiche vengono ammesse nel sistema.

Il metodo, chiamato Regularized Recursive Self-Improvement of Agent Harnesses (RRSI), interviene sull’«harness» che circonda un modello linguistico i cui parametri restano invariati: prompt, flusso di controllo, strumenti, memoria e gestione del contesto. Gli autori lo testano su compiti di programmazione, attività in ambienti di lavoro svolte da agenti e progettazione ingegneristica, riportando miglioramenti nei benchmark tenuti da parte. Gli esperimenti mostrano anche la tensione alla base del lavoro: un’evoluzione senza vincoli può ottenere punteggi più alti sul proprio insieme di riferimento, ma trasferire i risultati in modo meno affidabile.

RRSI limita le modifiche possibili a ogni ciclo

Invece di consentire al processo di ricerca di accumulare molte modifiche in ogni aggiornamento proposto, RRSI restringe gradualmente il numero di modifiche che un candidato può includere. Tiene traccia delle modifiche provate, del problema che ciascuna intendeva risolvere e della sua eventuale utilità. Quando i progressi si arrestano, il sistema può indirizzare le proposte verso componenti non ancora esplorati.

Una seconda serie di controlli determina quali candidati vengono mantenuti. Un valutatore individua logiche specifiche dei benchmark, come modifiche che incorporano nomi dei compiti o risposte. Una soglia minima di prestazioni corretta per la variabilità mira a evitare che una valutazione fortunata diventi una modifica permanente; i controlli sui costi limitano i token aggiuntivi usati nell’inferenza e una regola di potatura rimuove i componenti che cessano di essere utili.

«Su otto benchmark che comprendono compiti di programmazione, attività in ambienti di lavoro svolte da agenti e progettazione ingegneristica, RRSI guadagna fino a 14,1 punti sull’insieme usato per l’evoluzione e fino a 4,7 punti sui cinque benchmark fuori distribuzione, producendo al contempo un harness che usa il 30% di token della policy in meno rispetto all’evoluzione senza regolarizzazione.»

Scrivono Peng Xia e i coautori dello studio.

Il miglioramento maggiore dipende dal modello e dal test

Il risultato di 14,1 punti proviene da un esperimento di programmazione con Gemini 3.5 Flash come policy i cui parametri restano invariati: il punteggio su Terminal-Bench 2.1 è salito da 64,6 a 78,7. Sull’insieme SWE-bench Verified non visto durante l’evoluzione, lo stesso harness ha guadagnato 2,2 punti, passando da 76,8 a 79,0. In un esperimento separato con Claude Opus 4.8, il punteggio su Terminal-Bench è salito di 6 punti, mentre quello su SWE-bench Verified è migliorato di 1,8.

Per i principali risultati trasversali ai diversi ambiti dello studio, i ricercatori hanno usato Claude Opus 4.8 come policy i cui parametri restano invariati. Il sistema in evoluzione ha migliorato i punteggi su tutti gli insiemi tenuti da parte che sono stati testati: JobBench è salito di 4,7 punti, GDPval di 3,5, APEX-Agents di 3,7, i compiti di Harvey LAB tenuti da parte di 2,3, SWE-bench Verified di 1,8 e Frontier-Eng di 4,3 punti medaglia. I compiti comprendono incarichi lavorativi, correzioni software e progetti ingegneristici; secondo gli autori, i benchmark ingegneristici usano simulatori o banchi di prova deterministici, anziché valutatori basati su modelli.

Punteggi più alti nell’addestramento non hanno comportato miglioramenti più ampi

Il confronto più chiaro viene dall’esperimento di ablazione sulle attività in ambienti di lavoro svolte da agenti. RRSI ha ottenuto 90,5 sull’insieme di Harvey LAB usato per l’evoluzione e una media di 43,6 su JobBench, GDPval e APEX-Agents. L’evoluzione senza regolarizzazione ha ottenuto un punteggio più alto su Harvey LAB, pari a 92,8, ma la sua media fuori distribuzione è stata di 40,3, vicina al 39,7 dell’harness non modificato dall’evoluzione.

Il confronto dei costi rende il risultato meno lineare. Nello stesso esperimento, RRSI ha usato 2,42 milioni di token della policy per prova, contro i 3,80 milioni dell’evoluzione senza regolarizzazione. L’harness non modificato dall’evoluzione, però, ne ha usati 1,56 milioni. I controlli di RRSI hanno ridotto il costo dell’evoluzione, ma non hanno reso il sistema risultante meno costoso rispetto a lasciare invariato l’harness.

Lo studio si ferma all’harness

RRSI modifica le istruzioni, gli strumenti e gli altri elementi di supporto che circondano un modello, non i suoi pesi. Gli autori affermano che il loro studio non stabilisce come funzionerebbe il metodo se l’evoluzione aggiornasse anche quei pesi. Inoltre, per l’evoluzione si basano su un insieme finito di compiti e su impostazioni di regolarizzazione che possono influire sui risultati: la qualità del feedback e l’ampiezza del budget di ricerca restano quindi fattori limitanti.

I ricercatori hanno pubblicato l’implementazione nel repository Google Research RRSI con licenza Apache 2.0. Il repository precisa che il progetto non è un prodotto Google supportato ufficialmente.

Fonti

Esplora

Altri articoli