Come si può testare il filtraggio delle rotture false?

Come funziona il filtraggio delle rotture false come concetto

Il filtraggio delle rotture false mira a ridurre le operazioni innescate da rotture che non si comportano come previsto. Nella pratica, una “rottura” viene innanzitutto rilevata tramite una regola (ad esempio, il prezzo che supera un livello), dopodiché un filtro permette o blocca l’operazione in base a informazioni aggiuntive.

Una difficoltà fondamentale del test consiste nel separare due elementi:

• La meccanica stabile della progettazione del filtro (la logica applicata).
• Le condizioni variabili del mercato e dei dati (regime di volatilità, costi simili allo spread, qualità dell’esecuzione).

Il test dovrebbe quindi concentrarsi su se il filtro migliora un risultato predefinito rispetto a una linea di base, senza presupporre prevedibilità futura.

Definisci un’ipotesi verificabile e una linea di base

Per testare il filtraggio delle rotture false, parti da un’ipotesi che possa essere falsificata. Esempi di modelli di ipotesi (scritti come affermazioni neutre):

• “Quando un segnale di rottura è seguito da una specifica condizione post-rottura, il filtro riduce la quota di risultati che si invertono rapidamente.”
• “Rispetto alla semplice regola di rottura di base, l’aggiunta del filtro modifica le metriche di performance in modo coerente.”

Definisci quindi chiaramente la tua linea di base. Le linee di base più comuni sono:

1. Nessun filtro: viene utilizzata solo la regola iniziale di rilevamento della rottura.
2. Filtro ingenuo: una regola semplice e trasparente che non utilizza le stesse informazioni del filtro proposto (utile per verificare che qualsiasi miglioramento non sia dovuto semplicemente a una minore frequenza di operazioni).

Mantieni le metriche allineate all’ipotesi. Se l’ipotesi riguarda le rotture false, scegli metriche che riflettano la frequenza di inversione o comportamenti simili al drawdown, non solo i rendimenti grezzi.

Imposta la suddivisione dei dati e il protocollo di valutazione

Un filtro può sembrare efficace se accidentalmente è stato ottimizzato per un determinato periodo. Utilizza un protocollo che minimizzi il rischio di leakage:

1. Suddivisione basata sul tempo

• Addestramento (per scegliere regole o soglie).
• Validazione (per selezionare tra diverse impostazioni del filtro).
• Test (per la valutazione finale, mai toccata).

Evita il mescolamento casuale. Il comportamento delle rotture spesso dipende da condizioni di mercato che variano nel tempo.

2. Multipli regimi Se possibile, assicurati che il set di test includa diverse condizioni di volatilità e tendenza. Senza presupporre che un particolare “tipo di mercato” si ripeterà, puoi almeno verificare se l’effetto del filtro persiste in periodi diversi.

3. Coerenza nel momento della decisione Assicurati che la decisione del filtro sia presa usando solo informazioni disponibili al momento della decisione. Un errore frequente è utilizzare caratteristiche conosciute solo a posteriori (ad esempio, massimi/minimi futuri).

Assunzioni sui costi e sui fattori variabili

Anche per un test concettuale, hai bisogno di assunzioni esplicite per i componenti di calcolo. Altrimenti, i risultati possono essere fuorvianti.

Includi un modello di costi che corrisponda al tuo ambiente a un livello approssimativo:

• Costi di transazione (commissioni o spread come stima totale per operazione).
• Ritardo di esecuzione (se il tuo filtro richiede di attendere una conferma, potresti entrare più tardi a prezzi diversi).
• Margine per lo slippage (quanto peggio potrebbero essere gli eseguiti rispetto a una stima del prezzo di mezzo).

Dichiara queste assunzioni come variabili nel tuo piano di test. Poi esegui verifiche di sensibilità:

• Scenari con costi bassi, medi e alti.
• Assunzioni leggermente diverse per lo slippage.

Se il miglioramento apparente del filtro scompare con costi più realistici, il test suggerisce che l’effetto non è robusto.

Progetto di test con esempio o evidenza

Di seguito è riportato un progetto di test strutturato che puoi implementare senza fare affidamento su prezzi in tempo reale.

1. Scegli una regola di rottura Definiscila come un passaggio deterministico, ad esempio:

• “Un evento di rottura si verifica quando il prezzo supera un livello predefinito.”

Dichiara chiaramente la definizione dell’evento: a quale timeframe, quale tipo di livello (massimo precedente, range mobile), e come gestisci i casi limite.

2. Definisci la condizione del filtro La condizione del filtro dovrebbe essere legata all’ipotesi di rottura falsa. Ad esempio (forma generica):

• “Dopo la rotture, richiedi che una condizione successiva sia valida per N passaggi; altrimenti blocca l’operazione.”

Specifica N e la condizione successiva in modo che non possa essere interpretata diversamente da un altro lettore.

3. Definisci l’etichettatura dell’esito Se la tua ipotesi riguarda le “rotture false”, devi definire operativamente cosa significa “falsa”.

• Ad esempio: “un’operazione bloccata è quella in cui il prezzo si inverte oltre una soglia entro un certo orizzonte.”

Ancora una volta, definisci l’orizzonte e la soglia di inversione come assunzioni esplicite.

4. Confronta con la linea di base Calcola le stesse metriche per:

• Linea di base: eventi di rottura senza filtro.
• Filtrato: eventi di rottura con filtro.

Come minimo, confronta:

• Metriche di frequenza (quanti eventi sono consentiti rispetto a quelli bloccati).
• Metriche di esito negativo (quanto spesso si verificano i criteri di inversione).
• Metriche di rischio (quanto grandi diventano le escursioni negative).

Limitazioni e rischi: cosa può andare storto

Almeno una limitazione significativa dovrebbe far parte del piano di test.

Errori comuni:

1. Overfitting a un singolo periodo Se le soglie del filtro sono state ottimizzate usando l’intero dataset, i risultati del test potrebbero riflettere solo quel periodo specifico.

2. Leakage tramite informazioni post-evento Se una qualsiasi caratteristica del filtro utilizza informazioni non disponibili al momento della decisione, il test è invalido.

3. Dipendenza dal regime Un filtro potrebbe aiutare in un regime laterale ma fallire in un regime di tendenza (o viceversa). Ciò significa che una singola metrica di test può nascondere instabilità.

4. Divergenza tra costi ed esecuzione Se la valutazione presuppone eseguiti irrealisticamente favorevoli, un filtro che attende conferma potrebbe prestare peggio una volta inclusi i costi reali.

5. Problemi di qualità dei dati Diverse fonti di dati possono avere comportamenti diversi in termini di timestamping o microstruttura. Anche utilizzando lo stesso asset, piccole differenze possono alterare il rilevamento della “rottura”.

Le relazioni storiche non garantiscono risultati futuri. Anche un test ben progettato fornisce evidenze sul passato, non una garanzia sul futuro.

Verifica e prossime domande da porsi

Dopo aver calcolato i risultati, verifica l’affermazione principale invece di fidarti di un singolo numero.

1. Verifiche di robustezza

• Ripeti il test con assunzioni sui costi diverse ma ragionevoli.
• Varia le impostazioni del filtro in un intervallo ristretto per vedere se il comportamento cambia drasticamente.
• Valuta più asset o periodi se i tuoi dati lo permettono.

2. Verifica il meccanismo Se il filtro migliora i risultati, conferma che sia allineato al meccanismo previsto (ad esempio, meno inversioni o escursioni negative minori). Se i miglioramenti si verificano solo perché la frequenza delle operazioni diminuisce, devi reinterpretare il risultato.

3. Documenta la falsificabilità Scrivi quali risultati contraddirebbero l’ipotesi. Questo aiuta a distinguere tra “funziona in alcuni casi” e “funziona per un motivo stabile”.

4. Rivaluta i fattori variabili Se i risultati cambiano in modo significativo quando modifichi le assunzioni su ritardo di esecuzione o costi, ciò indica una sensibilità ed è una limitazione dell’approccio.

Se vuoi, condividi la tua definizione di rottura e la regola esatta del filtro che intendi testare (inclusi il momento della decisione e l’orizzonte).