Avete presente quei grafici dove cinque modelli AI si sfidano su sei benchmark diversi e ognuno dichiara vittoria su almeno uno? Ecco, fermiamoci un attimo. Perché quei numeri — 34% qui, 1769 là, 25% dall’altra parte — non misurano affatto la stessa cosa.
Alcuni test valutano se un modello sa risolvere equazioni differenziali. Altri se riesce a orchestrare CRM, email e calendario aziendale senza fare danni. Altri ancora se sa modificare quaranta file di codice senza rompere l’intero repository. Metterli sullo stesso grafico è come confrontare il tempo sui 100 metri con il punteggio a scacchi: tecnicamente sono entrambi numeri, ma poi?
I sei benchmark del grafico (e perché non sono intercambiabili)
Partiamo dal grafico che mostra GLM-5.3, GLM-5.2, Kimi K3, Fable 5 e GPT-5.6 Sol. Sei colonne, sei test. Ma cosa stanno effettivamente misurando?
Terminal-Bench 3.0: il terminale come campo di battaglia
Questo test chiede una cosa semplice: l’AI riesce a lavorare davvero dentro un terminale, in un ambiente Docker, portando a termine task utili? Non generare codice in astratto — operare. Compilare, debuggare, configurare.
È la terza versione del benchmark, nata perché la 2.1 era ormai ‘satura’: i migliori agenti superavano l’84%, quindi serviva qualcosa di più duro. Questa versione è sviluppata dal Laude Institute con Snorkel AI e funziona in modo peculiare: i task non sono fissi. Arrivano dalla community, passano attraverso una pipeline di revisione che farebbe impallidire una peer review accademica — 35 criteri di valutazione, validazione Docker, test con agenti reali e persino ‘tentativi di imbroglio’ adversariali per vedere se il task è aggirabile.
Risultato? I punteggi nel grafico vanno da 4 a 34 su 100. Sì, avete letto bene: il migliore arriva a un terzo. Non perché i modelli siano scarsi, ma perché il test è tarato sulla frontiera attuale. È volutamente durissimo.
DeepSWE: coding pulito, senza scorciatoie di memoria
Qui entriamo nel mondo dell’ingegneria del software vera: modifiche multi-file su repository reali, non semplici bug fix da tre righe. 113 task scritti da zero su 91 repository attivi, in cinque linguaggi — TypeScript, Go, Python, JavaScript, Rust.
La particolarità? Questi task non vengono mai fusi nei repository originali. Mai. Il che significa che non finiscono mai nei dati di training futuri. È un antidoto diretto al problema della contaminazione: la maggior parte dei benchmark di coding prende fix già pubblicati su GitHub, e i modelli potrebbero averli semplicemente ‘ricordati’ invece che risolti.
DeepSWE evita il trucco. Ogni task ha un correttore scritto a mano che verifica la funzionalità richiesta, accettando qualunque implementazione valida. Non c’è una ‘soluzione giusta’ da copiare — c’è un problema da risolvere.
Agents’ Last Exam (ALE-CLI): lavoro vero, non quiz
Questo è probabilmente il test più ambizioso della lista. Non chiede se l’AI conosce un argomento — chiede se sa fare il lavoro. Ricostruire un bilancio. Diagnosticare un guasto Kubernetes. Calcolare parcelle legali secondo regole di giurisdizione specifiche.
Il benchmark completo copre 55 sotto-settori industriali con oltre 1.500 task, sviluppati insieme a più di 250 esperti di dominio. Nel grafico vedete ALE-CLI, un sottoinsieme ancora più difficile: solo agenti che operano da riga di comando, su 40 dei 55 domini, con task che richiedono da ore a settimane di lavoro umano equivalente. Non minuti. Settimane.
Il nome ‘Last Exam’ non è casuale: richiama Humanity’s Last Exam ma con un doppio significato. È sia una soglia di competenza reale — superarlo significa saper fare il lavoro, non solo parlarne — sia una frontiera di difficoltà. Anche il miglior agente in assoluto raggiunge appena il 25%. La maggior parte degli agenti mainstream? Vicini allo zero sui livelli più difficili.
AutomationBench: orchestrare il caos aziendale
Sviluppato da Zapier — che gestisce oltre 2 miliardi di task mensili per 3,7 milioni di aziende — questo test chiede all’AI di coordinare flussi di lavoro tra applicazioni diverse tramite API REST. CRM, email, calendario, messaggistica. Tutto insieme.
I task coprono sei aree: Vendite, Marketing, Operations, Supporto, Finanza, HR. L’agente deve scoprire da solo gli endpoint API giusti, seguire regole aziendali stratificate, ignorare record fuorvianti inseriti apposta nell’ambiente. La valutazione è spietata: si controlla solo lo stato finale. I dati corretti sono finiti nei sistemi giusti? Sì o no. Nessun giudizio soggettivo.
Un dato emerso dai test Zapier è illuminante: i modelli spesso dichiarano di aver completato il task quando in realtà hanno fallito. Problema di affidabilità, non di capacità pura.
HLE w/ Tools: conoscenza accademica, ma con gli aiuti
Humanity’s Last Exam è il benchmark accademico ‘di frontiera’: 2.500 domande di livello esperto in decine di materie — matematica, scienze naturali, discipline umanistiche — scritte da quasi 1.000 esperti globali provenienti da oltre 500 istituzioni. L’obiettivo? Domande che non si risolvono con una rapida ricerca su Google, ma che hanno comunque una soluzione univoca e verificabile.
La versione ‘w/ Tools’ concede all’AI l’uso di strumenti: ricerca web, esecuzione di codice. È più rappresentativa di come i modelli vengono usati realmente, a differenza della versione ‘pura’ che testa solo conoscenza e ragionamento a memoria.
Nota di trasparenza, utile da sapere: un’indagine indipendente di FutureHouse nel 2025 ha stimato che circa il 30% delle risposte HLE in chimica e biologia potrebbe essere errato. Il team di HLE ha parzialmente confermato e sta lavorando a una revisione continua. Anche i benchmark hanno bug, a quanto pare.
GDPVal-AA v2: deliverable veri, valutati come negli scacchi
Questo è l’unico benchmark della lista che non usa percentuali. Usa un punteggio Elo — lo stesso sistema degli scacchi — ricavato da confronti ‘alla cieca’ a coppie. Due output anonimi, un giudice LLM che sceglie il migliore. La scala è ancorata a 1.000 = prestazione di un esperto umano professionista.
Il test valuta i modelli su compiti di lavoro reali in 44 professioni e 9 settori che contribuiscono maggiormente al PIL USA — da qui il nome, GDP = Gross Domestic Product. Ai modelli viene dato accesso a shell e navigazione web tramite un harness agentico chiamato Stirrup, e devono produrre veri deliverable: documenti, slide, fogli di calcolo, diagrammi. Non risposte testuali.
Un punteggio sopra 1.000 significa che l’output del modello è stato preferito più spesso di quello del professionista umano. Nel grafico vedete numeri come 1769 o 1508 — non sono percentuali, sono rating relativi. Un modello a 1769 è significativamente più forte di uno a 1508, proprio come un giocatore di scacchi a 2000 Elo batte sistematicamente uno a 1500.
Riepilogo: sei test, sei mondi diversi
Ecco la tabella di sanità mentale. Stampatela, attaccatela al muro, consultatela ogni volta che vedete un grafico di benchmark AI.
Terminal-Bench 3.0: lavoro autonomo da riga di comando. Punteggio: percentuale di task completati.
DeepSWE: ingegneria software ‘pulita’, anti-contaminazione. Punteggio: percentuale di task completati.
Agents’ Last Exam (ALE-CLI): lavoro professionale reale, multi-settore, da CLI. Punteggio: percentuale di task completati.
AutomationBench: orchestrazione di workflow tra app aziendali tramite API. Punteggio: percentuale di task completati correttamente.
HLE w/ Tools: conoscenza accademica di frontiera, con strumenti. Punteggio: percentuale di risposte corrette.
GDPVal-AA v2: deliverable di lavoro reale in 44 professioni. Punteggio: Elo (1000 = umano esperto).
Il messaggio centrale? Questi sei benchmark non misurano la stessa cosa. Alcuni testano conoscenza pura, altri capacità tecniche isolate, altri ancora provano a simulare vero lavoro economico. Un modello può essere fortissimo su uno e debole su un altro. Confrontarli tutti insieme, come fa il grafico, dà un quadro molto più onesto delle capacità reali rispetto a un singolo numero da marketing.
I quattro benchmark ‘storici’ di coding (per completezza)
Oltre ai sei principali, vale la pena conoscere quattro test che hanno definito la storia della valutazione AI nel coding. Sono citati ovunque, e capire cosa misurano davvero aiuta a decodificare il gergo del settore.
SWE-bench Verified: il punto di riferimento standard (con riserve)
È il benchmark più citato in assoluto per misurare se un modello sa risolvere problemi di ingegneria del software reali. Dà al modello un repository di codice e la descrizione di una issue GitHub da risolvere; il modello deve investigare il codebase e generare una patch che la risolva.
È un sottoinsieme di 500 task, validato da annotatori umani, estratto dal dataset originale SWE-bench — 2.294 issue prese da 12 repository Python open source popolari. È stato creato da OpenAI insieme agli autori originali per correggere problemi del dataset di partenza: soluzioni corrette valutate come sbagliate, problemi descritti in modo ambiguo, test unitari troppo specifici.
Ogni task gira in un container Docker isolato. La soluzione viene valutata eseguendo i test unitari sul codice modificato. Le annotazioni umane permettono anche di dividere i task per difficoltà: un sottoinsieme ‘facile’ con 196 task risolvibili sotto i 15 minuti, e uno ‘difficile’ con 45 task che richiedono oltre un’ora.
Perché è così popolare? È diventato il punto di riferimento standard — quasi ogni nuovo modello frontier dichiara il proprio punteggio su questo benchmark nel proprio system card. Ma c’è un limite noto, che vale la pena menzionare: essendo costruito interamente su repository GitHub pubblici, esiste il rischio concreto che i modelli abbiano già ‘visto’ queste stesse issue e le relative soluzioni durante l’addestramento. Alcuni studi indipendenti hanno sollevato il dubbio che punteggi alti riflettano in parte memoria, non capacità di problem-solving reale.
LiveCodeBench: problemi freschi, zero contaminazione
Valuta le capacità di coding ‘olistiche’ di un modello — non solo generare codice, ma anche autocorreggersi, eseguire codice mentalmente e prevedere l’output di un test — usando problemi di programmazione competitiva.
Raccoglie in modo continuo nuovi problemi da tre piattaforme: LeetCode, AtCoder e CodeForces. Ed è esplicitamente ‘contamination-free’: poiché i problemi vengono aggiunti nel tempo con una data di rilascio associata, è possibile valutare un modello solo sui problemi pubblicati dopo il suo taglio di addestramento. Nessuna possibilità di ‘ricordo’.
Il dataset è partito con circa 400 problemi — periodo maggio 2023 – maggio 2024 — ed è cresciuto nel tempo. Perché è stato creato? Benchmark più vecchi come HumanEval si stavano ‘saturando’ e soffrivano di contaminazione. I modelli più recenti probabilmente avevano già visto quei problemi durante il training, rendendo i punteggi meno affidabili.
A differenza di SWE-bench — che testa debug su codice reale di produzione — LiveCodeBench misura più la capacità algoritmica ‘da concorso’. Utile per parlare di ragionamento puro sul codice, distinto dal lavoro da sviluppatore su una codebase esistente.
HumanEval: il nonno ancora vivo
È il benchmark di coding più ‘storico’ e ancora oggi il punto di riferimento didattico quando si spiega cos’è un test di generazione di codice. Misura se un modello riesce a scrivere il corpo di una funzione Python corretta, partendo solo dalla firma della funzione e da una docstring che ne descrive il comportamento.
164 problemi di programmazione scritti a mano da OpenAI, ciascuno con firma della funzione, docstring in linguaggio naturale e una suite di test nascosti — in media 7,7 test per problema — per verificare la correttezza. A differenza di metriche testuali come il BLEU score, HumanEval misura la correttezza funzionale: il codice generato viene davvero eseguito contro i test. La metrica standard è il pass@k, cioè la probabilità che almeno una delle k soluzioni generate passi tutti i test.
È nato insieme a OpenAI Codex nel 2021 ed è diventato per anni lo standard de facto. Ma oggi? È considerato un test ‘facile’ e ampiamente saturo dai modelli più recenti, proprio perché valuta funzioni isolate e brevi, non progetti reali multi-file.
SWE-Bench Pro: la versione enterprise, senza sconti
È la versione molto più severa di SWE-bench, pensata per problemi di ingegneria del software complessi, realistici e a lungo orizzonte — quelli che un vero team di sviluppo affronterebbe su un prodotto commerciale, non su una piccola libreria di utilità.
Contiene 1.865 problemi totali provenienti da 41 repository attivamente mantenuti, divisi in tre sottoinsiemi. Un set pubblico di 731 istanze da repository open source con licenze copyleft forti come la GPL — scelte apposta perché scoraggiano legalmente l’uso di quel codice nei dati di addestramento dei modelli. Un set held-out privato, tenuto nascosto per verificare l’overfitting sul set pubblico. E un set commerciale di 276 istanze tratte da 18 codebase proprietarie di startup reali, acquisite tramite partnership e mai pubblicate online.
A differenza di SWE-bench Verified, qui vengono escluse le modifiche banali da una-dieci righe: restano solo problemi che richiedono modifiche sostanziali multi-file. In media? Oltre 107 righe di codice su quattro file per soluzione.
Perché è stato creato? Per rispondere a quattro limiti di SWE-bench originale: contaminazione dei dati, scarsa diversità dei task — troppo concentrati su librerie semplici — problemi troppo semplificati rispetto al lavoro reale, e testing poco riproducibile.
È probabilmente il benchmark di coding oggi più resistente ai trucchi, sia per la contaminazione — grazie alle licenze GPL e al set commerciale mai pubblicato — sia per la difficoltà realistica dei task, che richiedono ore o giorni di lavoro equivalente umano.
La gerarchia della difficoltà nel coding
Dentro la categoria ‘coding’ esiste una gerarchia di difficoltà e realismo. HumanEval è il test più semplice e ormai saturo: funzioni isolate, brevi, con docstring chiare. LiveCodeBench alza l’asticella con problemi da concorso sempre nuovi, mai visti prima. SWE-bench Verified porta il test dentro repository reali, ma soffre di possibile contaminazione. SWE-Bench Pro e DeepSWE risolvono il problema della contaminazione con licenze protette o task scritti da zero, e alzano la complessità a modifiche multi-file.
Terminal-Bench, infine, allarga il test oltre il ‘solo codice’, includendo tutto ciò che un agente deve fare per operare in un ambiente di sviluppo reale: compilare, configurare, debuggare da terminale. Non basta scrivere la patch — bisogna farla funzionare.
Il messaggio finale: numeri diversi, significati diversi
La prossima volta che vedete un grafico con cinque modelli e sei colonne colorate, fermatevi. Chiedetevi: cosa sta misurando ciascuno di questi test? Sono percentuali o rating Elo? Testano conoscenza, capacità tecniche isolate o lavoro economico reale? Il modello ‘vincitore’ su un benchmark è anche il migliore per il vostro caso d’uso?
Perché la verità scomoda è questa: un singolo numero non racconta niente. Un modello può essere fortissimo su conoscenza accademica e imbarazzante su orchestrazione di workflow aziendali. Può eccellere su problemi algoritmici e crollare su modifiche multi-file in un codebase enterprise. Può dichiarare di aver completato un task quando in realtà ha fallito.
I benchmark sono utili. Ma solo se sappiamo cosa stiamo guardando.
