Benchmark LLM: capire le classifiche (MMLU, Arena, SWE-bench)

#Perché i benchmark contano (e ti ingannano)

Un benchmark LLM è un insieme di domande di cui si conoscono le risposte, che si pongono a un modello per contare a quante risponde correttamente. Il risultato è un punteggio — una percentuale, una classifica Elo, un tasso di risoluzione. È l'unico linguaggio comune che permette di confrontare due modelli senza testarli personalmente per ore, e per questo motivo tutti se ne servono.

Il problema non è il principio, ma lo scarto tra ciò che indica il punteggio e ciò che tu vi leggi. Un modello che ottiene il 90% su MMLU non è «intelligente al 90%»: risponde correttamente al 90% delle domande di un test a risposta multipla di cultura accademica. Questo non dice nulla sulla sua capacità di seguire le tue istruzioni, di scrivere in francese corretto, di non generare allucinazioni nel tuo settore o di sostenere una conversazione di dieci turni. Un benchmark misura una competenza circoscritta in condizioni di laboratorio.

I benchmark si possono raggruppare in tre grandi famiglie, che misurano cose diverse e non si manipolano allo stesso modo: i benchmark accademici (questionari a scelta multipla su conoscenze e ragionamento), i benchmark basati su compiti reali (risolvere un vero bug, usare strumenti) e le arene delle preferenze umane (le persone votano per la risposta migliore). Li esamineremo in quest'ordine.

#I benchmark accademici: MMLU, GPQA, MATH

È la famiglia storica, quella delle tabelle dei punteggi che si vedono sulle pagine di presentazione dei modelli al momento del rilascio. Sono insiemi di domande con risposte verificabili, spesso a scelta multipla, valutate automaticamente. La loro forza è la riproducibilità; la loro debolezza è che sono facili da saturare e contaminare.

MMLU

Massive Multitask Language Understanding: circa 14.000 domande a risposta multipla distribuite su 57 materie (diritto, medicina, storia, matematica…). Il benchmark di conoscenza più citato. Oggi ampiamente saturo: i buoni modelli superano l'88-90 %, e le differenze tra loro rientrano nel rumore delle misurazioni.

MMLU-Pro

Versione più impegnativa di MMLU: 10 opzioni di risposta invece di 4, domande selezionate nuovamente per aumentarne la difficoltà, più ragionamento. Creata proprio perché MMLU non distingueva più i modelli migliori.

GPQA (Diamond)

« Google-Proof Q&A »: domande di livello dottorale in biologia, fisica e chimica, concepite in modo che una ricerca su Google non sia sufficiente. Il sottoinsieme « Diamond » è il più difficile. Un buon indicatore del ragionamento scientifico di punta.

MATH / AIME

Problemi di matematica (MATH: livello liceo/concorsi; AIME: olimpiadi americane). Risposta numerica unica, quindi facile da valutare. È diventato un indicatore dei modelli «di ragionamento» (reasoning), che ragionano in più fasi.

IFEval

Misura la capacità di SEGUIRE istruzioni verificabili (« rispondi con esattamente 3 punti elenco », « non usare la lettera e »). Spesso è più indicativo per un uso reale di un quiz a scelta multipla sulle conoscenze.

HLE (Humanity's Last Exam)

Benchmark recente e volutamente estremo: domande specialistiche in più ambiti, pensate per rimanere difficili a lungo. Anche i migliori modelli raggiungono ancora punteggi bassi, il che lo rende un buon indicatore per distinguere le loro prestazioni nel 2026.

#I benchmark di compiti reali: SWE-bench e gli agenti

Questa famiglia è più recente e molto più difficile da manipolare, perché non pone domande: chiede di svolgere un'attività completa il cui risultato è verificabile oggettivamente. Risolvere un vero ticket GitHub, far superare una suite di test, navigare in un repository di codice. Ne parliamo in dettaglio nella nostra guida dedicata ai benchmark di codice; ecco l'essenziale.

SWE-bench Verified

Un sottoinsieme di 500 problemi reali su GitHub (issue + patch attesa), verificati manualmente da OpenAI come risolvibili e ben specificati. Il modello deve produrre una patch che faccia superare i test del repository. È diventato LO standard per il codice in condizioni reali, molto più indicativo di HumanEval (oggi saturo al 96-98 %).

SWE-bench (full / Lite)

La versione completa (~2.300 task) e una versione alleggerita per iterare rapidamente. I punteggi pubblicati dipendono moltissimo dall’« harness » (l’agente che orchestra il modello): lo stesso modello può guadagnare 15 punti a seconda degli strumenti che lo affiancano.

Tau-bench / benchmark agentici

Benchmark di agenti che utilizzano strumenti (chiamate di funzioni, API, rispetto delle regole aziendali) su più turni. Misurano l'affidabilità nell'uso come «assistente che agisce», non soltanto come assistente che risponde.

LiveCodeBench

Problemi di programmazione competitiva raccolti continuamente, con una data di pubblicazione. È possibile valutare soltanto i problemi successivi alla data di addestramento di un modello — un antidoto diretto alla contaminazione.

#LMArena: il ranking per preferenza umana

LMArena (ex « Chatbot Arena » di LMSYS) funziona in modo diverso: due modelli anonimi rispondono alla stessa domanda posta da un utente reale, che vota per la risposta migliore. A partire da milioni di scontri, si calcola un punteggio Elo (lo stesso sistema degli scacchi). È il benchmark più vicino a « quale modello gli utenti preferiscono davvero? »

Cosa misura bene

La qualità percepita in una conversazione libera: tono, struttura, utilità complessiva, capacità di dare una risposta piacevole. È strettamente correlata alla soddisfazione nell'uso reale.

Ciò che misura male

L'accuratezza fattuale. Chi vota premia spesso risposte lunghe, ben formattate e dal tono sicuro, anche quando sono false. Un modello «compiacente» può salire in classifica senza essere più accurato.

Elo non è una percentuale

Una differenza di 10-20 punti Elo è rumore statistico. Guarda sempre l'intervallo di confidenza mostrato: due modelli possono essere 'in parità' anche se non si trovano sulla stessa riga della tabella.

Le classifiche per categoria

LMArena propone categorie (codice, matematica, risposte lunghe, stile controllato). La classifica specifica «hard prompts» o «style control» è spesso più informativa della classifica generale, che mescola tutto.

#La trappola n. 1: la contaminazione dei dati

La contaminazione è quando le domande di un benchmark (o le loro risposte) finiscono, volontariamente o no, nei dati di addestramento del modello. Il modello non ragiona più: ripete. I benchmark pubblici circolano sul web, su GitHub, Hugging Face — finiscono meccanicamente nei corpus di pre-addestramento. Risultato: un punteggio inflazionato che non prevede nulla per domande nuove.

È il punto debole di tutti i benchmark statici e pubblici. Più un benchmark è vecchio e famoso, maggiore è il rischio. Alcuni segnali che devono mettere in allerta:

Differenza tra versioni

Un modello che ottiene ottimi risultati su MMLU ma crolla su MMLU-Pro (stesse materie, domande nuove) fa pensare più alla memorizzazione che alla comprensione.

Punteggio insolitamente alto rispetto alle dimensioni

Un piccolo modello 7B che batte modelli 70B su UN benchmark specifico e soltanto su quello: diffida, spesso si tratta di un addestramento mirato («benchmaxxing») su quel set di test.

Benchmark con data associata

Le valutazioni «live» (LiveCodeBench, domande con indicazione di data e ora) aggirano il problema: si valuta solo ciò che è successivo alla data limite dei dati di addestramento del modello.

Vuoti di memoria sospetti

Alcuni test inseriscono varianti sentinella («canary strings») o riformulazioni per rilevare la recitazione di risposte memorizzate. Un grande divario tra la domanda originale e quella riformulata rivela la contaminazione.

#La trappola n. 2: la saturazione

Un benchmark è saturo quando i migliori modelli raggiungono punteggi così elevati da non poterli più distinguere. Quando tutti sono a 96-99 %, i 3 punti rimanenti sono rumore di misura (domande ambigue, errori di etichettatura) piuttosto che una vera differenza di capacità. HumanEval (codice) e MMLU (conoscenza) sono gli esempi canonici: sono stati molto utili, non lo sono più per distinguere il top del ranking.

È per questo che compaiono continuamente nuovi benchmark più difficili: MMLU-Pro sostituisce MMLU, GPQA Diamond e HLE subentrano per il ragionamento, SWE-bench Verified sostituisce HumanEval per il codice. Un benchmark ha una vita utile; una volta superato un certo livello medio, devi eliminarlo dai tuoi criteri decisionali.

#Leggere una classifica senza farsi ingannare

Ecco il metodo da applicare a qualsiasi tabella di punteggi, che provenga da un comunicato relativo a un modello o da una classifica pubblica.

1. 01
   Identifica chi pubblica

   Un grafico nell'annuncio di un modello è marketing: sceglie i benchmark favorevoli e il protocollo vantaggioso (cherry-picking). Un leaderboard esterno e neutro (Open LLM Leaderboard, LMArena, la pagina ufficiale di SWE-bench) è molto più affidabile di una slide di lancio.
2. 02
   Verifica il protocollo

   0-shot o few-shot? Con chain-of-thought? Con quale harness per i sistemi agentici? Due punteggi sono confrontabili solo se il metodo è identico. Un asterisco «self-reported» (autodichiarato) vale meno di un punteggio riprodotto da un terzo.
3. 03
   Guarda gli intervalli di confidenza

   Su LMArena, una differenza Elo inferiore a circa 15 punti è rumore. Nei benchmark con un campione ridotto (GPQA Diamond, 198 domande), una manciata di risposte corrette sposta il punteggio di diversi punti. Una classifica senza margine di errore va presa con cautela.
4. 04
   Confronta diversi benchmark

   Non prendere mai una decisione basandoti su un solo valore. Un modello solido ottiene buoni risultati su una serie di test diversi, non soltanto un singolo picco. Un picco isolato e anomalo suggerisce piuttosto un'ottimizzazione mirata.
5. 05
   Pondera in base al TUO uso

   Scrivi codice? Guarda SWE-bench e LiveCodeBench, non MMLU. Usi il francese? Nessuno di questi benchmark è in francese: cerca valutazioni in francese o fai delle prove tu stesso. Ti interessa la conversazione? LMArena ha la precedenza. Il modello migliore «in media» non è necessariamente il migliore per te.

#Valutare un modello locale sulle tue attività

La conclusione logica di tutto ciò che precede: il benchmark più affidabile per te è il tuo. Non può essere contaminato (le tue domande non sono sul web), non raggiunge mai la saturazione (lo calibri sui tuoi casi difficili) e misura esattamente ciò di cui hai bisogno. Non serve un'infrastruttura pesante: una ventina di esempi rappresentativi basta per scegliere tra due modelli.

1. 01
   Crea un piccolo insieme di test

   Raccogli da 15 a 30 prompt tratti dai tuoi reali casi d'uso (email da scrivere, estrazioni, domande sui tuoi documenti, frammenti di codice). Per ciascuno, annota cosa deve contenere una buona risposta. Mantieni questo insieme privato e invariato per confrontare i modelli nel tempo.
2. 02
   Installa i modelli da confrontare

   Con Ollama, scarica i modelli candidati. Ollama espone un'API compatibile con OpenAI su http://localhost:11434, il che permette di automatizzare le chiamate.
3. 03
   Automatizza le chiamate

   Un piccolo script scorre i tuoi prompt e registra le risposte di ogni modello una accanto all'altra, in un file, per confrontarle a freddo senza lasciarti influenzare dal nome del modello.
4. 04
   Valuta alla cieca

   Rileggi le risposte senza sapere quale modello abbia prodotto cosa (mescola l'ordine). Assegna un punteggio secondo i tuoi criteri: esattezza, rispetto delle istruzioni, qualità del francese, assenza di invenzioni. È la tua «Arena» personale.
5. 05
   Misura anche il costo reale

   La qualità non basta: annota la velocità (token/secondo) e la VRAM consumata. Un modello da 14B in Q4_K_M (~9 GB) che rientra nella memoria della tua RTX 4070 e risponde velocemente può superare un 70B (~40 GB) teoricamente «migliore» ma inutilizzabile sulla tua macchina.

# Récupérer deux candidats via Ollama
ollama pull qwen3:14b
ollama pull gemma3:12b

# Vérifier qu'ils répondent (API locale sur le port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:14b",
  "prompt": "Résume ce texte en 3 puces : ...",
  "stream": false
}'

import json, requests

OLLAMA = "http://localhost:11434/api/generate"
MODELES = ["qwen3:14b", "gemma3:12b"]

# Vos prompts réels — la clé d'une éval qui vous ressemble
prompts = [
    "Rédige un mail de relance poli à un client en retard de paiement.",
    "Extrais les dates et montants de ce texte : ...",
    "Explique la différence entre Q4_K_M et Q8_0 en 2 phrases.",
]

def interroger(modele, prompt):
    r = requests.post(OLLAMA, json={
        "model": modele, "prompt": prompt, "stream": False
    }, timeout=120)
    return r.json()["response"].strip()

resultats = []
for p in prompts:
    ligne = {"prompt": p}
    for m in MODELES:
        ligne[m] = interroger(m, p)
    resultats.append(ligne)

# À relire en aveugle, sans regarder la colonne du modèle
with open("comparaison.json", "w", encoding="utf-8") as f:
    json.dump(resultats, f, ensure_ascii=False, indent=2)
print("OK — comparaison.json généré, notez les réponses à froid.")

#Per approfondire

Queste guide approfondiscono i concetti trattati qui, per quanto riguarda i benchmark specializzati e la scelta concreta di un modello locale:

Benchmark di codice in dettaglio

«HumanEval è morto: capire i benchmark di programmazione degli LLM nel 2026» approfondisce SWE-bench, LiveCodeBench e come leggere i punteggi nei benchmark di programmazione — il seguito diretto di questa guida per quanto riguarda lo sviluppo.

Scegliere la quantizzazione

«Quantizzazione GGUF nel 2026: Q4_K_M vs Q5_K_M vs Q6_K» mostra come misurare l'impatto reale di una quantizzazione sulla qualità — una valutazione fatta in proprio applicata a un caso concreto.

Test completo del modello

« Qwen 3 in locale: test completo e benchmark reali » illustra il metodo di valutazione locale (token/sec, qualità FR, VRAM) su un modello specifico.