L’osservazione forward studia come si comporta un EA fisso con dati arrivati dopo aver fissato il piano. Serve solo se versione, informazioni disponibili a ogni decisione e regole di revisione restano tracciabili. Un intervallo redditizio scelto dopo non è lo stesso esperimento.
Separa prontezza operativa, completezza delle evidenze e valutazione della performance. La riconciliazione della prima guida stabilisce cosa è successo; questa definisce come osservarlo prospetticamente. Né un libro pulito né un calendario completato dimostrano redditività o autorizzano il finanziamento di un conto reale.
1. Scrivi la domanda prima di raccogliere risultati
Definisci comportamento e ambiente da valutare: tempistica dei segnali, riproduzione delle decisioni, gestione delle richieste, differenze di esecuzione o ipotesi di performance precisa. Indica confronto ed evidenze necessarie. Un saldo crescente non risponde a tutte queste domande.
Registra varianti e tentativi di selezione precedenti, inclusi quelli falliti. Un nuovo periodo forward non cancella la selezione del modello. Ritoccare ripetutamente dopo aver visto risultati trasforma quelle osservazioni in sviluppo. La guida all’overfitting spiega perché un backtest selezionato attraente richiede più attenzione.
2. Distingui evidenze shadow, demo e reali
Qui shadow indica un osservatore che registra decisioni senza inviare ordini. Demo significa richieste a un conto simulato del broker; live significa esecuzione su un conto finanziato realmente. Documenta esplicitamente la modalità, senza usare forward come garanzia di esecuzioni reali.
| Modalità | Cosa può registrare | Limite principale delle evidenze |
|---|---|---|
| Osservatore shadow | Decisioni e input disponibili; nessun ordine | Nessuna esecuzione osservata del broker |
| Conto demo | Decisioni, richieste simulate e registrazioni del broker | Non dimostra esecuzioni o costi reali |
| Conto reale | Richieste reali, registrazioni ed effetti sul conto | Capitale a rischio; risultati incerti |
L’esempio inventato usa solo demo e non raccomanda allocazioni reali. Confronta modalità solo dopo aver allineato versioni, dati e copertura temporale, mantenendo registri separati. La guida demo contro reale spiega le differenze; un osservatore non può dedurre fill reali da un grafico Bid.
3. Fissa un manifesto che identifichi l’esperimento
Archivia binario/build EA e, se disponibile, revisione del codice; registra hash, valori e file dei parametri. Includi server, conto e modalità, valuta, mappatura simboli, timeframe, dipendenze, build del terminale, base temporale, fonti, versione della politica di rischio, inizio, regola finale e revisioni. Un nome file non identifica la configurazione.
Nel caso didattico fissa EA-A e gli input I1 in una sessione demo EURUSD H1. Il manifesto contiene orari e identificativi delle decisioni previste dal calendario fisso. Mantieni invariate regole di trading e rischio; la guida non fornisce tali regole né un controllore. La sicurezza operativa segue la politica di rischio del conto esistente.
4. Acquisisci ciò che era disponibile a ogni decisione
Salva limite decisionale, identificativi delle barre chiuse, prezzi e variabili pertinenti, orari di origine, ricezione e controlli di freschezza. Usa normalizzazione temporale documentata. Nell’esempio F1 è marcata 09:00:00 ma arriva alle 09:00:08, dopo l’istantanea fissata alle 09:00:05. Non può entrare in quella decisione. La revisione delle 09:00:10 deve preservare il fatto.
Un timestamp di origine precedente non prova che l’EA potesse leggere allora il valore. Segui la regola fissa dei dati mancanti, inclusa una mancata entrata documentata se prevista. Salva correzioni successive a parte. Ricostruire con storico rivisto, barra allora in formazione ormai completa o valore ricevuto dopo introduce informazioni assenti nella sessione originale.
5. Predefinisci finestra e opportunità attese
Specifica inizio e regola di fine, calendario di mercato, sessioni ammesse, decisioni previste, esclusioni di riscaldamento e revisioni prima di osservare. Spiega chiusure, barre mancanti, riavvii e interruzioni. Un guasto non deve sparire dal denominatore solo perché non è stato inviato un ordine. Distingui finestre programmate da segnali, richieste e operazioni completate.
Il calendario inventato comprende 100 decisioni attese in 4 blocchi consecutivi di 25. Rivedi ogni fine blocco e termina dopo l’ultima decisione programmata. I conteggi rendono riproducibile l’audit; non sono un minimo consigliato né un calcolo di potenza statistica. Durata ed evidenze effettive dipendono da frequenza, dipendenza, condizioni di mercato e domanda.
6. Predefinisci revisione, interruzione e cambiamenti
Separa requisiti di qualità delle fonti, escalation operativa e criteri di performance. Definisci metriche, attribuzione, costi, flussi, posizioni aperte e tolleranze prima dei risultati. Le guide a equity e drawdown e ai costi danno contesto contabile, non soglie universali di accettazione.
Per questa demo ogni decisione attesa richiede evidenze tracciabili prima di approvare il dossier di performance. Una decisione irrisolta lascia l’approvazione inconcludente. Le revisioni pianificate non ritardano azioni urgenti della politica esistente. Non prolungare fino al guadagno, non fermarti su un picco favorevole e non cambiare silenziosamente una soglia dopo una perdita.
7. Verifica il caso inventato di copertura
La tabella contiene blocchi non sovrapposti, non totali cumulativi. Una decisione tracciabile conserva input disponibili allora ed esito registrato, compresi assenza di segnale o rinuncia documentata; una sconosciuta manca di prove sufficienti. R2 ha un record mancante ancora irrisolto alla fine. Non presumere che lì mancassero segnale, richiesta o esposizione.
| Blocco di revisione | Decisioni attese | Decisioni tracciabili | Decisioni sconosciute | Copertura delle evidenze |
|---|---|---|---|---|
| R1 | 25 | 25 | 0 | 100% |
| R2 | 25 | 24 | 1 | 96% |
| R3 | 25 | 25 | 0 | 100% |
| R4 | 25 | 25 | 0 | 100% |
In totale 99 decisioni su 100 sono tracciabili e 1 sconosciuta: copertura 99%. Blocchi completi successivi non riparano la lacuna. Con il requisito di completezza predefinito, il dossier resta inconcludente. Il calcolo non misura la percentuale di successo né dichiara fallita la strategia; anche registri completi richiedono valutazioni separate di adeguatezza e performance.
Facoltativo: riproduci conteggi e copertura
Decisioni attese: 25 + 25 + 25 + 25 = 100. Tracciabili: 25 + 24 + 25 + 25 = 99. Sconosciute: 0 + 1 + 0 + 0 = 1. Blocco completo: 25 / 25 × 100 = 100%. Incompleto: 24 / 25 × 100 = 96%. Copertura totale: 99 / 100 × 100 = 99%. Quota sconosciuta: 1 / 100 × 100 = 1%. Controllo: 99 + 1 = 100. Le percentuali descrivono solo evidenze; la notazione numerica resta inglese.
8. Tratta le regole cambiate come una nuova sessione
Una modifica a soglia, file input, insieme di simboli, filtro di sessione o rischio cambia l’esperimento. Registra motivo e momento effettivo, conserva la sessione vecchia e avvia una nuova versione identificata. EA-B con I2 non va aggiunto a EA-A con I1 come se nulla fosse cambiato. Anche modifiche infrastrutturali richiedono traccia datata e valutazione di comparabilità.
Una correzione può essere necessaria, ma non rende inedite osservazioni già viste. Conserva incidente e periodo coinvolto; raccogli evidenze successive sotto il nuovo protocollo. Riporta tutte le varianti e consultazioni precedenti. Non sovrascrivere una sessione negativa, non unire risultati incompatibili e non presentare un replay retrospettivo come forward originale.
9. Rispetta i limiti del tester storico e della piattaforma
Test storici e osservazione forward rispondono a domande diverse. MT4 documenta i propri limiti: funzioni esterne come WebRequest() e SendNotification() non vengono eseguite nello Strategy Tester, né vengono effettuate operazioni su simboli diversi da quello testato. Un passaggio storico non dimostra il funzionamento di dati e avvisi live.
Usa la guida al backtesting per ipotesi su modello e dati e la guida al monitoraggio per i percorsi operativi. Verifica gli input tra simboli separatamente dall’esecuzione. Ricezione, disconnessione, ripristino e protezione reali richiedono evidenze in un ambiente osservato adeguato, non l’ipotesi che il tester si trasferisca invariato.
10. Scrivi una conclusione circoscritta alla revisione prevista
Riporta identità del protocollo, modalità, date effettive, copertura attesa e osservata, incidenti, cambi, elementi irrisolti e metriche predefinite con limiti. Includi perdite ed esposizione aperta, non solo operazioni chiuse favorevoli. La statistica deve considerare dipendenza e selezione ripetuta; l’esempio non calcola significatività o probabilità di overfitting.
- Manifesto, confronto, finestra e regole sono stati fissati prima dei risultati?
- Ogni decisione ha usato solo informazioni realmente disponibili al proprio limite temporale?
- I registri shadow, demo e reali sono separati?
- Sono visibili lacune, incidenti, costi, posizioni aperte e cambi di versione?
- La conclusione segue i criteri originali senza scambiare copertura per redditività?
Concludi con precisione: evidenze incomplete, complete ma insufficienti per la domanda, oppure esito documentato con valutazione predefinita. Nessuno promuove automaticamente una demo a fondi reali. Eventuale distribuzione o allocazione successiva richiede decisione autorizzata e controlli propri. Conserva il dossier per monitoraggio e rivalidazione.
11. Domande sulla validazione forward
Forward significa operare con denaro reale?
No. Dichiara se è shadow, demo o live. Solo il live registra esecuzioni di un conto realmente finanziato ed espone capitale a perdite.
Le 100 decisioni bastano a validare un EA?
Non viene affermato. Sono dati inventati per la copertura, non una raccomandazione sulla dimensione. Le decisioni non sono necessariamente operazioni o osservazioni indipendenti; la completezza non dimostra un vantaggio.
Posso migliorare i parametri e mantenere lo stesso risultato forward?
Conserva il risultato precedente, ma identifica il cambiamento come nuova sessione/versione. Le osservazioni già usate per scegliere parametri sono sviluppo, non validazione inedita di quella scelta.
Copertura del 99% significa successo del 99%?
No. Indica la quota delle decisioni programmate con evidenza tracciabile. La lacuna irrisolta nell’esempio blocca l’approvazione predefinita delle evidenze indipendentemente dal trading.
12. Fonti e ambito
Fonti primarie: funzionamento e limiti di MQL4 Strategy Tester, configurazione del tester e parametri MetaTrader e Bailey e coautori, The Probability of Backtest Overfitting. Verificate il 2026-10-18. La ricerca motiva cautela nella selezione, non certifica protocollo o conteggi dell’esempio.
Nomi, orari delle variabili, calendario e conteggi sono dati didattici inventati. Non si forniscono strategia reale, performance live, campione minimo, rendimento atteso o raccomandazione di finanziamento. I diagrammi mostrano protocollo ed evidenze, non report originali del tester. Un piano fisso migliora la tracciabilità senza garantire trading redditizio o sicuro.