Povsem ponovljiv backtest je lahko manj vreden zaupanja kot tak, pri katerem se rezultat nekoliko spreminja. Ponovljivost dokazuje, da lahko dvakrat dobimo enak odgovor; ne pove pa ničesar o tem, ali je odgovor odvisen od poljubnega posnetka podatkov, posebnosti knjižnice ali skrite privzete nastavitve.
Morda zveni, kot da nasprotujem ponovljivosti, a ni tako. Zamrznite izvedbo, da jo boste lahko pojasnili. Nato namenoma spreminjajte predpostavke, ki ne bi smele odločati o rezultatu. Prvi korak omogoči revizijo rezultata, drugi pa pokaže, ali rezultat sploh kaj pomeni.
Kaj ponovljiv backtest v resnici potrjuje?
Če enaka koda, podatki, konfiguracija in naključno seme dajo enake posle in metrike, ste nadzorovali pomemben vir zmede. »Izboljšavo« agenta lahko primerjate z njegovo predhodno izvedbo. Popravek hrošča lahko ločite od spremenjenega cenika provizij. Sodelavec lahko pregleda isto knjigo poslov in najde enake izpolnitve naročil.
Toda rezultat je pogojen z vsem, kar ste zamrznili. Predstavljajte si kriptostrategijo, katere zgodovinska datoteka vsebuje enominutne svečke. Shranite zgoščeno vrednost datoteke, določite različico kode in pri vsakem ponovnem zagonu dobite Sharpe 1.4. Če ponudnik pozneje popravi več svečk, ta čista ponovljivost še vedno opisuje staro datoteko. Ne pove vam, ali signal vzdrži popravljeno zgodovino ali pa so bile te svečke v takšni obliki sploh na voljo v tistem času.
Zgoščena vrednost je uporabna: odvisnost naredi vidno. Ni pa dokaz, da je ta odvisnost neškodljiva.
Ohranite nespremenjeno izvedbo; preverite ugotovitev
Vprašanja rad ločim na dve. Ali lahko rekonstruiramo točno to izvedbo? In ali raziskovalni sklep vzdrži razumne spremembe? Prvo zahteva nespremenljiv zapis, drugo pa nadzorovane spremembe, vsakič samo ene predpostavke.
| Kaj zabeležiti | Kaj nato spreminjati | Kaj lahko razkrije |
|---|---|---|
| Različica neobdelanih podatkov in kontrolne vsote | Revizija ponudnika ali drugi vir | Odvisnost od popravljenih vrednosti ali vrednosti, specifičnih za ponudnika |
| Commit kode in različice paketov | Številčno enakovredna implementacija | Občutljivost na vrstni red, zaokroževanje ali knjižnico |
| Provizije, financiranje in predpostavke o izpolnitvah | Utemeljen razpon stroškov | Ali majhen presežni donos zahteva nenavadno ugodne pogoje izvedbe |
| Nabor instrumentov in članstvo v danem trenutku | Alternativna pravila za upravičene trge | Odvisnost od odločitev o vključitvi ali izključitvi |
Recimo, da strategija terminskih pogodb v osnovni ponovitvi pokaže 8-odstotni presežni donos na letni ravni. Ponovite simulacijo s stroški taker, višjimi za 25 %, s financiranjem, premaknjenim na naslednjo opaženo poravnavo, in z odstranitvijo dveh največjih prispevkov, vsakega posebej. To niso trije načini za izboljšanje modela. To so preizkusi: vsak sprašuje, ali pomemben podatek nosi glavno sporočilo.
Vsak preizkus izvedite ločeno. Če hkrati spremenite podatke, cenik provizij in čas izvedbe, vam slabši rezultat ne pove veliko o vzroku. Če je preizkus malo verjeten, ga označite kot stresni scenarij, namesto da ga predstavite kot verjeten izid.
Ne zamenjujte enakosti bajt za bajtom z numerično resničnostjo
Nekateri izračuni so občutljivi na vrstni red. Seštevanje s plavajočo vejico ni asociativno, zato se lahko vsota številnih majhnih vrednosti P&L ob drugačnem vrstnem redu seštevanja spremeni v zadnjih nekaj števkah. Vzporedno seštevanje, strojna oprema in različice knjižnic lahko vplivajo na natančen izhod. Običajno to ni problem; včasih pa že majhna numerična sprememba prevesi prag, spremeni pozicijo in preusmeri preostanek simulacije po drugi poti.
Zato bi ohranil tako natančne artefakte kot tolerance za primerjave. Zabeležite knjigo poslov, ne le končnega Sharpe. Najprej primerjajte odločitve in denarne tokove, nato pa metrike znotraj navedene tolerance. Če razlika enega centa spremeni odločitev o oddaji naročila, ta robni primer izrecno preučite.
Koristen zapis izvedbe vključuje identiteto podatkov in kode, konfiguracijo, naključno seme, okolje izvajanja in dovolj vmesnih izhodov, da lahko metriko povežemo z izpolnitvami in denarnimi tokovi. Sama končna ocena ni ponovljiv raziskovalni artefakt.
Kdaj so spremembe šum in kdaj ugotovitev
Vsaka spremenjena številka še ne pomeni krize. Majhen odmik metrike zaradi drugačnega vrstnega reda seštevanja morda ne spremeni poslov. Spremenjen posel blizu praga je morda vreden pregleda. Strategija, ki izgubi večino rezultata, ko ponudnik popravi majhen del zgodovine, nam je nekaj povedala o svoji krhkosti, četudi je prvotna izvedba še vedno povsem ponovljiva.
Kritiki preverjanj robustnosti imajo glede ene stvari prav: predpostavke je lahko spreminjati tako dolgo, da priljubljena strategija deluje odporna, ali pa zavrniti dober rezultat, ker ga poruši namenoma skrajen scenarij. Vnaprej določite verjetne spremembe, poročajte o celotnem naboru in ločite običajne alternative od stresnih scenarijev. Nato ohranite osnovno različico, da bo lahko drug raziskovalec natančno ponovil to, kar ste videli.
Ponovljivost vam da zanesljivo izhodišče. Nato sledi koristno vprašanje: kateri deli odgovora ostanejo nespremenjeni, ko se svet okoli te izvedbe spremeni na načine, ki jih lahko razumno pričakujemo?
← Vse objave
