Un agente AI per strategie può produrre un backtest valido usando informazioni che non esistevano ancora quando avrebbe dovuto eseguire le operazioni. Il codice funziona. La curva del capitale sembra plausibile. Il segnale può persino essere sensato. Eppure, un timestamp, una join o un campo dati aggiornato gli ha fornito di nascosto la risposta di domani.
La soluzione è includere il momento in cui i dati diventano disponibili nel protocollo di ricerca. Per ogni input servono risposte chiare a due domande: a quale momento si riferisce questo valore e quando la strategia avrebbe potuto conoscerlo per la prima volta?
Come si manifesta il bias di lookahead in una strategia generata dall'AI?
La forma più ovvia è un segnale calcolato sulla chiusura della stessa barra, seguito da un'esecuzione a quel prezzo di chiusura. Se la strategia ha bisogno del prezzo di chiusura per decidere, non può anche operare a quel prezzo. Ma gli agenti spesso introducono forme più sottili quando combinano fonti di dati o scelgono impostazioni predefinite comode.
Supponiamo che un modello calcoli una media mobile a 20 barre alla chiusura di ogni minuto e apra una posizione quando la chiusura la supera. Se il backtest esegue l'ordine alla stessa chiusura, ha usato l'ultimo scambio della barra prima che fosse disponibile alla strategia. Spostare l'ordine all'apertura della barra successiva può essere un'approssimazione ragionevole, anche se un ordine a mercato deve comunque considerare commissioni e impatto.
Ora immaginiamo che la feature sia un dato fondamentale giornaliero di un'azione o uno snapshot dell'open interest di una criptovaluta. La data della riga potrebbe indicare lunedì, ma il valore potrebbe essere stato pubblicato dopo la chiusura di lunedì o corretto in seguito. Una data non è un timestamp di disponibilità.
Come devo assegnare i timestamp agli input di una strategia?
Quando la fonte lo consente, conserva almeno 3 orari: il periodo a cui si riferisce un valore, l'ora in cui il publisher lo ha diffuso e l'ora in cui il tuo sistema lo ha ricevuto. Al momento della decisione, l'insieme di informazioni della strategia può includere solo valori già disponibili.
| Campo | A quale domanda risponde | Insidia tipica |
|---|---|---|
| Ora dell'evento | Quando si è verificato l'evento di mercato? | Usare la chiusura di una barra prima che sia completa |
| Ora di pubblicazione | Quando la fonte ha pubblicato questo valore? | Interpretare un'etichetta di fine giornata come una pubblicazione all'apertura |
| Ora di acquisizione | Quando avrebbe potuto essere utilizzato dal sistema di ricerca? | Ignorare i ritardi del fornitore o della pipeline |
| Ora della revisione | Quando è stata registrata o corretta questa versione? | Riempire la cronologia con valori rivisti come se fossero quelli originali |
Per una strategia a 1 minuto, un ritardo di un secondo non è automaticamente irrilevante. L'importanza dipende dal momento in cui viene presa la decisione e dai dati usati dal segnale. Se l'input è una statistica oraria già completata, potrebbe incidere appena. Se è uno squilibrio del book rilevato poco prima dell'ordine, può ribaltare l'operazione.
Un archivio dati point-in-time può impedire fughe di informazioni?
Sì, se per “point-in-time” si intende poter recuperare il valore noto in un determinato momento decisionale storico, compresa la versione allora disponibile. Una tabella con semplici date storiche può comunque contenere i valori corretti oggi per quelle date.
Per ogni record, conserva un intervallo di validità e un timestamp di disponibilità; mantieni anche le revisioni invece di sovrascriverle. Poi rendi esplicite le query storiche: restituisci l'ultima versione disponibile al momento della decisione simulata. È particolarmente importante per i dati fondamentali, la composizione degli indici, le pubblicazioni economiche e i dataset ripuliti dai fornitori.
C'è un dettaglio operativo poco appariscente: un timestamp di pubblicazione perfetto non serve a nulla se il processo di acquisizione è partito con venti minuti di ritardo. Se l'archivio storico non registra l'ora di acquisizione, applica un ritardo prudenziale e dichiaralo. Una precisione mai registrata dalla fonte è solo decorativa.
Quali controlli individuano il bias di lookahead prima del paper trading?
Chiedi all'agente di ricerca di produrre, insieme al backtest, una cronologia delle feature e degli ordini. Per ogni decisione, registra l'ultimo momento di disponibilità delle fonti per ciascuna feature, l'ora della decisione, quella dell'ordine e l'ora di esecuzione simulata. Scarta ogni riga in cui un input è arrivato dopo la decisione.
- Ritarda i segnali di una barra e confronta i risultati. Un forte calo può rivelare una dipendenza dalle tempistiche tra chiusure successive, anche se si tratta di un controllo diagnostico, non di una prova di fuga di dati.
- Tronca ogni fonte a una data limite storica, riesegui la pipeline e confronta le feature risultanti con quelle storiche archiviate.
- Sostituisci una feature sospetta con una costante. Se le prestazioni restano quasi identiche, verifica se il codice ha davvero usato la serie prevista.
- Fai passare nella pipeline una feature futura volutamente impossibile. La validazione dovrebbe interrompersi segnalando chiaramente l'errore quando il suo momento di disponibilità è successivo a quello della decisione.
Questi controlli non certificano una strategia. Rendono visibili specifiche ipotesi sulle tempistiche e individuano i modi più comuni in cui vengono violate.
Il paper trading dimostra che il backtest non aveva fughe di dati?
No. Il paper trading può rivelare un flusso di dati in tempo reale in ritardo, incompleto o allineato diversamente da quello storico. Non può stabilire se le vecchie feature di training rispecchiassero ciò che si sapeva all'epoca. Un modello può anche smettere di beneficiare della fuga di dati semplicemente perché il futuro intravisto per errore è ormai diventato presente.
Usa il paper trading come verifica di coerenza: confronta i valori delle feature in tempo reale, i timestamp delle decisioni, la generazione degli ordini e le esecuzioni simulate con le definizioni del backtest. Quando non coincidono, risali all'input e all'orologio precisi. Un team di agenti capace di spiegare l'insieme di informazioni usato per ogni decisione sta facendo ricerca utile. Un team che sa solo mostrarti una curva regolare ha saltato la verifica più difficile.
← Tutti gli articoli
