Data Leakage nei modelli predittivi: il nemico invisibile del Data Scientist

Il modello segna AUC 0.96 sul test set. Il responsabile è soddisfatto. Parte il deploy in produzione. Tre mesi dopo, le previsioni non funzionano — il modello non batte nemmeno un classificatore casuale. Cosa è andato storto?

In molti casi la risposta è data leakage: il training set conteneva informazioni che in produzione non esistono ancora al momento della previsione. Il modello aveva imparato a usare il futuro per predire il futuro. Un risultato garantito in validazione, inutile nel mondo reale.

Il problema è subdolo: non genera warning, non lascia tracce nelle metriche di training. Si manifesta solo quando il modello incontra dati nuovi, in un contesto operativo dove quelle informazioni “sbagliate” non sono più disponibili.

Cos’è il Data Leakage

Il data leakage si verifica quando il training set include feature che contengono informazioni sull’evento che si vuole predire, ma che in produzione non sarebbero disponibili al momento in cui la previsione viene fatta.

La causa più frequente è la dimensione temporale. In qualsiasi problema di previsione — churn, domanda, rischio di credito, manutenzione predittiva — esiste un momento preciso in cui la previsione deve essere prodotta. Tutto ciò che accade dopo quel momento non può essere usato come input. Se una feature viene costruita usando dati successivi all’evento di interesse, il modello impara una correlazione che non potrà mai sfruttare in produzione.

La seconda causa è la costruzione delle feature su insiemi di dati che includono il target. Se per calcolare una statistica — una media, un’aggregazione, un encoding categorico — si usa l’intero dataset prima di fare il split, il test set contiene informazioni derivate anche dai propri esempi.

L’importanza dei timestamp

In un problema di churn prediction su base mensile, il modello deve predire a inizio mese quali clienti lasceranno entro fine mese. Le feature devono essere costruite usando solo dati disponibili a inizio mese: storico delle transazioni, numero di chiamate al supporto, prodotti attivi, data di attivazione. Non possono includere eventi che avvengono durante il mese in corso.

Questo sembra ovvio, ma nella pratica è facile sbagliare. Se il dataset viene estratto “a fine mese con tutto lo storico”, alcune feature aggregate — come “numero di interazioni negli ultimi 30 giorni” — includono già le interazioni del mese corrente. Il modello impara che chi interagisce di più a fine periodo è più a rischio, il che è vero — ma quell’informazione in produzione non è ancora disponibile quando la previsione deve essere fatta.

Esempi pratici di Leakage in produzione

Il caso più citato nella letteratura pratica è quello del cellsite zero nella previsione del churn nelle telecomunicazioni. Nei sistemi di billing di alcuni operatori, i clienti in fase di chiusura del contratto venivano agganciati a un’antenna fittizia con identificativo zero. Nei dataset storici, questa feature risultava altamente correlata con il churn: chi mostrava traffico sul cellsite zero aveva una probabilità di abbandono molto elevata.

Il problema è che il cellsite zero veniva popolato dopo che il cliente aveva già avviato la procedura di recesso. Era una conseguenza del churn, non un segnale predittivo. In produzione, un cliente che non ha ancora deciso di andarsene non avrà mai traffico su quella cella.

Un esempio diverso viene dai modelli di riammissione ospedaliera. In alcuni dataset clinici, tra le feature disponibili compaiono codici diagnostici registrati durante il ricovero corrente. Se il modello deve predire la probabilità di riammissione entro 30 giorni dalla dimissione, usare diagnosi poste durante il ricovero è lecito. Ma se si usano codici di follow-up registrati nelle settimane successive, si sta usando il futuro.

Sventare gli anacronismi nei dati

Il termine tecnico per questo tipo di errore è anacronismo nei dati: una feature viene computata con informazioni che temporalmente non potevano esistere al momento della previsione. Il modo più diretto per evitarli è costruire ogni feature con un cutoff rigoroso: nessun dato posteriore al momento di previsione può entrare nel calcolo.

In pratica, questo richiede di ragionare sulla pipeline di produzione prima di costruire il training set. Quali dati saranno disponibili quando il modello girerà in produzione? Con quale frequenza? Con quale ritardo? Un dato che in teoria è “del giorno prima” potrebbe avere un ritardo di ingestione di 48 ore e quindi non essere disponibile quando serve.

Attenzione ai modelli troppo perfetti

Un segnale d’allarme affidabile è la performance eccessivamente buona. Un modello di churn con AUC superiore a 0.90 su un problema complesso merita un’analisi approfondita prima del deploy, non un applauso. I problemi di business reali raramente producono modelli così precisi — se il risultato è troppo bello, è probabile che il modello stia imparando qualcosa che non dovrebbe sapere.

Le feature importance e i SHAP value sono utili in questa fase. Se una feature ha un peso sproporzionatamente alto rispetto alle altre, vale la pena tracciarne la definizione fino alla sorgente: quando viene computata, su quali dati, con quale logica. Le feature più pericolose non sono quelle costruite male — sono quelle costruite correttamente su dati sbagliati.

Un altro segnale è il crollo delle performance tra validazione e produzione. Se è grande, o se le performance in produzione degradano rapidamente nel tempo, è probabile che qualcosa nel training set non rifletta la realtà operativa. Il data leakage è una delle cause più frequenti di questo pattern.

Vale la pena distinguere il data leakage dal selection bias, con cui viene spesso confuso. Il selection bias è un problema di rappresentatività: il training set non è un campione corretto della popolazione reale. Il data leakage è un problema di informazione: il training set contiene dati che non sarebbero disponibili in produzione. Entrambi rompono il modello, ma per ragioni diverse.

Separazione Learn-Predict

La risposta strutturale al data leakage è il framework Learn-Predict: una separazione netta tra il momento in cui il modello apprende (con dati storici) e il momento in cui il modello predice (con dati presenti). Ogni feature usata in training deve essere computata esattamente come verrebbe computata in produzione al momento della previsione — stessa logica, stesse sorgenti dati, stessa finestra temporale.

In pratica, questo significa costruire due pipeline distinte fin dall’inizio: una di training e una di inference. La pipeline di inference è quella che gira in produzione. La pipeline di training deve replicarne esattamente il comportamento, applicata però ai dati storici. Se le due pipeline divergono anche su un solo dettaglio, il rischio di leakage è concreto.

La gestione del cross-validation in presenza di dati temporali è un caso specifico di questo principio. Il k-fold classico mescola osservazioni di periodi diversi: il fold di validazione può contenere dati antecedenti a quelli usati per il training, il che è una forma di leakage. La soluzione è il time-series split: i fold di validazione sono sempre posteriori ai fold di training, rispettando la direzione del tempo.

Per le feature calcolate su aggregazioni — medie mobili, encoding per frequenza, statistiche di gruppo — devono essere calcolate esclusivamente sul training set e poi applicate al test set come trasformazione fissa. Calcolarle sull’intero dataset prima dello split introduce leakage: il test set incorpora statistiche calcolate anche sui propri esempi.

Una nota operativa: in contesti aziendali, il dato grezzo spesso non arriva con timestamp precisi o con una storia coerente. I sistemi ERP registrano eventi in modo retroattivo, i dati di terze parti hanno latenze variabili, i database vengono corretti dopo il fatto. Documentare esattamente quando ogni informazione diventa disponibile nel flusso operativo — non quando viene registrata nel sistema — è un prerequisito per costruire un training set senza anacronismi.

Il data leakage non è un errore da principianti. Colpisce progetti maturi, con team esperti, su dataset curati. È invisibile finché il modello non va in produzione, e a quel punto il costo — in tempo e credibilità — è già stato pagato. L’unico modo per gestirlo è costruire le pipeline con la giusta disciplina fin dall’inizio, ragionando sempre sulla stessa domanda: questa informazione, sarebbe disponibile al momento della previsione?

Conclusione

Un modello che funziona bene in validazione e fallisce in produzione non è un problema di algoritmo. Quasi sempre è un problema di dati — o meglio, di come i dati sono stati usati. Il data leakage è la versione più silenziosa di questo problema: non si vede durante lo sviluppo, si manifesta solo quando le previsioni smettono di tornare.

Difendersi richiede una sola abitudine: prima di costruire qualsiasi feature, chiedersi quando quella informazione sarebbe disponibile in produzione. Se la risposta è “dopo il momento della previsione”, quella feature non può entrare nel modello. Nessuna eccezione, anche quando la correlazione è alta e la pressione di mostrare risultati è forte.

Se stai costruendo modelli predittivi per processi operativi — supply chain, produzione, customer analytics — e vuoi verificare che la tua pipeline sia progettata correttamente, contattami per una consulenza. Partiamo da un’analisi delle sorgenti dati e del flusso di produzione prima di toccare qualsiasi algoritmo.