Golden dataset e test set

Primo articolo della serie sul testing dei sistemi AI. Prima di decidere chi valuta — un modello, come nel secondo articolo, o una persona, come nel terzo — c'è una domanda che sta sotto a entrambe le risposte: rispetto a cosa, esattamente, stiamo misurando?

Una scena che ho visto troppe volte

Riunione di allineamento su un assistente basato su RAG. Qualcuno ha modificato il prompt di sistema per risolvere una segnalazione. Il product owner chiede: «ok, ma adesso funziona meglio o peggio di prima?».

Segue silenzio. Poi la risposta che conosciamo tutti: «a me sembra meglio».

Il problema non è la buona fede di chi risponde. Il problema è che non esiste nessun modo, in quella stanza, per distinguere «ho risolto un caso e ne ho rotti tre» da «ho risolto un caso e basta». Il software tradizionale ha risolto questo problema trent'anni fa con i test di regressione. Nei sistemi generativi il concetto è lo stesso, ma la ground truth te la devi costruire a mano.

Quella ground truth costruita a mano si chiama golden dataset.

Cosa significa esattamente

Un golden dataset (o gold standard, o golden set) è una raccolta curata di esempi in cui l'output atteso — o quantomeno il criterio di accettazione — è considerato verità di riferimento.

Il termine arriva dalla medicina diagnostica: il gold standard è l'esame che per convenzione si assume corretto, e contro cui si misurano tutti gli altri esami più economici o più rapidi. La sostanza è identica: è il riferimento che decidi di trattare come vero, con la piena consapevolezza che è una decisione tua e non un fatto di natura.

Golden dataset ≠ test set

I due termini vengono usati come sinonimi, ma la differenza operativa conta:

Nel machine learning classico fai 70/15/15 e vai. Il test set eredita la qualità del dataset: se il 5% delle etichette è sbagliato, il tuo test set ha il 5% di etichette sbagliate e il tuo tetto di accuratezza misurabile è il 95%.

Il golden dataset è un'altra cosa. È scritto o selezionato con l'intenzione esplicita di rispondere a domande specifiche: questo sistema gestisce bene le domande ambigue? Rispetta il formato? Si rifiuta quando deve rifiutarsi? È piccolo perché ogni esempio è costato attenzione umana, ed è utile proprio per quello.

La forma concreta

Nel caso più semplice è una lista di coppie input → output atteso. Nella pratica dei sistemi LLM diventa quasi sempre qualcosa di più ricco:

- id: RIM-014
  categoria: rimborso_fuori_termine
  input: "ho comprato il 3 gennaio, posso ancora restituire?"
  contesto_atteso: [policy_resi_v3, eccezioni_festivita]
  criteri:
    - deve citare il limite dei 30 giorni
    - non deve promettere un rimborso
    - deve indicare il canale di assistenza
  note: "caso di confine, la data cade nel periodo esteso natalizio"
  origine: ticket_produzione_2025-02

Nota che non c'è una risposta attesa parola per parola. Per i task generativi il confronto esatto non ha senso: quello che si fissa è un insieme di criteri di accettazione, che poi verranno verificati da un judge automatico, da un controllo deterministico o da una persona. Il golden dataset definisce cosa deve essere vero, non come deve essere scritto.

I cinque criteri di un dataset che serve a qualcosa

Nella letteratura recente circola un framework mnemonico utile, le 5 D (Practical Guide for Evaluating LLMs). Lo riporto perché è una checklist onesta:

1. Defined scope — ambito definito. Un dataset per componente, oltre a quello end-to-end. Se il retriever e il generatore hanno il loro set separato, quando il numero cala sai dove guardare. È il ragionamento dell'unit test applicato alla pipeline.

2. Demonstrative of production — somigliante alla produzione. Costruito su traffico reale, non su ciò che immaginavi che gli utenti avrebbero chiesto. È il criterio più violato in assoluto. Un dataset generato dalla documentazione è troppo pulito, troppo ben scritto, troppo grammaticale. Gli utenti veri scrivono in minuscolo senza punteggiatura, cambiano idea a metà frase, incollano pezzi di email.

3. Diverse — diverso. Argomenti, intenti, difficoltà, lingue, casi avversariali. Se tutti gli esempi sono happy path, il punteggio resterà al 95% per sempre senza dirti nulla.

4. Decontaminated — decontaminato. Non deve sovrapporsi ai dati di training o fine-tuning. Ci torno tra poco perché è il punto più insidioso.

5. Dynamic — vivo. Un dataset assemblato a gennaio descrive il traffico di gennaio. A luglio gli utenti chiedono altro e il prodotto ha funzionalità nuove. Va trattato come un log in append, con la data su ogni item, così sai a colpo d'occhio quanto è stantio.

Da dove vengono gli esempi

Tre sorgenti, e servono tutte e tre.

Produzione. La sorgente migliore, senza confronto. Trace reali, ticket di assistenza, conversazioni finite male. Ogni segnalazione di un utente è un candidato a diventare un test permanente. Attenzione al GDPR: gli esempi vanno anonimizzati prima di finire in un repository che tutto il team può leggere.

Esperti di dominio. Necessari quando il task richiede conoscenza che il modello non ha e che tu non trovi nei log: normativa di settore, procedure interne, casi limite che si verificano due volte l'anno ma costano cari. È la parte costosa e lenta, ed è quella che dà valore al dataset. Chi si occupa di annotazione seria misura anche l'accordo tra annotatori (Cohen's kappa): se due esperti non concordano sul caso, quel caso non è pronto per entrare nel golden set — o va riformulato, o il criterio di accettazione è ambiguo e il problema è a monte.

Generazione sintetica. Utile per riempire i buchi: hai tre esempi di una categoria rara, ne generi venti variazioni. La letteratura recente distingue i silver dataset (etichette prodotte da un LLM) dai golden (verificati da umani) e persino dai super-golden (curati da team di esperti diversi). La distinzione è sana: tenerli separati e sapere sempre quale stai guardando evita di confondere «il modello è d'accordo con se stesso» con «il modello ha ragione».

Il mix che funziona nella pratica: nucleo di casi reali dalla produzione, arricchito da casi scritti dagli esperti sui punti dolenti noti, espanso sinteticamente solo dove i dati veri sono troppo scarsi.

Quanto deve essere grande

La domanda arriva sempre, e la risposta delude sempre: molto meno di quanto pensi.

Gli ordini di grandezza che si trovano nelle guide pratiche recenti sono coerenti tra loro:

• ~50 esempi — sufficienti a intercettare regressioni grosse. È il gate veloce da far girare su ogni pull request.
• ~200 esempi — cominci ad avere confidenza statistica su differenze del 3-5%. È la soglia dove il numero smette di essere aneddotico.
• oltre 500 — rendimenti decrescenti, a meno che il sistema non abbia sotto-task molto diversi che meritano set separati.

Per i task deterministici (classificazione, estrazione strutturata) i numeri salgono, perché lì la valutazione costa pochissimo e puoi permetterti migliaia di casi.

Il punto vero è che la provenienza conta più della dimensione. Cento casi presi dai fallimenti reali valgono più di duemila casi generati da un LLM a partire dal manuale utente. Il secondo dataset ti darà numeri più belli e informazione zero.

Come si usa davvero

Tre livelli, con costi e cadenze diverse. La scaletta è quella proposta da Hamel Husain e ripresa un po' ovunque, e ha il pregio di essere realistica:

Livello 1 — Unit test deterministici. Assertion che girano in millisecondi a ogni commit: il JSON è valido? Il campo obbligatorio c'è? La risposta contiene il disclaimer richiesto? Ha superato i 500 token? Sono banali, coprono più casi di quanto si creda e costano zero. Molti team li saltano per correre dritti al judge, e poi pagano in latenza e token quello che potevano avere con una regex.

Livello 2 — Golden dataset + valutazione (judge o umana). Gira sulla pull request o sulla nightly. Qui vive il grosso del segnale: cambio prompt, cambio modello, cambio strategia di chunking → rilancio il set → guardo il delta rispetto alla baseline.

Livello 3 — A/B test in produzione. Traffico vero, campioni significativi, utile solo quando il prodotto è maturo e i primi due livelli sono stabili.

Chi parte dal livello 2 o 3 senza il livello 1 perde il ciclo di feedback rapido che rende sopportabili i livelli lenti.

Sul gate di CI: la pratica comune è bloccare il merge se una metrica primaria peggiora oltre una soglia (il 5% è il valore che si vede più spesso). E una nota importante, che a chi viene dal software tradizionale suona eretica: il pass rate non deve essere il 100%. È una decisione di prodotto. Un sistema che passa il 100% del golden set sta probabilmente dicendo che il golden set è troppo facile.

Cosa ti restituisce

Segnale riproducibile a costo quasi nullo. Una valutazione umana su 200 esempi costa ore-uomo e non la rifai a ogni virgola cambiata nel prompt. Un golden set gira in due minuti e lo puoi lanciare venti volte al giorno.

Le discussioni diventano oggettive. Si smette di litigare a impressioni. «Ho perso 4 punti sulla categoria rimborsi» è una frase su cui si può lavorare; «mi sembra peggiorato» no.

Vedi le regressioni invisibili. Quelle che l'occhio non nota perché stavi guardando altrove. È il beneficio che si apprezza solo la prima volta che ti salva.

Diagnosi, non solo voto. Se il dataset è stratificato per categoria, il risultato ti dice dove stai sbagliando. Un 90% aggregato può nascondere un 40% sulla categoria critica poco rappresentata — ed è quasi sempre quella che ti farà male.

Governance. Nei contesti regolati (AI Act, settori vigilati) avere evidenza documentata e versionata di come il sistema è stato valutato prima di ogni rilascio non è un vezzo, è materiale di audit.

I contro, che sono la parte interessante

La legge di Goodhart

Quando una misura diventa un obiettivo, smette di essere una buona misura.

Se ottimizzi iterativamente contro gli stessi 100 esempi, dopo venti iterazioni hai un sistema che eccelle su quei 100 esempi. Non necessariamente sul resto del mondo. È overfitting fatto a mano, dal team, senza gradient descent: guardi i fallimenti, aggiusti il prompt per risolverli, rilanci, ripeti. Il numero sale ed è tutto vero — sui casi che stai guardando.

La mitigazione è disciplinare, non tecnica: tenere una parte del set come holdout cieco, che non si guarda mai durante lo sviluppo e si usa solo per la validazione finale. Se il set di sviluppo sale e l'holdout no, hai la tua risposta.

La contaminazione

È il problema che ha reso i benchmark pubblici quasi inutilizzabili come misura assoluta. Se gli esempi di valutazione sono finiti nel training del modello, i numeri misurano memorizzazione, non capacità.

L'esperimento più pulito su questo è GSM1k di Scale AI: hanno commissionato mille problemi di matematica delle elementari costruiti per rispecchiare distribuzione, difficoltà e statistiche delle risposte di GSM8k, il benchmark standard del settore. Poi hanno rivalutato i modelli. Alcune famiglie (Phi, Mistral, alcuni Llama) hanno perso fino a 13 punti percentuali; i modelli di frontiera quasi nulla. E il divario correlava con la probabilità che il modello riproducesse letteralmente i testi di GSM8k. Traduzione: parte di quel punteggio era ricordo.

Dettaglio che dice tutto: hanno deciso di non rilasciare pubblicamente GSM1k, se non una cinquantina di campioni, proprio per non bruciarlo.

La lezione per chi costruisce prodotti: il tuo golden set deve restare privato, e i benchmark pubblici vanno letti come indizi grossolani, non come misure. Se il tuo dataset finisce su GitHub in chiaro, sappi che hai iniziato un conto alla rovescia.

Il gold standard non è oro

Questo è il punto più scomodo. L'assunzione «l'etichetta di riferimento è corretta» è, appunto, un'assunzione.

MMLU è probabilmente il benchmark più citato della storia recente degli LLM. Un'analisi manuale di 5.700 domande condotta da quattordici esperti ha stimato circa il 6,5% di domande errate, con picchi assurdi: nel sottoinsieme di virologia oltre il 57% degli esempi analizzati aveva qualche problema, e il 30% aveva proprio la ground truth sbagliata. Rivalutando i modelli sul dataset corretto, la classifica cambia.

Se succede a un benchmark accademico su cui è stata costruita mezza narrazione del settore, immagina cosa c'è nel tuo file CSV messo insieme in due pomeriggi.

Corollario pratico: quando un caso del golden set fallisce, la prima ipotesi non è sempre «il modello ha sbagliato». A volte il modello ha ragione e l'etichetta è sbagliata. Vale la pena riguardare i casi che falliscono sistematicamente da mesi: ogni tanto ci trovi un errore tuo, fossilizzato, che il sistema sta prendendo in giro da sempre.

Copertura limitata e falso senso di sicurezza

Duecento esempi non coprono la coda lunga di ciò che chiedono gli utenti reali. «Il golden set passa al 94%» mentre in produzione le persone trovano modi di rompere il sistema che nessuno aveva immaginato — perché nessuno può immaginarli tutti, ed è esattamente per questo che esistono la review a campione e il monitoraggio online.

Costo di manutenzione

Va aggiornato quando cambiano il dominio, il prodotto, la normativa. Un golden set fermo a due anni fa misura un problema che non esiste più, con la sicurezza tranquilla di chi non sa di essere fuori tempo. E la manutenzione non è divertente: è il primo lavoro che salta quando c'è una scadenza.

L'ambiguità del "corretto"

Per la classificazione è facile. Per «riassumi questo documento» o «scrivi questa email» non esiste un unico output corretto, e il confronto stringa-per-stringa non funziona. Si passa a criteri, rubriche, similarità semantica, LLM-as-judge — che introduce i suoi bias e la sua variabilità, e che a sua volta va validato contro giudizi umani. È il punto in cui questo articolo si aggancia al prossimo della serie: il golden set è anche il banco di prova del judge, non solo del sistema.

Cose imparate sul campo

Il dataset finto che dava il 97%. Su un classificatore di ticket avevamo costruito il set di valutazione partendo dalla tassonomia ufficiale delle categorie: per ogni categoria, qualche esempio scritto da noi. Risultato: 97%, e via in produzione. In produzione l'accuratezza percepita era intorno al 60%. Il motivo era banale col senno di poi: i nostri esempi erano scritti da chi conosceva già la tassonomia, quindi contenevano le parole chiave giuste. Gli utenti scrivevano «non funziona più niente da stamattina». Abbiamo ricostruito il set da 300 ticket veri, il punteggio è crollato a 61% ed è stato il momento in cui abbiamo iniziato a capire qualcosa.

Il caso che falliva da otto mesi. Un caso di test rosso da sempre, ereditato, che tutti scavalcavano perché «quello è noto». Quando finalmente l'abbiamo aperto, l'output atteso era sbagliato: qualcuno l'aveva scritto interpretando male una policy interna. Il modello aveva ragione da otto mesi. Da lì la regola: nessun test resta rosso più di due sprint senza una decisione esplicita, o si corregge o si cancella.

Il set che è diventato il prodotto. Su un assistente documentale il golden set era cresciuto fino a 400 casi, tutti costruiti a partire da un particolare tipo di domanda su cui ci eravamo accaniti. Sei mesi dopo il punteggio era eccellente e gli utenti insoddisfatti: nel frattempo il traffico si era spostato su un'altra tipologia di domande, che nel set era rappresentata da quattro esempi. Il dataset descriveva il nostro passato, non il loro presente. Da allora una quota fissa di ogni revisione mensile va a riallineare il set con la distribuzione reale delle domande.

Il gate che nessuno rispettava. Avevamo messo il blocco in CI al 5% di regressione. Nelle prime settimane è scattato spesso, e ogni volta la reazione era «sì ma è un falso positivo, sblocca». Il gate è sopravvissuto solo quando abbiamo aggiunto due cose: la lista dei casi specifici che erano cambiati (non solo il numero aggregato), e la possibilità di approvare esplicitamente una regressione motivandola. Un gate che si può solo subire viene disattivato; un gate che si può discutere resta.

Come costruirne uno che non muoia dopo tre mesi

Una checklist operativa, in ordine di importanza:

1. Parti dai fallimenti reali. Non dalla documentazione, non dalla tassonomia, non dalla fantasia. Se non hai ancora produzione, parti dalle telefonate del supporto o dai casi che gli esperti di dominio ti raccontano con esasperazione.
2. Versionalo come codice. In git, con changelog. Un cambio nei numeri deve essere attribuibile o al sistema o al dataset, mai a entrambi contemporaneamente.
3. Metti metadati su tutto. Categoria, difficoltà, data di inserimento, origine. Servono per stratificare i risultati e per capire quanto è invecchiato.
4. Tieni un holdout che non guardi. Anche piccolo. È l'unica difesa reale contro l'overfitting umano.
5. Includi i casi negativi. Input ambigui, fuori dominio, prompt injection, domande a cui il sistema deve rifiutarsi di rispondere. Un sistema che risponde con sicurezza a una domanda su cui dovrebbe fermarsi sta fallendo, anche se la risposta è ben scritta.
6. Ogni incidente diventa un caso. È la regola che tiene vivo il dataset senza bisogno di volontà: se una cosa ha generato un ticket, entra nel set. Per sempre.
7. Datalo e potalo. Se un caso è dentro da due anni e passa sempre, forse non sta più misurando niente.
8. Non usarlo da solo. Il golden set copre il «sappiamo cosa deve succedere». Serve accanto alla review umana a campione e al monitoraggio in produzione per tutto il resto.

Necessario, e lontano dal sufficiente

Il golden dataset è la tua suite di test di regressione, non la tua QA. Ti dice se hai rotto qualcosa che sapevi di dover far funzionare. Non ti dice se il prodotto è buono, non ti dice cosa non hai previsto, e smette di dirti qualsiasi cosa nel momento in cui diventa l'obiettivo da massimizzare invece della misura da consultare.

È necessario. È molto lontano dall'essere sufficiente. Ed è la cosa che, in un progetto AI, conviene costruire per prima — perché senza di essa ogni altra decisione tecnica si riduce a «a me sembra meglio».

Fonti

• Zhang et al., A Careful Examination of Large Language Model Performance on Grade School Arithmetic (GSM1k, Scale AI) — https://scale.com/research/llm-performance-grade-school-arithmetic
• Versione completa del paper GSM1k (NeurIPS 2024, Datasets and Benchmarks Track) — https://proceedings.neurips.cc/paper_files/paper/2024/file/53384f2090c6a5cac952c598fd67992f-Paper-Datasets_and_Benchmarks_Track.pdf
• Leaderboard e descrizione del dataset GSM1k (Scale Labs) — https://labs.scale.com/leaderboard/math
• Gema et al., Are We Done with MMLU? (MMLU-Redux, NAACL 2025) — https://arxiv.org/abs/2406.04127
• Versione pubblicata su ACL Anthology — https://aclanthology.org/2025.naacl-long.262.pdf
• A Practical Guide for Evaluating LLMs and LLM-Reliant Systems (il framework delle 5 D) — https://arxiv.org/abs/2506.13023
• Hamel Husain, Your AI Product Needs Evals (i tre livelli di valutazione) — https://hamelhusain.substack.com/p/evals
• Langfuse, Golden dataset evaluation: build and maintain LLM test sets — https://langfuse.com/resources/engineering/golden-dataset-evaluation
• Getmaxim, Building a "Golden Dataset" for AI Evaluation: A Step-by-Step Guide — https://www.getmaxim.ai/articles/building-a-golden-dataset-for-ai-evaluation-a-step-by-step-guide/
• Statsig, Golden datasets: creating evaluation standards — https://www.statsig.com/perspectives/golden-datasets-evaluation-standards
• The Evolution of LLM Adoption in Industry Data Curation Practices (silver, golden e super-golden dataset) — https://arxiv.org/abs/2412.16089