A chi serve — A chi sviluppa o valuta strategie sistematiche e deve distinguere una misura ottenuta su dati realmente non consultati da una semplice continuazione del processo di ottimizzazione.
Un test out of sample (OOS) valuta una specifica già definita su dati che non hanno contribuito a sceglierne regole, variabili, parametri o criteri di selezione. La sua funzione è misurare la capacità di generalizzare oltre il campione di sviluppo. Non dimostra che il comportamento continuerà in futuro: riduce una particolare forma di ottimismo, purché la separazione sia reale.
La purezza dell'OOS riguarda il flusso delle decisioni, non soltanto una colonna di date. Se il risultato del test induce a modificare il modello, quel segmento è ormai informazione di sviluppo. La versione modificata richiede un nuovo test non consultato; non è corretto ritoccare la strategia e continuare a definire “out of sample” gli stessi dati.
Un segmento OOS riutilizzato per scegliere feature, parametri o regole perde dunque lo status di test mai visto, anche se conserva la stessa etichetta.
In-sample, validazione, test e forward non sono sinonimi
| Blocco | Uso consentito | Che cosa lo contamina |
|---|---|---|
| Training / in-sample | Stima e adattamento dei parametri | Non è destinato a una valutazione imparziale |
| Validazione | Scelta fra specifiche e iperparametri | Consultazioni ripetute sono ammesse ma vanno conteggiate |
| Test finale OOS | Valutazione conclusiva di una specifica congelata | Qualunque modifica guidata dal suo risultato |
| Walk-forward | Sequenza di fit e test ordinati nel tempo | Regole ridisegnate dopo aver visto l'intera sequenza |
| Forward o paper test | Osservazione successiva nel tempo, spesso senza denaro reale | Differenze fra fill simulati, operatività e capitale live |
Un OOS può essere un holdout finale, una finestra di una procedura rolling o una parte di cross-validation temporale. Il nome non specifica da solo il disegno. Occorre documentare ampiezza delle finestre, ordine, orizzonte delle label, frequenza di refit e numero totale di decisioni prese sui risultati.
Lo split non ha una proporzione universale
Non esiste una regola generale come “70% sviluppo e 30% test”. La scelta dipende da quantità e qualità dei dati, frequenza, orizzonte di previsione, stabilità del processo, numero di parametri e necessità di osservare regimi diversi. Un test molto lungo riduce i dati di sviluppo; uno troppo corto può produrre stime imprecise o rappresentare un solo regime.
Nelle serie temporali l'ordine conta. Uno split casuale standard può far entrare nel training osservazioni fortemente connesse a quelle del test. Non va però dichiarato universalmente invalido: la sua appropriatezza dipende dal problema e dalle assunzioni sulla dipendenza. In finanza, autocorrelazione, feature costruite su finestre e label sovrapposte richiedono spesso split bloccati, rolling o tecniche specifiche di separazione.
Purging ed embargo
Quando una label usa un intervallo futuro — per esempio il rendimento fra l'apertura e la chiusura di una posizione — un'osservazione di training può condividere parte dello stesso intervallo informativo con un'osservazione di test. Il purging rimuove dal training le osservazioni i cui intervalli di label si sovrappongono al test. L'embargo aggiunge un buffer temporale per ridurre dipendenze residue attorno al confine.
Il buffer deve essere motivato da orizzonte, disponibilità dei dati e struttura della dipendenza; una percentuale fissa non è un principio generale. Purging ed embargo non correggono survivorship bias, dati revisionati, costi irrealistici, test multipli o cambi di regime.
Protocollo di validazione
- Definire l'unità informativa. Specificare timestamp delle feature, inizio e fine della label, frequenza e possibili sovrapposizioni.
- Separare i ruoli. Assegnare dati a training, validazione e test prima di osservare le metriche finali; non chiamare “test” il blocco usato per il tuning.
- Scegliere il disegno. Motivare holdout, rolling origin, finestra expanding o rolling, cross-validation bloccata ed eventuali purge/embargo.
- Congelare la pipeline. Versionare trasformazioni, feature, universo, iperparametri, costi, benchmark e regola decisionale.
- Registrare tutte le prove. Contare modelli, semi, periodi, filtri e metriche consultati, non soltanto la variante pubblicata.
- Eseguire il test finale. Calcolare metriche nette, incertezza e confronto con il benchmark senza riaprire la selezione.
- Classificare l'esito. “Non conclusivo”, “incoerente con l'ipotesi” e “compatibile con ulteriore verifica” sono giudizi più corretti di un pass/fail basato su una soglia universale.
- Documentare ogni riuso. Se il risultato orienta una modifica, spostare formalmente quel periodo nel patrimonio di sviluppo.
Walk-forward e test finale
Nel walk-forward il modello viene stimato usando soltanto dati precedenti a ciascuna finestra di test. La procedura imita refit successivi e mostra come il risultato varia nel tempo. Deve dichiarare se la finestra di training cresce o scorre, il passo di avanzamento, l'orizzonte testato e la cadenza di ricalibrazione.
La concatenazione delle finestre non è automaticamente un track record puro. Se, dopo averne osservato l'insieme, si cambiano famiglia del modello, feature, finestre o regole di arresto, l'intera sequenza ha partecipato allo sviluppo. Quando possibile, una procedura di selezione interna può essere affiancata da un holdout finale esterno mai consultato.
Esempio illustrativo
Esempio dichiarato illustrativo — Un modello mensile viene ristimato con una finestra mobile e valutato sul mese successivo. Le label delle posizioni possono estendersi per più giorni: prima di ogni test si eliminano dal training quelle che ne intersecano l'intervallo. Il ricercatore confronta quattro famiglie di modello nella validazione interna e registra tutte e quattro. Un successivo blocco temporale rimane sigillato per la decisione finale. Le durate sono elementi dell'esempio, non proporzioni raccomandate.
Il risultato va riportato con dispersione fra finestre, costi ed esposizioni, non solo come metrica aggregata. Una media favorevole può infatti nascondere che quasi tutto il valore proviene da un singolo periodo.
Limiti
- Un solo holdout può essere fortemente influenzato dal regime che contiene.
- Riserve multiple di dati non creano nuova informazione indipendente.
- La non stazionarietà può rendere poco rappresentativi sia training sia test.
- La scelta del disegno di validazione è essa stessa una scelta di ricerca e deve entrare nel registro dei tentativi.
- OOS, purging e walk-forward non sostituiscono dati point-in-time, simulazione causale, costi plausibili e controllo del data snooping.
Fonti
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, International Journal of Forecasting, 2000 — rolling origin, ricalibrazione e periodi di test multipli.
- Christoph Bergmeir e José M. Benítez, On the use of cross-validation for time series predictor evaluation, Information Sciences, 2012 — disegni di cross-validation per predittori temporali.
- Christoph Bergmeir, Rob J. Hyndman e Bonsoo Koo, A note on the validity of cross-validation for evaluating autoregressive time series prediction, 2018 — condizioni sotto cui la cross-validation può essere valida per serie autoregressive.
- David H. Bailey et al., The Probability of Backtest Overfitting — selezione fra configurazioni e limiti del semplice holdout nei backtest d'investimento.
- Marcos López de Prado, Advances in Financial Machine Learning — indice ufficiale Wiley, Wiley, 2018 — riferimento monografico per purged K-fold ed embargo; non è citato qui come articolo peer-reviewed.