← Blog

Cosa misura davvero una valutazione dell'IA

Un punteggio di benchmark misura le prestazioni su un test specifico, secondo le sue regole di valutazione. Non dimostra che un modello funzionerà sui vostri documenti né che prenderà le decisioni di cui la vostra azienda ha bisogno. Prima di acquistare, definite cosa significa risultato corretto sui vostri casi, tenete da parte un set di test mai visto ed esaminate gli errori, non solo il punteggio medio.

La barra più alta nel grafico di un fornitore può essere corretta e lasciare comunque senza risposta la vostra domanda d’acquisto. Un modello che vince sulle domande di matematica può avere difficoltà con le abbreviazioni dei vostri ticket di assistenza. Un estrattore di documenti può funzionare bene su fatture pulite e fallire sulle scansioni che il vostro team riceve davvero.

Questo scarto non è disonestà del marketing. È un problema di misurazione, ed è stato documentato con abbastanza cura da poterlo verificare da soli.

Un benchmark è uno strumento, e gli strumenti vanno validati

Nelle scienze che misurano cose non osservabili direttamente, uno strumento di misura deve guadagnarsi fiducia. La proprietà misurata deve essere definita, e il test deve misurare quella proprietà e non qualcosa che è semplicemente correlato con essa. La psicometria chiama questa relazione validità di costrutto. Le stime dell’incertezza rispondono a una domanda diversa: quanto è preciso il risultato?

I benchmark per i modelli linguistici sono strumenti di questo tipo. “Ragionamento” e “utilità” non sono osservabili direttamente, quindi un benchmark li rappresenta. Nel 2025 un gruppo di 29 revisori ha esaminato la solidità di quella relazione in 445 benchmark tratti dalle principali conferenze di elaborazione del linguaggio naturale e apprendimento automatico, in un lavoro pubblicato nel track Datasets and Benchmarks di NeurIPS 2025.

Vale la pena leggere i numeri con calma:

  • 16,0% ha usato test statistici o stime dell’incertezza per confrontare i risultati. Una differenza riportata senza questi controlli può essere meno significativa di quanto sembri.
  • 47,8% dei benchmark che definivano un obiettivo misurava un fenomeno controverso, cioè qualcosa sulla cui definizione il settore non concorda.
  • 81,3% usava la corrispondenza esatta per almeno una parte della valutazione, e il 40,7% la usava esclusivamente. Può andare bene per un’etichetta o un numero preciso; per una risposta aperta, può scartare una risposta valida formulata in modo diverso.
  • 42,6% riutilizzava elementi di benchmark esistenti. Il riutilizzo può trasmettere i limiti di un test, oltre ai confronti utili che consente.

Niente di tutto questo significa che i benchmark siano inutili. Significa che un punteggio di benchmark è un’affermazione più debole di quanto sembri, e la forza di quell’affermazione raramente viene indicata accanto.

Il problema della contaminazione rende il numero ancora più fragile

Un test delle prestazioni su esempi mai visti funziona solo se quegli esempi restano effettivamente mai visti. Con corpus di addestramento ampi e divulgati solo in parte, è difficile da accertare.

Ricercatori della Shanghai Jiao Tong University hanno testato 31 modelli alla ricerca di indizi di contaminazione da dati dei benchmark su GSM8K e MATH, due dataset di ragionamento matematico. Circa la metà mostrava segni compatibili con l’esposizione ai dati dei benchmark. La loro procedura di rilevamento ha campionato cinque posizioni iniziali per ciascun esempio e ha verificato la previsione delle successive sequenze di cinque token. Qwen-1.8B ha previsto correttamente tutte le sequenze campionate in 223 esempi del set di addestramento di GSM8K, 67 esempi del set di addestramento di MATH e 25 esempi del set di test di MATH.

Sono indizi di una possibile esposizione, non un resoconto completo dei dati su cui i modelli sono stati addestrati. La memorizzazione può gonfiare un punteggio, rendendo più difficile distinguere la familiarità con il test dalla capacità di risolvere un caso nuovo. Non dimostra che il modello non abbia capacità utili al di fuori di quel test.

Come appariva nella ricerca

Il mio dottorato riguardava il far svolgere a modelli preaddestrati compiti visivi per cui non erano mai stati addestrati, senza esempi etichettati: trovare corrispondenze semantiche con un modello di diffusione a NeurIPS 2023, poi punti chiave dalla stessa classe di modelli alla conferenza Computer Vision and Pattern Recognition del 2024. Entrambi sono stati misurati su benchmark etichettati standard, perché è così che il settore confronta i metodi.

Quei numeri erano reali e i confronti erano equi. Non potevano però rispondere alla domanda che si porrebbe un’azienda, cioè se il metodo funziona sulle sue immagini, alla sua risoluzione, con la sua illuminazione, secondo la sua definizione di risposta corretta. Le prestazioni sui benchmark e quelle in produzione sono misure diverse. Chiunque abbia portato un modello da un articolo a un prodotto ha visto questo scarto.

Costruite una valutazione intorno alla vostra decisione

La soluzione parte dai vostri casi. Prima di impegnarvi con un sistema di IA, raccogliete esempi della vostra attività ed etichettate a mano il risultato corretto. In questo modo la valutazione avrà un compito e una definizione di successo propri della vostra azienda.

Campionate dalla realtà, non dai casi facili. Prendete lead reali, ticket reali, fatture reali, foto reali, compresi i casi mal formati. Un insieme tratto solo da esempi puliti misura un sistema che non avete.

Scegliete la dimensione del campione in base alla decisione. Iniziate con casi che il vostro team possa etichettare con cura, poi dimensionate la valutazione in base alla differenza di prestazioni da rilevare e al rischio di trarre una conclusione sbagliata. Le linee guida del NIST sui test delle proporzioni rendono esplicite queste scelte. Un numero comodo di esempi non dimostra, da solo, che il test possa rispondere alla vostra domanda.

Scrivete cosa significa corretto prima di guardare qualsiasi output. Due persone dello stesso team spesso non concordano sul fatto che un lead fosse qualificato o che un documento fosse archiviato correttamente. Risolvere quel disaccordo sulla carta vale la pena anche se poi non acquistate nulla, e farlo dopo significa piegare la definizione al risultato.

Etichettate come ambigui i casi ambigui. Imporre una risposta binaria a un caso che il vostro stesso team farebbe salire di livello crea un test che punisce il comportamento corretto.

Tenetene da parte una porzione. Conservate una parte che non viene vista da nessuno di chi costruisce o regola il sistema, compreso il vostro fornitore. Vi dà una stima più pulita delle prestazioni sui casi nuovi. La sua utilità dipende comunque da un campionamento rappresentativo, da etichette affidabili e da un numero di esempi sufficiente a sostenere la decisione.

Esaminate i disaccordi tra i vostri etichettatori. L’accordo misura quanto coerentemente le persone etichettano gli stessi casi; l’accuratezza confronta le risposte con un riferimento. Risolvete le etichette contestate o indicate i casi come ambigui prima di usarli per giudicare il sistema. Per confrontare le persone con il modello, valutate entrambi sulle stesse risposte verificate e con la stessa metrica. Il solo tasso di accordo tra gli etichettatori non dimostra né prestazioni di livello umano né che un fornitore abbia visto le risposte del test.

Un caso, con una definizione utilizzabile di risposta corretta

Immaginate di valutare un assistente che instrada i ticket di fatturazione e redige le risposte. È un esempio illustrativo, non il risultato di un cliente.

Parte della valutazioneCosa registra il revisore
Messaggio del cliente«La mia banca mostra due addebiti per un solo ordine. Uno è in sospeso e uno è completato.»
Instradamento previstoVerifica da parte del team fatturazione. Il messaggio da solo non dimostra la presenza di due addebiti effettivamente contabilizzati.
Bozza accettabileRiconoscere il problema, distinguere la voce in sospeso dall’addebito completato e indicare che il team fatturazione verificherà la registrazione del pagamento.
ErrorePromettere un rimborso o affermare che al cliente è stato addebitato l’importo due volte senza verificare la registrazione.

Un etichettatore potrebbe inizialmente indicare «rimborso necessario» mentre un altro indica «verifica del pagamento». Risolvete quel disaccordo in base alla politica sui pagamenti prima di assegnare un punteggio al modello. Se la registrazione disponibile non basta a dirimerlo, il risultato corretto è l’escalation, non una supposizione forzata.

Una risposta può suonare eccellente e fallire comunque questo caso. Su tutto l’insieme di valutazione, registrate separatamente le promesse di rimborso non supportate e gli instradamenti sbagliati: quegli errori hanno conseguenze diverse. Concordate quali errori impediscono l’uso automatico e quali consentono una bozza rivista da una persona. Poi giudicate il candidato sui casi mai visti in base a quelle stesse regole. Il punteggio medio non deve nascondere l’errore che rende inaccettabile la messa in produzione.

Cosa chiedere a un fornitore

Le domande utili riguardano il metodo, non il punteggio.

Chiedete su cosa è stato misurato il numero riportato e se il sistema è stato regolato su quegli stessi dati. Chiedete di vedere gli errori, raggruppati in base alle loro conseguenze sul vostro flusso di lavoro. Fornite casi che il fornitore non ha mai visto. Chiedete stime dell’incertezza, e ripetete le prove dove le risposte del sistema variano. Ripetere lo stesso test non rappresentativo non ne corregge la copertura.

Un fornitore che sa rispondere a queste domande sta facendo il lavoro. Un fornitore che risponde solo con una posizione in classifica vi ha detto dove si colloca nel test di qualcun altro.

Come lo applichiamo

I flussi di lavoro del nostro catalogo di sistemi di IA richiedono test diversi: estrarre correttamente un documento e qualificare correttamente un lead sono risultati diversi. In entrambi i casi, l’ambito dell’implementazione dovrebbe specificare i casi reali usati per l’accettazione, chi verifica le risposte attese e cosa succede quando il sistema sbaglia.

Il nostro AI Opportunity Audit è l’incarico di pianificazione: un inventario dei flussi di lavoro, calcoli del ROI, decisioni tra sviluppo e acquisto, una mappa dei dati e degli accessi e una roadmap di 90 giorni. Quel piano dovrebbe rendere esplicito il lavoro di valutazione prima che una stima delle ore risparmiate diventi il motivo per acquistare.

La valutazione è anche ciò che dà senso a una soglia di interruzione scritta. Concordare in anticipo di fermarsi a un livello di prestazione definito è una promessa vuota senza un modo concordato di misurare le prestazioni.

Fonti

  • Measuring what Matters: Construct Validity in Large Language Model Benchmarks, track Datasets and Benchmarks di NeurIPS 2025: arxiv.org/abs/2511.04703
  • Benchmarking Benchmark Leakage in Large Language Models, Xu, Wang, Fan e Liu: arxiv.org/html/2404.18824v1

Vuoi che lo facciamo per te?

Prenota una consulenza gratuita di 30 minuti. Nessun pitch finche non vedi il valore.

Teegan Johnson, Founder & CGO, ti risponderà via email in merito alla tua richiesta. Puoi annullare l’iscrizione in qualsiasi momento. Privacy

Preferisce parlare prima? Prenoti una chiamata di 30 minuti.

Aggiungerci come fonte preferita su Google

Un'impostazione gratuita di Google per vedere più dei nostri articoli rilevanti nelle sue ricerche. Può modificarla in qualsiasi momento.