Data leakage: quando un buon risultato AI nasconde un test sbagliato

Un modello può ottenere un risultato eccellente senza aver imparato ciò che interessa davvero. Succede quando nel test entra, direttamente o indirettamente, informazione che non sarebbe disponibile nel momento della previsione. Questo problema si chiama contaminazione dei dati, o data leakage. Riconoscerlo è essenziale per leggere un articolo scientifico e per decidere se una prova aziendale merita di essere sviluppata.

Il confine che rende significativo un esperimento

I dati di addestramento servono a costruire il modello. Quelli di validazione aiutano a scegliere configurazioni e soglie. Il test finale dovrebbe misurare il comportamento su casi rimasti separati da queste decisioni. La separazione non è soltanto una divisione di righe: deve rispettare la domanda. Se vogliamo prevedere nuovi clienti, avere documenti dello stesso cliente in entrambi i gruppi può rendere il compito artificialmente facile.

Kapoor e Narayanan analizzano la contaminazione nella ricerca basata sul machine learning; il lavoro è apparso su arXiv nel 2022 e in Patterns nel 2023. Il messaggio pertinente è metodologico: una valutazione può apparire convincente pur incorporando informazione impropria. Non basta quindi leggere la percentuale finale, né una pubblicazione elimina la necessità di controllare il disegno sperimentale.

Una manutenzione predittiva che conosce già il futuro

Immaginiamo di voler prevedere se una macchina richiederà un intervento entro una settimana. È un esempio ipotetico. Nel database compare un codice di chiusura inserito dopo l'intervento. Se quel codice viene usato come ingresso, il modello può riconoscere l'esito attraverso un'informazione futura. Il risultato sullo storico sembra ottimo, ma nel momento in cui la previsione dovrebbe essere emessa il codice non esiste ancora.

La correzione richiede ricostruire lo stato dei dati alla data della decisione. Non è sufficiente eliminare la colonna più evidente: anche un costo definitivo, una nota successiva o una durata totale possono contenere la risposta. Per ogni variabile conviene annotare quando viene generata, quando diventa disponibile e chi può modificarla. Il tempo di registrazione e il tempo dell'evento possono essere diversi e vanno trattati esplicitamente.

Duplicati che sembrano esempi indipendenti

Un altro caso riguarda documenti, immagini e messaggi quasi identici. Una scansione e la sua versione compressa possono finire in gruppi diversi. Un modello viene così valutato su un materiale molto simile a quello già incontrato. Nelle imprese succede con moduli derivati dallo stesso modello, fotografie consecutive dello stesso pezzo o email appartenenti alla stessa conversazione. La casualità della divisione non risolve questa dipendenza.

La prova dovrebbe riflettere il cambiamento atteso: nuovi periodi, nuovi impianti, nuovi fornitori o nuove famiglie di documenti. Si possono costruire più test, ciascuno con una domanda precisa. Un buon risultato sui documenti abituali e uno più debole su un fornitore mai visto non sono necessariamente contraddittori: descrivono due condizioni operative. Aggregarli senza spiegarlo può nascondere il limite più rilevante.

Quando il test diventa parte dello sviluppo

Anche senza duplicati, un test consultato continuamente può perdere indipendenza. Se ogni errore viene trasformato in una nuova istruzione e poi si misura soltanto sugli stessi casi, si sta ottimizzando sul test. È utile mantenere un insieme separato per la decisione finale e registrare quali esempi sono stati mostrati agli sviluppatori. Dopo molte iterazioni potrebbe essere necessario raccogliere nuovi casi rappresentativi.

Per leggere un paper o una proposta tecnica, poniamo domande concrete: qual è l'unità indipendente? La divisione rispetta il tempo? Le trasformazioni dei dati sono state apprese solo sul gruppo corretto? Esiste una baseline semplice? Sono descritti gli errori? La disponibilità del codice aiuta a riprodurre il procedimento, ma non dimostra da sola che i dati rappresentino il futuro ambiente di utilizzo.

Che cosa significa per il lavoro EL-AI

Per EL-AI, che racconta applicazioni e sviluppo di soluzioni AI, questo criterio serve prima di attribuire valore a un risultato. La disponibilità di documenti e processi in ELAI Nexus può offrire un contesto da studiare; non certifica automaticamente un dataset pronto per addestrare un modello. Un eventuale progetto predittivo dovrebbe partire dalla ricostruzione delle informazioni effettivamente disponibili al momento della decisione.

Una valutazione più severa può abbassare il punteggio iniziale e migliorare la qualità della scelta. Scoprire il limite prima dell'adozione permette di cambiare obiettivo, raccogliere dati mancanti o preferire una procedura più semplice. La reputazione di un progetto AI dipende anche dalla capacità di mostrare questi confini, senza trasformare ogni sperimentazione in un successo già acquisito.

Articolo preparato con assistenza AI e verifica delle fonti indicate. Esempi applicativi ipotetici salvo diversa indicazione. Fonti consultate il 20 settembre 2026.

Copertina illustrativa generata con AI; non rappresenta persone, sedi o installazioni reali di EL-AI.