Benchmark: come si misura un LLM (e come si bara)

Ogni volta che esce un nuovo modello arriva la stessa scena: una tabella con i punteggi, un paio di righe evidenziate in grassetto, il numero più alto della concorrenza. Poi lo provi sul tuo problema — un contratto da riassumere, un pezzo di codice legacy da capire — e la magia non c’è. Il modello che stracciava tutti sulla carta ora tentenna. Non è necessariamente pubblicità ingannevole. È il segno che i benchmark misurano qualcosa di più stretto di quello che promettono, e che quel qualcosa si può gonfiare in molti modi, alcuni innocenti e altri no.

Cosa misura davvero un benchmark

Un benchmark è un insieme fisso di domande con risposte note. MMLU raccoglie migliaia di quiz a scelta multipla su decine di materie; GSM8K propone problemi di aritmetica da scuola media; HumanEval chiede di scrivere piccole funzioni e le esegue per vedere se passano i test. Il modello risponde, si contano le risposte esatte, esce una percentuale. Comodo, riproducibile, confrontabile. E proprio per questo fragile.

Il primo limite è che un test fisso è una fotografia, non un ritratto in movimento. Somiglia a un esame di teoria per la patente: puoi rispondere perfettamente a tutti i quiz ministeriali e non saper parcheggiare. Le domande sono quelle, sempre quelle, pubblicate; misurano la capacità di rispondere a quelle domande, non di guidare nel traffico. Un modello può eccellere su GSM8K e inciampare su un problema di aritmetica appena riformulato, perché ha imparato la forma dei quiz più che il ragionamento sotto.

Quando una misura diventa un obiettivo, smette di essere una buona misura. La legge di Goodhart non risparmia nessuno, tantomeno un settore in cui la classifica vale miliardi.

La contaminazione: quando il test finisce nel training

Ecco il problema più insidioso, e spesso il meno intenzionale. I grandi modelli si addestrano su enormi quantità di testo prelevato dal web. Ma i benchmark vivono sul web: sono su GitHub, nei paper, nei forum, ripubblicati in mille tutorial. Così le domande d’esame, con le loro risposte, finiscono dentro i dati di addestramento. Il modello non ha imparato a risolvere il problema: lo ha già visto risolto. È lo studente che, il giorno prima dell’esame, trova il compito svolto e lo impara a memoria. Il registro dirà che è bravissimo; in realtà ha solo letto le risposte in anticipo. Questo fenomeno ha un nome tecnico — contaminazione dei dati — e basta a spiegare perché un punteggio altissimo possa convivere con una resa mediocre sul tuo caso reale, che nel test non c’era.

I dati di addestramento (terracotta) inghiottono quasi tutto il web; i benchmark (teal) vivono sul web. Nella zona di sovrapposizione (ocra) le domande d’esame entrano nel training: il modello le ha già viste, e il punteggio si gonfia.

Chi costruisce benchmark seri prova a difendersi. Un metodo diffuso è la stringa canarino: una sequenza casuale univoca inserita nel file del benchmark, con la richiesta esplicita di non addestrarci sopra. Se in seguito un modello riesce a completare quella stringa, sappiamo che il test è finito nei suoi dati. È un allarme antifurto, non un lucchetto: segnala l’effrazione, non la impedisce.

I modi per gonfiare un punteggio

Oltre alla contaminazione accidentale ci sono scelte più deliberate, e non tutte sono barare nel senso stretto: molte sono zone grigie di presentazione. Vale la pena conoscerle per leggere una tabella con l’occhio giusto.

• Addestrare sulla forma del test. Anche senza copiare le domande esatte, si può riempire il training di esercizi con lo stesso stampo. Il modello impara il genere «quiz a scelta multipla di fisica» e va meglio all’esame, senza essere più capace fuori.
• Scegliere i benchmark che convengono. Ne esistono decine. Mostrare solo i tre in cui il tuo modello brilla, e tacere i cinque in cui arranca, è tecnicamente vero e sostanzialmente fuorviante. Il grassetto sulla slide è una scelta editoriale, non un fatto neutro.
• Limare il prompt e il formato. Lo stesso modello può guadagnare punti solo cambiando l’ordine delle opzioni, il modo di chiedere, il numero di esempi mostrati prima. Confrontare il tuo modello ben calibrato con quello altrui misurato alla buona non è un confronto alla pari.
• Riportare il colpo migliore. Generare dieci risposte e tenere quella giusta («best-of-10») produce un numero più alto di quello che l’utente vedrà davvero, che riceve una risposta sola al primo tentativo.

Come leggere i benchmark da adulti

La reazione sbagliata è buttare via i benchmark: restano il modo meno peggiore che abbiamo per confrontare i modelli. La reazione giusta è smettere di trattarli come verdetti e iniziare a trattarli come indizi. Alcune bussole aiutano. Cerca test freschi, costruiti dopo l’addestramento del modello o tenuti privati: se un modello regge su domande mai pubblicate, il suo punteggio è più credibile. Diffida dei salti sospetti: quando un modello vola su un benchmark noto ma cade su una versione riscritta dello stesso compito, è la firma della contaminazione, non del talento. Preferisci le valutazioni con giudizio umano, dove persone reali confrontano due risposte alla cieca: sono più difficili da gonfiare di un quiz statico, anche se hanno rumore e mode loro.

Ma la bussola più affidabile è la meno citata: costruisci il tuo mini-benchmark privato. Venti o trenta esempi presi dal tuo lavoro reale — i tuoi contratti, il tuo codice, le tue email — tenuti fuori da internet, valgono più di qualsiasi classifica pubblica. Nessun laboratorio può contaminarli, perché non li ha mai visti. Ti dicono l’unica cosa che ti serve: come si comporta il modello sul problema che hai tu, non su quello che aveva chi ha stilato la tabella.

Perché ti riguarda

La prossima volta che leggi «il nostro modello supera tutti su MMLU», ora sai le domande da farti: questo test poteva essere nei dati di addestramento? Stanno mostrando i benchmark scelti o tutti? Il numero è al primo tentativo o al migliore di dieci? Non serve diventare cinici — serve smettere di comprare la classifica come fosse una pagella oggettiva. Un punteggio alto è una promessa, non una prova. La prova la fai tu, sui tuoi esempi, dopo. E se un modello mantiene la promessa proprio lì, sul lavoro che nessun benchmark aveva previsto, allora quel numero valeva qualcosa.