A chi ha creato la strategia basata sui dati sull’occupazione,
Hai definito una regola semplice: dopo il rapporto sull’occupazione statunitense, la strategia mantiene un ETF azionario per cinque sessioni se la crescita mensile dei salari supera 175,000. Altrimenti, resta in liquidità. Hai programmato l’ingresso dopo l’apertura del mercato azionario, incluso i costi di trading e mantenuto fissa la soglia. Poi hai scaricato una serie storica sui salari e l’hai usata per ricostruire ogni segnale.
Il problema rimasto è il download. Una serie economica storica può contenere stime riviste che non erano disponibili nelle date in cui, secondo la simulazione, la strategia avrebbe negoziato. Per testare con rigore un segnale macro, ti serve la versione disponibile al momento di ogni decisione. Spostare l’ingresso avanti di una barra non corregge un dato pubblicato due mesi dopo.
La tua osservazione di gennaio ha diverse date di nascita
Considera questa cronologia di pubblicazioni inventata. Date e variazioni dei salari illustrano il meccanismo; non sono dati economici reali.
| Pubblicazione | Mese di riferimento | Variazione dei salari riportata | La regola a quella pubblicazione |
|---|---|---|---|
| 7 febbraio, 08:30 ET | Gennaio | +150,000 | Resta in liquidità |
| 7 marzo, 08:30 ET | Gennaio, rivisto | +185,000 | Non modifica la decisione di febbraio |
| 4 aprile, 08:30 ET | Gennaio, rivisto di nuovo | +210,000 | Non modifica la decisione di febbraio |
Se il download riporta +210,000 per gennaio, nella simulazione entri nell’ETF a febbraio. La regola effettiva avrebbe mantenuto la liquidità. Prezzi, orari degli ordini e commissioni possono essere tutti corretti, ma quell’intera operazione è fittizia.
Non puoi presumere che questa contaminazione migliori la performance. Le revisioni possono creare operazioni vincenti o perdenti, oppure eliminarle. Il difetto è che la simulazione risponde a una domanda che la strategia non avrebbe potuto porsi in quel momento.
E gennaio è solo il periodo misurato. Non è la data in cui hai appreso la misurazione. Una riga con l’etichetta 1 gennaio non ti autorizza a negoziare quel dato il 1 gennaio.
Registra la cronologia di disponibilità di ogni valore
La tabella di ricerca deve contenere più di un mese e un numero. Conserva il periodo di riferimento, il valore, l’orario di pubblicazione, l’identificativo della versione e la fonte. Se raccogli i dati nel tempo, registra anche quando il tuo sistema ha ricevuto la pubblicazione. Conserva le versioni precedenti invece di sovrascriverne i valori.
Al momento di una decisione, seleziona per ogni osservazione la versione più recente disponibile il cui timestamp di disponibilità non sia successivo alla decisione. Poi calcola le feature a partire da quella fotografia ricostruita.
La regola di recupero dei dati: prima limita i record a quelli già disponibili, poi seleziona le versioni pertinenti e infine calcola il segnale. Calcolare le feature sulla cronologia rivista di oggi e spostare il risultato a posteriori mantiene la contaminazione.
Il periodo di mantenimento di cinque sessioni non rende facoltosa questa registrazione. Ti lascia più margine per scegliere un orario d’ingresso prudente; non ti dà accesso anticipato alle revisioni.
Per le ricerche meno recenti, potresti avere prove dell’orario di pubblicazione al pubblico senza alcuna registrazione dell’orario di ricezione da parte tua. Mantieni esplicita questa distinzione. Puoi modellare l’accesso a partire da un timestamp di pubblicazione documentato, applicando un ritardo dichiarato. Non puoi presentare questa ipotesi come una ricostruzione misurata della consegna storica.
Ti servirà anche un timestamp che tenga conto del fuso orario. Registra l’orario locale documentato della pubblicazione e converti correttamente l’ora: un offset UTC fisso per New York non funziona durante i cambi dell’ora legale. Fai questo piccolo favore al te del futuro. Il te di settembre non dovrebbe dover decifrare la colonna del te di marzo chiamata date_actual_final2.
Le tue feature mobili richiedono le versioni storiche complete
Supponiamo che tu sostituisca la soglia fissa con «la crescita dei salari supera la media mobile degli ultimi dodici mesi». Ora ti servono le osservazioni precedenti così come risultavano al momento della decisione, comprese le revisioni già pubblicate entro quella data.
Usare per sempre la prima pubblicazione di ogni mese definisce una feature diversa. Può essere una scelta legittima se vuoi esplicitamente analizzare la storia degli annunci iniziali. Ma non ricostruisce la storia economica visibile in una determinata mattina, perché l’insieme informativo di quella mattina può già includere revisioni dei mesi precedenti.
Se ricavi le variazioni mensili dei salari dai livelli occupazionali, ricostruisci la serie dei livelli per la versione pertinente prima di calcolare le differenze. Mescolare un livello appena pubblicato con il livello del mese precedente appartenente a una versione più vecchia può produrre una variazione che non compare in nessuna fotografia pubblicata.
Devi quindi specificare cosa rappresenta la tua feature: gli annunci iniziali, il quadro economico più aggiornato disponibile oppure le revisioni stesse. «Crescita dei salari» lascia troppe cose da decidere.
Verifica una pubblicazione prima di rieseguire dieci anni di dati
Puoi iniziare da ALFRED, che fornisce le versioni storiche di molte serie economiche. Verifica la copertura per la serie e il periodo specifici che ti interessano. La sola data della versione non dimostra la disponibilità intraday; abbinala a un orario di pubblicazione documentato prima di usarla per un segnale nella stessa giornata.
Per il primo controllo, scegli una pubblicazione e ricostruiscila a mano:
- Trova la pubblicazione archiviata e registra il timestamp di pubblicazione, il mese di riferimento e il valore iniziale.
- Ricostruisci la fotografia dei dati che la strategia avrebbe ricevuto prima dell’ingresso.
- Calcola il segnale a mano e confrontalo con quello della simulazione.
- Aggiungi ai dati una revisione successiva e verifica che la decisione precedente resti invariata.
Quest’ultimo controllo è particolarmente utile in una pipeline di ricerca automatizzata. Fornisci al tuo agente di ricerca il limite temporale della fotografia e gli identificativi delle versioni selezionate, insieme ai valori delle feature. Ti servono prove sufficienti per risalire da un’operazione a una specifica pubblicazione, anche quando il database sottostante si è ampliato.
Una volta riprodotta quella singola decisione, riesegui la cronologia e confronta le divergenze dei segnali prima di confrontare i rendimenti. Conta gli ingressi creati, eliminati o spostati dalla correzione. Imparerai di più dalle decisioni modificate che da un singolo Sharpe prima e dopo.
La tua operazione di febbraio deve reggersi sulle informazioni disponibili a febbraio. Lascia la revisione di aprile ad aprile.
← Tutti gli articoli
