In un’azienda il bilancio lo prepara l’amministrazione, ma a certificarlo è un revisore esterno, di un’altra società. Non perché i contabili interni siano disonesti: perché chi ha costruito i numeri li rilegge con gli stessi occhi con cui li ha scritti, e gli errori che non ha visto la prima volta non li vede neanche la seconda. Il revisore, poi, non si fa raccontare il bilancio dal direttore amministrativo. Apre i registri e controlla le fatture.
È questa, trasferita agli agenti che fanno ricerca, l’idea di ARIS: Autonomous Research via Adversarial Multi-Agent Collaboration, un rapporto tecnico uscito su arXiv il 4 maggio 2026 (2605.03042). Lo firmano Ruofeng Yang, Yongcan Li e Shuai Li, della Shanghai Jiao Tong University e dello Shanghai Innovation Institute. Non è un modello nuovo ma un harness, cioè l’impalcatura attorno ai modelli: decide che cosa conservare, che cosa recuperare e che cosa mostrare al modello a ogni passo. Il codice è pubblico, in un repository dal nome che dice molto delle intenzioni: Auto-claude-code-research-in-sleep, la ricerca che va avanti mentre il ricercatore dorme.
Il problema non è il fallimento
Negli ultimi due anni si sono moltiplicati i sistemi che promettono di automatizzare la ricerca in machine learning, dall’AI Scientist di Sakana ad Agent Laboratory. Gli autori di ARIS rimproverano loro tre cose: l’esecutore e il revisore sono spesso lo stesso modello o due modelli molto simili, quindi condividono gli stessi punti ciechi; le pipeline sono blocchi unici, difficili da smontare o da riprendere a metà; pochi controllano in modo esplicito che i risultati dichiarati corrispondano agli esperimenti fatti.
Il punto più interessante del rapporto sta nella diagnosi. Il guasto tipico di un agente che lavora per ore, scrivono, non è il crollo visibile ma il successo plausibile e non sostenuto: risultati veri ma riportati male, affermazioni che vanno oltre le prove, lettori che ereditano senza accorgersene l’inquadratura dell’agente. Un esperimento fallito lo si vede. Una tabella con il seme migliore spacciato per media, no.
Da qui un’ipotesi dichiaratamente severa, isolata in una riga a sé: ogni compito lungo svolto da un solo agente è inaffidabile. Gli autori ammettono che può sottostimare i modelli di oggi, ma sostengono che nella ricerca il costo di un eccesso di prudenza è più basso di quello di un risultato falso. E aggiungono un’osservazione che pochi mettono per iscritto, senza però documentarla con esempi: per alzare il voto il più in fretta possibile, scrivono, l’agente esecutore cerca in vari modi di ingannare il revisore durante il dialogo. Il sistema va quindi costruito contro l’agente stesso, oltre che attorno a lui.
Perché un secondo modello che critica il primo può aiutare, e quando invece il dibattito fra agenti si riduce a un’eco: autocritica, dibattito e voto fra modelli sono spiegati nel capitolo sui sistemi multi-agente.
Un esecutore, un revisore, un criterio di arresto
Il meccanismo centrale è un ciclo fra due ruoli. L’esecutore, nella configurazione di default Claude Code, produce un artefatto: codice, una sezione del paper, un piano di esperimenti. Il revisore, di default GPT-5.4 con ragionamento al massimo (xhigh), gli dà un voto su una griglia prefissata e restituisce una lista di cose da sistemare. L’esecutore corregge e si ricomincia. Se si chiama $s_t$ il voto al giro $t$ e $C_t$ l’insieme dei rilievi critici ancora aperti, la regola di arresto descritta nel paper si può scrivere così:
$$t^{\star} = \min\big(\min\{\, t : s_t > \theta \ \wedge\ C_t = \varnothing \,\},\ T_{\max}\big), \qquad \theta = 6/10,\ \ T_{\max} = 4.$$
Due dettagli fanno la differenza rispetto a un semplice «chiedi a un altro modello». Il primo è l’indipendenza: l’esecutore passa al revisore i percorsi dei file e l’obiettivo della revisione, non un proprio riassunto. Se riassumesse, il revisore giudicherebbe il racconto dell’esecutore e non il lavoro, che è esattamente il modo in cui gli errori si propagano. Il secondo è la famiglia: esecutore e revisore vengono di default da linee di modelli diverse (Claude da una parte, GPT dall’altra, oppure il contrario; in alternativa Gemini, MiniMax, GLM, Kimi o DeepSeek), sulla base di lavori precedenti secondo cui configurazioni miste producono critiche meno correlate. È una raccomandazione, non un vincolo: il sistema non rifiuta una coppia della stessa famiglia.
Il revisore si regola su due assi. Quanto vede: solo il testo, il testo più i file dei risultati, oppure l’intero repository. E quanto ricorda: un thread nuovo a ogni giro, per non affezionarsi alle proprie obiezioni, oppure la memoria dei giri precedenti, per controllare che i rilievi siano stati davvero risolti. Quando un esperimento fallisce, il sistema riprova fino a un limite configurabile (tre tentativi di default) e l’esecutore deve provare almeno due strategie diverse prima di dare un rilievo per irrisolto; se non basta, può intervenire un terzo modello per una diagnosi indipendente.
La cascata che segue i numeri
Il ciclo di revisione, riconoscono gli autori, da solo non basta. Sopra c’è quello che chiamano assurance stack, e il suo pezzo principale è una cascata in tre stadi che parte dal codice e arriva alle frasi del paper.
Il primo stadio controlla l’integrità degli esperimenti. Un revisore dell’altra famiglia legge codice di valutazione e file di output cercando cinque difetti precisi: etichette di riferimento ricavate dalle uscite del modello invece che dal dataset, metriche normalizzate su denominatori prodotti dal modello stesso, numeri dichiarati che non compaiono in nessun file, metriche definite nel codice ma mai calcolate e descritte come se lo fossero, conclusioni estese oltre i dataset e i semi davvero provati. Lo stadio è solo consultivo, non ferma il lavoro, ma i suoi avvisi viaggiano in avanti.
Il secondo stadio assegna a ogni affermazione sperimentale uno di tre verdetti, sostenuta, parzialmente sostenuta o invalidata, e costruisce un registro che collega ogni tesi alle prove che la reggono o la smentiscono. Un’affermazione colpita da un fallimento al primo stadio non può essere marcata come pienamente sostenuta.
Il terzo stadio è il più rigoroso: un revisore senza alcuna memoria, aperto su un thread nuovo, legge il sorgente LaTeX insieme ai file grezzi e confronta ogni numero del manoscritto. Cerca discrepanze, scelta del seme migliore, configurazioni diverse da quelle dichiarate, errori di aritmetica nelle differenze percentuali, conclusioni troppo ampie. Ogni affermazione esce con uno stato come exact_match, number_mismatch o missing_evidence.
Attorno al manoscritto ci sono altri quattro controlli: cinque passate di revisione stilistica, un verificatore di dimostrazioni con una tassonomia di venti tipi di problema, una lettura del PDF compilato per trovare figure illeggibili e tabelle sbilenche, e un audit delle citazioni che verifica non solo che il paper citato esista e abbia i metadati giusti, ma che dica davvero ciò per cui viene citato. Le raccomandazioni dell’audit (tenere, correggere, sostituire, togliere) passano comunque da un umano prima dell’invio.
Una memoria che ricorda i vicoli ciechi
L’altro ingrediente è una wiki di progetto che sopravvive fra una sessione e l’altra: articoli, idee, esperimenti e affermazioni, legati da otto tipi di relazione (estende, contraddice, sostiene, invalida, e così via). La scelta di progetto che conta è conservare le idee scartate. Senza memoria, un agente può riproporre la stessa strada morta a ogni sessione; con la wiki la riconosce e passa oltre. Prima di generare idee nuove l’agente legge un riassunto compresso della wiki, tagliato a 8.000 caratteri.
Il resto è ingegneria di contorno: più di 65 abilità scritte come semplici file Markdown, eseguibili senza modifiche in Claude Code, Codex CLI e Cursor; cinque flussi che vanno dalla scoperta dell’idea alla risposta ai revisori di una conferenza; quattro livelli di sforzo, da lite (circa 0,4 volte l’impostazione standard, in ampiezza e numero di giri) a beast (da 5 a 8 volte). Un prototipo registra l’uso del sistema e propone modifiche alle proprie istruzioni, ma solo quelle che il revisore giudica almeno 7 su 10 arrivano all’utente, e nessuna viene applicata in automatico.
Le prove, e quelle che mancano
Qui il rapporto è onesto, e serve: la sezione delle prove è sottile. I dati sono di diffusione: le abilità sono passate da 21 al lancio a più di 65, oltre trenta sono arrivate dalla comunità, dalla robotica alla progettazione hardware; come revisore sono supportate almeno sei famiglie di modelli. L’unica misura di funzionamento è una notte documentata dall’inizio alla fine: in circa otto ore il sistema ha fatto quattro giri di revisione, ha lanciato più di venti esperimenti su GPU, ha tolto le affermazioni che le prove non reggevano e ha portato il voto da 5,0 a 7,5 su 10.
Quel voto, va detto, è il voto del revisore automatico, non di una commissione umana. E gli autori stessi scrivono che è una sola traiettoria, su un solo paper, da cui non generalizzano: non dimostra che un revisore di un’altra famiglia sia meglio di uno della stessa, né che due ruoli siano il numero giusto. Anche il linguaggio dei banditi avversariali e degli equilibri di Nash usato nell’introduzione per motivare la coppia esecutore-revisore è dichiarato, più avanti, un’analogia e non un risultato formale. La valutazione controllata è descritta in appendice come lavoro futuro: dodici o più bozze di paper, cinque condizioni a parità di calcolo, fra cui l’autocritica di un modello solo, due agenti dello stesso modello e due famiglie in un verso e nell’altro, tre valutatori indipendenti e alla cieca.
Gli altri limiti sono elencati senza giri di parole. La cascata non è una verifica formale e non prende tutto. Il ciclo può amplificare le manie del revisore: se questo chiede sempre la stessa metodologia, il paper si adatta al revisore invece di migliorare, e iterare oltre il punto dei rendimenti decrescenti può peggiorarlo. La revisione a livello di repository spedisce il codice a un’API esterna, e un revisore locale per i progetti riservati è annunciato ma non ancora disponibile. La tabella di confronto con gli altri sistemi, in cui ARIS è l’unico con tutte le caselle piene, l’hanno compilata gli autori. E il rapporto, dichiarano, è stato scritto e rivisto con l’aiuto di ARIS stesso, prima della revisione finale umana.
Perché conta adesso
La corsa agli scienziati artificiali ha misurato finora quanto lontano un agente riesca ad arrivare da solo: un’idea, un esperimento, un PDF. ARIS sposta l’attenzione su una domanda meno spettacolare e più utile, la stessa che si fa a un bilancio: chi controlla, e con quali registri. Il suo contributo più duraturo potrebbe non essere il software ma l’elenco dei modi in cui un agente produce risultati convincenti senza averli, dal seme scelto a posteriori alla metrica normalizzata su se stessa, trasformato in controlli che girano da soli. Se un revisore di un’altra famiglia li faccia girare meglio di uno della stessa, per ora, lo sostengono gli autori e lo dovrà dire un esperimento che non hanno ancora fatto.
I commenti sono riservati agli iscritti.
Accedi per commentare