Egy tökéletesen reprodukálható backteszt kevésbé lehet megbízható, mint egy, amelynek eredménye kissé változik. Az ismételhetőség azt bizonyítja, hogy kétszer is megkaphatod ugyanazt az eredményt; arról semmit sem mond, hogy az eredmény egy önkényesen választott adatpillanatképtől, egy könyvtár sajátosságától vagy egy rejtett alapértelmezett beállítástól függ-e.
Ez úgy hangzik, mintha a reprodukálhatóság ellen érvelnénk, pedig nem erről van szó. Rögzítsd a futást, hogy meg tudd magyarázni. Aztán szándékosan változtass azokon a feltételezéseken, amelyeknek nem kellene eldönteniük az eredményt. Az első lépéstől auditálható lesz az eredmény; a másodikból kiderül, hogy jelent-e bármit.
Mit bizonyít valójában egy reprodukálható backteszt?
Ha ugyanaz a kód, adat, konfiguráció és véletlenszám-mag ugyanazokat a kötéseket és mutatókat eredményezi, akkor a félreértések egyik fontos forrását már kontrolláltad. Egy agent „javulását” össze tudod vetni a kiinduló futásával. Elkülöníthető a hibajavítás a díjszabás módosításától. Egy kolléga ugyanazt a tranzakciós naplót vizsgálhatja át, és ugyanazokat a kötéseket találhatja benne.
Az eredmény azonban mindentől függ, amit rögzítettél. Vegyünk egy kriptostratégiát, amelynek előzményfájlja 1 perces gyertyákat tartalmaz. Elmented a fájl hashét, rögzíted a kódot, és minden újrafuttatáskor 1.4-es Sharpét kapsz. Ha a szolgáltató később több gyertyát korrigál, a makulátlan reprodukálhatóság továbbra is a régi fájlt írja le. Azt nem árulja el, hogy a jelzés megmarad-e a korrigált előzményeken, vagy hogy ezek a gyertyák annak idején egyáltalán ilyen formában rendelkezésre álltak-e.
A hash hasznos: láthatóvá teszi a függőséget. Azt viszont nem bizonyítja, hogy ez a függőség ártalmatlan.
Rögzítsd a futást; tedd próbára a megállapítást
Szeretem két külön kérdésként kezelni ezt. Újra elő tudjuk állítani pontosan ezt a futást? És a kutatás következtetése észszerű változtatások mellett is megállja a helyét? Az elsőhöz változtathatatlan feljegyzés kell; a másodikhoz kontrollált, egyszerre egy tényezőt érintő módosítások.
| Mit rögzítsünk | Min változtassunk utólag | Mire derülhet fény |
|---|---|---|
| A nyers adatok verziója és ellenőrző összegei | A szolgáltató módosított adatai vagy egy második forrás | Korrigált vagy szolgáltató-specifikus értékektől való függés |
| Kódverzió-azonosító és csomagverziók | Numerikusan egyenértékű implementáció | A műveleti sorrend, a kerekítés vagy a könyvtár érzékenysége |
| Díjak, finanszírozás és kötési feltételezések | Védhető költségtartomány | Szüksége van-e a csekély előnynek szokatlanul kedvező végrehajtásra |
| Instrumentumkör és az adott időpontban érvényes tagság | Alternatív jogosultpiaci szabályok | A beválasztási vagy kizárási döntésektől való függés |
Tegyük fel például, hogy egy határidős stratégiánál az alaphelyzetet lejátszva 8% évesített többlethozam adódik. Futtasd újra 25%-kal magasabb taker-költségekkel, a finanszírozást a következő megfigyelt elszámolási időpontra tolva, majd egyenként elhagyva a két legnagyobb hozzájárulót. Ez nem három módszer a modell javítására. Ezek vizsgálatok: mindegyik azt kérdezi, vajon egy hihető részlet adja-e a címlapra kívánkozó eredményt.
Minden vizsgálatot külön végezz el. Ha egyszerre módosítod az adatokat, a díjszabást és a végrehajtás időzítését, a rosszabb eredményből alig tudsz következtetni az okra. Ha pedig egy vizsgálat valószerűtlen, jelöld stresszhelyzetnek, és ne a várható kimenetként mutasd be.
Ne téveszd össze a bájtról bájtra egyezést a numerikus pontossággal
Egyes számítások érzékenyek a műveleti sorrendre. A lebegőpontos összeadás nem asszociatív, ezért sok kis P&L-érték más sorrendben történő összeadása az utolsó néhány számjegyet megváltoztathatja. A párhuzamos redukciók, a hardver és a könyvtárverziók mind befolyásolhatják a pontos kimenetet. Ez általában ártalmatlan; néha azonban egy apró numerikus eltérés átbillent egy küszöbértéken, módosít egy pozíciót, és más pályára állítja a szimuláció hátralévő részét.
Ezért őrizném meg a pontos artefaktumokat és az összehasonlítások tűréshatárait is. Ne csak a végső Sharpét rögzítsd, hanem a kötési naplót is. Először a döntéseket és a pénzáramlásokat hasonlítsd össze, utána a mutatókat az előre megadott tűréshatáron belül. Ha egy 1 centes eltérés megváltoztatja, hogy beküldünk-e egy megbízást, külön vizsgáld meg ezt a határhelyzetet.
A hasznos futásnapló tartalmazza az adat és a kód azonosítóját, a konfigurációt, a véletlenszám-magot, a végrehajtási környezetet, valamint elegendő köztes kimenetet ahhoz, hogy egy mutatót vissza lehessen vezetni a kötésekig és a pénzáramlásokig. A végső pontszám önmagában nem reprodukálható kutatási artefaktum.
Mikor zaj a változás, és mikor megállapítás
Nem minden megváltozott szám ad okot aggodalomra. Egy másik redukciós sorrend miatt fellépő apró mutatóeltérés mellett a kötések változatlanok maradhatnak. Egy küszöb közelében megváltozó kötést érdemes lehet felülvizsgálni. Ha egy szolgáltató az előzmények kis részét módosítja, és a stratégia erre elveszíti az eredményének nagy részét, megtudtál valamit a saját sérülékenységéről, még akkor is, ha az eredeti futás tökéletesen reprodukálható marad.
A robusztussági ellenőrzések bírálói egy dologban igazat mondanak: könnyű addig változtatni a feltételezéseken, amíg a nekünk tetsző stratégia ellenállónak látszik, vagy elvetni egy megalapozott eredményt, mert egy szándékosan szélsőséges forgatókönyvben elbukik. Előre határozd meg a hihető változtatásokat, közöld a teljes eredményhalmazt, és különítsd el a szokásos alternatívákat a stresszhelyzetektől. Ezután őrizd meg az alaphelyzetet, hogy egy másik kutató pontosan reprodukálhassa, amit láttál.
A reprodukálhatóság megbízható kiindulópontot ad. Ezután jön a hasznos kérdés: a válasz mely részei maradnak változatlanok, ha a futás körülményei olyan módon változnak meg, amelyre észszerűen számíthatunk?
← Összes bejegyzés
