En AI-strategiagent kan skapa en giltig backtest samtidigt som den använder information som inte fanns när affärerna skulle ha genomförts. Koden körs. Eget kapital-kurvan ser rimlig ut. Signalen kan till och med verka vettig. Ändå har en tidsstämpel, en join eller ett reviderat datafält i tysthet gett agenten morgondagens svar.
Lösningen är att göra tillgänglighetstid till en del av forskningskontraktet. För varje indata behöver vi kunna svara tydligt på två frågor: vilken tidpunkt beskriver värdet, och när kunde strategin tidigast ha känt till det?
Hur ser lookahead-bias ut i en AI-genererad strategi?
Det uppenbara fallet är en signal som beräknas från stängningskursen för samma bar, följd av en fill till den kursen. Om strategin behöver stängningskursen för att fatta beslut kan den inte samtidigt handla till den kursen. Men agenter skapar ofta mer subtila varianter när de sammanfogar datakällor eller väljer praktiska standardvärden.
Anta att en modell beräknar ett glidande medelvärde över 20 barer vid stängningen av varje minut och tar en position när stängningskursen korsar medelvärdet. Om backtestet lägger ordern till samma stängningskurs har den använt barens sista avslut innan den handeln var tillgänglig för strategin. Att flytta ordern till nästa bars öppning kan vara en rimlig approximation, även om en marknadsorder fortfarande måste ta hänsyn till avgifter och marknadspåverkan.
Byt nu ut signalen mot ett dagligt fundamentalt nyckeltal för en aktie eller en ögonblicksbild av open interest för krypto. Radens datum kanske anger måndag, men värdet kan ha publicerats efter måndagens stängning eller korrigerats senare. Ett datum är inte en tidsstämpel för när informationen blev tillgänglig.
Hur bör jag tidsstämpla en strategis indata?
Spara minst tre tidpunkter när källan tillåter det: perioden som värdet beskriver, tidpunkten då utgivaren publicerade det och tidpunkten då ditt system tog emot det. Strategins informationsmängd vid beslutstillfället får bara innehålla värden som var tillgängliga då.
| Fält | Vad det besvarar | Vanlig fallgrop |
|---|---|---|
| Händelsetid | När inträffade marknadshändelsen? | Att använda en bars stängningskurs innan baren är färdig |
| Publiceringstid | När publicerade källan det här värdet? | Att tolka en markering för dagens slut som om värdet publicerades vid öppning |
| Inläsningstid | När kunde forskningssystemet ta in värdet? | Att bortse från fördröjningar hos leverantören eller i datapipelinen |
| Revisionstid | När registrerades eller korrigerades den här versionen? | Att fylla på med reviderad historik som om den vore originalet |
För en 1-minutsstrategi är en fördröjning på en sekund inte automatiskt harmlös. Om den spelar roll beror på när beslutet fattas och vad signalen använder. Om indata är ett färdigberäknat timvärde kanske fördröjningen knappt spelar någon roll. Om det är en obalans i orderboken som samplas nära ordertidpunkten kan den vända affären.
Kan ett point-in-time-datalager förhindra läckage?
Det hjälper, om ”point-in-time” innebär att du kan hämta det värde som var känt vid en historisk beslutstidpunkt, inklusive den version som gällde då. En tabell med enbart historiska datum kan fortfarande innehålla dagens korrigerade värden för dessa datum.
Spara för varje post ett giltighetsintervall och en tidsstämpel för när den blev tillgänglig, och behåll revisioner i stället för att skriva över dem. Gör sedan historiska frågor uttryckliga: returnera den senaste versionen som var tillgänglig vid den simulerade beslutstidpunkten. Det här är särskilt viktigt för fundamentala data, indexsammansättning, ekonomiska publiceringar och datamängder som har rensats av leverantörer.
Det finns en mindre glamorös operativ hake: en perfekt publiceringstid är värdelös om inläsningsjobbet kördes tjugo minuter för sent. Om det historiska lagret inte registrerar inläsningstid bör du använda en konservativ fördröjning och ange det. Precision som källan aldrig registrerade är bara kosmetik.
Vilka kontroller upptäcker lookahead-bias före paper trading?
Be forskningsagenten skapa en tidslinje över features och ordrar tillsammans med backtestet. Registrera för varje beslut den senaste tillgänglighetstiden för varje feature, beslutstidpunkten, ordertidpunkten och den modellerade fill-tidpunkten. Avvisa varje rad där en indata anlände efter beslutet.
- Flytta signalerna framåt med en bar och jämför resultaten. En kraftig försämring kan avslöja ett beroende av tajmingen mellan stängning och stängning, men det är ett diagnostiskt test och inte ett bevis på läckage.
- Kapa varje källa vid en historisk brytpunkt, kör om pipelinen och jämför de resulterande features med de sparade historiska features.
- Ersätt en misstänkt feature med en konstant. Om resultatet nästan inte förändras bör du kontrollera om koden faktiskt använde den avsedda serien.
- Kör en avsiktligt omöjlig framtidsfeature genom pipelinen. Valideringen ska avbrytas med ett tydligt fel när dess tillgänglighetstid är senare än beslutstidpunkten.
De här kontrollerna certifierar inte en strategi. De synliggör specifika antaganden om tajming och upptäcker vanliga sätt som dessa antaganden bryts på.
Bevisar paper trading att backtestet inte hade något läckage?
Nej. Paper trading kan avslöja att den levande datavägen är försenad, saknar data eller är inriktad på ett annat sätt än den historiska. Den kan inte fastställa att gamla träningsfeatures återspeglade det som var känt då. En modell kan också sluta dra nytta av läckage helt enkelt för att framtiden den råkade se nu har blivit nutid.
Använd paper trading som en kontroll av överensstämmelse: jämför livevärdena för features, beslutstidsstämplarna, ordergenereringen och de modellerade fillsen med definitionerna i backtestet. När de skiljer sig åt bör du spåra den exakta indatan och klockan. Ett agentteam som kan förklara varje besluts informationsmängd bedriver användbar forskning. Ett agentteam som bara kan visa upp en jämn kurva har hoppat över den svåraste granskningen.
← Alla inlägg
