AutoResearch di EvoMap: il laboratorio automatico che non si fida dei propri numeri

Un piccolo gruppo di EvoMap presenta un sistema di ricerca automatica in due tempi: un'idea si mette alla prova solo se sa dire perché dovrebbe funzionare, un risultato si accetta solo se un agente che non l'ha prodotto lo trova sostenuto dalle prove. Il caso più istruttivo è un cronometro sbagliato scoperto prima di festeggiare. I numeri sono interessanti, il metro con cui si contano i problemi degli altri sistemi molto meno chiaro.

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.

Leggi «Sistemi multi-agente» 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.

Due cancelli: perché provarci, perché crederci GENERAZIONE DELLE IDEE segnali esterni base di conoscenza forgia 3 generano, 3 rivedono 1 perché provarci? «nessun abbinamento»: scartata ESECUZIONE pianifica, scrive, esegue critico contesto nuovo 2 perché crederci? non PASS: diagnosi, revisione, nuova esecuzione Una settimana su un server (larghezze non in scala) 2584 idee candidate 355 in coda 22 eseguiti 14 convalidate Ogni passaggio è più selettivo del precedente. Valori approssimati dagli autori, 2608.17906, § 4.

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.

Problemi confermati dall’audit issue events · più basso è meglio
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.

Tre gare, tre decisioni Kaggle · base di partenza, risultato e obiettivo fissato prima
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.

Leggi «Overfitting e validazione» nel libro →

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