Nell’atletica un record non vale finché qualcuno non ha guardato l’anemometro. Un cento metri corso con più di due metri al secondo di vento a favore finisce negli annali come tempo ventoso, non come primato, e il cronometraggio passa per un controllo che l’atleta non fa. Nessuno pensa che il velocista stia barando: semplicemente, chi ha appena corso è la persona meno indicata per decidere se il tempo è regolare.
È la stessa idea che sta al centro di AutoResearch: Insight In, Hallucination Out, depositato su arXiv il 18 agosto 2026 (2608.17906; la versione attuale, la 4, è del 17 settembre, dopo una terza che lo ritirava) e fra i paper in tendenza su Papers with Code. Nella versione 4 lo firmano sei autori dell’Infinite Evolution Lab di EvoMap, con Haoyang Zhang come responsabile del progetto; il codice è su github.com/EvoMap/AutoResearch. È un rapporto tecnico breve, dieci pagine bibliografia compresa, e più che un nuovo meccanismo propone un modo di guardare ai sistemi che fanno ricerca da soli.
Automatizzare di più non basta
Gran parte dei progressi recenti, scrivono gli autori, è avanzata lungo una sola dimensione: quanta parte del lavoro di ricerca si può affidare agli agenti, e quanto poco deve intervenire una persona. Ma un processo più automatico non è per questo un processo più scientifico. Un errore nel codice, nella misura o nell’interpretazione può attraversare tutta la pipeline e uscire in fondo come una conclusione coerente e infondata. Il paper lo chiama allucinazione a livello di sistema: non la frase inventata da un modello, ma la tesi che nessun esperimento sostiene davvero.
La risposta è dividere il lavoro in due tempi con due domande diverse. La generazione delle idee deve rispondere a perché vale la pena provarci; l’esecuzione a perché vale la pena crederci. Da qui il titolo: l’intuizione entra, l’allucinazione esce.
Come si coordinano più agenti con ruoli diversi, e perché dividere il lavoro fra loro cambia che cosa sanno e che cosa sbagliano: i sistemi multi-agente hanno un capitolo nel libro.
Il primo tempo: un’idea deve sapere perché
Il sistema raccoglie di continuo segnali da paper, repository, media tecnici e piattaforme social, X e Xiaohongshu comprese. Non tutte le fonti pesano uguale: chi ha dimostrato nel tempo buon fiuto riceve una fiducia a priori più alta, e il flusso passa per normalizzazione, deduplica e un filtro affidato a un modello. Accanto c’è una base di conoscenza curata sul dominio di arrivo, cioè quello che il campo sa già.
Il passaggio interessante è il criterio con cui un segnale diventa un’idea. Non basta un tema o un miglioramento riportato: serve un meccanismo, qualcosa che spieghi perché una cosa funziona e che si possa staccare dal contesto in cui è nata. Ogni generatore riceve il segnale e il dominio e deve dire se quel meccanismo può affrontare un problema aperto lì. Può anche rispondere di no, e il paper spiega il senso di questa uscita: senza, ogni notizia letta verrebbe forzata dentro una proposta di ricerca. In pratica tre modelli di frontiera generano, tre revisori valutano ogni candidata, e servono almeno due pareri favorevoli per andare avanti. Seguono un controllo di freschezza, che aggiorna modelli e benchmark diventati vecchi, e uno di coerenza col dominio.
Il secondo tempo: chi giudica non ha lavorato
Il piano diventa un grafo di compiti con le loro dipendenze, e un coordinatore lancia in parallelo quelli pronti. Lavorano un pianificatore, un programmatore, un esecutore, poi un revisore e un critico, infine una tappa di chiusura. Lo stato della ricerca, cioè piano, codice, risultati, critiche e decisioni, è persistente: un progetto riparte da quello che è stato verificato, non da una cronologia di conversazione opaca.
La scelta di progetto che dà senso al resto riguarda il critico. È un agente con contesto nuovo, che non eredita il ragionamento di chi ha scritto e lanciato l’esperimento: riceve solo ipotesi, piano, artefatti e criteri, e deve ricostruire da lì se il risultato regge. Emette un verdetto a tre valori, PASS, PARTIAL o FAIL, e tutto quello che non è un PASS apre una strada di correzione invece di sparire nel racconto finale:
$$v_k \neq \mathrm{PASS} \;\Longrightarrow\; a_{k+1} \in \{\mathrm{DIAGNOSE},\, \mathrm{REVISE},\, \mathrm{RERUN}\}.$$
E una tesi $c$ viene accettata solo se lo stesso giudizio indipendente, applicato alle prove che la riguardano $E_c$ e ai criteri $\Gamma_c$, dà esito positivo:
$$\mathrm{Accept}(c) \;\Rightarrow\; V(c, E_c, \Gamma_c) = \mathrm{PASS}.$$
Le prove, qui, non sono le frasi dell’agente ma terne: un’azione, l’osservazione che ne è uscita e un artefatto che resta, cioè un log, un file di risultati, un checkpoint. Alla fine il sistema può continuare, rivedere, allargare o fermarsi, e fermarsi con un’ipotesi smentita è un esito valido, se le prove lo sostengono. Un risultato positivo non sostenuto, invece, no.
Il cronometro sbagliato
Delle tre prove, quella che racconta meglio il sistema è la più umile. Il compito è moltiplicare due matrici 1024 × 1024 in FP32 con un contratto esplicito: meno di 200 millisecondi, errore relativo sotto $10^{-5}$ rispetto a due riferimenti numerici, coefficiente di variazione sotto il 20% su dieci prove cronometrate. Il primo pilota passa i primi due cancelli e cade sul terzo: i tempi ballano troppo. Invece di promuovere il numero veloce, il sistema apre una diagnosi e trova il guasto nel cronometro: sotto una BLAS multi-thread misurava il tempo di CPU, che somma il lavoro di tutti i thread, e lo scambiava per il tempo trascorso. Corretta la misura e rilanciato l’esperimento, la base riproducibile è di 3,4 millisecondi, 626 GFLOPS, circa 58 volte più veloce del limite richiesto.
Il tempo finale, scrivono gli autori, non è il risultato importante, e in effetti moltiplicare matrici con una libreria ottimizzata non è una scoperta. Conta che un risultato attraente sia stato tenuto fermo finché la sua misura non era giustificata. È il tempo ventoso che non entra negli annali.
I numeri
Un’idea che diventa progresso. Sul recupero immagine–testo di RSICD, un dataset di immagini telerilevate con didascalie, la forgia propone un metodo in tre pezzi: un allineamento globale più forte fra immagine e testo, un’aggregazione di caratteristiche locali guidata dal testo, un legame esplicito fra entità e posizione. Il sistema li introduce uno alla volta con lo stesso protocollo, e il recall medio sale da 32,84 a 33,89, poi 34,04, infine 34,69: più 1,85 punti. Per gli autori la crescita monotona rende misurabile il contributo di ogni pezzo; va detto che ciascuno è aggiunto sopra i precedenti, in un ordine fisso.
Meno problemi degli altri. Nei primi due scenari il paper confronta AutoResearch con quattro sistemi noti: The AI Scientist, Agent Laboratory, R&D-Agent e AutoResearchClaw. Tutti ricevono lo stesso obiettivo e lo stesso contratto sperimentale, e gli artefatti prodotti vengono sottoposti a un audit che conta i problemi confermati («issue events»). In entrambi gli scenari AutoResearch ne registra meno di tutti.
| Sistema | RSICD | Matrici |
|---|---|---|
| AutoResearch | 5 | 4 |
| R&D-Agent | 11 | 5 |
| AutoResearchClaw | 15 | 7 |
| Agent Laboratory | 18 | 5 |
| The AI Scientist | 27 | 8 |
Sapere quando smettere. Su tre gare Kaggle classiche il sistema parte da una base economica e confronta i progressi con un obiettivo fissato prima. Dal confronto dipende la decisione.
| Gara e metrica | Base | Risultato | Obiettivo | Decisione |
|---|---|---|---|---|
| Titanic, accuratezza in validazione incrociata a cinque fold | 0,822 | 0,843 | 0,830 | si allarga |
| House Prices, errore (RMSLE) | 0,2008 | 0,1251 | 0,120 | si rivede |
| Disaster Tweets, F1 | 0,763 | 0,805 | 0,835 | si ferma |
Su Titanic il risultato supera l’obiettivo. Su House Prices l’errore scende vicino all’obiettivo, ma non sotto. Su Disaster Tweets resta lontano, con guadagni ormai marginali: il sistema si ferma e conserva il risultato negativo.
Perché un’accuratezza misurata su cinque fold dice più di una su un solo taglio dei dati, e che cosa non dice: la validazione e i suoi tranelli sono nel capitolo sull’overfitting.
C’è infine una misura di scala, con cifre approssimate. Su un solo server, con due Intel Xeon Platinum 8563C, otto GPU NVIDIA L20 e 944 GiB di memoria, in una settimana di funzionamento continuo il sistema ha generato circa 2584 idee; dopo revisione e filtri 355 sono entrate in coda, 22 esperimenti sono stati eseguiti in automatico e 14 idee convalidate.
Che cosa resta da verificare
Il metro dei problemi non è descritto. Il confronto con gli altri sistemi si regge tutto sui «problemi confermati dall’audit», e il paper non dice chi conduce l’audit, con quali regole un evento diventa un problema, se il revisore sapeva quale sistema stava giudicando, né se i problemi pesano tutti uguale. Senza questo, 5 contro 27 è un numero che non si può riprodurre, e il sospetto naturale, cioè che un audit progettato dagli autori premi proprio i controlli che il loro sistema fa, resta aperto.
Mancano i risultati degli altri. Su RSICD il paper riporta il recall di AutoResearch ma non quello ottenuto dai quattro concorrenti sullo stesso obiettivo, e sulle matrici nemmeno i loro tempi. Sappiamo che l’audit ha trovato loro più problemi, non se abbiano ottenuto di meno.
Una prova per scenario, nessuna varianza. Il paper non riporta ripetizioni né intervalli: ogni confronto ha l’aria di un singolo giro. I compiti sono piccoli: una moltiplicazione di matrici, tre gare Kaggle da manuale. Nessun giudizio umano valuta se le 14 idee convalidate siano nuove o utili, e il paper non dice che cosa voglia dire «convalidata». Non nomina nemmeno i tre modelli di frontiera, che pesano su tutto il primo tempo, e non dice se i cinque sistemi del confronto girassero sugli stessi.
La memoria è ancora un progetto. Nella discussione gli autori scrivono che il passo successivo è rimettere nella base di conoscenza le prove e gli esiti di ogni ciclo, $K_{t+1} = U(K_t, E_t, Y_t)$. Il sistema, dunque, non lo fa ancora: ogni ciclo parte dalla conoscenza curata e dai segnali, non dalla propria esperienza, che è proprio uno dei punti su cui AutoResearchClaw aveva investito.
Perché conta adesso
In un paio d’anni, da The AI Scientist in poi, i sistemi che promettono di fare ricerca da soli sono passati da curiosità a categoria, e la loro misura di successo è rimasta per lo più la stessa: quanto arrivano lontano senza aiuto. AutoResearch sposta la domanda su un terreno più scomodo e più utile, quanto di ciò che concludono sia sostenuto da una prova che qualcun altro ha guardato. Il paper non basta a dimostrare di avere la risposta migliore, perché il metro con cui misura gli altri è il pezzo meno documentato. Ma l’idea di fondo, che chi ha corso non omologhi il proprio tempo, vale per questi sistemi come per i laboratori fatti di persone: e conservare un risultato negativo, come quello di Disaster Tweets, è un’abitudine che anche la ricerca fatta a mano pratica meno di quanto dovrebbe.

I commenti sono riservati agli iscritti.
Accedi per commentare