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 | decidere usando il prezzo finale dell'asta e retrodatare l'ordine alla stessa asta |
| 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 | il training incorpora esiti non ancora osservabili al suo cutoff | una label di cinque sedute termina dentro il periodo di 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: istante in cui il segnale è pronto; va distinto dal cutoff, l'ultima informazione ammessa nel calcolo.
- Order time: creazione e invio dell'ordine, con il successivo arrivo e l'accettazione sul mercato.
- Fill time: istante o intervallo in cui l'ordine ammesso può incontrare prezzo e quantità compatibili.
Se la decisione richiede il prezzo finale close[t], non può determinare la partecipazione alla stessa asta che forma quel prezzo. Un ordine di chiusura impartito prima rispetta invece i cutoff della sede e usa l'informazione allora disponibile: la scheda NYSE citata distingue ingresso degli ordini e processo d'asta. Un fill successivo potrebbe avere lo stesso prezzo numerico, ma non lo stesso istante. Massimo e minimo definitivi della barra non sono input disponibili per una decisione precedente al loro completamento; un replay intrabarra deve usare soltanto gli eventi già osservati a ogni decisione.
Per comunicati, filing e dati macro, la data del periodo economico non è la data di disseminazione. La strategia deve inoltre aver ricevuto e poter elaborare il dato. I dati point-in-time conservano le versioni (vintage): una revisione successiva non sostituisce quella disponibile alla decisione. ALFRED ricostruisce ciò che era noto a una data storica; non certifica da solo l'orario intraday o la latenza del proprio fornitore.
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.
Per standardizzare una variabile: z = (x − media_train) / deviazione_train. Media e deviazione si stimano nel training di ciascun fold e si riusano sul relativo test senza ricalcolarle; la procedura deve gestire anche deviazione nulla. La documentazione scikit-learn distingue fit e transform.
Ricerca e selezione
Il data snooping riguarda il riuso del campione per inferenza o selezione: può produrre un vincitore fortuito anche quando tutti gli input rispettano il tempo. Non coincide quindi con il look-ahead.
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”. Alla decisione
t, escludi i record conavailable_at > te scegli, per ciascun dato, la versione allora disponibile; documenta come è costruitoavailable_at. - Fitta nel train soltanto. Stima imputazione, scaling e selezione di variabili nel training di ciascun fold; applica al test le trasformazioni già apprese. La selezione dei parametri usa la validazione, preservando il test finale.
- Rispetta l'ordine temporale. Ogni label usata per il training deve essere già osservabile al suo cutoff. Se gli intervalli informativi si sovrappongono al test, valuta purge e gap in base alle date effettive, non alla sola vicinanza delle righe.
- 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 disponibilità e vintage del comunicato e del consenso sulle attese, calcola il segnale e attende una finestra di esecuzione compatibile con l'arrivo dell'ordine. 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.
Label future e confini del training
La label è il risultato da prevedere. Per esempio, il rendimento delle cinque sedute successive alla riga t è noto soltanto dopo quelle sedute. Usarlo come obiettivo di un training svolto più tardi è normale; inserirlo fra gli input di t, oppure usarlo in un training concluso prima che maturi, introduce informazione futura. Rimuovere le label che oltrepassano il cutoff è diverso dal vietare qualsiasi correlazione fra osservazioni. Il gap di scikit-learn conta righe escluse: non ricostruisce automaticamente durata e disponibilità di ogni label.
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, Common pitfalls — Data leakage e StandardScaler — training, preprocessing e applicazione al test.
- NYSE, Opening and closing auctions, p. 2 — sequenza di ingresso degli ordini e asta di chiusura, nel mercato descritto.
- scikit-learn, TimeSeriesSplit — cross-validation ordinata nel tempo e parametro di gap; documentazione tecnica ufficiale.