En backtest, der kan reproduceres perfekt, kan være mindre troværdig end én, der varierer en smule. Gentagelighed viser, at du kan få det samme svar to gange; den siger intet om, hvorvidt svaret afhænger af ét vilkårligt datasnapshot, en særhed i et bibliotek eller en skjult standardindstilling.
Det lyder som et argument imod reproducerbarhed, men det er det ikke. Fastlås kørslen, så du kan forklare den. Variér derefter bevidst de antagelser, der ikke bør afgøre resultatet. Første skridt gør resultatet efterprøveligt; det andet fortæller dig, om det betyder noget.
Hvad fastslår en reproducerbar backtest egentlig?
Hvis den samme kode, de samme data og den samme konfiguration og random seed giver de samme handler og målinger, har du kontrolleret en vigtig kilde til forvirring. En agents ”forbedring” kan sammenlignes med dens oprindelige kørsel. En fejlrettelse kan adskilles fra en ændret gebyrstruktur. En kollega kan gennemgå den samme transaktionsbog og finde de samme fills.
Men resultatet gælder kun under alt det, du fastlåste. Forestil dig en kryptostrategi, hvis historiske fil indeholder 1-minutsbarer. Du gemmer filens hash, fastlåser koden og får en Sharpe på 1.4 ved hver genkørsel. Hvis dataleverandøren senere korrigerer flere candles, beskriver den rene reproducerbarhed stadig den gamle fil. Den fortæller dig ikke, om signalet holder i den korrigerede historik, eller om candle-dataene var tilgængelige i den form på det tidspunkt.
Hashen er nyttig: Den gør afhængigheden synlig. Den er ikke et bevis på, at afhængigheden er harmløs.
Fastlås kørslen; udfordr fundet
Jeg foretrækker at skelne mellem to spørgsmål. Kan vi genskabe netop denne kørsel? Og holder forskningskonklusionen ved rimelige ændringer? Det første kræver en uforanderlig registrering; det andet kræver kontrollerede ændringer, én ad gangen.
| Hvad du skal registrere | Hvad du skal variere bagefter | Hvad det kan afsløre |
|---|---|---|
| Version af rådata og checksums | Revision fra dataleverandøren eller en anden kilde | Afhængighed af korrigerede værdier eller værdier, der er specifikke for dataleverandøren |
| Kodecommit og pakkeversioner | Numerisk ækvivalent implementering | Følsomhed over for rækkefølge, afrunding eller biblioteker |
| Gebyrer, funding og antagelser om fills | Et velbegrundet omkostningsinterval | Om en lille edge kræver usædvanligt gunstig eksekvering |
| Univers og medlemskab på det givne tidspunkt | Alternative regler for, hvilke markeder der er kvalificerede | Afhængighed af beslutninger om inklusion eller eksklusion |
Forestil dig for eksempel, at en futuresstrategi viser et annualiseret merafkast på 8% i en baseline-replay. Kør den igen med taker-omkostninger, der er 25% højere, funding flyttet til den næste observerede afregning og hver af de to største bidragydere fjernet efter tur. Det er ikke tre måder at forbedre modellen på. Det er sonderinger: Hver af dem spørger, om en plausibel detalje bærer hovedresultatet.
Hold hver sondering adskilt. Hvis du ændrer data, gebyrstruktur og eksekveringstidspunkt på én gang, giver et dårligere resultat dig kun lidt indsigt i årsagen. Og hvis en sondering er usandsynlig, så mærk den som et stresstilfælde i stedet for at præsentere den som det forventede udfald.
Forveksl ikke identiske bytes med numerisk sandhed
Nogle beregninger er følsomme over for rækkefølgen. Addition med flydende komma er ikke associativ, så hvis mange små P&L-værdier summeres i en anden rækkefølge, kan de sidste cifre ændre sig. Parallelle reduktioner, hardware og biblioteksversioner kan alle påvirke det præcise output. Som regel er det harmløst; nogle gange ændrer en lille numerisk forskel en tærskel, ændrer en position og sender resten af simuleringen ad en anden vej.
Derfor ville jeg gemme både de præcise artefakter og tolerancer for sammenligninger. Registrér handelsbogen, ikke kun den endelige Sharpe. Sammenlign først beslutninger og pengestrømme, derefter målinger inden for en angivet tolerance. Hvis en forskel på én cent ændrer, om en ordre bliver afgivet, skal du undersøge netop den grænse.
En nyttig kørselsregistrering indeholder identiteten på data og kode, konfigurationen, random seed, eksekveringsmiljøet og nok mellemliggende output til at spore en måling tilbage til fills og pengestrømme. En slutscore alene er ikke et reproducerbart forskningsartefakt.
Hvornår variation er støj, og hvornår den er et fund
Ikke alle ændrede tal er en krise. En lille afvigelse i målingen som følge af en anden summeringsrækkefølge ændrer måske ikke handlerne. En ændret handel tæt på en tærskel kan være værd at gennemgå. En strategi, der mister det meste af sit resultat, når én dataleverandør reviderer et lille udsnit af historikken, har afsløret noget om sin egen skrøbelighed, selvom den oprindelige kørsel stadig kan reproduceres perfekt.
Kritikere af robusthedstjek har ret i én ting: Det er let at blive ved med at ændre antagelser, indtil en foretrukken strategi ser robust ud, eller at forkaste et solidt resultat, fordi et bevidst ekstremt scenarie får det til at bryde sammen. Definér på forhånd de plausible variationer, rapportér dem alle, og skeln mellem almindelige alternativer og stresstilfælde. Bevar derefter baseline, så en anden forsker kan reproducere præcis det, du så.
Reproducerbarhed giver dig et pålideligt udgangspunkt. Det nyttige spørgsmål kommer bagefter: Hvilke dele af svaret holder sig, når verden omkring kørslen ændrer sig på måder, du med rimelighed kunne forvente?
← Alle indlæg
