Valutare un LLM prima di adottarlo: checklist su benchmark, data leaking e chatbot Arena

Il 31 marzo 2026 ho ricevuto la proposta di un vendor per sostituire il modello backbone del sistema di estrazione documentale nella mia pipeline personale di automazione AI. La tabellona comparativa metteva affiancati otto modelli con percentuali da capogiro: 92,3% su MMLU, 88,1% su HumanEval, 76% su GPQA. Le fonti? Un mix di pagine marketing, qualche screenshot di leaderboard non datato, e due valori presi da blog post aggregati senza metodologia dichiarata. Ho chiesto due cose: con quale protocollo di evaluation, e su quale data cutoff. Il vendor non ha saputo rispondere. Lì si è chiusa la valutazione. Otto criteri operativi che ho distillato dopo anni di questi scambi e che oggi uso come prima pagina di qualsiasi valutazione LLM seria prima di un commitment enterprise.

Cosa sta misurando davvero un benchmark pubblico nel 2026?

Un benchmark è un insieme di domande con risposte attese, usato per stimare la capacità di un modello su un task. Il benchmarking è il confronto sistematico fra modelli usando lo stesso benchmark. Fin qui la teoria. La pratica 2026 è che le percentuali che leggi sulle pagine marketing non sono confrontabili se non sono accompagnate da cinque variabili esplicite: numero di shot, eventuale chain-of-thought, temperature, data cutoff del modello, versione esatta del benchmark. Cambiarne una vuol dire cambiare il numero senza cambiare il titolo.

Il benchmark più citato in assoluto è MMLU, introdotto nel paper Measuring Massive Multitask Language Understanding di Hendrycks et al. (2020): 57 materie, domande a scelta multipla, protocollo originale 0-shot o 5-shot. Stanford CRFM ha dovuto pubblicare HELM MMLU nel 2024 proprio perché i vendor stavano riportando MMLU con protocolli non standard. L'episodio più citato è il blog post di Google su Gemini Ultra, dove il 90,04% dichiarato era ottenuto con "Chain-of-Thought with uncertainty routing" confrontato contro il 5-shot regolare di GPT-4 (83,7%): confronto tecnicamente corretto nei numeri, editorialmente ingannevole nel mettersi uno accanto all'altro. La morale operativa: se non è scritto il protocollo, il numero non vale.

Criterio 1: Il benchmark è noto, documentato e riproducibile?

Chiedi al fornitore il nome esatto del benchmark, la versione (MMLU standard vs MMLU-Pro vs MMLU-Redux), il numero di shot, il protocollo di scoring (esatto, inclusivo, chain-of-thought). Se la risposta non occupa almeno quattro righe, il numero è irriproducibile e quindi inutile.

Criterio 2: Data cutoff del modello vs data di pubblicazione del benchmark

Il data leaking (o data contamination) è quando il test set finisce nei dati di training. Invalida tutti i numeri. Il paper How Much Can We Forget about Data Contamination? presentato a ICML 2025 ha mostrato un risultato contro-intuitivo: se il modello è ampiamente "overtrained" (sopra cinque volte la soglia Chinchilla), anche 144 esposizioni al test set vengono "dimenticate". Sembra una buona notizia; non lo è. Vuol dire che le garanzie di contamination-free si sono spostate su un regime pratico che solo i foundation lab conoscono davvero. Per una PMI il criterio operativo resta il vecchio: se il benchmark è stato pubblicato prima del cutoff del modello, i risultati sono sospetti.

Il caso pubblico 2025 è Llama 4: allegation di uso di una variante non pubblica fine-tuned per benchmark gains, Meta ha negato, il dibattito è rimasto in piedi. Non c'è sentenza finale ma c'è un dato di fatto editoriale: nessun vendor è immune alla tentazione di pubblicare numeri per segnalare capacità.

Criterio 3: Il benchmark è adatto al TUO task?

MMLU misura conoscenza generale su 57 materie. HumanEval misura correttezza di codice Python su 164 problemi didattici. GSM8K misura aritmetica scolastica. GPQA Diamond misura reasoning su domande graduate level in biologia, fisica, chimica (198 questioni filtrate, paper Rein et al. 2023/2024). DROP misura comprensione testuale con aritmetica embedded.

Se il tuo task è classificazione di documenti legali italiani, nessuno di questi benchmark è rilevante. Un modello che eccelle su GPQA può fallire su un task di classificazione italiana perché il dominio è scollegato. Il benchmark pubblico ti dice qualcosa sulle capacità generali, non sulle capacità specifiche. Solo un held-out set costruito sul tuo dominio dà garanzie operative.

Se vuoi vedere come costruisco pipeline di evaluation interne con held-out set proprietari e governance dei costi, nel mio hub dedicato all'automazione AI trovi articoli tecnici con metodologia applicata e perimetro dichiarato.

Criterio 4: Numero di shot dichiarato esplicitamente

Zero-shot, one-shot, few-shot cambiano le performance in modo significativo. Un modello base può passare dal 45% al 75% di accuracy su MMLU passando da 0-shot a 5-shot. Paragoni fra due numeri con shot diversi sono falsati in partenza. Regola pratica: quando un vendor riporta "88% su MMLU" senza specificare il numero di shot, non è un numero, è uno slogan.

Criterio 5: Pass@k o pass@1?

Sui benchmark di codice (HumanEval, MBPP, APPS) c'è la metrica pass@k: il modello ha k tentativi, la risposta è considerata corretta se almeno uno è giusto. pass@1 è il caso più stringente (un solo tentativo). pass@10 è molto più generoso; pass@100 è quasi inflazionato. Anche qui: senza la k dichiarata, il numero non è un numero.

Criterio 6: Chatbot Arena, ovvero il test nel mondo reale e i suoi limiti

LMArena (rebrandata ufficialmente in Arena il 28 gennaio 2026, ma la comunità usa ancora LMArena come shorthand) è la piattaforma di evaluation a voto anonimo su prompt utente reali. Sito: lmarena.ai. Metodologia: pairwise blind voting, modello Bradley-Terry, risultati riportati in scala Elo-like per familiarità. Ad aprile 2026 il Text Arena aveva accumulato oltre 5,78 milioni di voti su 339 modelli.

I pro: prompt reali di utenti reali, bassa contaminazione (prompt nuovi a ogni run), copertura di task aperti. I contro: voti non controllati, possibili bias per stile (risposte lunghe e polite vincono ingiustamente), attacchi di vote rigging documentati nella letteratura (paper Improving Your Model Ranking on Chatbot Arena by Vote Rigging). Arena Hard e Arena Expert filtrano i prompt più difficili (top 5,5% per Expert) producendo classifiche diverse. Se guardi solo l'overall rischi di scegliere il modello che vince sui prompt semplici e fallisce sui tuoi casi reali.

Criterio 7: Held-out interno sul TUO dominio

Questo è il criterio che fa la differenza tra valutazione seria e marketing. Costruisci un dataset di 200-500 esempi reali (anonimizzati) dal tuo dominio, con risposta attesa validata manualmente. Usalo come test set. Valuta ogni candidato modello con lo stesso protocollo (stesso system prompt, stessa temperature, stesso parser di output). Misura precisione, latenza, costo per chiamata.

Tre ore di lavoro serio su un held-out ti danno più informazioni di tre mesi di lettura di leaderboard pubblici. E ti immunizzano dal rischio di scegliere un modello che vince sui benchmark ma perde sul tuo caso d'uso.

Criterio 8: Latenza, costo, throughput: le variabili operative che nessun benchmark pubblico misura

Un modello con il 2% in più di accuracy ma il 300% in più di latenza non è migliore per una pipeline ad alto volume. Un modello con costo per milione di token quadruplo non è migliore per un chatbot in produzione. Artificial Analysis è una delle poche fonti 2026 che riporta simultaneamente quality, price, throughput e latency con metodologia pubblicata. È il punto di partenza per la dimensione operativa; va comunque incrociato con il tuo held-out perché la latenza dipende anche dalla lunghezza del tuo prompt tipico.

Tenete anche a mente che il tokenizer cambia il conto: come ho misurato per Claude Opus 4.7, il nuovo tokenizer produce mediamente il 35% di token in più sullo stesso testo italiano rispetto a 4.6. Un confronto "per milione di token" non è comparabile fra vendor che usano tokenizer diversi.

Pattern commerciali da cui diffidare in una proposta tecnica

Tre trappole che ricorrono nei preventivi italiani 2026.

Leaderboard mix-and-match. La tabella del fornitore ha MMLU 5-shot per modello A, MMLU 25-shot per modello B (che non esiste: 25-shot è ARC nell'Open LLM Leaderboard HF, non MMLU). L'errore può essere in buona fede o malafede; in entrambi i casi la tabella è invalidata.

Benchmark proprietari senza metodologia. "Il nostro modello ha il 94% sul nostro benchmark interno." Bello. Dov'è il protocollo? Dov'è il dataset? Dov'è il confronto riproducibile? Senza risposte è autorlog di marketing.

Riferimenti a Chatbot Arena senza data. Le classifiche Arena cambiano settimanalmente. "Il nostro modello è nella top 10" senza data è privo di contenuto. Chiedi sempre la data dello snapshot.

Mini case: come ho disallineato un vendor su numeri gonfiati

Un esempio concreto che racconto in aula quando discuto di evaluation con CTO PMI. Nel mio laboratorio di sperimentazione, a febbraio 2026, ho confrontato tre modelli su un held-out di 300 fatture elettroniche italiane scansionate a bassa risoluzione (una condizione reale, non da benchmark). Task: estrazione di sette campi strutturati.

Modello A, presentato dal vendor come "top MMLU 92%, top HumanEval 88%": sul mio held-out ha ottenuto F1 0,71 con latenza mediana 4,2 secondi.
Modello B, presentato come "il miglior open-weight europeo": F1 0,82, latenza 2,8 secondi.
Modello C, un Claude Sonnet 4.6 off-the-shelf con prompt caching e sei esempi few-shot: F1 0,91, latenza 1,9 secondi, costo leggermente superiore ma ampiamente compensato dal minor tempo di validazione umana a valle.

Il modello A aveva ottimi numeri sui benchmark generali e numeri mediocri sul mio task. Non era colpa del modello, era colpa dei benchmark generali come indicatore. Se avessi scelto in base alla tabella del fornitore avrei perso cinque mesi di progetto. L'held-out da 300 esempi mi ha fatto prendere la decisione giusta in sei ore di lavoro.

Questa è la differenza che separa un'evaluation responsabile da una commitment fidando sui colori di una tabella PowerPoint: sei ore di setup contro sei mesi di rework.

Errori più comuni quando si costruisce l'held-out

Quattro trappole che ho osservato ripetutamente.

Held-out troppo piccolo. Cinquanta esempi non bastano per stabilizzare la metrica. Con cinquanta esempi la varianza è tale che un modello con F1 0,82 e uno con 0,78 sono statisticamente indistinguibili. Minimo 200, meglio 500.

Esempi non rappresentativi. Se tutti i tuoi 300 esempi sono fatture di una stessa tipologia, il risultato si generalizza solo a quella tipologia. Devi coprire edge case (formati non standard, scanner di bassa qualità, dati corrotti) proporzionalmente a come si presentano in produzione.

Ground truth sporco. Se l'annotazione manuale dei tuoi 300 esempi è fatta in fretta, hai contaminato la metrica. Una revisione a quattro occhi su almeno il 20% del dataset è igiene minima.

Mescolare training e evaluation. Gli esempi che hai usato per il prompt few-shot NON possono essere nel tuo held-out. Sembra ovvio ma è uno degli errori più frequenti quando i dataset sono costruiti in fretta.

Come strutturare la fase di evaluation in un progetto PMI

Cinque step operativi che seguo in ogni progetto LLM che passa dal mio tavolo.

Primo step, definisci la metrica che conta per te. Precision sulla estrazione? Recall sul retrieval? F1 sulla classificazione? Tempo mediano di risposta? Costo per mille chiamate? Un progetto senza metrica dichiarata è un progetto senza fine-line.
Secondo step, costruisci l'held-out interno. Minimo 200 esempi, curati da una persona che conosce il dominio. Questa è la parte più faticosa e più preziosa.
Terzo step, seleziona i candidati con due filtri: un filtro "capacità generale" sui benchmark pubblici (senza fidarti troppo, solo per scartare modelli evidentemente sottodimensionati) e un filtro "economia" su Artificial Analysis per escludere modelli fuori budget.
Quarto step, valuta i 3-5 candidati rimasti sul tuo held-out con lo stesso protocollo. Registra tutto (prompt, output grezzi, errori, costo per chiamata, latenza). Questo è il tuo dataset di verità, da versionare in Git.
Quinto step, considera il trade-off operativo, non solo l'accuracy. Il modello migliore per il tuo progetto è quello che massimizza la tua metrica di business, non quello che vince i benchmark generali.

Valutare un LLM prima di adottarlo è un esercizio di rigore statistico che nel 2026 è alla portata di chiunque voglia farlo seriamente. Farlo non richiede un dottorato in ML; richiede disciplina nel costruire un held-out, nel fissare il protocollo, nel rifiutare di accettare percentuali senza metodologia. Il prezzo di saltare questo passaggio lo paghi sei mesi dopo, quando scopri che il modello che hai scelto "perché era in cima a MMLU" sbaglia il 30% delle fatture italiane con formato non standard. Se hai un progetto AI in fase di valutazione e vuoi costruire la pipeline di evaluation prima del commitment al vendor, il modulo di preventivo gratuito ti risponde in due minuti se il caso rientra nel mio ambito, oppure ti indirizza a figure più adatte. I benchmark pubblici sono una mappa, non il terreno; il terreno è il tuo held-out, e quello non lo costruisce nessuno al posto tuo.