Muli naming pinatakbo ang isang naka-save na backtest at iba ang naging equity curve. Parehong code ng strategy, parehong saklaw ng petsa, parehong symbol. Nagkakaiba nang 1.8% ang panghuling balanse, at nailipat nang isang bar ang tatlong trade.
Sapat na iyon para mahirap pagkatiwalaan ang resulta ng pananaliksik. Kung hindi kayang ulitin ng kasamahan, ng susunod na bersyon mo, o ng serbisyong paper trading ang run, hindi mo malalaman kung nagpahusay ba sa strategy ang pagbabago o binago lang nito ang eksperimento. Ganito ang sinundan naming mga hakbang para hanapin ang paglihis.
Araw 1: Itinala namin kung ano ang ibig sabihin ng “parehong run”
Ang una naming pagkakamali ay ituring na eksperimento ang file ng strategy. Hindi iyon sapat. Nakadepende rin ang run sa input data, bersyon ng engine, kalendaryo, metadata ng instrumento at mga setting ng execution. Isang bahagi lang ng pagkalkula ang inilalarawan ng code.
Gumawa muna kami ng manifest ng run bago magbago ng anuman. Itinala rito ang commit ng strategy, mga identifier ng snapshot ng data, saklaw ng petsa, venue, iskedyul ng bayarin, pinagmulan ng funding, fill model at mga bersyon ng software. Iniligtas din namin ang mga order at fill na nagresulta, dahil hindi ipinapakita ng equity curve lang kung saan unang nagkahiwalay ang dalawang run.
| Artifact | Ano ang itatala | Bakit mahalaga |
|---|---|---|
| Market data | Snapshot ID, bersyon ng schema, mga adjustment | Inaayos ng mga vendor ang history at nirerebisa ang mga corporate action |
| Execution | Fee tier, serye ng funding, mga setting ng fill at impact | Binabago ng mga default at palagay sa account ang mga resulta |
| Runtime | Commit ng code, mga bersyon ng engine at dependency | Maaaring baguhin ng mga library ang pagkakasunod-sunod, pag-round o mga indicator |
| Output | Mga order, fill, posisyon at metric | Ipinapakita kung saan nagsisimulang magkaiba ang mga run |
Araw 2: Mga trade ang pinagkumpara namin, hindi ang Sharpe
Nakagambala ang mga buod na metric. Halos magkapareho ang Sharpe ng dalawang run, pero ipinakita ng mga fill log ang unang hindi pagtutugma sa settlement ng funding. Sinisingil ng isang run ang rate sa posisyong bukas sa timestamp ng settlement; ginamit naman ng isa ang posisyon pagkatapos ng rebalance sa timestamp na iyon.
Hindi nagbago ang code ng strategy. Nagbago ang pagkakasunod-sunod ng mga event sa engine. Dahil sa maliit na pag-update ng bersyon, naging tahasan ang pagkakasunod-sunod na dati'y nakadepende sa kung paano nagkataong naayos ang dalawang event.
Inayos namin ang kontrata ng run para tukuyin ang pagkakasunod-sunod: ilapat ang funding sa posisyong hawak pagdating sa settlement, saka iproseso ang mga desisyon ng strategy para sa timestamp na iyon. Maaaring mag-iba ang eksaktong pamamaraang ito ayon sa venue at engine. Ang hindi pagtukoy rito ang bug.
Araw 3: Magkaiba pala ang mga file ng data na inakala naming “pareho”
Matapos itakda ang pagkakasunod-sunod ng mga event, ilang trade sa equity lang ang may natitirang mga hindi pagtutugma. Itinama ng vendor ang isang makasaysayang adjustment para sa stock split. Pareho ang pangalan at bilang ng mga row ng file namin gaya ng dati, kaya inakala naming hindi ito nagbago.
Ngayon, gumagawa kami ng fingerprint para sa bawat hindi nababagong snapshot ng data at itinatabi rito ang patakaran sa adjustment. Sinasabi ng hash kung nagbago ang mga byte; hindi nito ipinapaliwanag kung bakit. Kaya kasama rin sa manifest ang pinagmulan, oras ng pagkuha at bersyon ng pagbabago. Para sa data na nirerebisa, bahagi ng resulta ang mga detalyeng iyon.
Dapat masagot ng reproducible na backtest ang tanong na “Aling bersyon ng nakaraan ang nakita nito?”
Araw 4: Nakakita kami ng isang tahimik na default
Ang huling pagkakaiba ay bayarin ng maker na naging zero dahil hindi isinama ng config ng strategy ang field na iyon. Inilapat naman ng mas bagong engine ang default na bayarin ng account. Sapat ang iisang default na iyon para mabago ang mga marginal na trade at maipaliwanag ang malaking bahagi ng agwat sa panghuling balanse.
Tahasan naming itinakda ang mga setting na may epekto sa ekonomiya at ipinaprint sa engine ang nalutas na configuration sa talaan ng run. Maginhawa ang mga default habang nagsasaliksik. Hindi magandang ebidensiya ang mga ito kapag naghahambing ng mga resulta sa paglipas ng panahon.
Mga hindi na namin uulitin sa susunod
Kalahating araw ang ginugol namin sa paghahambing ng mga pinagsama-samang metric bago tingnan ang unang fill na nagkaiba. Huwag doon magsimula. Ayusin ayon sa timestamp ang dalawang event log at ikumpara ang unang paglihis; madalas na kasunod lang nito ang mga pagkakaiba sa bandang huli.
Hindi na rin namin uulitin ang paniniwalang sapat nang gumawa ng container image para maging reproducible ang isang run. Napipirmi nito ang malaking bahagi ng kapaligiran ng software, pero hindi ang panlabas na file ng data, iskedyul ng bayaring kinukuha habang tumatakbo ang program, o binagong history ng vendor.
Kapag nagbago ang backtest, panatilihin ang parehong manifest at log ng run, saka isa-isang ayusin ang mga pinagmulan ng paglihis. Hindi lang basta curve na maaari mong patakbuhin muli ang kapaki-pakinabang na resulta. Isa itong talaang nagpapaliwanag kung aling data at mga palagay ang bumuo rito, at kung bakit maaaring magkaiba ang susunod na run.
← Lahat ng post
