L'ottimizzazione walk-forward ha la reputazione di essere il modo onesto di tarare una strategia, e se la merita — rispetto all'ottimizzare su tutti i dati e ammirare il risultato. Ma la tecnica ha modalità di fallimento silenziose, e ognuna produce lo stesso artefatto: un report di validazione che dice "robusta" spillato a una strategia che non lo è. Ecco le tre contro cui abbiamo dovuto progettare, ordinate per i danni che lasciano.
Fallimento uno: le finestre perdono informazione
Il modo sbagliato: tarare su gennaio-giugno, validare su luglio, poi lasciare che qualcosa di luglio influenzi un secondo passaggio — una nuova esecuzione dopo aver visto il numero out-of-sample, una "piccola modifica" alla griglia di parametri, una feature normalizzata sull'intera serie. Ciascuna sembra innocua. Insieme trasformano la finestra out-of-sample in dati in-sample con un ritardo.
Il danno: uno Sharpe out-of-sample che misteriosamente segue lo Sharpe in-sample. I risultati out-of-sample veri sono rumorosi e deludenti; una relazione IS/OOS sospettosamente regolare significa che l'informazione sta fluendo all'indietro. Monitoriamo il rapporto esplicitamente — in-sample oltre 3x l'out-of-sample segnala la run, e un out-of-sample pari o inferiore a zero la uccide per quanto bello possa apparire l'in-sample.
Fallimento due: shopping di metriche tra le finestre
Esegui tre finestre walk-forward, ottieni tre risultati rumorosi, poi riassumi: Sharpe medio? Mediano? Scartare la finestra peggiore per via di un "cambio di regime"? Ogni scelta è un grado di libertà, e un ottimizzatore determinato (umano o bayesiano) troverà la sintesi sotto la quale questa strategia appare al meglio. Settantacinque trial Optuna per finestra sono settantacinque occasioni per adattarsi al rumore, moltiplicate per quante sintesi si è disposti a prendere in considerazione.
Il danno: una strategia che supera la validazione e poi in reale consegna la performance della finestra peggiore, perché la finestra peggiore era l'unica onesta. La nostra regola: l'aggregazione è fissata in configurazione prima della run, il budget di trial è fissato, e l'analista legge i risultati per singola finestra con la dispersione in evidenza. Una strategia che ha bisogno della sintesi compiacente per passare non passa.
Fallimento tre: l'holdout che ha smesso di esserlo
Un holdout funziona esattamente una volta. La seconda volta che una strategia viene valutata su di esso — dopo una ritoccata ai parametri, una modifica al segnale, un "diamo solo un'occhiata" — non è più un holdout; è un lento validation set. Quindici giorni intatti sembrano banali da preservare finché non arriva la pressione dell'iterazione e ricontrollare sembra innocuo.
Il danno è sottile: risultati di holdout che migliorano attraverso le iterazioni della stessa strategia. Dati out-of-sample freschi non hanno alcun motivo di premiare l'iterazione tre rispetto alla uno, e quando lo fanno, l'holdout è stato scavato. Imponiamo il colpo unico in modo meccanico: l'holdout viene valutato una volta per esecuzione della pipeline, il risultato viene scritto a registro, e una strategia che ha bisogno di un altro tentativo ripercorre l'intero percorso a ostacoli — nuove finestre comprese. Deve conservare almeno il 70% dello Sharpe out-of-sample walk-forward, e quel dado non si tira una seconda volta.
Il segnale che sopravvive a tutti e tre
Prima di tutto questo, eseguiamo una semplice analisi di sensibilità: spostiamo ogni parametro del ±20% e osserviamo le metriche. Un edge reale degrada in modo graduale; una coincidenza precipita da un dirupo. È il test più economico della pipeline e mette il veto su strategie che avrebbero superato indenni tutto quanto sopra — perché un dirupo nei parametri è l'aspetto che ha l'overfitting prima che gli si dia occasione di nascondersi nel macchinario di validazione.
Niente di tutto questo rende sicura l'ottimizzazione. Rende rumorose le modalità di fallimento — che è il massimo che si possa onestamente chiedere a un processo di validazione.
← Tutti gli articoli