Come si può fare backtest responsabilmente dell’RSI Range?
Definire RSI Range e le regole testabili
RSI Range è un modo per descrivere come i valori dell’RSI si muovono all’interno di bande (ad esempio, zone “range-high” e “range-low”), piuttosto che trattare l’indicatore come un segnale binario sì/no. Prima di fare un backtest, definisci chiaramente la meccanica:
- Come viene calcolato l’RSI (periodo di lookback, metodo di smoothing se applicabile).
- Cosa significa “Range” (i confini esatti delle bande e se sono fissi o derivati).
- Cosa viene misurato (ad esempio, se si rilevano i contatti, il tempo trascorso in una banda, i rimbalzi o la persistenza).
Un backtest responsabile inizia trasformando ogni concetto in una regola deterministica riproducibile. Se due persone codificassero definizioni diverse delle bande a partire dalla stessa descrizione, i risultati del test non sarebbero verificabili.
Stabilire assunzioni e scegliere le regole sui dati
Il backtesting è accurato quanto lo sono le sue regole sui dati. Usa assunzioni chiare e dichiarale prima di calcolare qualsiasi risultato:
- Granularità a barre o tick: utilizzi candele (apertura/ massimo/ minimo/ chiusura) e a quale timeframe? L’RSI è sensibile al campionamento.
- Evitare il look-ahead: assicurati che il valore usato per decidere sia disponibile al momento della decisione.
- Gestione del tempo: se usi dati giornalieri, non puoi assumere un ordinamento intraday. Mantieni le assunzioni di esecuzione coerenti con i tuoi dati.
- Pulizia dei dati: decidi come gestire le barre mancanti, i giorni festivi e gli outlier.
Un metodo pratico è creare un “contratto dati”: una breve checklist che definisce esattamente il dataset, il timeframe, i timestamp e qualsiasi filtro. Senza questo, due backtest non possono essere confrontati in modo significativo.
Modellare costi ed esecuzione come parte dell’ipotesi
Molti backtest falliscono perché considerano il trading privo di attriti. Anche quando l’obiettivo è educativo e non decisionale, modellare i costi ti aiuta ad evitare conclusioni fuorvianti.
Includi componenti che possono alterare materialmente i risultati:
- Effetto spread o bid/ask (anche in forma semplificata costante).
- Modello di slippage (ad esempio, un offset avverso fisso per ogni esecuzione, o un range di offset).
- Tempistica degli ordini: si assume che gli ingressi avvengano all’apertura della prossima barra, alla chiusura di una barra, o nella barra che contiene la condizione RSI Range?
- Durata della posizione o logica di uscita: definiscila nello stesso modo deterministico degli ingressi.
Quindi effettua verifiche di sensibilità. Se i risultati valgono solo sotto assunzioni di costo ottimistiche e ristrette, questo è un campanello d’allarme.
Controllare il bias con una validazione robusta
Un backtest responsabile richiede contromisure contro il “progettare il risultato”. Comuni controlli contro il bias includono:
- Validazione walk-forward: calibra eventuali parametri solo su dati passati, quindi testa su dati futuri non visti.
- Valutazione out-of-sample: mantieni un periodo di riserva mai usato per ottimizzare definizioni (ampiezza delle bande, soglie, lunghezza RSI).
- Suddivisioni multiple: ripeti la procedura su diverse finestre temporali per ridurre la probabilità che un singolo periodo di mercato domini.
- Disciplina sui parametri: limita il numero di gradi di libertà che ottimizzi. Se regoli molte soglie per inseguire un pattern specifico, rischi l’overfitting.
Uno standard utile di verifica è: un collega potrebbe riprodurre esattamente la tua pipeline e osservare le stesse tendenze metriche, dato lo stesso dataset e le stesse assunzioni?
Riconoscere almeno una limitazione significativa
Il backtest dell’RSI Range può fallire per diversi motivi, e dovresti cercare attivamente i modi di fallimento:
- Cambi di regime: il “comportamento in range” dell’RSI può cambiare quando la struttura di volatilità o la partecipazione al mercato cambiano.
- Non stazionarietà: le proprietà statistiche dei rendimenti e delle oscillazioni possono derivare, quindi le bande storiche potrebbero non comportarsi allo stesso modo in futuro.
- Overfitting della definizione: se i confini delle bande sono scelti dopo aver visto i risultati, potrebbero codificare rumore.
- Disallineamento nell’esecuzione: se la tua decisione usa informazioni intrabarre ma il tuo backtest assume esecuzioni a livello di candela, la performance modellata può essere irrealisticamente costante.
Un articolo o notebook responsabile dovrebbe evidenziare quale limitazione è più rilevante per la sua configurazione e come la validazione tenti di rilevarla.
Verifica con una checklist chiara e indipendente
Se vuoi verificare in modo indipendente i fatti, usa una checklist che si concentri sulla verificabilità piuttosto che sulla previsione:
- Controllo definizione: le regole di RSI e delle bande possono essere ricreate esattamente?
- Controllo dati: il backtest evita il look-ahead e corrisponde al timeframe dichiarato?
- Controllo costi: spread e slippage sono modellati in modo trasparente, con test di sensibilità?
- Controllo bias: è presente una validazione walk-forward o out-of-sample con ottimizzazione limitata?
- Controllo modi di fallimento: hai testato almeno uno scenario di interruzione (costo variato, diversa suddivisione temporale o tempistica di esecuzione modificata)?