Benchmark di coding AI: come confrontare i risultati

In breve: la cifra «risolve il 76 percento dei task» da sola dice quasi nulla. Conta sapere quale insieme di task l’ha prodotta, quale modello e wrapper dell’agente sono stati valutati insieme, se i task sono recenti o vecchi e quanto è costato. Senza queste condizioni, la percentuale va bene per uno slogan pubblicitario, ma non per scegliere uno strumento.

Ora spiegherò in parole semplici che cosa misurano i due principali benchmark di programmazione, dove si nasconde l’inghippo nelle tabelle e come controllare qualsiasi classifica in un minuto prima di farci affidamento. Qui si discutono definizioni storiche dei benchmark. Non è riprodotto uno snapshot aggiornato di una classifica appaiata: punteggi o costi attuali richiedono una tabella collegata, data e configurazione proprie.

Scopri di più su come lavorare con i modelli nella documentazione di Ailoot.

Che cosa mostra davvero una percentuale di un benchmark?#

Il funzionamento di un benchmark è semplice. Esiste un elenco già pronto di task di programmazione. A ogni task viene sottoposto uno strumento, che restituisce del codice; il sistema esegue test automatici per verificare se la soluzione funziona. La quota di task superati è la percentuale mostrata nella tabella.

Il punto di forza è l’obiettività della valutazione. Un test è superato o non superato; nessuno assegna un punteggio «a occhio». Sotto questo aspetto, i benchmark sono più affidabili di qualsiasi recensione o testimonianza.

Il punto debole è proprio lo stesso. L’insieme di task è finito e noto in anticipo a tutti, compresi coloro che addestrano i modelli. Ogni misurazione ha le sue condizioni. E quasi certamente i task dell’insieme non somigliano a quelli che svolgi tu. Da qui derivano tutte le insidie di cui parlerò più avanti. La percentuale descrive il comportamento di uno strumento su un elenco chiuso di task di qualcun altro e non si trasferisce direttamente al tuo progetto.

Che cosa misura HumanEval e perché ormai non puoi più scegliere in base a questo benchmark?#

HumanEval è stato creato da OpenAI e pubblicato nel 2021 insieme al modello Codex. Contiene 164 piccoli task in Python: ai modelli viene fornita a parole la descrizione di una funzione, loro ne scrivono il corpo e una serie di test automatici verifica che funzioni correttamente.

All’epoca era un buon criterio per distinguere i modelli. Nel loro articolo, gli autori riportano questa cifra: il primo Codex risolveva il 28,8 percento dei task in un solo tentativo, mentre il normale GPT-3 non ne risolveva nessuno.

Da allora i modelli sono migliorati e oggi quelli più forti completano quasi tutto HumanEval. Quando tutti ottengono un punteggio vicino al 100 percento, la tabella smette di distinguere alcunché: le differenze tra gli strumenti scompaiono. Si parla di saturazione del benchmark, e HumanEval si trova in questo stato da molto tempo.

Il secondo difetto è più grave. I task sono minuscoli: scrivere una funzione partendo da una descrizione. Il lavoro reale è diverso: si lavora su un progetto grande e con una storia alle spalle, dove bisogna capire il codice scritto da qualcun altro, trovare un difetto ed evitare di rompere le parti adiacenti. Tra «scrivere una funzione da zero» e «correggere un bug in un progetto attivo» c’è un abisso. Perciò, oggi un punteggio alto a HumanEval non è più un motivo per scegliere uno strumento; è più che altro un segnale che «le basi ci sono».

Che cosa misura SWE-bench e in che modo è più vicino al lavoro reale?#

SWE-bench è fondamentalmente diverso e, proprio per questo, più interessante. È stato costruito a partire da issue e pull request reali in progetti GitHub popolari. Secondo i suoi autori, comprende 2.294 task provenienti da 12 grandi repository Python ed è stato pubblicato nell’ottobre 2023.

La logica di valutazione è oggettiva. Si prende un punto di un progetto in cui si era verificato un difetto reale e si usano i test che all’epoca fallivano. Allo strumento viene fornita la descrizione del problema e lo strumento modifica il codice. Poi vengono eseguiti gli stessi test: se passano, il task è stato davvero risolto; qui nessuno si fida delle promesse a parole.

Le prime cifre mostrano quanto sia più difficile rispetto ai task giocattolo. Il primo approccio di riferimento ha ottenuto appena l’1,96 percento a SWE-bench, mentre il primo agente ha raggiunto il 12,47 percento. In altre parole, anche avvicinarsi al lavoro reale di programmazione era difficile; in seguito le percentuali sono cresciute, ma erano partite da quasi zero.

Perciò, quando oggi vedi cifre elevate in una classifica di agenti di programmazione con l’IA, nella maggior parte dei casi provengono da SWE-bench o dal suo sottoinsieme di 500 task verificati da persone, chiamato SWE-bench Verified. È un benchmark ragionevole. Ma anche questo ha condizioni senza le quali la percentuale è fuorviante, e ne parlerò tra poco.

Anche il benchmark più onesto di una tabella non è ancora un risultato sul tuo progetto. L’esito dipende da come lavori con lo strumento, e la posizione in cima alla classifica conta ben poco. Per lavorare in modo affidabile, conta la combinazione: clone AI, Second Brain e ingegneria del contesto. Un contesto pulito migliora il tuo tasso di successo personale in modo molto più evidente che scegliere un modello da una tabella.

Perché lo stesso modello ottiene percentuali diverse?#

È qui che si nasconde l’errore più comune quando si leggono i benchmark. Si legge una tabella come una classifica di modelli: questo modello è più intelligente di quell’altro del due percento. Ma la percentuale dipende da tre fattori, e il modello è solo uno di questi.

Primo, il modello stesso. Secondo, il wrapper dell’agente che lo circonda: un programma che permette al modello di esplorare i file, eseguire comandi, leggere gli errori e riscrivere il codice. Lo stesso modello in un wrapper intelligente e in uno semplice ottiene risultati diversi, perché il wrapper determina il modo in cui lavora sul progetto. Terzo, il livello di ragionamento, cioè la profondità con cui il modello valuta ogni passaggio. Più a lungo ragiona, in genere più alta è la percentuale, ma anche il costo aumenta.

Un confronto riproducibile conserva la configurazione completa. Usa questa struttura come modello di rendicontazione, non come classifica misurata:

Così puoi capire cosa sia cambiato e se il confronto isoli davvero il ragionamento. Il precedente esempio numerico senza collegamento non viene trattato come un risultato misurato.

La regola è questa: una buona classifica specifica sempre quale modello, quale wrapper e quale livello di ragionamento sono stati usati. Se la tabella riporta solo il nome del modello e una percentuale, senza indicare il wrapper, è difficile fidarsi: non sai che cosa sia stato effettivamente misurato. L’articolo sulla classifica degli agenti di programmazione con l’IA spiega meglio che cosa comprende la combinazione «modello più wrapper».

Questo spiega anche perché uno strumento con un punteggio massimo a volte fa fatica con il tuo lavoro. Il benchmark misura un modello all’interno del wrapper ottimizzato di qualcun altro, su task di qualcun altro. Il tuo wrapper, il tuo progetto e il contesto che fornisci al modello sono diversi. Nel tuo progetto, il risultato dipende dal contesto; la riga della tabella viene dopo.

Perché i task «scadono» e che cos’è la contaminazione dei dati di addestramento?#

Ecco l’inghippo, invisibile nella cifra stessa, che la compromette più di qualsiasi altro fattore. I modelli vengono addestrati su enormi quantità di testi e codice raccolti su Internet. E quasi tutti i benchmark di programmazione sono pubblici: task, test e soluzioni di riferimento.

Il meccanismo è semplice. Se un task e la sua soluzione corretta sono finiti nei dati di addestramento, il modello potrebbe averli memorizzati. Durante la valutazione, quindi, invece di risolvere davvero il task, recupera dalla memoria una risposta che gli è familiare. Sembra una soluzione, ma è soltanto un ricordo. Si parla di contaminazione dei dati o leakage nell’addestramento.

Più l’insieme di task è vecchio e popolare, maggiore è il rischio. HumanEval è online dal 2021; è stato riscritto, analizzato e incluso innumerevoli volte in altrettanti dataset. Sarebbe strano aspettarsi che un modello moderno non lo abbia «già visto». Per questo l’attualità dei task è un indicatore di qualità distinto per un benchmark. Un buon insieme viene aggiornato regolarmente oppure mantiene alcuni task chiusi, così non possono essere imparati in anticipo.

Che cosa devi fare quando leggi una classifica? Controlla la data dei task e se l’insieme viene aggiornato. Un benchmark costruito a partire da difetti recenti degli ultimi mesi merita più fiducia. Se invece usa un insieme di cinque anni fa, una percentuale alta dice più della buona memoria del modello che della sua capacità di risolvere un tuo nuovo task. Questo effetto preciso è mostrato con un esempio concreto nell’articolo sul benchmark FrontierCode recente, i cui task erano stati creati appositamente da poco.

Perché una differenza di un paio di punti percentuali spesso non significa nulla?#

Un altro fattore che rende fuorviante il primo posto di una tabella: un modello non risponde sempre nello stesso modo. A parità di prompt, può seguire un ragionamento leggermente diverso. Perciò, se esegui più volte uno strumento sullo stesso insieme di task, la percentuale oscilla un po’ da un’esecuzione all’altra: questa oscillazione si chiama variabilità.

La conseguenza pratica è semplice. Quando due righe in classifica differiscono di uno o due punti percentuali, quella differenza potrebbe facilmente essere rumore. Inseguire uno strumento che è «più alto del due percento» è sciocco: alla prossima esecuzione potrebbero facilmente scambiarsi di posto. Una differenza merita di essere considerata significativa quando è evidente e si mantiene su un ampio insieme di task; un paio di punti non bastano.

E l’ultimo fattore, quasi sempre più importante della percentuale stessa, è il prezzo. Risultati simili possono costare cifre molto diverse. Un confronto dei costi richiede entrambe le configurazioni modello-harness e la spesa completa sul set di valutazione, compresi i fallimenti. Dividi per i tentativi per il costo per attività tentata, oppure per i successi per il costo per attività risolta, indicando il denominatore. Qui non è fornita una misurazione appaiata documentata dei costi. Quindi leggi sempre una riga della classifica insieme al suo prezzo, perché la percentuale da sola significa poco. L’articolo sul costo di un task risolto spiega come confrontare correttamente gli strumenti in base al costo.

Come puoi leggere qualsiasi tabella di benchmark in un minuto?#

Riassumo tutto in una breve lista di controllo. Apri una qualsiasi tabella di classifica e considera questi sette punti, nell’ordine indicato.

1. Quale insieme di task? Oggi HumanEval è poco utile; SWE-bench è più vicino al lavoro reale. Se l’insieme non è neanche nominato, non serve continuare a leggere.
2. I task sono recenti o vecchi? Un insieme recente o parzialmente chiuso è più affidabile di uno vecchio e pubblico che il modello potrebbe aver imparato.
3. Quale modello è stato misurato? Il nome e la versione esatti, non un vago «IA» o il nome di una famiglia di modelli.
4. Quale wrapper dell’agente? La percentuale riguarda la combinazione «modello più wrapper». Se il wrapper non è specificato, non sai che cosa sia stato misurato.
5. Quale livello di ragionamento? Uno stesso modello a livelli diversi dà percentuali e costi diversi.
6. Quanto costa un task? A risultati simili possono corrispondere prezzi molto diversi. Leggi la percentuale insieme al costo.
7. Qual è la variabilità? Una differenza di uno o due punti tra le righe spesso è solo rumore.

C’è un’ottava domanda, che riguarda te: I task dell’insieme somigliano al tuo lavoro? Un benchmark di task Python dice poco a chi crea un sito o un bot usando strumenti diversi. Neanche una cifra onesta ottenuta sui task di qualcun altro garantisce risultati sul tuo progetto. C’è un solo modo affidabile di verificarlo: fare eseguire allo strumento un paio di task tipici e valutare personalmente il risultato. L’articolo su come verificare il codice generato dall’IA spiega come capire se il codice funziona anche se non programmi.

Quindi, che cosa dovresti considerare alla fine?#

Il punto principale dell’intero articolo è breve: un posto in classifica è un motivo per esaminare meglio uno strumento, ma il resto lo devi approfondire tu. Una cifra elevata dice soltanto che lo strumento ha ottenuto buoni risultati su uno specifico elenco chiuso di task e in condizioni specifiche. La percentuale non indica se quelle condizioni corrispondono alle tue.

Quindi leggi quello che si trova sotto la riga della classifica: quali task, quanto sono recenti, quale combinazione di modello e wrapper è stata usata, quale livello di ragionamento, quanto costa e se la differenza si perde nel rumore. Una tabella che non risponde a queste domande è materiale da slogan pubblicitario. La recensione quale strumento usare per programmare nel 2026 spiega quale strumento scegliere per i tuoi task.

Ecco che cosa conta più di qualsiasi benchmark. Anche lo strumento migliore in classifica fatica con un contesto disordinato e lavora bene con un contesto pulito. Il tuo tasso di successo personale dipende da ciò che fornisci al modello e da come imposti il task; la riga della tabella viene dopo. La classifica aiuta a escludere le opzioni chiaramente deboli, ma il risultato lo produci tu.

La posizione in classifica permette di escludere le opzioni deboli, ma i risultati sul tuo progetto dipendono dal metodo: clone AI più Second Brain più ingegneria del contesto.

Per continuare a lavorare, Ailoot.