En backtest som kan reproduseres helt nøyaktig, kan være mindre til å stole på enn en som varierer litt. At resultatet kan gjentas, beviser at du kan få samme svar to ganger; det sier ingenting om hvorvidt svaret avhenger av ett vilkårlig dataøyeblikksbilde, en særegenhet i et bibliotek eller en skjult standardinnstilling.
Det høres ut som et argument mot reproduserbarhet, men det er det ikke. Frys kjøringen slik at du kan forklare den. Varier deretter bevisst forutsetningene som ikke burde avgjøre resultatet. Det første steget gjør resultatet etterprøvbart; det andre viser om det betyr noe.
Hva viser en reproduserbar backtest egentlig?
Hvis den samme koden, de samme dataene, den samme konfigurasjonen og det samme tilfeldige frøet gir de samme handlene og måltallene, har du kontrollert en viktig kilde til forvirring. En agents «forbedring» kan sammenlignes med den tilhørende kjøringen. En feilretting kan skilles fra en endret gebyrstruktur. En kollega kan undersøke den samme transaksjonsloggen og finne de samme utførelsene.
Men resultatet er betinget av alt du frøs. Tenk deg en kryptostrategi der historikkfilen inneholder 1-minuttsbarer. Du lagrer filens hash, låser koden til en bestemt versjon og får en Sharpe på 1.4 ved hver ny kjøring. Hvis dataleverandøren senere korrigerer flere lys, beskriver den rene reproduserbarheten fortsatt den gamle filen. Den forteller deg ikke om signalet holder seg med den korrigerte historikken, eller om lysene var tilgjengelige i den formen på det aktuelle tidspunktet.
Hashen er nyttig: Den gjør avhengigheten synlig. Den er ikke et bevis på at avhengigheten er ufarlig.
Hold kjøringen fast; utfordre funnet
Jeg liker å skille mellom to spørsmål. Kan vi gjenskape akkurat denne kjøringen? Og holder forskningskonklusjonen seg ved rimelige endringer? Det første krever en uforanderlig logg; det andre krever kontrollerte endringer, én om gangen.
| Hva du bør registrere | Hva du kan variere etterpå | Hva det kan avdekke |
|---|---|---|
| Versjon av rådata og kontrollsummer | Revisjon fra dataleverandøren eller en alternativ kilde | Avhengighet av korrigerte eller leverandørspesifikke verdier |
| Kodeversjon og pakkeversjoner | Numerisk ekvivalent implementering | Følsomhet for rekkefølge, avrunding eller bibliotek |
| Gebyrer, funding og forutsetninger om utførelse | Et forsvarlig kostnadsspenn | Om en liten fordel krever uvanlig gunstig utførelse |
| Univers og medlemskap på hvert tidspunkt | Alternative regler for hvilke markeder som er kvalifisert | Avhengighet av beslutninger om inkludering eller ekskludering |
Anta for eksempel at en futuresstrategi viser 8% annualisert meravkastning i en grunnlinjesimulering. Kjør den på nytt med takerkostnader som er 25% høyere, funding forskjøvet til neste observerte oppgjør og de to største bidragsyterne fjernet etter tur. Dette er ikke tre måter å forbedre modellen på. Det er undersøkelser: Hver av dem spør om en plausibel detalj er det som bærer hovedresultatet.
Hold hver undersøkelse atskilt. Hvis du endrer dataene, gebyrstrukturen og utførelsestidspunktet samtidig, forteller et dårligere resultat deg lite om årsaken. Og hvis en undersøkelse er lite plausibel, bør du merke den som en stresstest i stedet for å presentere den som det sannsynlige utfallet.
Ikke forveksle identiske byte med numerisk sannhet
Noen beregninger er følsomme for rekkefølgen. Addisjon med flyttall er ikke assosiativ, så summering av mange små P&L-verdier i en annen rekkefølge kan endre de siste sifrene. Parallelle reduksjoner, maskinvare og bibliotekversjoner kan alle påvirke det nøyaktige resultatet. Vanligvis er det ufarlig; noen ganger tipper en liten numerisk endring en terskel, endrer en posisjon og sender resten av simuleringen inn på et annet spor.
Derfor ville jeg bevart både de nøyaktige artefaktene og toleransegrenser for sammenligninger. Registrer handelsloggen, ikke bare den endelige Sharpe-verdien. Sammenlign først beslutninger og kontantstrømmer, deretter måltall innenfor en oppgitt toleranse. Hvis en forskjell på én cent endrer om en ordre sendes inn, bør du undersøke den grensen særskilt.
En nyttig kjørelogg inneholder identiteten til dataene og koden, konfigurasjonen, det tilfeldige frøet, kjøremiljøet og nok mellomresultater til å spore et måltall tilbake til utførelser og kontantstrømmer. En sluttscore alene er ikke et reproduserbart forskningsartefakt.
Når variasjon er støy, og når den er et funn
Ikke alle endrede tall er en krise. En liten forskyvning i måltallene på grunn av en annen summeringsrekkefølge kan la handlene være uendret. En endret handel nær en terskel kan være verdt å undersøke. En strategi som mister mesteparten av resultatet sitt når én leverandør reviderer en liten del av historikken, har lært oss noe om sin egen skjørhet, selv om den opprinnelige kjøringen fortsatt kan reproduseres helt nøyaktig.
Kritikere av robusthetstester har rett i én ting: Det er lett å fortsette å endre forutsetninger til en foretrukket strategi ser robust ut, eller å forkaste et solid resultat fordi et bevisst ekstremt scenario bryter sammen. Definer de plausible variasjonene på forhånd, rapporter hele settet, og skill mellom ordinære alternativer og stresstester. Bevar deretter grunnlinjen slik at en annen forsker kan gjenskape nøyaktig det du så.
Reproduserbarhet gir deg et pålitelig utgangspunkt. Det nyttige spørsmålet kommer etterpå: Hvilke deler av svaret står seg når omgivelsene rundt kjøringen endres på måter du med rimelighet kunne forvente?
← Alle innlegg
