L’agente giudice non ha letto le dimostrazioni

Nell’hackathon ICML 2026, agenti AI hanno riprodotto 2.200 paper, ma i verdetti automatici si sono rivelati contraddittori in 242 casi

6.816 logbook di riproduzione. 35.908 affermazioni giudicate. 496 paper con almeno un’affermazione falsificata o contestata. Il più grande esperimento di verifica della letteratura sul machine learning è stato condotto quasi interamente da macchine che controllano altre macchine.

A luglio 2026, l’hackathon di riproduzioni ICML ha coinvolto più di 1.200 membri della comunità nel tentativo di riprodurre i paper pubblicati alla conferenza. Il lavoro sporco lo hanno fatto agenti di codifica come Claude Code, Codex, Cursor e OpenResearch’s orx. Ogni esecuzione ha prodotto un logbook Trackio: codice, artefatti, resoconto. Alla chiusura, i logbook di riproduzione pubblicati erano 6.816.

Poi è entrato in scena il controllore. Il giudice automatico dei logbook, basato sul modello open-weights GLM-5.2, ha emesso un verdetto per ogni affermazione: verificata, falsificata, toy o inconcludente. Le 35.908 affermazioni giudicate sono state congelate in un dataset pubblico di verdetti alla chiusura della sfida.

Il revisore che non ha letto le dimostrazioni

Secondo il bilancio delle riproduzioni, il 23% dei paper esaminati — 496 su 2.200 — aveva almeno un’affermazione falsificata o contestata. Ma il dato più destabilizzante riguarda i verdetti opposti: 242 paper hanno visto team indipendenti arrivare a conclusioni contraddittorie sulle stesse affermazioni.

Il giudice automatico non solo non è infallibile: in una frazione rilevante dei casi è arbitrario.

C’è una dichiarazione che vale più di mille metriche.

“My low confidence score is because I did not check all the proofs carefully.”

A firmarla è un revisore di un paper spotlight accettato a ICML 2026. Tradotto: il paper è passato, ma il revisore ammette di non aver controllato le dimostrazioni. Se il controllo umano funzionava così, forse l’automazione non è il problema: è il sintomo.

Quattordici logbook su diciassette

Il paradosso più riuscito ha un titolo che sembra una profezia: il paper “A Coin Flip for Safety”, uno studio sulla inaffidabilità dei giudici LLM nella misurazione della robustezza avversariale, ha avuto 14 logbook su 17 che verificavano ogni affermazione.

Il paper che sostiene che i giudici automatici falliscono è stato validato da giudici automatici.

Poi c’è il caso in cui la riproduzione automatica ha funzionato davvero. Un logbook ha misurato il termine additivo che cresce come 0.38 ln k e ha individuato il punto esatto della dimostrazione che si rompe. La re-implementazione degli autori ha esteso la scansione a k = 1.024 confermando la crescita a circa nove sigma. La vera robustezza è Hk + Θ(log k). E i controesempi dei tre team mostrano violazioni che appaiono per la prima volta dopo il passo 224.

Perché AWS integra i modelli cinesi proprio adesso?

Mentre la scienza apre questa scatola nera, Amazon ne chiude un’altra. Sul blog tecnico di SageMaker HyperPod, il modello Qwen e DeepSeek vengono presentati come modelli di fondazione pubblicamente disponibili. Nessuna menzione di audit indipendente sui pesi, sui dati di addestramento o sui possibili vincoli di licenza. E Google, nello stesso momento, promuove Gemini 3.7 Flash come il modello workhorse più intelligente per coding e agenti.

Il tempismo non è casuale. Se la verifica scientifica diventa un processo che le macchine eseguono su altre macchine, chiunque controlli i modelli controlla anche la validazione. Senza controllo indipendente — senza un revisore che possa almeno dire di non aver letto le dimostrazioni — il ciclo si chiude.

E i regolatori, dal GDPR alle autorità antitrust, restano a guardare un processo che non capiscono.

Alla fine resta una domanda: se un agente riproduce un paper, un altro agente lo giudica, e un terzo agente archivia il verdetto, chi è responsabile quando il verdetto è sbagliato? E se la risposta è “nessuno”, stiamo ancora facendo scienza?