En AI-strategiagent kan produsere en gyldig backtest samtidig som den bruker informasjon som ikke fantes da handlene skulle utføres. Koden kjører. Egenkapitalkurven ser plausibel ut. Signalet kan til og med være fornuftig. Likevel har et tidsstempel, en sammenføyning eller et revidert datafelt i det stille gitt den svaret på morgendagen.
Løsningen er å gjøre tilgjengelighetstid til en del av forskningskontrakten. For hver inndata må det finnes et tydelig svar på to spørsmål: Hvilket tidspunkt beskriver denne verdien, og når kunne strategien tidligst ha kjent til den?
Hvordan ser lookahead-bias ut i en AI-generert strategi?
Den åpenbare varianten er et signal som beregnes fra sluttkursen på samme bar, etterfulgt av en utførelse til den sluttkursen. Hvis strategien trenger sluttkursen for å ta en beslutning, kan den ikke også handle til den prisen. Men agenter lager ofte mer subtile varianter når de kobler sammen datakilder eller velger praktiske standardverdier.
Tenk deg at en modell beregner et glidende gjennomsnitt over 20 barer ved slutten av hvert minutt og tar en posisjon når sluttkursen krysser gjennomsnittet. Hvis backtesten utfører ordren til den samme sluttkursen, har den brukt barens siste handel før denne handelen var tilgjengelig for strategien. Å flytte ordren til åpningen av neste bar kan være en rimelig tilnærming, selv om en markedsordre fortsatt må ta høyde for gebyrer og markedspåvirkning.
Bytt nå ut funksjonen med et daglig nøkkeltall for aksjer eller et øyeblikksbilde av åpen interesse i krypto. Datoen på raden kan være mandag, men verdien kan ha blitt publisert etter mandagens slutt, eller korrigert senere. En dato er ikke et tilgjengelighetstidsstempel.
Hvordan bør jeg tidsstemple inndataene til en strategi?
Ta vare på minst tre tidspunkter der kilden gir dem: perioden en verdi beskriver, tidspunktet publisisten kunngjorde den, og tidspunktet systemet ditt mottok den. Strategiens informasjonsgrunnlag når den tar en beslutning kan bare inneholde verdier som var tilgjengelige innen da.
| Felt | Hva det forteller | Vanlig fallgruve |
|---|---|---|
| Hendelsestid | Når skjedde markedshendelsen? | Å bruke barens sluttkurs før baren er fullført |
| Publiseringstid | Når publiserte kilden denne verdien? | Å behandle en slutt-på-dagen-merking som om den ble publisert ved åpning |
| Inntakstid | Når kunne dette forskningssystemet ha lest den? | Å ignorere forsinkelser hos leverandøren eller i datapipelinen |
| Revisjonstid | Når ble denne versjonen registrert eller korrigert? | Å fylle historikken med reviderte verdier som om de var de opprinnelige |
For en 1-minuttsstrategi er en forsinkelse på ett sekund ikke automatisk ubetydelig. Om den spiller noen rolle, avhenger av når beslutningen tas og hva signalet bruker. Hvis inndataene er en fullført statistikk per time, har det kanskje knapt noe å si. Hvis de er en ubalanse i ordreboken målt like før ordren, kan det snu handelen.
Kan et punkt-i-tid-datalager hindre lekkasjer?
Det hjelper hvis «punkt-i-tid» betyr at du kan hente verdien som var kjent på et historisk beslutningstidspunkt, inkludert den versjonen som gjaldt da. En tabell med historiske datoer kan fortsatt inneholde dagens korrigerte verdier for disse datoene.
Bevar et gyldighetsintervall og et tilgjengelighetstidsstempel for hver post, og ta vare på revisjoner i stedet for å overskrive dem. Gjør deretter historiske spørringer eksplisitte: returner den nyeste versjonen som var tilgjengelig på det simulerte beslutningstidspunktet. Dette er særlig viktig for nøkkeltall, indeksmedlemskap, økonomiske publiseringer og datasett som er renset av leverandører.
Her er en lite glamorøs driftsutfordring: Et perfekt publiseringstidsstempel er ubrukelig hvis jobben som henter inn data, kjørte tjue minutter for sent. Hvis det historiske lageret ikke registrerer inntakstid, bruk en konservativ forsinkelse og opplys om det. Presisjon som kilden aldri registrerte, er bare pynt.
Hvilke kontroller avdekker lookahead-bias før paper trading?
Be forskningsagenten lage en tidslinje for funksjoner og ordrer sammen med backtesten. Registrer for hver beslutning det seneste tilgjengelighetstidspunktet for kilden til hver funksjon, beslutningstidspunktet, ordretidspunktet og det modellerte utførelsestidspunktet. Avvis alle rader der en inndata kom etter beslutningen.
- Forskyv signalene én bar frem og sammenlign resultatene. Et kraftig fall kan avdekke avhengighet av tidsberegningen mellom sluttkurser, men dette er en diagnostisk kontroll, ikke et bevis på lekkasje.
- Avgrens hver kilde ved et historisk skjæringstidspunkt, kjør pipelinen på nytt og sammenlign de resulterende funksjonene med de lagrede historiske funksjonene.
- Bytt ut en mistenkt funksjon med en konstant. Hvis resultatene er nesten uendret, undersøk om koden faktisk brukte den tiltenkte serien.
- Kjør en bevisst umulig fremtidsfunksjon gjennom pipelinen. Valideringen bør feile tydelig når tilgjengelighetstidspunktet ligger etter beslutningstidspunktet.
Disse kontrollene sertifiserer ikke en strategi. De synliggjør konkrete antakelser om timing og avdekker vanlige måter disse antakelsene brytes på.
Beviser paper trading at backtesten var fri for lekkasjer?
Nei. Paper trading kan avdekke en live-datastrøm som er forsinket, mangelfull eller justert annerledes enn den historiske. Det kan ikke fastslå at de gamle treningsfunksjonene gjenspeilte det man visste på det aktuelle tidspunktet. En modell kan også slutte å dra nytte av en lekkasje ganske enkelt fordi fremtiden den ved et uhell så, nå er blitt nåtiden.
Bruk paper trading som en paritetskontroll: Sammenlign live-verdiene for funksjonene, beslutningstidsstemplene, ordreopprettingen og de modellerte utførelsene med definisjonene i backtesten. Når de avviker, spor den nøyaktige inndataen og klokken. Et agentteam som kan forklare informasjonsgrunnlaget for hver beslutning, gjør nyttig forskning. Et agentteam som bare kan vise deg en jevn kurve, har hoppet over den vanskeligste revisjonen.
← Alle innlegg
