Come valutare un modello AI sui tuoi dati: metriche, test e gli errori che non si vedono in laboratorio

Chi ha appena capito cos’è l’overfitting arriva quasi sempre alla stessa domanda, ed è quella giusta: «va bene, ma sui miei dati?». Il salto fra il capitolo del corso e il primo modello che entra in produzione non è tecnico, è metodologico. In laboratorio il dataset è pulito, bilanciato e fermo nel tempo. In azienda i dati sono sporchi, sbilanciati e si muovono. Valutare un modello AI sui propri dati significa costruire un esperimento che somigli abbastanza alla realtà da poterci scommettere sopra una decisione aziendale.

Questo articolo non è un elenco di formule: le formule le trovi ovunque. È il gradino che di solito manca, quali metriche dicono qualcosa di utile, come si costruisce un test set che non menta, perché i benchmark pubblici sono quasi irrilevanti per il tuo caso, e cosa succede quando tutti i test passano ma la produzione no.

In questo articolo scoprirai:

• Cosa vuol dire davvero che un modello «funziona»
• Due modelli sullo stesso dataset: quando i numeri si contraddicono
• Costruire un test set che somigli alla produzione
• Data leakage: perché il tuo test set mente senza che te ne accorga
• Perché i benchmark pubblici dicono poco sui tuoi dati

Cosa vuol dire davvero che un modello «funziona»

«Funziona» non è una proprietà del modello: è una proprietà della decisione che il modello deve supportare. Un classificatore che sbaglia il 5% delle volte è ottimo se ordina raccomandazioni di prodotto e potenzialmente pericoloso se filtra candidature o segnala anomalie cliniche. La metrica giusta si sceglie a partire dal costo dell’errore, non dal codice.

La documentazione del Machine Learning Crash Course di Google è esplicita su questo punto: l’accuratezza va evitata sui dataset sbilanciati. Il motivo è aritmetico. Se i casi positivi sono l’1% del totale, un modello che risponde sempre «negativo» ottiene il 99% di accuratezza pur essendo, testualmente, «inutile». Ed è esattamente la situazione della maggior parte dei problemi aziendali interessanti: frodi, guasti, abbandoni, difetti di produzione. Le cose che vuoi prevedere sono rare per definizione.

Precision, recall e F1: quale metrica scegliere per il tuo caso

Le quattro grandezze da avere in testa sono poche. La recall (TP / TP+FN) risponde a «quanti casi veri sono stato capace di trovare»: è la metrica da guardare quando il falso negativo costa caro, una frode non intercettata, una diagnosi mancata. La precision (TP / TP+FP) risponde a «quanto posso fidarmi quando il modello dice sì»: conta quando il falso positivo costa caro, perché ogni allarme consuma tempo di una persona. L’F1 è la media armonica delle due, ed è preferibile all’accuratezza sui dati sbilanciati. L’AUC-ROC misura la capacità di separare le classi indipendentemente dalla soglia scelta.

Il punto pratico è che queste metriche non si scelgono, si negoziano, con chi userà il sistema. Alzare la recall abbassa quasi sempre la precision, e la posizione di quel compromesso è una decisione di business travestita da parametro. Prima di aprire un notebook, la domanda da fare in riunione è: preferite perdere un caso vero o disturbare dieci persone per niente?

Due modelli sullo stesso dataset: quando i numeri si contraddicono

Un esempio costruito, con aritmetica pura e verificabile a mano. Dataset di 10.000 transazioni, 100 delle quali fraudolente (1%, una proporzione realistica). Modello A è un classificatore prudente che segnala 40 transazioni, di cui 30 davvero fraudolente. Modello B è aggressivo: ne segnala 500, di cui 80 fraudolente.

Modello A: precision 75%, recall 30%, accuratezza 99,2%. Modello B: precision 16%, recall 80%, accuratezza 95,6%. Se avessi guardato solo l’accuratezza avresti scelto A, che lascia passare sette frodi su dieci. Se guardi la recall scegli B, che però costringe l’antifrode a esaminare 500 casi per trovarne 80. Nessuno dei due è «il migliore»: la risposta dipende da quanto costa una frode non vista rispetto a un’ora di lavoro istruttoria. Ed è per questo che un report di valutazione con un solo numero dentro non è un report di valutazione.

Valutare un modello AI fuori dai dati di sviluppo: il caso Epic Sepsis

Che questa non sia un’astrazione lo dimostra il caso più documentato del settore. L’Epic Sepsis Model, sistema proprietario di allerta precoce per la sepsi installato in centinaia di ospedali americani, veniva presentato dal fornitore con un AUC dichiarato fra 0,76 e 0,83. Una validazione esterna indipendente pubblicata su JAMA Internal Medicine su 27.697 pazienti e 38.455 ricoveri ha misurato un AUC reale di 0,63, con sensibilità al 33% e valore predittivo positivo al 12%. In pratica: il modello ha mancato 1.709 pazienti settici su 2.552 (il 67%), generando nel frattempo allarmi sul 18% di tutti i ricoverati. Stesso modello, stessa metrica, un divario che nessuno aveva visto finché qualcuno non lo ha misurato su dati diversi da quelli di sviluppo.

Costruire un test set che somigli alla produzione

Il train/test split all’80/20 è il primo strumento che si impara ed è anche il primo che tradisce. La documentazione di scikit-learn lo dice con precisione: tenere da parte un test set aiuta, ma se ci ottimizzi sopra gli iperparametri «la conoscenza del test set può filtrare nel modello e le metriche non riportano più le prestazioni di generalizzazione». Se hai provato quaranta configurazioni e hai tenuto quella con lo score migliore sul test, il tuo test set è diventato un secondo training set.

Da qui la cross-validation, ma soprattutto la variante giusta di cross-validation. E qui la maggior parte degli errori aziendali nasce dallo scegliere quella sbagliata.

Split stratificati, per gruppo e temporali: quale usare

StratifiedKFold mantiene la proporzione delle classi in ogni fold. Senza, su un dataset con 45 negativi e 5 positivi, un normale KFold produce fold interi privi della classe rara, e metriche che diventano indefinite o assurde. GroupKFold garantisce che lo stesso gruppo non compaia mai contemporaneamente in training e in test. È il caso di ogni dataset con osservazioni ripetute per soggetto: più visite dello stesso paziente, più ordini dello stesso cliente, più sessioni dello stesso utente. Se non separi per gruppo, il modello riconosce il soggetto invece di imparare il fenomeno, e il punteggio è gonfio.

TimeSeriesSplit serve quando i dati hanno un ordine temporale: allena sul passato, testa sul futuro. Uno split casuale su dati temporali è la forma più elegante di autoinganno che esista, perché il modello vede il futuro mentre impara. Se il tuo problema ha una data dentro, e quasi tutti i problemi aziendali ce l’hanno, questo è l’unico split difendibile.

Data leakage: perché il tuo test set mente senza che te ne accorga

Il leakage è il modo più comune per ottenere un 98% di accuratezza in laboratorio e un disastro in produzione. Ha tre forme ricorrenti, tutte banali e tutte frequentissime.

La prima è il preprocessing calcolato su tutto il dataset. Se normalizzi i dati con media e deviazione standard stimate prima dello split, il test set ha già influenzato la trasformazione. La documentazione scikit-learn indica la soluzione: la standardizzazione va appresa dal training set e applicata al test set, e usare una Pipeline lo garantisce automaticamente. È una riga di codice che separa una valutazione onesta da una fasulla.

Leakage da feature e leakage organizzativo: quando il dato contiene già la risposta

La seconda è la feature che contiene la risposta. Un campo «data di chiusura pratica» in un modello che deve prevedere se la pratica verrà chiusa, un «importo rimborso» in un modello antifrode: informazioni che in produzione, al momento della predizione, non esistono ancora. Microsoft, nelle linee guida del Well-Architected Framework per i carichi di lavoro AI, raccomanda esplicitamente di verificare la presenza di perdite di dati «per impedire che le informazioni future o derivate dall’etichetta possano contaminare i dati di training», e avverte che «anche la perdita sottile può danneggiare le prestazioni del modello».

La terza è organizzativa: i dati con cui valuti non sono i dati che avrai. Se il modello girerà su documenti scansionati e tu lo valuti su testo già estratto e pulito, non stai valutando il sistema, ne stai valutando un pezzo in condizioni di favore. È la ragione per cui preparare i dati aziendali è un lavoro che precede la valutazione, non che la segue, ed è anche uno dei motivi ricorrenti dietro il fatto che la larga maggioranza dei progetti AI non arriva mai in produzione.

Perché i benchmark pubblici dicono poco sui tuoi dati

La classifica su cui hai scelto il modello misura una cosa diversa da quella che ti interessa. Non è un’opinione: è stato misurato. Il team di ricerca di Scale ha costruito GSM1k, un benchmark di problemi aritmetici progettato per replicare stile e complessità del popolarissimo GSM8k ma generato interamente da annotatori umani dopo l’addestramento dei modelli, quindi impossibile da aver visto in fase di training. Il risultato: alcune famiglie di modelli, fra cui Phi e Mistral, hanno perso fino a 13 punti percentuali di accuratezza passando dal benchmark noto a quello equivalente ma inedito, mentre i modelli di frontiera hanno mostrato un divario minimo.

Interessante è la spiegazione degli autori, più sfumata dello slogan che circola: la contaminazione diretta dei dati «probabilmente non è la spiegazione completa». Il fenomeno passa anche per meccanismi indiretti, raccogliere dati di training simili ai benchmark, selezionare il checkpoint del modello in base al punteggio ottenuto. In altre parole, un intero settore ha ottimizzato contro un test. È overfitting su scala industriale, ed è esattamente lo stesso errore che si fa scegliendo la configurazione migliore sul proprio test set.

Come usare i benchmark quando devi valutare un modello AI sui tuoi dati

La conseguenza operativa è semplice e impopolare: una classifica pubblica serve a scartare, non a scegliere. Restringi la rosa a tre candidati con i benchmark, poi decidi con il tuo dataset. Se stai valutando modelli linguistici, la comparazione va fatta sulle tue domande, sui tuoi documenti, con i tuoi criteri di correttezza, un tema che tocchiamo anche nella guida su come funzionano gli LLM e in quella sul funzionamento del RAG.

Valutare un LLM sui tuoi dati: golden dataset e giudici automatici

Con i modelli generativi la valutazione cambia natura, perché non esiste una risposta unica corretta da confrontare. Lo strumento base resta però lo stesso: un insieme di casi di riferimento. Microsoft lo chiama golden dataset, coppie input-output attendibili, create o validate da esseri umani, rappresentative del dominio e con rumore minimo. È l’equivalente del test set, e va costruito una volta e curato per sempre. Cento casi reali scelti bene valgono più di diecimila casi sintetici, perché i casi reali contengono le ambiguità che i casi sintetici non sanno inventare.

Sulle metriche, le linee guida Microsoft insistono su un punto: non basarsi mai su una singola misura. La groundedness, quanto la risposta è effettivamente sostenuta dal contesto fornito e non inventata, è centrale in ogni sistema documentale, ed è il primo controllo da mettere in piedi quando si progetta un RAG aziendale su misura. Ma un modello ben ancorato può comunque essere sbilanciato, verboso o fuori tono: servono più assi di misura, non uno solo.

Quanto ci si può fidare di un LLM che giudica un altro LLM

La tecnica dell’LLM-as-a-judge, usare un modello per valutare gli output di un altro, è ormai standard perché è l’unica che scala. Va usata sapendo cosa misura. Uno studio sistematico su 21 modelli giudice di 9 fornitori, per circa 541.000 giudizi, ha rilevato che l’accordo con le etichette umane, misurato con il kappa di Cohen invece che con la percentuale grezza di coincidenze, crolla drasticamente: su MT-Bench il divario fra le due misure arriva a 41 punti percentuali. Gli autori segnalano inoltre che un’alta riproducibilità (test-retest sopra 0,95) può convivere con un forte bias di posizione, cioè con la tendenza a preferire la risposta che compare per prima. Un giudice coerente non è necessariamente un giudice valido. Traduzione operativa: usa i giudici automatici per il volume, ma calibrali contro un campione umano e alterna l’ordine delle risposte.

Quando i test passano e la produzione no

Il modello supera la valutazione, va online, e per qualche settimana funziona. Poi smette, lentamente e senza segnalarlo. Non è aneddotica: lo studio Temporal quality degradation in AI models pubblicato su Scientific Reports ha testato 128 coppie modello-dataset (4 algoritmi × 32 dataset da sanità, meteo, traffico aeroportuale e finanza) e ha osservato degradazione temporale nel 91% dei casi. Il dettaglio più utile è un altro: modelli diversi invecchiano a velocità diverse sullo stesso identico dataset, e la degradazione a volte è graduale, a volte è esplosiva, stabile per mesi e poi un collasso improvviso. Una lettura divulgativa dello studio ne riassume le implicazioni pratiche per chi porta modelli in produzione.

Data drift e concept drift: come invecchia un modello in produzione

Le cause si dividono in due. La data drift è il cambiamento della distribuzione degli input: nuovi clienti, nuovi canali, un formato di file diverso. La concept drift è il cambiamento della relazione fra input e risposta: il comportamento d’acquisto che cambia dopo il lancio di un concorrente, e le stesse feature che non significano più la stessa cosa. La seconda è più insidiosa perché i dati in ingresso sembrano normali, ed è la ragione per cui la manutenzione di un sistema AI dopo il deployment è una voce di progetto, non un imprevisto.

Il problema pratico è che le etichette vere arrivano tardi o non arrivano affatto: sapere se un cliente abbandonerà richiede mesi. La guida di Evidently AI sul data drift propone il monitoraggio della distribuzione degli input come segnale proxy della qualità del modello quando il ground truth non è disponibile, con un’indicazione tecnica precisa: test di ipotesi come Kolmogorov-Smirnov o chi-quadro su dataset piccoli, metriche di distanza come Wasserstein, Jensen-Shannon o Population Stability Index sui grandi volumi, dove i test statistici diventano «eccessivamente sensibili». E un avvertimento che vale come regola: il drift rilevato non è un trigger automatico di retraining. Prima si verifica se sia un bug della pipeline dati o un cambiamento con una spiegazione di business; a volte la risposta corretta è spostare una soglia, non riaddestrare. Su come strumentare tutto questo abbiamo un pezzo dedicato all’osservabilità degli agenti AI in produzione.

Un protocollo minimo per valutare un modello sui tuoi dati

Mettendo insieme i pezzi, ecco la sequenza difendibile, quella che regge davanti a chi ti chiede perché dovrebbe fidarsi del numero che hai scritto nella slide.

Uno. Definisci la decisione prima della metrica: cosa succede quando il modello sbaglia in un verso e cosa succede quando sbaglia nell’altro. Due. Costruisci un test set che rispetti la struttura reale dei dati: stratificato se le classi sono sbilanciate, per gruppo se ci sono soggetti ripetuti, temporale se c’è una data. Tre. Riserva un holdout finale che tocchi una volta sola, alla fine: tutto il tuning avviene in cross-validation sul training.

Valutazione per fetta di dati e monitoraggio prima del deploy

Quattro. Non fermarti alla metrica aggregata. La valutazione per fetta di dati è ciò che distingue un’analisi da una pagella: nel materiale didattico di Made With ML sulla valutazione dei modelli, un classificatore con prestazioni complessivamente solide mostra F1 per classe che vanno da 0,932 a 0,813, quasi dodici punti di differenza fra la classe migliore e la peggiore, invisibili nel numero unico. Fai lo stesso sui segmenti che ti interessano: il cliente grande, la lingua minoritaria, il testo corto.

Cinque. Metti in piedi il monitoraggio prima del deploy, non dopo il primo incidente: distribuzione degli input, metriche di qualità dove le etichette arrivano, e una baseline di riferimento con cui confrontare. Sei. Definisci in anticipo la soglia oltre la quale si interviene e chi la guarda. Un cruscotto senza un proprietario è un cruscotto spento.

Nessuno di questi passaggi è esotico. Sono tutti noiosi, e sono esattamente ciò che separa un modello che ha funzionato in un notebook da un sistema di cui ci si può fidare, il passaggio di cui parliamo più diffusamente nel pezzo su come si porta un agente AI dal pilot alla produzione. La valutazione non è l’ultimo capitolo del progetto: è l’infrastruttura che gli permette di durare.

Fonti:

• Google Machine Learning Crash Course — Accuracy, precision, recall
• JAMA Internal Medicine — External validation of a widely implemented sepsis prediction model
• scikit-learn — Cross-validation: evaluating estimator performance
• Microsoft Azure Well-Architected Framework — Test dei carichi di lavoro AI
• Scale AI Labs — GSM1k: LLM performance on grade school arithmetic
• arXiv — Studio sistematico su 21 modelli giudice e circa 541.000 giudizi (LLM-as-a-judge)
• Scientific Reports (Nature) — Temporal quality degradation in AI models
• NannyML — Il 91% dei modelli ML degrada nel tempo: lettura dello studio
• Evidently AI — Data drift in produzione: come rilevarlo e cosa farne
• Made With ML — Evaluation (corso MLOps)