Come leggere un benchmark AI senza farsi ingannare
AILmanac cita numeri da benchmark su decine di pagine sui modelli. Lo fanno anche ogni post di lancio, ogni tabella di confronto e ogni thread "abbiamo battuto la frontiera". Quasi nessuno di loro ti dice le tre cose che decidono cosa significa un numero: quale scaffold l'ha prodotto, su quanti tentativi è mediato, e se il modello aveva già letto le risposte.
Quelle tre non sono pignolerie. In un esempio pubblicato più sotto, gli stessi pesi del modello segnano 77,2% e 82,0% sugli identici 500 problemi — il divario di 4,8 punti è interamente harness. In un altro, modelli di frontiera che risolvono oltre il 70% di un benchmark di coding risolvono circa il 23% di uno più difficile costruito sullo stesso tipo di compito. Nessuno dei due divari è una bugia. Entrambi sono invisibili se leggi solo il titolo.
Questa pagina è il manuale per leggere il numero invece del titolo.
- Sapere cosa misura letteralmente un punteggio SWE-bench — e cosa ha verificato 'Verified'
- Separare il modello dallo scaffold, usando la nota metodologica di un vendor stesso come prova
- Riconoscere lo sconto da contaminazione: perché un benchmark più difficile costruito su codice mai visto taglia i punteggi di decine di punti
- Leggere i numeri 'high compute' e 'best-of-n' per quello che sono: un prodotto diverso, a un prezzo diverso
- Applicare una checklist di sei domande a qualunque affermazione su un benchmark in meno di due minuti
- Sapere quando un benchmark è saturo e ha smesso di dirti qualcosa
Cosa misura letteralmente un punteggio SWE-bench
Parti dai meccanismi, perché i meccanismi sono l'avvertenza.
SWE-bench è stato costruito scandagliando pull request e issue di 12 repository Python popolari, producendo 2.294 istanze di compito. Ogni istanza consegna al modello una descrizione di issue e uno snapshot del repository. Il modello scrive una patch. La patch viene valutata eseguendo i test che fallivano prima della correzione reale e passavano dopo — l'insieme "Fail-to-Pass".
Quindi un punteggio SWE-bench è questa frase e nient'altro:
Dato il testo di una issue e un repository, il sistema ha prodotto un diff che fa passare dal rosso al verde un insieme specifico di test nascosti.
Nota tutto quello che quella frase non afferma. Non che la patch sia quella che un manutentore avrebbe fatto il merge. Non che sia leggibile, minimale o sicura. Non che eviti di rompere qualcosa che nessun test copre. Non che un umano avrebbe accettato la pull request. Il benchmark è un oracolo basato su suite di test, e le suite di test sono una specifica incompleta della correttezza — che è lo stesso motivo per cui il reward hacking negli agenti di coding è un problema vivo e non teorico.
Cosa ha verificato davvero "Verified"
SWE-bench Verified è un sottoinsieme di 500 istanze dell'originale, creato in collaborazione con OpenAI. Annotatori umani hanno rivisto ogni istanza per confermare tre cose: la descrizione del problema è chiara, la patch di test è corretta, e il compito è risolvibile con le informazioni date.
Leggi quell'elenco con attenzione. Verified ha corretto i difetti del benchmark stesso — issue sottospecificate, grader rotti, compiti impossibili. È una garanzia di pulizia, non una garanzia di difficoltà e non una garanzia di realismo. "Verified" nel nome fa sentire alle persone "validato come misura di abilità ingegneristica". Significa "abbiamo verificato che queste 500 domande siano rispondibili e valutate correttamente".
Verified = le domande sono eque. Non: le domande sono difficili, rappresentative o mai viste. Quelle sono tre proprietà separate, e le prossime due sezioni riguardano quelle che Verified non ha mai rivendicato.
La tassa dello scaffold: il numero è un punteggio di sistema, non di modello
Questa è la cosa più utile di questa pagina, e la prova è una nota metodologica di un vendor stesso.
Quando Anthropic ha pubblicato Claude Sonnet 4.5, la nota metodologica affermava che tutti i risultati di Claude usavano "un semplice scaffold con due strumenti — bash e modifica di file tramite sostituzioni di stringhe." La cifra di punta su SWE-bench Verified, 77,2%, è stata prodotta con nessun test-time compute, mediata su 10 tentativi, con un budget di thinking di 200K, sull'intero set di 500 problemi.
Lo stesso post riportava un secondo numero: 82,0%, sotto "high compute". Quella configurazione campiona tentativi multipli in parallelo, scarta le patch che rompono i test di regressione visibili (rejection sampling), poi usa un modello di scoring interno per scegliere il miglior sopravvissuto.
Stessi pesi. Stessi 500 problemi. +4,8 punti dal solo harness.
Ne seguono quattro conseguenze, e si generalizzano ben oltre questo singolo esempio.
1. Una riga di classifica è un agente, non un modello. Due sottomissioni degli stessi pesi con scaffold diversi sono sistemi diversi. Quando una tabella di confronto mette il Modello A al 74% accanto al Modello B al 71%, e le righe vengono da harness diversi, la tabella ha misurato gli harness almeno quanto i modelli. Le CLI degli agenti di coding a confronto esiste perché l'harness è una variabile di prima classe.
2. I numeri "high compute" sono un prodotto diverso a un prezzo diverso. Best-of-n con un verificatore sono n esecuzioni di inferenza più un passaggio di scoring. Se la cifra di punta di un vendor è quella high-compute, il prezzo che pagheresti per riprodurla è circa n volte quello ovvio. Chiedi sempre a quale numero corrisponde la pagina dei prezzi. Perché gli agenti bruciano token è il lato costi della stessa aritmetica.
3. Il rejection sampling ha bisogno di un segnale che potresti non avere. "Scarta le patch che rompono i test di regressione visibili" funziona su SWE-bench perché ogni istanza porta con sé una suite di test. Sulla tua codebase, quel passaggio vale solo quanto valgono i tuoi test. Un punteggio high-compute è in parte una misura della copertura dei test del benchmark, trapiantata nell'agente come filtro.
4. La politica di media è portante. "Mediato su 10 tentativi" è una scelta onesta che costa punti — le esecuzioni agentiche hanno alta varianza, e una singola esecuzione best-of-10 leggerebbe più alta. Un paper che riporta una sola esecuzione e un paper che riporta una media su 10 tentativi non sono confrontabili, e la differenza raramente è nel titolo.
Quando un punteggio non dichiara lo scaffold, il numero di tentativi e la convenzione pass@k, non è una misurazione riproducibile — è marketing con la virgola. Vale quando il numero fa bella figura a Claude tanto quanto quando la fa a qualunque altra cosa.
Lo sconto da contaminazione
La seconda variabile invisibile: se il modello ha visto le risposte.
SWE-bench è stato assemblato dalla cronologia pubblica di GitHub. La cronologia pubblica di GitHub è dati di addestramento. Per qualunque benchmark costruito così, non c'è modo pulito di dimostrare che un modello stia risolvendo il compito invece di ricordare la correzione già fatta. La posizione di OpenAI è ormai esplicita in un post intitolato Why we no longer evaluate SWE-bench Verified.
SWE-Bench Pro è la risposta strutturale. Scale ha costruito 1.865 compiti su 41 repository mantenuti attivamente, deliberatamente selezionati così che la sovrapposizione con i set di addestramento sia improbabile per costruzione:
| Sottoinsieme | Repo | Come si resiste alla contaminazione |
|---|---|---|
| Pubblico | 11 | Licenze copyleft forti (famiglia GPL) — legalmente scomode su cui addestrare |
| Held-out | 12 | Pubblicati come benchmark, trattenuti dal rilascio aperto |
| Commerciale | 18 | Codebase private sotto accordi di partnership; mai pubbliche |
I compiti sono anche più difficili di proposito: problemi che richiedono a ingegneri professionisti da ore a giorni, tipicamente su più file.
Il risultato al lancio è il numero che vale ricordare. I modelli migliori, con oltre il 70% su SWE-bench Verified, si sono fermati attorno al 23% sul set pubblico di SWE-bench Pro — e ancora più in basso sul sottoinsieme commerciale, dove il codice dimostrabilmente non era mai stato pubblico:
| Modello (come testato al lancio) | SWE-bench Pro, pubblico | SWE-bench Pro, commerciale |
|---|---|---|
| OpenAI GPT-5 | 23,3% | 14,9% |
| Claude Opus 4.1 | 23,1% | 17,8% |
Quei modelli sono superati da tempo — il punto non è la riga, è la forma. Stessa famiglia di compito, stesso meccanismo di valutazione, due scelte di design cambiate (codice mai visto, orizzonte più lungo), e il numero crolla di decine di punti. Il calo da pubblico a commerciale dentro lo stesso benchmark è il segnale di contaminazione più pulito pubblicato, perché tiene la difficoltà del compito grosso modo fissa e varia solo se il codice poteva essere stato usato per l'addestramento.
L'abitudine portabile: quando due benchmark misurano "la stessa cosa" e discordano di 40 punti, il disaccordo è l'informazione. Chiediti quale scelta di design differisce — dati mai visti, orizzonte più lungo, grader più severo — e dai per scontato che la tua codebase assomigli a quella più difficile. Il tuo repository è privato, di lunga vita e poco testato; assomiglia al sottoinsieme commerciale molto più che a una famosa issue di Django del 2021.
Saturazione: quando un benchmark smette di portare informazione
Un benchmark dove i leader si ammassano sul novanta e qualcosa ha smesso di separarli. Il divario residuo è dominato dal rumore del grader, dalle differenze di scaffold e dalla manciata di istanze con specifiche ambigue.
La spia utile è una variante più difficile accoppiata. Nella tabella di lancio di Ember-1, gli stessi modelli che segnano 80-93% su SWE-bench Verified segnano 6,7-21,3% su SWE-Interact, che richiede di fare domande all'utente a metà compito. Una di quelle due colonne sta ancora misurando qualcosa. Quando vedi un titolo con un novanta e qualcosa, la tua prima mossa è trovare il numero accoppiato che non è un novanta e qualcosa — è lì che sta il divario di capacità vivo, ed è lo stesso fenomeno che il divario capacità-affidabilità descrive dal lato del deployment.
E sulle classifiche di preferenza umana
Le classifiche in stile arena hanno il problema speculare. Il voto umano a coppie premia in modo affidabile le risposte più lunghe e più formattate, indipendentemente dal fatto che siano più corrette. È per questo che LMArena pubblica una vista separata con controllo dello stile, che corregge statisticamente per lunghezza della risposta e struttura markdown. Se citi una posizione in arena, cita da quale vista viene — i due ordinamenti non sono gli stessi, e quello non corretto misura in parte la verbosità.
Sei domande, due minuti
- SWE-bench, Verified, Lite, Multimodal, Multilingual e Pro sono dataset diversi con dimensioni e difficoltà diverse. Un numero senza variante è illeggibile. 'SWE-bench 74%' potrebbe significare quattro cose incompatibili.
- Quali strumenti, quanti turni, quale budget di thinking, c'era retrieval? Se il post non lo dice, il numero non è riproducibile. La dichiarazione di Anthropic sui due strumenti bash-più-sostituzione-di-stringhe è lo standard a cui tenere tutti — Anthropic compresa.
- Le valutazioni agentiche hanno alta varianza. Una media su 10 tentativi e una singola esecuzione fortunata differiscono di diversi punti sullo stesso sistema. 'High compute', 'best-of-n', 'con verificatore' e 'test-time compute parallelo' significano tutti: questo costa n volte più di quanto pensi.
- Costruito dalla cronologia pubblica di GitHub prima del cutoff del modello? Dai per scontato un richiamo parziale. Preferisci benchmark con sottoinsiemi held-out o privati, e pesa più di tutto il punteggio sul sottoinsieme privato — è il proxy più vicino al tuo repository mai visto.
- Eseguito dal vendor su benchmark scelti dal vendor è un segnale legittimo e debole. Cerca lo stesso modello su una classifica indipendente con un harness fisso. Dove i numeri del vendor e quelli indipendenti discordano, il delta è di solito scaffold.
- Se i primi cinque stanno entro tre punti vicino al tetto, la classifica è rumore. Trova la variante accoppiata più difficile — interattiva, a orizzonte lungo, su repository privati — e leggi quella colonna invece.
Interroga un post di lancio
Incolla la sezione benchmark di un vendor e fai fare al modello il passo 2 per te. Il punto non è il riassunto; è l'elenco di ciò che è esplicitamente mancante.
Audit di un'affermazione su un benchmark
You are auditing a benchmark claim for reproducibility. Here is the benchmark section of a model launch post: <launch_post> [PASTE THE BENCHMARK SECTION AND ALL FOOTNOTES] </launch_post> For each benchmark number reported, produce a row with: - benchmark name and exact variant (e.g. SWE-bench Verified, 500 instances) - the score, and whether it is pass@1, best-of-n, or an average of k trials - the scaffold: tools available, turn limit, thinking/reasoning budget, retrieval - whether any test-time-compute technique was used (parallel sampling, rejection sampling against visible tests, a verifier or scoring model) - who ran the eval: the vendor, or an independent party with a fixed harness Then output two lists: 1. NOT STATED — every field above that the post does not disclose. 2. COMPARABILITY RISKS — specific reasons a reader could not place these numbers next to another vendor's numbers for the same benchmark. Do not estimate or infer missing values. If the post does not say it, it goes in list 1. Quote the footnote text you relied on for each field you did fill in.
Esegui lo stesso prompt sui post di due vendor per lo stesso benchmark e i rischi di comparabilità di solito ti scrivono da soli la riga di avvertenze della tabella di confronto.
Errori comuni
| Errore | Perché inganna | Cosa fare invece |
|---|---|---|
| Trattare una riga di classifica come un punteggio di modello | È un modello più scaffold, politica di tentativi e budget di calcolo | Confronta righe solo dentro un harness fisso, oppure confronta onestamente sistemi interi |
| Mettere il numero high-compute del vendor A accanto al pass@1 del vendor B | Uno è n esecuzioni di inferenza con un verificatore; l'altro è una sola esecuzione | Allinea la convenzione di calcolo, oppure etichetta l'asimmetria |
| Leggere "Verified" come "validato come realistico" | Ha verificato che le domande siano rispondibili e valutate correttamente | Usalo come dataset pulito, non come prova di abilità nel mondo reale |
| Citare un punteggio vicino al tetto come prova di un vantaggio | I benchmark saturi classificano rumore | Cita la variante accoppiata più difficile |
| Dare per scontato che un benchmark da GitHub pubblico non sia contaminato | I dati precedono il cutoff e sono nel crawl | Preferisci sottoinsiemi held-out o privati; pesali più di tutto |
| Estrapolare un punteggio di benchmark al tuo repository | Il tuo codice è privato, di lunga vita e testato poco | Costruisci una piccola valutazione sui tuoi compiti — vedi Valutare il tuo agente AI |
| Citare una posizione in arena senza la vista | Il voto a coppie non corretto premia in parte lunghezza e formattazione | Di' se è la classifica con controllo dello stile |
L'ultima riga è quella che conta più di tutte in pratica. Un benchmark pubblicato risponde a "questo modello è bravo su questo benchmark". La domanda che hai davvero è "questo modello è bravo sul mio lavoro", e l'unico strumento per quella è una valutazione sui tuoi compiti. Le valutazioni spiega come costruirne una; venti dei tuoi ticket reali, valutati con una rubrica scritta da te, battono ogni classifica di questa pagina per la tua decisione.
Check yourself
0/3- Un punteggio di benchmark è un punteggio di sistema. Modello + scaffold + politica di tentativi + budget di calcolo. Il divario pubblicato tra 77,2% e 82,0% sugli stessi problemi è la prova.
- 'Verified' significa che le domande sono eque, non che siano difficili, realistiche o mai viste. Tre proprietà separate, una parola rassicurante.
- I benchmark da GitHub pubblico non possono dimostrare che il modello non stia ricordando. Pesa più di tutto i sottoinsiemi held-out e privati — sono il proxy più vicino al tuo repository.
- Un disaccordo di 40 punti tra due benchmark che misurano 'la stessa cosa' è l'informazione, non un errore. Trova la scelta di design che differisce.
- I punteggi vicini al tetto classificano rumore. Leggi sempre la variante accoppiata più difficile.
- Nessun benchmark pubblicato risponde alla tua domanda vera. Venti dei tuoi ticket con una rubrica battono ogni classifica qui.
Avanti
- Valutare il tuo agente AI — il playbook per costruire la valutazione che risponde davvero alla tua domanda, dato che nessun benchmark pubblico lo farà
- Il modello è stato depotenziato? Come capirlo davvero — la stessa disciplina di misurazione puntata sull'altra domanda ricorrente, con un protocollo a design accoppiato che puoi eseguire
- Le CLI degli agenti di coding a confronto — l'harness come variabile di prima classe, che è esattamente ciò che dice la tassa dello scaffold
Fonti e approfondimenti
- SWE-bench — la costruzione (2.294 istanze, 12 repository Python) e il meccanismo di valutazione Fail-to-Pass
- SWE-bench Verified — il sottoinsieme di 500 istanze costruito con OpenAI, ed esattamente cosa ha verificato l'annotazione umana
- Introducing Claude Sonnet 4.5 — Anthropic — la nota metodologica citata qui: scaffold a due strumenti, media su 10 tentativi, budget di thinking di 200K, e cosa aggiunge "high compute"
- SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? — arXiv 2509.16941 — 1.865 compiti, 41 repository, la divisione pubblico / held-out / commerciale
- SWE-Bench Pro: Raising the Bar for Agentic Coding — Scale — la strategia anti-contaminazione (copyleft più codice commerciale privato) e i risultati pubblico-vs-commerciale al lancio
- SWE-Bench Pro leaderboard — Scale — le posizioni attuali, per quando i numeri al lancio qui sopra saranno storia
- Why we no longer evaluate SWE-bench Verified — OpenAI — citato per la posizione dichiarata; la pagina blocca il recupero automatico
- LMArena leaderboard — confronta la vista predefinita e quella con controllo dello stile degli stessi modelli
- Correlati: Valutazioni · Reward hacking negli agenti di coding · Il divario capacità-affidabilità · Perché gli agenti bruciano token