En AI-strategiagent kan lave en gyldig backtest, selvom den bruger information, der ikke fandtes, da handlerne skulle udføres. Koden kører. Egenkapitalkurven ser plausibel ud. Signalet kan endda virke fornuftigt. Alligevel har et tidsstempel, et join eller et revideret datafelt i det skjulte givet den svaret på morgendagens spørgsmål.
Løsningen er at gøre tidspunktet, hvor data bliver tilgængelige, til en del af forskningsaftalen. For hvert input skal der være et klart svar på to spørgsmål: Hvilken periode beskriver værdien, og hvornår kunne strategien tidligst have kendt til den?
Hvordan ser lookahead bias ud i en AI-genereret strategi?
Den mest åbenlyse variant er et signal, der beregnes ud fra samme bars lukkepris, efterfulgt af en udførelse til den pris. Hvis strategien skal bruge lukkeprisen for at træffe en beslutning, kan den ikke samtidig handle til den pris. Men agenter laver ofte mere subtile varianter, når de joiner datakilder eller vælger bekvemme standardindstillinger.
Forestil dig, at en model beregner et glidende gennemsnit over 20 bars ved hvert minuts lukning og tager en position, når lukkeprisen krydser gennemsnittet. Hvis backtesten udfører ordren ved samme lukning, har den brugt barens sidste handel, før den handel var tilgængelig for strategien. At flytte ordren til næste bars åbning kan være en rimelig tilnærmelse, men en markedsordre kræver stadig gebyrer og priseffekt.
Lad nu denne feature være et dagligt fundamentaldatafelt for en aktie eller et øjebliksbillede af open interest i krypto. Datoen på rækken siger måske mandag, men værdien kan være offentliggjort efter mandagens lukning eller rettet senere. En dato er ikke et tilgængelighedstidsstempel.
Hvordan bør jeg tidsstemple strategiens input?
Gem mindst tre tidspunkter, når kilden gør det muligt: den periode, en værdi beskriver, tidspunktet, hvor udgiveren offentliggjorde den, og tidspunktet, hvor dit system modtog den. Strategiens informationsmængde på beslutningstidspunktet må kun indeholde værdier, der var tilgængelige på det tidspunkt.
| Felt | Hvad det besvarer | Typisk faldgrube |
|---|---|---|
| Hændelsestidspunkt | Hvornår fandt markedshændelsen sted? | At bruge en bars lukkepris, før baren er afsluttet |
| Offentliggørelsestidspunkt | Hvornår offentliggjorde kilden denne værdi? | At behandle en slut-på-dagen-markering, som om værdien blev offentliggjort ved dagens start |
| Indlæsningstidspunkt | Hvornår kunne dette researchsystem have indlæst værdien? | At ignorere forsinkelser hos leverandøren eller i datakørslen |
| Revisionstidspunkt | Hvornår blev denne version registreret eller rettet? | At udfylde historikken med reviderede værdier, som om de var de oprindelige |
For en 1-minutsstrategi er en forsinkelse på 1 sekund ikke automatisk harmløs. Om den betyder noget, afhænger af, hvornår beslutningen træffes, og hvad signalet bruger. Hvis inputtet er en afsluttet statistik for en time, betyder det måske næsten intet. Hvis det er en ubalance i ordrebogen målt tæt på ordretidspunktet, kan den vende handlen på hovedet.
Kan et point-in-time-datalager forhindre lækager?
Det hjælper, hvis »point-in-time« betyder, at du kan hente den værdi, der var kendt på et historisk beslutningstidspunkt, inklusive den revision, der gjaldt dengang. En tabel med historiske datoer kan stadig indeholde dagens korrigerede værdier for de datoer.
Gem for hver post et gyldighedsinterval og et tilgængelighedstidsstempel, og behold revisionerne i stedet for at overskrive dem. Gør derefter historiske forespørgsler eksplicitte: returnér den seneste version, der var tilgængelig på det simulerede beslutningstidspunkt. Det er især vigtigt for fundamentaldata, indekssammensætning, økonomiske offentliggørelser og datasæt, som leverandører har renset.
Der er en usexet operationel detalje: Et perfekt offentliggørelsestidsstempel er værdiløst, hvis indlæsningsjobbet kørte 20 minutter for sent. Hvis det historiske lager ikke registrerer indlæsningstidspunktet, så brug en konservativ forsinkelse og gør rede for det. Præcision, som kilden aldrig har registreret, er kun pynt.
Hvilke tjek afslører lookahead bias før paper trading?
Bed researchagenten om at vise en tidslinje for features og ordrer sammen med backtesten. Registrér for hver beslutning det seneste tilgængelighedstidspunkt for kilden til hver feature, beslutningstidspunktet, ordretidspunktet og det modellerede udførelsestidspunkt. Afvis enhver række, hvor et input ankom efter beslutningen.
- Forskyd signalerne 1 bar frem, og sammenlign resultaterne. Et stort fald kan afsløre afhængighed af timing fra lukning til lukning, men det er en diagnostisk kontrol, ikke et bevis på lækage.
- Afskær hver kilde ved et historisk skæringstidspunkt, kør datapipelinen igen, og sammenlign de resulterende features med de gemte historiske features.
- Erstat en mistænkelig feature med en konstant. Hvis performance stort set er uændret, så undersøg, om koden faktisk brugte den tilsigtede dataserie.
- Kør en bevidst umulig fremtidsfeature gennem pipelinen. Valideringen skal fejle tydeligt, når dens tilgængelighedstidspunkt ligger efter beslutningstidspunktet.
Disse tjek certificerer ikke en strategi. De gør konkrete antagelser om timing synlige og afslører almindelige måder, de antagelser bliver brudt på.
Beviser paper trading, at backtesten ikke havde lækager?
Nej. Paper trading kan afsløre en live-datastrøm, der er forsinket, mangelfuld eller synkroniseret anderledes end den historiske. Det kan ikke fastslå, at gamle træningsfeatures afspejlede det, man vidste på det tidspunkt. En model kan også holde op med at få fordel af lækagen, simpelthen fordi fremtiden, den ved et uheld så, nu er blevet nutid.
Brug paper trading som en kontrol af overensstemmelse: Sammenlign liveværdierne for features, beslutningstidsstempler, ordreoprettelse og modellerede udførelser med backtestens definitioner. Når de afviger, så spor det præcise input og ur. Et agentteam, der kan forklare informationsmængden bag hver beslutning, udfører nyttigt researcharbejde. Et agentteam, der kun kan vise dig en glat kurve, har sprunget den vanskeligste revision over.
← Alle indlæg
