A chi serve — A chi trasforma dati storici in segnali, ottimizza parametri, usa machine learning o simula ordini. Un modello può essere programmato senza errori e tuttavia “conoscere” il futuro perché la causalità è stata violata in una join, una feature, uno split o un prezzo di esecuzione.
Il data leakage è la contaminazione di una procedura di ricerca con informazione che non avrebbe dovuto essere disponibile nel punto in cui viene utilizzata. Il look-ahead bias è il caso temporale: la decisione al tempo t incorpora direttamente o indirettamente dati conosciuti soltanto dopo t. Il risultato non è semplicemente ottimistico; è una simulazione di una strategia diversa, dotata di un canale informativo inesistente.
In parole semplici — Non basta ordinare le righe per data. Ogni passaggio deve rispettare questa catena: informazione disponibile → segnale → ordine → eventuale fill → posizione → risultato.
Distinzioni essenziali
| Problema | Che cosa accade | Esempio |
|---|---|---|
| Look-ahead | un valore futuro entra nella decisione | usare la chiusura della barra per comprare alla stessa chiusura senza asta o latenza |
| Target leakage | la variabile da prevedere filtra nelle feature | aggregazione che comprende anche il periodo futuro del target |
| Leakage di preprocessing | stima o selezione usa train e test insieme | normalizzare con media e deviazione dell'intero campione |
| Leakage fra campioni | osservazioni correlate attraversano il confine | label sovrapposte presenti sia nel train sia nel test |
| Informazione revisionata | si usa il valore finale invece del vintage disponibile | dato macro corretto mesi dopo |
| Simulazione non causale | l'ordine riceve un prezzo impossibile | segnale sul close e fill garantito allo stesso close |
Il survivorship bias è distinto: nasce dall'osservare soltanto entità sopravvissute o selezionate a posteriori. Può coesistere con il leakage, ma correggere i timestamp non ricrea da solo strumenti falliti, fondi chiusi o vecchi componenti di un indice.
Tre orologi: segnale, ordine e fill
Una regola di trading deve dichiarare almeno tre momenti:
- Signal time: ultima informazione ammessa nel calcolo.
- Order time: primo istante in cui l'ordine può essere creato e trasmesso.
- Fill time: istante o intervallo in cui il modello di esecuzione può assegnare quantità e prezzo.
Se il segnale usa close[t], un fill a close[t] richiede una meccanica realmente disponibile prima o durante l'asta e dati compatibili con quella decisione. In assenza di tale prova, una convenzione più difendibile è inviare l'ordine dopo il segnale e modellare un'esecuzione successiva. Analogamente, il massimo e il minimo completi della barra non possono decidere un ordine eseguito all'interno della stessa barra senza una sequenza intrabarra osservabile.
Per comunicati, filing e dati macro serve il timestamp di disseminazione, non la data del periodo economico. I dati point-in-time aggiungono inoltre vintage, ritardo del vendor e correzioni successive.
Dove si nasconde il leakage
Feature e trasformazioni
- medie centrate, filtri bidirezionali o interpolazioni che usano osservazioni future;
- ranking cross-section calcolato su un universo ricostruito oggi;
- winsorization, imputazione o standardizzazione stimate su tutto il dataset;
- fondamentali allineati alla chiusura del trimestre invece che al filing;
- split e dividendi applicati senza distinguere data effettiva e informazione nota.
Ricerca e selezione
Il test set viene contaminato anche senza una colonna futura. Consultarne ripetutamente il risultato per scegliere feature, soglie o modelli lo trasforma progressivamente in dato di sviluppo. L'out-of-sample non è un'etichetta del file: è un ruolo nel processo. Numero di alternative provate, decisioni scartate e criteri di selezione devono essere registrati.
Ordini ed esecuzione
Un prezzo OHLC non dimostra che l'ordine sarebbe stato eseguito. Stop e limit possono essere toccati senza fill; la quantità disponibile può essere insufficiente; la priorità in coda non è nota; ritardi e fill parziali cambiano la posizione. Assegnare sempre il prezzo più favorevole della barra è una forma di conoscenza retrospettiva, separata ma collegata ai costi di transazione nel backtest.
Protocollo causale
- Scrivi la decisione prima del codice. Elenca input, timestamp, timezone, cutoff, frequenza e azione prodotta.
- Versiona i dati grezzi. Conserva snapshot, vintage, universo e corporate action senza sovrascrivere la storia.
- Calcola ogni feature “as of”. La query al tempo
tdeve escludere qualunque record conavailable_at > t. - Fitta nel train soltanto. Imputazione, scaling, selezione di variabili e ottimizzazione devono essere appresi nel sottoinsieme consentito e poi applicati in avanti.
- Rispetta l'ordine temporale. Usa split cronologici; se label o posizioni si sovrappongono, valuta purge e gap coerenti con l'orizzonte.
- Congela la specifica. Prima della valutazione finale registra regole, parametri, universo, benchmark e metriche.
- Separa segnale, ordine e fill. Applica ritardi, calendario, tipo d'ordine e dati realmente osservabili.
- Conserva tutte le prove. Un registro delle varianti riduce l'invisibilità del data snooping.
- Ripeti da uno snapshot pulito. Il risultato deve essere riproducibile senza file intermedi costruiti con il futuro.
Esempio illustrativo — Una regola compra all'apertura quando l'utile trimestrale supera le attese. Il database associa il dato alla fine del trimestre, ma il comunicato arriva sei settimane dopo. Il test originario compra quindi prima della pubblicazione. La correzione conserva il timestamp del comunicato, attende la prima finestra negoziabile successiva e usa il vintage allora disponibile. Numeri e sequenza servono a illustrare il controllo causale, non una strategia consigliata.
Test diagnostici
| Test | Che cosa può rivelare |
|---|---|
| Spostare ogni feature di una barra | dipendenza nascosta dalla barra corrente |
| Ricostruire il dataset a una data storica | valori revisionati o membership retrospettiva |
| Aumentare artificialmente latenza e gap | fragilità alla sequenza causale |
| Fittare preprocessing separatamente per fold | contaminazione train/test |
| Eliminare il prezzo “perfetto” della barra | fill impossibili o selezione favorevole |
| Eseguire un placebo con target temporalmente spostato | correlazioni sospette della pipeline |
Un crollo dopo questi test è un allarme, non una prova automatica della causa. Anche un risultato stabile non dimostra assenza di leakage: alcune fughe possono sopravvivere alle perturbazioni.
Limiti
Split temporali, walk-forward o cross-validation non riparano dati già contaminati. Purge ed embargo devono derivare dalla struttura delle label e non essere applicati come rituali. Un dataset causale può comunque soffrire di errori di misura, selezione multipla, cambio di regime, bassa potenza o universo incompleto. La validazione richiede quindi sia controlli statistici sia audit del percorso informativo.
Fonti
- Halbert White, A Reality Check for Data Snooping, Econometrica, 2000 — inferenza quando il risultato selezionato emerge da molte specifiche.
- Robert D. Arnott, Campbell R. Harvey e Harry Markowitz, A Backtesting Protocol in the Era of Machine Learning — separazione fra ricerca, selezione, holdout e scarsità dei dati finanziari.
- David H. Bailey, Jonathan M. Borwein, Marcos López de Prado e Qiji Jim Zhu, The Probability of Backtest Overfitting — rischio di sovra-adattamento derivante dalla selezione fra molte configurazioni.
- Federal Reserve Bank of St. Louis, FRED® versus ALFRED® — differenza fra informazione storica disponibile oggi e vintage noto nel passato.
- scikit-learn, TimeSeriesSplit — cross-validation ordinata nel tempo e parametro di gap; documentazione tecnica ufficiale.