Ett perfekt reproducerbart backtest kan vara mindre tillförlitligt än ett som varierar lite. Upprepbarhet visar att du kan få samma svar två gånger; den säger inget om huruvida svaret beror på en godtycklig ögonblicksbild av data, en egenhet i ett bibliotek eller ett dolt standardvärde.
Det låter som ett argument mot reproducerbarhet, men det är det inte. Frys körningen så att du kan förklara den. Variera sedan medvetet de antaganden som inte borde avgöra resultatet. Det första steget gör resultatet granskningsbart; det andra visar om det betyder något.
Vad visar ett reproducerbart backtest egentligen?
Om samma kod, data, konfiguration och slumpfrö ger samma affärer och mätvärden har du kontrollerat en viktig källa till förvirring. Du kan jämföra en agents ”förbättring” med dess föregående körning. En buggfix kan skiljas från ett ändrat avgiftsschema. En kollega kan granska samma transaktionslogg och hitta samma avslut.
Men resultatet är villkorat av allt du har fryst. Tänk dig en kryptostrategi vars historikfil innehåller 1-minutsstaplar. Du sparar filens hash, låser koden och får en Sharpe-kvot på 1.4 vid varje omkörning. Om leverantören senare korrigerar flera ljusstakar beskriver den prydliga reproducerbarheten fortfarande den gamla filen. Den säger inte om signalen håller i den korrigerade historiken eller om ljusstakarna såg ut så vid den aktuella tidpunkten.
Hashen är användbar: den gör beroendet synligt. Den visar inte att beroendet är ofarligt.
Håll körningen fast; pröva resultatet
Jag brukar skilja på två frågor. Kan vi återskapa exakt den här körningen? Och håller forskningsslutsatsen vid rimliga förändringar? Den första kräver en oföränderlig dokumentation; den andra kräver kontrollerade störningar, en i taget.
| Vad du ska dokumentera | Vad du ska variera efteråt | Vad det kan avslöja |
|---|---|---|
| Version av rådata och kontrollsummor | Leverantörsrevision eller en andra källa | Beroende av korrigerade eller leverantörsspecifika värden |
| Kodens commit och paketversioner | Numeriskt likvärdig implementering | Känslighet för ordningsföljd, avrundning eller bibliotek |
| Avgifter, funding och antaganden om avslut | Ett försvarbart kostnadsintervall | Om en liten fördel kräver ovanligt gynnsamma avslut |
| Universum och medlemskap vid den aktuella tidpunkten | Alternativa regler för vilka marknader som får ingå | Beroende av beslut om inkludering eller exkludering |
Anta till exempel att en futuresstrategi visar 8% annualiserad överavkastning i en baslinjeåterskapning. Kör om den med 25% högre takerkostnader, funding förskjuten till nästa observerade avräkning och de två största bidragsgivarna borttagna, en i taget. Det är inte tre sätt att förbättra modellen. Det är prövningar: var och en undersöker om en rimlig detalj bär upp huvudresultatet.
Håll varje prövning separat. Om du ändrar data, avgiftsschema och exekveringstidpunkt samtidigt säger ett sämre resultat inte mycket om orsaken. Och om en prövning är orimlig ska du märka den som ett stresstest i stället för att presentera den som det sannolika utfallet.
Förväxla inte identiska byte med numerisk sanning
Vissa beräkningar är känsliga för ordningsföljden. Flyttalsaddition är inte associativ, så när många små P&L-värden summeras i en annan ordning kan de sista siffrorna ändras. Parallella reduktioner, hårdvara och biblioteksversioner kan alla påverka det exakta resultatet. Oftast är det ofarligt; ibland gör en liten numerisk förändring att en tröskel passeras, en position ändras och resten av simuleringen tar en annan väg.
Därför skulle jag spara både de exakta artefakterna och toleransgränser för jämförelser. Dokumentera transaktionsloggen, inte bara den slutliga Sharpe-kvoten. Jämför först beslut och kassaflöden och jämför sedan mätvärden inom en angiven tolerans. Om en skillnad på ett cent avgör om en order skickas, granska den gränsen särskilt.
En användbar körningsdokumentation innehåller data- och kodidentitet, konfiguration, slumpfrö, exekveringsmiljö och tillräckligt med mellanresultat för att spåra ett mätvärde tillbaka till avslut och kassaflöden. Ett slutresultat räcker inte som reproducerbar forskningsartefakt.
När variation är brus och när den är ett resultat
Alla förändrade tal är inte en kris. En liten förskjutning i ett mätvärde på grund av en annan summeringsordning kan lämna affärerna oförändrade. En ändrad affär nära en tröskel kan vara värd att granska. En strategi som förlorar större delen av sitt resultat när en leverantör reviderar en liten del av historiken har lärt dig något om sin egen skörhet, även om den ursprungliga körningen fortfarande är perfekt reproducerbar.
Kritiker av robusthetstester har rätt i en sak: det är lätt att fortsätta ändra antaganden tills en strategi man föredrar verkar tålig, eller att förkasta ett hållbart resultat för att ett avsiktligt extremt scenario får det att fallera. Fördefiniera rimliga variationer, redovisa hela uppsättningen och skilj vanliga alternativ från stresstester. Bevara sedan baslinjen så att en annan forskare kan reproducera exakt det du såg.
Reproducerbarhet ger dig en tillförlitlig utgångspunkt. Sedan kommer den användbara frågan: vilka delar av svaret står sig när omvärlden kring körningen förändras på sätt som du rimligen kunde förvänta dig?
← Alla inlägg
