Valutazione degli LLM: dai benchmark pubblici al tuo golden set

Quasi ogni discussione sulla valutazione è fatta da due persone che misurano cose diverse. Ci sono tre progetti e non condividono lo stesso strumento.

La confusione costa cara in una direzione. Una leaderboard ti dice che un model è forte nel ragionamento di livello universitario; non può dirti se instraderà i tuoi ticket di supporto. E una valutazione applicativa che assegna un punteggio a una risposta per input non può vedere affatto un agent, perché un agent ha una distribuzione di traiettorie e una risposta è un singolo campione da quella distribuzione. Il Capitolo 22 ha dato un nome a quella terza riga e l'ha lasciata vuota: la misura di performance, l'unica parte della specifica di un agent che i team scrivono per ultima o mai.

Conta anche l'ordine, e lo dice lo stesso vendor che ti vende il model. La guida agli agent di OpenAI riduce la selezione del model a tre passaggi, in quest'ordine: «Configura evals per stabilire una baseline di performance», «Concentrati sul raggiungimento del tuo target di accuratezza con i migliori model disponibili», «Ottimizza costi e latenza sostituendo i model più grandi con model più piccoli dove possibile».¹ La valutazione viene prima, perché i passaggi due e tre non significano nulla senza un numero.

Un golden set è una lista di input, ciascuno con la risposta scritta, e un grader che decide se un output corrisponde. È noioso, è piccolo, ed è l'unico artefatto in questo capitolo che è tuo. Quello costruito qui contiene venti task su una directory di cinque file — non i tre del Capitolo 23, quindi le risposte non sono le stesse — e il grader viene scritto prima che l'agent giri:

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

Due proprietà reggono tutto. La lista mustNot esiste perché un model che nomina tre file includendo quello giusto non ha risposto. E answer è scritto in prosa oltre che in pattern, perché più avanti servirà sia a un umano sia a un giudice — e scrivere lo stesso fatto due volte in due notazioni è il modo in cui scopri di non essere d'accordo con te stesso su quale fosse il task.

Ora la tabella che decide. Quattro sistemi candidati, gli stessi venti task, accuratezza con il suo intervallo, e le due colonne che una tabella di sole accuratezze nasconde sempre:

Leggi gli intervalli prima del vincitore. Il braccio B va dall'11 % al 47 %; il braccio A dal 3 % al 30 %. Si sovrappongono per gran parte della loro lunghezza, cioè il risultato del Capitolo 4 che arriva esattamente dove era stato promesso: venti casi non possono classificare quattro sistemi. Il Capitolo 15 lo ha reso più preciso ponendo invece la domanda appaiata — tra i casi in cui due bracci dissentono, quanto è sbilanciata la divisione? — perché la difficoltà condivisa del set si annulla. Ecco ogni coppia:

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

Nessuno dei sei confronti è stabilito. Il braccio migliore batte quello senza tool di quindici punti, e tutto poggia su tre casi discordanti. Venti casi mostrano un meccanismo e non possono scegliere un fornitore; dire il contrario in riunione è il modo in cui si compra un cattivo model.

C'è una cosa che questa tabella stabilisce, ed è la colonna che nessuno mette. Il braccio D costa tredici volte il braccio B per task risolto, perché campionare tre traiettorie e prendere la risposta modale triplica il conto, che triplichi o no l'accuratezza. Le tabelle di accuratezza che omettono il costo rendono invisibile quello scambio.

Ora il risultato che cambia il modo in cui leggerai ogni benchmark che vedrai. Prendi gli stessi duecento transcript — venti task, dieci run, non un token rigenerato — e assegnagli un punteggio in tre modi:

Zero, tredici, ventisei. Il sistema non è cambiato. È cambiato il grader. L'exact match restituisce zero non perché l'agent sia inutile, ma perché nessuna risposta free-text è mai byte-identica a un riferimento: misura la formattazione e la riporta come capacità.

Non è una curiosità, è un meccanismo, e ha un nome. Una metrica hard-cutoff valuta un task tutto-o-niente su diversi sotto-fatti, quindi li compone. Il task t12 chiede tre status code insieme. Sulle dieci run:

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

Ogni fatto è corretto circa tre quarti delle volte; pretendere tutti e tre insieme dimezza il punteggio, e $0.77^3 = 0.457$ è abbastanza vicino allo 0.50 misurato da mostrare da dove arrivi il calo. Generalizziamo:

Leggi la riga 0.90 contro la riga 0.95 a $k = 10$: un miglioramento per fatto di cinque punti diventa venticinque punti sulla congiunzione. Al model non è successo nulla di discontinuo. Una curva liscia letta attraverso una metrica tutto-o-niente sembra un salto — ed è precisamente l'argomento di Schaeffer, Miranda e Koyejo sulle capacità emergenti, che il Capitolo 10 ha rimandato qui.² Il loro audit ha trovato che al massimo 5 delle 39 metriche preferite di BIG-Bench mostrano davvero emergenza, con due metriche discontinue responsabili di oltre il 92 % dei casi dichiarati.

Quindi la disciplina, in una riga: un salto in un grafico è evidenza sulla metrica finché non si dimostra il contrario. Prima di credere che sia apparsa una capacità, traccia le stesse run con una metrica che dia credito parziale e vedi se il precipizio resta.

C'è una versione di secondo ordine che Kalai e colleghi sostengono stia facendo danni a monte: i benchmark valutati giusto-o-sbagliato premiano l'indovinare rispetto al dire «non lo so», quindi un model ottimizzato contro di essi impara a indovinare. La correzione proposta non è un altro benchmark sulle hallucination, ma «modificare il punteggio dei benchmark esistenti che sono disallineati ma dominano le leaderboard».³ Il tuo golden set ha la stessa leva, ed è una riga: decidi se un'astensione conta come fallimento o come categoria propria. La maggior parte delle persone non decide mai, quindi conta silenziosamente come fallimento, e il sistema che spediscono indovina.

Finora abbiamo valutato un tentativo per task. Un agent non è un tentativo. Il Capitolo 17 ha stabilito che non hai determinismo nemmeno a temperature zero, quindi lo stesso input produce una distribuzione di traiettorie e un benchmark che esegue ogni task una volta riporta un campione da quella distribuzione.

Il contributo di τ-bench è la metrica per questo. Il paper la definisce chiaramente: «proponiamo una nuova metrica – pass^k (pass hat k), definita come la probabilità che tutte le k prove i.i.d. di un task abbiano successo, mediata sui task».⁴ Esegui ogni task $n$ volte, conta i $c$ successi, e gli stimatori non distorti sono:

Il secondo è il familiare pass@k della generazione di codice: la probabilità che almeno uno di $k$ tentativi riesca. Mettili fianco a fianco sugli stessi conteggi misurati e si muovono in direzioni opposte:

Stesse run, stesso grader, stessi venti task. Una colonna dice che il sistema migliora con più tentativi e l'altra dice che peggiora, ed entrambe sono corrette, perché rispondono a domande diverse. pass@k è la metrica giusta quando un umano filtra l'output — generazione di codice, bozze, brainstorming — e i tentativi extra costano poco. pass^k è la metrica giusta quando l'agent agisce senza filtro, che è ciò che significa «agent». Pubblicare la prima dove vale la seconda è la sovrastima più comune in questo campo, e il titolo stesso di τ-bench è la versione onesta: gpt-4o a circa 61 % pass^1 nel retail scende a circa 25 % a pass^8.⁴

Ora la puntura nei miei numeri. pass^10 sui miei venti task è 5.0 %: esattamente un task su venti risolto in tutte e dieci le run. Quel task è t19, «Il deploy 42 è riuscito?», e qui ci sono due delle dieci risposte che la rubrica ha valutato corrette:

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

La prima non risponde mai. La seconda aggiunge un'affermazione falsa — il deploy 41 era stato rolled back. Entrambe hanno fatto match con /succe|yes/. L'unico task che tiene pass^10 sopra zero è un artefatto del grader, quindi il valore vero è zero, e nessun aggregato me lo avrebbe mostrato. Campionare i transcript dietro al tuo task con il punteggio migliore è dove i grader vanno a morire.

E un altro numero, quello da cui prende il nome questa sezione. Dieci valutazioni identiche — stesso sistema, stessi venti task, stesso codice, nulla cambiato tranne i seed:

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

Un intervallo di trenta punti su un sistema che non è cambiato. Se esegui la suite una volta prima di un rilascio e una volta dopo, un «miglioramento» di otto punti sta dentro quella dispersione e lo spedirai credendo di averlo causato. Ecco perché l'intervallo pooled sopra — 26.0 % [20.4, 32.5] — è troppo stretto per essere citato da solo: tratta duecento prove correlate come se fossero duecento indipendenti. Il riassunto onesto di una valutazione di un agent è una media e una dispersione tra ripetizioni, e quasi nessuno pubblica la seconda.

Le rubriche non scalano alle risposte aperte, quindi la mossa standard è far valutare l'output a un model. Funziona abbastanza bene a scala frontier da essere il default, e ha tre failure mode con nome: position bias, verbosity bias e self-enhancement bias.⁵

Misuralo prima di fidarti. Le stesse sessanta risposte — tre delle dieci run — sono state etichettate in tre modi. L'etichetta umana è mia: ho letto tutte e sessanta con i cinque file aperti e ho applicato una regola scritta, passa se e solo se la risposta afferma il fatto richiesto dalla domanda e non contiene nulla di contraddetto dai file.

Il giudice ha detto PASS sessanta volte su sessanta. Avrebbe riportato questo agent al 100 % di accuratezza su un set in cui l'umano lo valuta al 18 %. Un giudice senza potere discriminativo non è uno strumento rumoroso; è una funzione costante, e una funzione costante dà lo stesso punteggio al tuo sistema migliore e al tuo peggiore.

Il prompting non l'ha salvato. Quattro varianti, stessi sessanta item:

Invertire l'ordine delle due etichette nell'istruzione ha spostato quattro verdetti. È un effetto misurabile ed è il tipo sbagliato di effetto: il giudice risponde alla forma del prompt invece che alla risposta davanti a sé.

La dimostrazione pulita è pairwise. Venti domande, ciascuna con un candidato chiaramente corretto e uno chiaramente sbagliato, presentati in entrambi gli ordini:

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

Ha scelto la posizione A quaranta volte su quaranta. Il 50 % sulla correttezza non è competenza parziale — è aritmetica, perché la risposta corretta si trova in posizione A esattamente in metà delle prove. La coerenza qui è definita come in MT-Bench, «la percentuale di casi in cui un giudice dà risultati coerenti quando si scambia l'ordine di due assistant», il che rende il confronto omogeneo: GPT-4 ottiene 65.0 % su quella misura, e il few-shot prompting lo porta a 77.5 %.⁵ Il mio ottiene zero.

La mitigazione standard viene anch'essa da quel paper: «chiamare un giudice due volte scambiando l'ordine di due risposte e dichiarare una vittoria solo quando una risposta è preferita in entrambi gli ordini».⁵ Applicala qui e il giudice produce zero verdetti utilizzabili su venti coppie — che è l'esito corretto, e infinitamente meglio di venti verdetti sicuri.

Una nota metodologica che vale più del risultato. Ho eseguito anche un test di verbosity: la stessa risposta corretta, una copia riempita con una frase di 36 parole che non aggiunge nulla. Il giudice ha preferito la versione più lunga esattamente nel 50 % delle prove — cosa che sembra assenza di verbosity bias e non lo è affatto, perché un giudice che sceglie sempre la posizione A ottiene 50 % su qualunque pairing bilanciato. Non puoi misurare un secondo bias finché il primo non è controllato. Scambiare le posizioni non è una rifinitura da aggiungere dopo; è ciò che rende interpretabile ogni altra misura.

La cautela onesta: questo giudice è un model da mezzo miliardo di parameter, e nessuno dovrebbe usarne uno per valutare. Il punto non è che i giudici siano cattivi. È che i numeri sopra sono costati otto minuti da produrre, e senza di essi il verdetto di questo giudice su una decisione di rilascio sarebbe stato 100 %.

Questo è il terzo e ultimo pannello Python dichiarato del corso, e il motivo è da dove arrivano i numeri pubblici. lm-evaluation-harness copre «oltre 60 benchmark accademici standard per LLMs, con centinaia di subtasks e varianti implementate» ed è «il backend della popolare Open LLM Leaderboard di Hugging Face»; HELM, SWE-bench e τ-bench sono pacchetti Python con entry point Python.⁶ Eseguire il tuo model contro una cifra pubblicata significa eseguire il loro codice, e il giorno in cui vuoi confrontarti con un numero citato da qualcuno, questo è l'ecosistema in cui ti trovi:

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

Il secondo motivo è che una misura in questo capitolo è impossibile via HTTP. Contamination — il test set trapelato nei dati di training — è il fallimento che rende silenziosamente inutile un benchmark pubblico, e la sonda più affilata richiede la loss del model, che nessuna chat API restituisce. È la cross-entropy per token del Capitolo 8, puntata a una domanda sulla memoria:

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

Dieci coppie di frasi: cinque presenti in ogni crawl del web da quando esiste, cinque scritte per questo capitolo stamattina, ciascuna abbinata a una versione riformulata con lo stesso contenuto.

Il model è quattro volte più sorpreso da una frase scritta stamattina che da una vista un milione di volte, e riformulare costa il doppio sulle frasi famose — il costo extra è la parte memorizzata invece che compresa. La loss assoluta confonde memorizzazione e normale naturalezza, quindi il gap è la statistica migliore e il test di continuazione lo è ancora di più. Dagli le prime sei parole:

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

Tre delle cinque stringhe famose sono continuate parola per parola da sei parole; nessuna delle cinque fresche lo ha fatto. È un model da mezzo miliardo di parameter che recita la Licenza MIT. Se il tuo benchmark è sul web pubblico, presumi che sia nei weights. È anche l'argomento dell'intero capitolo: un golden set scritto da te sui tuoi dati, tenuto fuori da qualunque repository letto da un crawler, è l'unico test set di cui puoi essere certo che non sia mai stato usato in training.

Vale comunque la pena leggerli, purché tu legga cosa misura ciascuno invece del singolo numero associato.

Prendi la tabella più di qualsiasi riga. I benchmark agentic mettono tutti gli umani molto sopra i model, l'opposto dei benchmark di conoscenza e il miglior riassunto in una riga dello stato del campo; le loro cifre invecchiano in mesi, quindi citale con la data in cui le hai lette; e ognuno misura un task che non è il tuo.

L'accuratezza è la metrica su cui si discute. Queste sono quelle che decidono se la cosa viene spedita. Tutte e quattro escono dalle duecento run già misurate.

Costo per task risolto, non per call. L'agent costa $0.001345 per tentativo e $0.005172 per task effettivamente risolto — 3.85 volte di più, perché tre quarti dei tentativi non producono nulla. La latenza si comporta allo stesso modo: 1,213 ms per tentativo, 4,667 ms per task risolto. Ogni retry, ogni nuova domanda, ogni traiettoria abbandonata è nel secondo numero e invisibile nel primo.

Una diagnostica che batte l'accuratezza. In 123 tentativi su 200 l'agent ha risposto senza chiamare nemmeno un tool — ha indovinato invece di guardare. Dividendo su questo:

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

Gli intervalli non arrivano neanche vicini a toccarsi. Vale più dell'aggregato 26 %, perché nomina la cosa da sistemare — il model non sta fallendo nel ragionare, sta fallendo nel guardare — e la correzione è nel harness, non nel model. Una cautela che questo capitolo deve ai propri standard: i due gruppi sono task diversi, non gli stessi task appaiati, quindi una parte del gap può dipendere dal fatto che salti i tool proprio sulle domande che trova difficili. La divisione è una diagnostica, non un'affermazione causale.

Il tasso di intervento umano è la metrica che un acquirente chiede per prima: quale frazione di run si è fermata a un'approvazione, un guardrail o un handoff. Le interruzioni tipizzate del Capitolo 23 lo rendono contabile, e contato per tipo di task e per settimana è ciò che separa un agent che impara il proprio lavoro da uno che diventa silenziosamente una coda.

L'abbandono è quello che nessuna suite offline può vedere: l'utente che ha letto la risposta, ha chiuso la scheda e ha svolto il task da solo. La valutazione offline è un gate; la valutazione in produzione è un campione continuo di traffico reale, valutato con lo stesso grader più queste quattro.

E una regola ereditata dal Capitolo 17: non fare mai assert sull'output esatto. Fai assert su proprietà — JSON valido, schema corretto, il tool giusto chiamato, un numero entro tolleranza, una substring richiesta presente. La colonna exact-match all'inizio di questo capitolo è ciò che succede quando quella regola viene infranta.

Valutare un fornitore non riguarda solo l'accuratezza, e questa è la seconda metà dell'etica di questo corso, con un titolo proprio invece che un'appendice.

Misura il bias, non presumerlo. Qualunque cosa tu creda sul comportamento di un model su nomi, dialetti, generi o nazionalità, è una proprietà misurabile della tua pipeline, e lo strumento è quello che hai già: prendi il tuo golden set, varia solo l'attributo, confronta in modo appaiato. HELM esiste proprio perché si riportava solo l'accuratezza dove bias, tossicità, calibrazione e robustness erano anch'essi decidibili.⁸ La model card di un vendor è un punto di partenza, non evidenza sui tuoi input.

La contamination è anche una domanda da fornitore. La sonda sopra è il motivo per chiedere su cosa sia stato misurato un numero pubblicato, e quando siano stati tagliati i dati del model.

Retention, training e residency, letto il 7 settembre 2026. Queste cose cambiano, quindi registra la data accanto alla risposta. La pagina policy di Anthropic afferma: «Per impostazione predefinita, non useremo i tuoi input o output dai nostri prodotti commerciali (ad es. Claude for Work, Anthropic API, Claude Gov, ecc.) per addestrare i nostri model», con l'eccezione dei contenuti che invii esplicitamente come feedback, conservati «fino a 5 anni».¹⁶ La documentazione sui controlli dei dati di OpenAI afferma che «i dati inviati alla OpenAI API non sono usati per addestrare o migliorare i model OpenAI (a meno che tu scelga esplicitamente di condividere dati con noi)», descrive una retention predefinita di trenta giorni per i log di monitoraggio abusi, e offre Zero Data Retention, che «esclude i contenuti dei clienti dai log di monitoraggio abusi», più data residency configurabile in una lista di regioni.¹⁷

Quattro domande da mettere per iscritto prima della prima call di produzione, perché ognuna ha un owner diverso: i miei dati sono usati per training; per quanto tempo sono conservati e da chi; dove sono elaborati e archiviati; e cosa succede a tutto questo se uso un reseller, un gateway o un aggregatore invece del provider diretto. L'ultima è dove vive la maggior parte delle sorprese, e nessun benchmark te lo dirà.

Ora hai lo strumento: un golden set che possiedi, un intervallo su ogni numero, un test appaiato per ogni confronto, pass^k per le run che non hai mostrato a nessuno, un giudice misurato, e una sonda per capire se un punteggio pubblico significhi qualcosa. L'affermazione finale del Capitolo 23 può ora essere verificata invece che dichiarata — un harness rende un agent governabile, non corretto — e verificarla ha richiesto duecento run e otto minuti.

C'è una proprietà di un agent che nulla di tutto questo misura, ed è quella che fa licenziare le persone.

Ogni task nel golden set di questo capitolo è stato scritto da me, e ogni file letto dall'agent è stato scritto da me. Nulla in quella directory stava cercando di fare qualcosa. Cambia una riga in un file che l'agent deve leggere — una riga che finisce con un'istruzione rivolta a chiunque la legga dopo — e l'agent che ha ottenuto 26 % la seguirà con gli stessi tool, gli stessi permessi e la stessa trace pulita, e ogni numero in questo capitolo resterà esattamente dov'è. Una suite di valutazione misura quanto spesso un sistema raggiunge il tuo obiettivo. Non misura quanto facilmente qualcun altro possa sostituirlo con il proprio.

Il Capitolo 30 è questo: prompt injection, la trifecta letale di dati privati, contenuto non affidabile e comunicazione esterna, e quanto costa dare a un agent permessi reali. Si apre con l'osservazione che questo capitolo ha evitato — che lo stesso punteggio di passaggio è compatibile con un agent che fa esattamente ciò che un attaccante ha scritto in un file che gli è stato detto di leggere.

Ogni numero sopra è stato prodotto su una macchina e nessuno ha toccato un endpoint a pagamento. L'agent è il loop del Capitolo 23 con due dei suoi quattro tool su una directory di cinque file; il model dietro la porta è Qwen/Qwen2.5-0.5B-Instruct, esposto tramite un piccolo server della stessa forma di un endpoint chat completions esattamente come nel Capitolo 23, ma in half precision su una GPU consumer invece che sulla CPU di quel capitolo. I costi usano le tariffe del Capitolo 16 — $2.00 per milione di input tokens e $12.00 per milione di output — applicate ai conteggi di token misurati. Le run ripetute usano temperature 0.7 con seed fissi così l'intero set si riproduce; la tabella a quattro bracci è greedy. Gli intervalli sono Wilson al 95 %, i confronti appaiati sono sign test esatti a due code sulle coppie discordanti; l'intervallo di Wilson è quello del Capitolo 4 e il sign test appaiato esatto è quello del Capitolo 15, entrambi riusati senza modifiche. Le etichette umane sono mie, applicate a sessanta risposte secondo la regola scritta citata nel testo. Leggi ogni grandezza qui come proprietà di un model da mezzo miliardo di parameter e ogni metodo come trasferibile: un model più grande sposta tutti i numeri verso l'alto e non sposta nessuno degli strumenti.