Test walk-forward per bot crypto: un esempio pratico
Scegli le impostazioni sui dati precedenti, congelale per una finestra successiva e preserva il percorso dell’equity. Lavora sulla suddivisione delle date, regola di selezione, compounding e decisioni sulle posizioni in portafoglio aperte.
Testi venti configurazioni del bot sullo stesso grafico e scegli quella con il rendimento più alto. Le sue impostazioni ora riflettono le informazioni di tutto quel periodo. Eseguirla nuovamente sulle stesse date non ti fornisce nuove evidenze.
Il test walk-forward seleziona ripetutamente le impostazioni su una finestra di training precedente, le congela per una successiva finestra di test e combina i risultati di queste finestre successive. Ti permette di analizzare un processo di selezione in condizioni di mercato variabili, evitando che i prezzi futuri influenzino ogni decisione di selezione.
Per le strategie grid e DCA, c’è un ulteriore problema contabile: le coin e le posizioni aperte possono oltrepassare il confine della finestra. Un test utile richiede una regola per queste posizioni in portafoglio prima che compaia il primo risultato.
Training, test e demo forward hanno significati diversi
| Termine | Cosa fai | Cosa può mostrare |
|---|---|---|
| Training in-sample | Confronta le impostazioni consentite su una finestra storica precedente | Quale candidato sceglierebbe la tua regola di selezione |
| Test storico out-of-sample | Applica le impostazioni scelte sulla finestra successiva senza rituning | Come si comporta quella selezione su dati storici successivi |
| Sequenza walk-forward | Ripeti training e test man mano che il tempo avanza | Il comportamento combinato del processo di selezione |
| Demo forward | Blocca una configurazione e osserva nuovi dati di mercato con fondi virtuali | Se il workflow e il comportamento corrispondono al tuo piano in un nuovo periodo |
La guida generale al backtesting tratta le principali limitazioni della simulazione storica. Il walk-forward aggiunge una suddivisione temporale ripetuta; non elimina le ipotesi di esecuzione, gli errori nei dati o la tentazione di modificare le regole dopo aver visto i risultati.
La documentazione sul walk-forward di QuantConnect descrive la selezione dei parametri su finestre mobili e il compromesso nella frequenza di ottimizzazione. Una ri-ottimizzazione più frequente genera più decisioni e maggiori opportunità di adattarsi al rumore recente.
Scrivi il protocollo prima di confrontare i risultati
Scegli il mercato, l’intervallo dei dati, il fuso orario e le impostazioni esatte dei candidati. Mantieni la lista dei candidati abbastanza ridotta da poterla esaminare. Un test con tre configurazioni dichiarate è più facile da spiegare rispetto a una ricerca tra migliaia di combinazioni non documentate.
Specifica inoltre:
- La durata del training e la durata del test, inclusi i timestamp esatti dei limiti.
- La metrica di selezione, il requisito minimo di evidenza e la regola di spareggio.
- Commissioni, slippage, dimensioni minime, arrotondamenti e modello di esecuzione.
- Il trattamento delle posizioni in portafoglio e degli ordini aperti a ogni confine.
- Gli asset iniziali del benchmark e le regole di ribilanciamento.
Ad esempio, un protocollo ipotetico potrebbe scegliere il rendimento di training più alto tra tre candidati il cui drawdown di training rimane sotto un limite prestabilito. Se nessuno soddisfa il requisito, la strategia mantiene liquidità per il mese di test successivo. Definisci il limite di drawdown e la soluzione di fallback prima di esaminare i mesi di test.
Il limite è un vincolo di selezione, non una promessa sul drawdown futuro. Una strategia che lo rispetta durante il training può superarlo nella fase di test.
Dividi le date senza contare due volte un mese di test
Usa tre mesi per il training e un mese per il test in questo esempio illustrativo di pianificazione rolling. Ogni timestamp riportato di seguito è in UTC e ogni intervallo include la data di inizio ma esclude quella di fine.
| Round | Finestra di training | Finestra di test non toccata |
|---|---|---|
| 1 | 1 gen - 1 apr | 1 apr - 1 mag |
| 2 | 1 feb - 1 mag | 1 mag - 1 giu |
| 3 | 1 mar - 1 giu | 1 giu - 1 lug |
| 4 | 1 apr - 1 lug | 1 lug - 1 ago |
Le finestre di training si sovrappongono. Le quattro finestre di test no. Aprile può diventare dati di training storico per il turno successivo solo dopo che è terminato; non puoi usare l’andamento dei prezzi di aprile per scegliere le impostazioni testate su aprile stesso.
Salva la selezione effettuata a ogni confine. Un resoconto completo include i candidati scartati e le loro metriche di training, così un altro revisore può ricostruire perché è stato scelto il vincitore.
Un primo round completo
La tabella seguente contiene valori didattici inventati. Non si tratta di risultati di backtesting misurati né di osservazioni di mercato. Si supponga che la regola di selezione scritta richieda un drawdown nel training non superiore al 10%, quindi selezioni il rendimento netto più alto nel training. Tutti i rendimenti sono al netto dei costi dichiarati dal modello.
| Candidato | Rendimento del training | Drawdown massimo del training | Ammissibile? |
|---|---|---|---|
| A | +5,0% | 8,0% | Sì |
| B | +8,0% | 15,0% | No |
| C | +4,0% | 6,0% | Sì |
Il protocollo seleziona A. Il rendimento più alto del candidato B non prevale sul vincolo di drawdown dichiarato. Il candidato C rimane nel registro anche se perde il confronto.
Blocca A per aprile. Supponiamo che l’esempio didattico gli attribuisca un rendimento netto di aprile pari a −2%. Questo valore entra nel record out-of-sample. Passare a C perché avrebbe gestito meglio aprile significherebbe riutilizzare il mese di test nella decisione.
Al confine di maggio, il protocollo originale confronta nuovamente tutti i candidati utilizzando i dati da febbraio ad aprile. Può selezionare C per maggio se C risulta vincente in questo nuovo confronto di training. Si tratta di un aggiornamento pianificato che utilizza le informazioni disponibili in quel momento.
Unisci le ultime finestre di test in un unico percorso dell’equity
Supponiamo che le prossime selezioni e i rendimenti di test siano i seguenti. Questi valori proseguono lo stesso esempio contabile fittizio e non derivano da una reale simulazione di strategia.
| Mese di test | Configurazione selezionata | Rendimento netto del test | Equity iniziale | Equity finale |
|---|---|---|---|---|
| Aprile | A | −2,0% | 1.000,00 $ | 980,00 $ |
| Maggio | C | +1,0% | 980,00 $ | 989,80 $ |
| Giugno | A | −3,0% | 989,80 $ | 960,11 $ |
| Luglio | C | +2,0% | 960,11 $ | 979,31 $ |
I valori finali sottostanti non arrotondati sono 980, 989,8, 960,106 e 979,30812. Il rendimento combinato è:
(1 − 0,02) × (1 + 0,01) × (1 − 0,03) × (1 + 0,02) − 1 = −2,069188%.
La somma delle quattro percentuali dà −2%, che però differisce dal risultato composto. Porta l’equity finale della finestra precedente in quella successiva e arrotonda solo ai fini della visualizzazione.
Le osservazioni di fine mese mostrano un calo massimo di circa il 3,99% rispetto ai 1.000,00 $ iniziali. L’equity all’interno del mese potrebbe essere scesa ulteriormente, quindi le osservazioni mensili non permettono di determinare il vero drawdown massimo.
Per questo esempio contabile, si assume che ogni reset ai confini sia incluso nei rendimenti netti mensili indicati. Un vero backtest deve calcolare tali reset a partire dalle proprie posizioni in portafoglio e dal modello di esecuzione.
Decidi cosa succede alle posizioni in portafoglio aperte di grid o DCA
Supponiamo che un bot termini aprile con 0,01 BTC e 400 USDT in portafoglio. Con un ipotetico prezzo BTC di 50.000 $, il suo equity è di 900 USDT. Un nuovo mese non lo riporta al valore iniziale di 1.000 USDT.
Scegli una politica di gestione dei limiti coerente:
Trasferisci le posizioni in portafoglio. Porta le monete effettive, la liquidità e lo stato delle posizioni nella finestra di test successiva. Definisci cosa comporta una modifica delle impostazioni sugli ordini e sulle posizioni già esistenti. Il simulatore deve supportare questa transizione; un nuovo backtesting avviato con asset di default potrebbe non rappresentarla correttamente.
Chiudi e azzera. Annulla gli ordini aperti, vendi o chiudi l’esposizione residua utilizzando il modello di esecuzione dichiarato, sottrai i costi e inizia la finestra successiva con l’equity risultante. Se la configurazione successiva richiede una posizione iniziale in coin, modella anche quell’acquisizione e i relativi costi.
Entrambe le policy possono descrivere un processo operativo reale. Modificarle dopo aver visto i risultati può nascondere delle perdite. Mantieni la stessa policy anche nel benchmark, dove rilevante, e mostra l’effetto di una policy diversa come verifica di sensibilità separatamente etichettata.
Controlla il modello di esecuzione e il benchmark
Una candela che tocca un prezzo limite non dimostra che il tuo ordine sarebbe stato eseguito per intero. I dati delle candele possono anche nascondere se sia stato raggiunto prima un livello di acquisto o di vendita. Impostazioni grid molto fitte possono sembrare allettanti in una simulazione che presume un ordinamento intrabar favorevole.
Documenta come il modello gestisce i fill parziali, la priorità in coda, lo spread e i gap. Ripeti l’analisi con costi o fill meno favorevoli, se lo strumento lo consente. Una conclusione che scompare dopo una piccola variazione dei costi merita un approfondimento.
Usa le stesse date, equity iniziale e asset iniziali per il confronto. Un bot che parte con metà in coin e metà in contanti non è direttamente confrontabile con un benchmark completamente investito, a meno che tu non spieghi questa differenza di allocazione.
La checklist dei risultati del backtesting è utile per esaminare il report ottenuto. Tieni traccia del percorso mensile, dell’attività di trading, dell’esposizione e dei costi insieme al rendimento totale.
Tieni separata la valutazione finale dalla progettazione del protocollo
I test walk-forward ripetuti possono a loro volta diventare una forma di training. Se analizzi tutti e quattro i mesi di test, modifichi la lista dei candidati e ripeti lo stesso periodo, il metodo aggiornato ha utilizzato informazioni provenienti da quei mesi.
Registra quella revisione e riserva la cronologia non modificata o i nuovi dati forward per la valutazione successiva. Un nuovo etichettamento sulle stesse date non le rende di nuovo non viste.
Il registro scaricabile può essere semplice: una riga per ogni round con date di training, versione del candidato, metriche di selezione, configurazione scelta, date di test, modello di costo, policy sui limiti e risultato netto del test. Conserva i report grezzi e i riferimenti ai dati accanto ad esso. L’esempio qui sotto include la tabella fittizia come CSV esportabile per esercitarsi nella rendicontazione.
Dopo i controlli storici, esegui una demo forward fissa
Esegui la contabilità dell’esempio
Scarica le quattro righe fittizie dei mesi di test, inclusi equity iniziale e finale. Si tratta di valori inventati a scopo didattico, non di un report di backtesting.
Osserva la tua configurazione nella demo di Bitsgap
Dopo aver completato l’analisi storica in uno strumento che supporta le finestre e la contabilità richieste, blocca una configurazione del bot supportata nella demo di Bitsgap. Registra gli asset iniziali e le impostazioni, quindi osservala con fondi virtuali e prezzi di mercato attuali. La demo è un esercizio forward separato; questo flusso di lavoro non presuppone un ottimizzatore walk-forward integrato.
Domande frequenti
Il test walk-forward previene l’overfitting?
Riduce una fonte di bias in-sample separando ogni finestra di selezione dalla successiva finestra di test. Cambiamenti ripetuti nel protocollo, leakage dei dati, esecuzioni irrealistiche e reporting selettivo possono comunque produrre risultati fuorvianti.
Quanto dovrebbero durare le finestre?
Non esiste una durata universale. La frequenza di trading, la cronologia disponibile e il metodo di selezione determinano quante informazioni contiene ciascuna finestra. La suddivisione in tre mesi e un mese qui è solo un esempio didattico.
Posso sommare i rendimenti delle diverse finestre di test?
Compone i rendimenti sequenziali quando ogni finestra inizia con l’equity finale della finestra precedente. Conserva anche il percorso dell’equity sottostante, i costi e l’esposizione; una percentuale finale da sola nasconde differenze importanti.
La demo forward è la stessa cosa di un backtest out-of-sample?
Un test storico out-of-sample utilizza dati storici successivi all’interno di un simulatore. La demo forward osserva nuovi dati con fondi virtuali. Entrambi hanno dei limiti e nessuno dei due garantisce esecuzioni reali o rendimenti futuri.
