Benchmark AI: punteggi simili, modelli molto diversi

Punteggi simili nei benchmark di AI possono nascondere modelli che lavorano in modi molto diversi in un repository reale. DeepSWE colloca Luna Max 2,2 punti dietro Sol High, ma Luna compie quasi il triplo dei passaggi. Il solo tasso di successo non mi dice quanta supervisione richiede un modello né se accetterei la sua pull request.

Che cosa misura un punteggio del 67% rispetto al 69%?

Misura il successo per tentativo in una specifica configurazione di DeepSWE. Il 69,4% di Sol High supera il 67,2% di Luna Max di 2,2 punti, ma il divario è inferiore all’incertezza tra le esecuzioni riportata negli stessi dati [2]. Il risultato mi dà un motivo per provare entrambi i modelli, non una recensione completa.

Misurazione	Luna Max	Sol High
Successo per tentativo, %	67,2	69,4
Intervallo del 95% tra esecuzioni	63,2–71,2%	68,0–70,8%
Tentativi valutati	448	451
Task con ≥1 successo, %	90,3 (Valore migliore della riga)	86,7
Costo medio per tentativo, $	0,61 (Valore migliore della riga)	3,47
Token di output per tentativo, migliaia	73,4	28,5 (Valore migliore della riga)
Passaggi dell'agente per tentativo	101,7	36,9 (Valore migliore della riga)

I dati di DeepSWE v1.1 pubblicati da Datacurve registrano 301 tentativi riusciti su 448 per Luna Max e 313 su 451 per Sol High [1] [2]. Questi totali producono i punteggi principali della figura 1.

DeepSWE mantiene costanti diverse variabili importanti. I suoi 113 task provengono da 91 repository open source e coprono TypeScript, Go, Python, JavaScript e Rust [1]. Sono stati scritti per questa valutazione invece di essere copiati da vecchie issue di GitHub. Ogni modello ha usato anche mini-swe-agent con lo stesso strumento bash e lo stesso prompt di base [5], mentre un container nuovo ha verificato che ogni patch avesse il comportamento richiesto e non introducesse regressioni.

Questi controlli rendono utile il confronto, ma il risultato conserva un margine di incertezza. Datacurve assegna a Luna un intervallo di confidenza al 95% dal 63,2% al 71,2%, mentre quello di Sol va dal 68,0% al 70,8% [2]. Gli intervalli si sovrappongono, quindi il divario di 2,2 punti è inferiore alla variazione osservata tra le esecuzioni. Datacurve non pubblica un confronto statistico dei due modelli sugli stessi task, perciò i dati non stabiliscono che il vantaggio di Sol sia ripetibile.

Le due configurazioni usano inoltre livelli di effort diversi: max per Luna e high per Sol. La classifica cambia se uso il Pass@4 empirico di Datacurve, che verifica se almeno uno dei tentativi registrati ha risolto ciascun task. Con questa misura, Luna copre il 90,3% dei 113 task e Sol l’86,7% [2]. Il risultato per tentativo favorisce Sol, mentre la copertura dei task favorisce Luna, perché le due misure rispondono a domande diverse.

Ogni dato della figura 1 appartiene ai task e alla configurazione dell’agente di DeepSWE. Il mio repository può premiare qualità diverse e mettere in luce altri fallimenti, quindi ora conta capire come ciascun modello arriva al risultato.

Perché punteggi vicini possono nascondere quasi il triplo dei passaggi

Il tasso di successo non mostra come il modello è arrivato alla patch, quindi due punteggi simili possono richiedere quantità di lavoro molto diverse allo sviluppatore. Osservo se il modello trova i file giusti, rispetta il design esistente, fa una domanda prima di adottare un’ipotesi rischiosa, si riprende dopo un comando fallito e si ferma quando la modifica richiesta è completa. DeepSWE non valuta questi comportamenti separatamente.

I dati grezzi di DeepSWE offrono un indizio. Luna Max ha usato in media 101,7 passaggi dell’agente e 73.400 token di output per tentativo, rispetto ai 36,9 passaggi e 28.450 token di Sol High [2]. Luna ha quindi impiegato circa 2,8 volte più passaggi e 2,6 volte più token di output per ottenere un tasso di successo simile. I due modelli non hanno lavorato allo stesso modo.

Anche il costo mostrato richiede contesto. I trial di Luna sono stati eseguiti il 7 luglio 2026, quando il consumo registrato dei token costava circa 3,03 dollari per tentativo [2] [3]. OpenAI ha ridotto i prezzi dei token di Luna dell’80% il 30 luglio 2026 [4], e DeepSWE ha ricalcolato il vecchio consumo con la nuova tariffa. È così che 3,03 dollari sono diventati gli 0,61 dollari mostrati. La cifra più bassa è una stima valida del costo attuale dello stesso consumo, ma non è quanto Datacurve ha pagato quando ha eseguito il test.

Il costo API per tentativo è inoltre diverso dal costo necessario per ottenere una modifica accettata. Il prezzo della leaderboard esclude nuovi tentativi, tempo di revisione, modifiche manuali, attese ed eventuali secondi modelli usati per controllare o riparare il lavoro del primo. Un modello può costare un sesto per tentativo e risultare comunque più caro nel complesso se un ingegnere deve supervisionare ogni decisione.

Gli sviluppatori chiamano a volte queste differenze “big model smell”: la sensazione che un modello più capace capisca il lavoro con meno spiegazioni e prenda meno decisioni da annullare. L’espressione è informale, ma l’esperienza che descrive si può misurare. Posso contare quante volte devo reindirizzare il modello, riparare il suo lavoro o rifiutare una patch che ha superato i test.

L’impressione diventa così una serie di domande concrete. Il modello ha tenuto presenti tutti i vincoli, preso decisioni sensate per questo repository ed evitato modifiche non correlate? Quando ha fallito, il problema era facile da riconoscere e annullare? Un singolo tasso di successo non può rispondere a queste domande.

Quanto può influire la configurazione sul punteggio?

Negli esempi pubblicati qui sotto, modificare la configurazione del benchmark ha spostato i punteggi da circa 5 a 15 punti percentuali senza cambiare il modello [6] [7]. È più del divario di 2,2 punti tra Luna e Sol. Un benchmark di programmazione non misura solo il modello, ma anche il prompt, gli strumenti, i limiti di esecuzione, il numero di tentativi e il valutatore.

Il paper SWE-agent pubblicato da NeurIPS offre un esempio chiaro. Con lo stesso GPT-4 Turbo su SWE-bench Lite, un’interfaccia limitata alla shell ha risolto l’11% dei task, mentre l’interfaccia completa di SWE-agent ne ha risolti il 18% [6]. Quando i ricercatori hanno sostituito i risultati di ricerca ripetuti con uno strumento che li riassumeva, il punteggio è salito dal 12% al 18%. Limitare il visualizzatore a 100 righe invece di restituire un file intero ha portato il punteggio dal 12,7% al 18%. Queste modifiche all’interfaccia hanno aggiunto da cinque a sette punti percentuali senza cambiare il modello.

Il numero di tentativi può cambiare ancora di più il dato principale. Sei esecuzioni della stessa configurazione GPT-4 e SWE-agent hanno ottenuto in media il 17,94% al primo tentativo. Contando un task come risolto quando almeno uno dei sei tentativi riusciva, la copertura saliva al 32,67% [6]. L’aumento di 14,73 punti può essere utile se un sistema di produzione genera davvero sei candidati e sa identificare quello corretto. È fuorviante quando compare accanto a un risultato a tentativo singolo senza un’etichetta chiara.

Anche l’infrastruttura può aggiungere rumore. Anthropic ha mantenuto costanti il modello Claude, l’harness e i task di Terminal-Bench 2.0, poi ha cambiato i limiti di CPU, memoria e durata. La configurazione senza limiti rigidi ha ottenuto circa sei punti percentuali in più, mentre gli errori dell’infrastruttura sono scesi dal 5,8% allo 0,5% [7]. Una riga della leaderboard va quindi letta come il risultato di un sistema testato, non come un numero permanente legato al nome del modello.

Le quattro modifiche qui sotto hanno spostato i punteggi più del divario principale tra Luna e Sol.

Modifica al sistema	Prima	Dopo	Variazione
Solo shell → interfaccia SWE-agent	11,0%	18,0%	+7,0 pp
File intero → vista di 100 righe	12,7%	18,0%	+5,3 pp
Uno → sei tentativi	17,94%	32,67%	+14,73 pp
Limiti rigidi → senza limiti	Non pubblicato	Non pubblicato	circa +6 pp

Questo non rende inutili i benchmark, ma rende la configurazione parte del risultato. Prima di confrontare due punteggi, controllo che usino la stessa versione dei task, la stessa configurazione dell’agente, le stesse risorse, lo stesso numero di tentativi e la stessa regola di valutazione.

Perché una patch che supera i test può fallire la code review?

Superare un benchmark significa che una patch ha superato i controlli del benchmark. È un’indicazione utile del fatto che il codice funziona, ma non equivale a una code review. I controlli possono non rilevare una correzione incompleta e potrebbero ignorare la manutenibilità, la compatibilità con l’architettura esistente, le modifiche non correlate o il lavoro necessario prima del merge.

Il paper EvalPlus pubblicato da NeurIPS ha mostrato quanto i test scelti possano influenzare il risultato. I ricercatori hanno ampliato di circa 80 volte le suite di test di HumanEval e valutato 26 modelli. Con i test più rigorosi, i tassi di successo dei modelli più colpiti sono diminuiti da 19,3 a 28,9 punti percentuali e alcune classifiche si sono invertite [8]. Le risposte non erano cambiate; le suite più grandi hanno semplicemente rilevato più errori.

I benchmark basati sui repository hanno lo stesso problema. Nel febbraio 2026, OpenAI ha controllato 138 task di SWE-bench Verified che o3 falliva in modo incoerente in 64 esecuzioni. Ha trovato problemi sostanziali nel 59,4% del gruppo selezionato, inclusi test che rifiutavano soluzioni valide e test che richiedevano comportamenti non menzionati nella issue [9]. L’audit si concentrava deliberatamente su task sospetti, quindi il 59,4% non descrive tutti i 500 task. Mostra però che errori nei task e nei test possono alterare le differenze tra modelli molto capaci.

L’errore opposto conta altrettanto: una patch può superare i test automatici e non essere pronta per il merge. METR ha chiesto ai maintainer di esaminare 296 pull request generate dall’AI in tre repository e 95 task. Il loro tasso di accettazione era inferiore di 24,2 punti percentuali rispetto al punteggio automatico di SWE-bench [10]. Hanno rifiutato patch per problemi nella funzione principale, rotture non correlate, scarsa qualità del codice e altri difetti di integrazione. Un punteggio binario nasconde tutte queste ragioni dietro la stessa etichetta di “successo” o “fallimento”.

più test in EvalPlus

80×

alcune classifiche si sono invertite

problemi in un audit mirato

59,4%

non rappresentativo di tutti i 500 task

divario rispetto ai maintainer

24,2 pp

METR ha esaminato 296 pull request

Insieme, questi risultati mostrano che la qualità dei test e la revisione umana rispondono a domande diverse. “La patch ha superato i test” resta un’informazione utile, ma non mi dice se voglio che quel modello modifichi ogni giorno il mio branch.

Che cosa nasconde una media? Ripetibilità e task lunghi

Un tasso medio combina tutti i successi e i fallimenti in un solo numero. Non mostra se il modello riesce con costanza, se l’affidabilità cala nei task più lunghi o se un’esecuzione fallita produce un piccolo diff sbagliato oppure danneggia lo stato di lavoro. Queste differenze contano quando uso il modello più volte invece di provarlo una sola volta.

Il paper tau-bench pubblicato su arXiv rende visibile il problema della ripetibilità con pass^k, che verifica se un agente completa lo stesso task ogni volta in più prove. GPT-4o ha ottenuto il 61,2% nei task retail in una singola prova, ma il suo pass^8 retail è sceso sotto il 25% [11]. Un modello che funziona tre volte e fallisce alla quarta può comunque mantenere una media rispettabile. Come collaboratore quotidiano, sembra imprevedibile.

La lunghezza del task crea una differenza simile. METR ha valutato gli agenti su 170 task con circa otto esecuzioni per ogni coppia modello-task. La durata dei task che un modello risolveva nell’80% dei casi era da quattro a sei volte inferiore al suo orizzonte di successo al 50% [12]. Un modello può quindi ottenere credito per task impegnativi di due ore alla soglia del 50%, pur restando affidabile solo su lavori molto più brevi.

Questo aiuta a spiegare perché le impressioni nate dall’uso diretto possono divergere da una leaderboard. Il lavoro quotidiano comprende task ripetuti, contesto del repository facile da ignorare, comandi non riusciti, requisiti ambigui, cicli di revisione e le conseguenze dei peggiori tentativi falliti. Anche le impressioni personali possono essere sbagliate, perché una risposta ben presentata o un solo fallimento disastroso possono dominare la memoria. Invece di scegliere tra benchmark e intuizione, devo misurare le parti del mio flusso di lavoro che hanno creato quell’impressione.

Come confronto i modelli per il mio lavoro?

Uso i benchmark pubblici come filtro. Mi dicono quali modelli vale la pena provare, e un benchmark controllato come DeepSWE offre informazioni molto migliori rispetto a una demo di lancio. La scelta finale dipende comunque da una piccola valutazione costruita sul mio lavoro.

Anthropic consiglia di iniziare la valutazione di un agente con un gruppo da 20 a 50 task ricavati dai controlli manuali, dai fallimenti comuni, dai bug report e dalle richieste degli utenti già emerse durante lo sviluppo [13]. Sono sufficienti per rivelare grandi differenze senza fingere di produrre una leaderboard universale. Per un confronto serrato, eseguirei gli stessi task più di una volta mantenendo fissi ambiente, strumenti, prompt, livello di effort e budget.

Prima di guardare gli output, definirei che cosa significa accettare il risultato. I test vengono prima, ma non sono l’intero criterio. Registrerei anche:

• l’accettazione del risultato al primo tentativo;
• il tempo totale per arrivare a un risultato accettato, inclusi revisione e riparazione;
• i minuti di revisione attiva invece della sola latenza del modello;
• il numero di chiarimenti, correzioni di rotta, riavvii e modifiche manuali;
• i file cambiati senza motivo e le violazioni delle convenzioni del repository;
• i fallimenti gravi, come regressioni di sicurezza, rischio di perdita dei dati o rotture non correlate;
• i token e il costo API per l’intero risultato accettato.

Per valutare la qualità del codice, nasconderei i nomi dei modelli e rivedrei le patch concorrenti in ordine casuale quando possibile. Riporterei i risultati per tipo di task invece di sommare correzioni di bug, revisioni, refactoring e feature lunghe in un unico totale. Se due modelli restassero vicini dopo più prove, sceglierei quello meno costoso. Se però il maggiore costo di revisione assorbisse il risparmio sull’API, non sarebbe il modello più economico per il mio flusso di lavoro.

DeepSWE ha fatto abbastanza per inserire Luna Max nella mia lista di modelli da provare. Nel prossimo confronto manterrei fissi task e strumenti, poi conterei l’intero percorso fino a una patch accettata: indicazioni, revisione, riparazioni e tentativi falliti. Se il prezzo API più basso di Luna resiste a questi costi, è più economica per il mio lavoro. Altrimenti, il prezzo della leaderboard non è quello che pago.