Nel Machine Learning c’è una categoria di errori particolarmente insidiosa: quella degli errori invisibili. Non si manifestano con un crash, non producono messaggi di errore, non interrompono nessuna pipeline. Il modello gira, le metriche sembrano ragionevoli, i grafici raccontano una storia convincente.
Eppure, sotto, nelle predizioni del modello, qualcosa non va.
Questi sono gli errori fondamentali, che nella mia esperienza di Data Scientist sono stati i più difficili da individuare, capire, risolvere e comunicare. E la loro frequenza, anche in team esperti, suggerisce che non si tratti di semplice disattenzione, ma di qualcosa di più strutturale, legato al modo in cui tendiamo a costruire, valutare e fidarci dei modelli.
Errore #1 – Overfitting
L’Overfitting è forse l’errore più discusso nel Machine Learning, eppure continua a presentarsi con sorprendente frequenza, e non sempre nelle forme più riconoscibili.
Come lo studente che studia la lezione “a memoria”, ritrovandosi spiazzato davanti a una domanda formulata in modo diverso, anche il modello può imparare troppo bene i dati che ha davanti. Si adatta così precisamente al training set, al suo rumore, ai suoi esempi specifici, alle sue eccezioni, tanto da perdere qualsiasi capacità di generalizzare. Quando il modello incontra dati nuovi, non sa cosa fare e sbaglia di conseguenza le predizioni.
Il segnale diagnostico più comune è la divergenza tra le metriche di training e quelle di validazione: performance ottime, a volte quasi perfette, sul training set, che degradano irrimediabilmente sul validation set.
Ma esistono anche forme più subdole, in cui questa divergenza è contenuta o mascherata da un validation o test set non sufficientemente rappresentativo, e sono proprio queste le più difficili da intercettare.
Le cause sono spesso tecniche: un modello troppo complesso per la quantità di dati disponibili, un training prolungato oltre il necessario, l’assenza di tecniche di regolarizzazione o di cross-validation.
Vale anche la pena notare che non tutti gli algoritmi sono ugualmente esposti. Le reti neurali, eccellenti su dati non strutturati come immagini e testo, tendono a mostrare questo problema con maggiore frequenza quando applicate a dati tabellari, spesso i più analizzati in ambito aziendale.
È anche qui che entra in gioco l’esperienza del Data Scientist, che deve saper scegliere che algoritmo applicare i base ai dati che si trova di fronte.
Errore #2 – Data Leakage
Il Data Leakage è un errore particolarmente subdolo, che si nasconde nei risultati.
Nella sua definizione essenziale, si verifica quando informazioni che non sarebbero disponibili al momento della predizione reale entrano, in modo diretto o indiretto, nel processo di training o di valutazione del modello.
Il risultato è un modello che sembra funzionare eccezionalmente bene, perché ha avuto accesso, durante l’addestramento, a qualcosa che non avrebbe dovuto vedere.
Chi lavora con i dati da abbastanza tempo conosce bene quella sensazione: le metriche sono ottime, tutto sembra girare alla perfezione, e c’è un momento “eureka” in cui si pensa di aver costruito qualcosa di incredibilmente efficace. Ho vissuto quella sensazione più di una volta. E più di una volta si è rivelata un’illusione prodotta esattamente da questo errore.
Il leakage si annida quasi sempre nella fase di feature engineering.
Costruire variabili che contengono implicitamente informazioni sulla label è un errore più comune di quanto sembri, e tanto più difficile da individuare quanto più la logica di costruzione è complessa.
Un altro caso frequente riguarda i dati temporali: quando uno split che dovrebbe rispettare il fattore temporale (passato vs. futuro) viene eseguito con campionamento casuale, informazioni future si mescolano con informazioni passate, e il modello impara da ciò che non avrebbe potuto conoscere.
Ho visto esperimenti costruiti così, con risultati che puntualmente non reggevano al contatto con la realtà.
Come difendersi? Un modo può essere un’analisi attenta della feature importance, fatta con strumenti di explainability come SHAP, per rivelare segnali anomali. Per esempio, una singola variabile che domina le predizioni in modo sproporzionato deve far “drizzare le antenne” al Data Scientist, segnalando un possibile Data Leakage.
In generale, un modello che sulla carta performa troppo bene, in modo troppo consistente, merita sempre una seconda lettura.
Errore #3 – Bias
Il Bias è un altro errore difficile da vedere perché spesso non si manifesta come un errore.
Il modello gira, le metriche sono accettabili, nessuna pipeline si interrompe.
Eppure il sistema produce predizioni sistematicamente distorte nei confronti di determinati gruppi, contesti o sottopopolazioni.
Le origini del bias sono quasi sempre nei dati. Un dataset che sovrarappresenta certi profili e ne ignora altri produce un modello che riflette fedelmente quella sproporzione.
In questo caso la forma di apprendimento può essere anche corretta ma è applicata a una rappresentazione scorretta del mondo. Il modello impara ciò che gli viene mostrato: il problema è cosa gli viene mostrato.
Esistono diverse forme di bias (in questo articolo avevo provato a raccontare alcuni famosi bias congnitivi).
In tutti i casi, il problema non è nella fase di training ma prima, nella fase di raccolta e costruzione del dataset, il che lo rende strutturalmente più difficile da correggere a posteriori.
La mitigazioni esistono e si articolano su più livelli: tecniche di resampling, vincoli durante il training, calibrazione delle threshold, regole costruite ad hoc.
Ma nessuna di queste soluzioni è universale, e la scelta dell’azione di più appropriata spesso richiede ragionamenti che trascendono i tecnicismi e richiedono invece conoscenza di dominio e business acumen.
Errore #4 – Eccessiva fiducia nei Dati Sintetici
Nel Machine Learning esiste una tentazione ricorrente: quando i dati non bastano, o non sono distribuiti nel modo giusto, si cerca di “generare” sinteticamente ciò che manca.
È un’idea ragionevole in linea di principio, e in alcuni contesti funziona bene. Ma come molti strumenti potenti, i dati sintetici vanno maneggiati con cura.
Per esempio, la Synthetic Minority Oversampling Technique, più nota come SMOTE, è una tecnica molto diffusa per affrontare il problema dello sbilanciamento tra classi.
In un classico problema di classificazione, ad esempio, se devo classificare un cliente di tipo A o tipo B, è facile che abbia classi sbilanciate. I clienti di tipo A infatti potrebbero essere oltre il 90%, e i tipo B addirittura anche meno del 5%. Il modello ha quindi “pochi” esempi da cui attingere per la classe minoritaria (tipo B).
Con SMOTE, o altre tecniche simili, vengono generati nuovi campioni sintetici, che devono andare a “rimpolpare” gli esempi nella classe minoritaria.
C’è tuttavia un errore procedurale che merita attenzione: applicare SMOTE sull’intero dataset prima di effettuare lo split tra training e test set.
In questo caso, i campioni sintetici derivati dal training si mischiano al test set, la valutazione diventa ottimistica per costruzione, e si ricade, per una strada diversa, nello stesso problema del Data Leakage.
Più in generale, i dati sintetici, SMOTE inclusa, non sono una panacea ma un’approssimazione. E come tutte le approssimazioni, hanno limiti che è importante conoscere prima di affidarsi ai loro risultati.
Per esempio, possono essere generati esempi che esistono “matematicamente”, ma che non corrispondono a nulla di realmente osservabile nel fenomeno che si sta modellando.
Oppure, se i dati originali contengono bias di rappresentazione, i campioni sintetici li amplificano. In altre parole, si moltiplicano esempi che erano già sbagliati (ricadendo quindi nell’errore #3).
Errore #5 – Metric Illusion
“C’è un tempo e un luogo per ogni metrica” (semicit.)
Esistono errori che non riguardano il modello in sé, ma il modo in cui lo valutiamo.
L’Accuracy del modello, per esempio, è la metrica più immediata e forse la più ingannevole.
Infatti, se avessi un dataset in cui il 98% dei campioni appartiene alla classe maggioritaria, potrei millantare facilmente un modello con Accuracy al 98%: basterà far predire al modello sempre la classe maggioritaria, ma in questo caso il “modello” sarà un “non-modello”, completamente inutile!
Per evitare di cadere in questo errore paradossale (nel senso che esiste proprio un paradosso chiamato Accuracy paradox), bisogna sapere che l’Accuracy non è una metrica interessante quando le classi sono fortemente sbilanciate.
Precision e Recall invece raccontano storie diverse, e la scelta tra le due non è tecnica ma dipende dalle conseguenze degli errori.
Le due metriche sono in trade-off tra loro: all’aumentare dell’una, diminuirà l’altra.
Su queste non c’è una regola fissa: a volte la Precision può essere più importante, a volte posso “sacrificare” Precision (accettando dei falsi positivi) per aumentare la Recall (minimizzando i falsi negativi).
L’AUC-ROC offre una visione più robusta dell’intera curva di performance, ma anche questa può essere fuorviante in presenza di forte sbilanciamento tra classi, e richiede poi di scegliere la threshold che meglio mitiga il trade-off.
Anche nei problemi di regressione esistono trappole analoghe.
Un R² alto, ad esempio non garantisce che le previsioni siano accurate in senso assoluto, né che gli errori siano distribuiti in modo omogeneo.
In un modello di previsione della domanda, un errore grande su un singolo giorno può essere irrilevante; in un sistema di controllo industriale, può essere critico. La scelta della metrica di valutazione è, anche qui, una scelta di dominio prima che una scelta statistica.
In generale, un modello non è buono (solo) perché ha una metrica alta. È buono perché misura la cosa giusta, nel modo giusto, per le persone giuste.
Conclusione
Rileggendo questi cinque errori insieme, emergono tratti in comune che riguardano chiunque si approcci all’utilizzo di modelli di Machine Learning.
Overfitting, data leakage, bias, dati sintetici mal applicati, metriche sbagliate sono errori che si commettono non per mancanza di conoscenza tecnica, ma per mancanza di esperienza ed eccesso di fiducia nei confronti degli strumenti.
Penso che il Machine Learning, nella sua pratica, richieda una certa forma di mindset “scettico”, proprio come quello di uno scienziato. Questo scetticismo dev’essere direzionato non verso i modelli o gli algoritmi in sé, ma verso i risultati che producono e verso le procedure con cui sono ottenuti.
Gli errori descritti in questo articolo non hanno un’unica soluzione ma hanno, invece, una condizione che forse può aiutarci ad evitarli: la consapevolezza che possano esistere.
Comments are closed.