Maaaring hindi gaanong mapagkakatiwalaan ang backtest na eksaktong nauulit kaysa sa bahagyang nagbabago. Pinatutunayan ng pag-uulit na makukuha mo ang parehong sagot nang dalawang beses; wala itong sinasabi kung nakadepende ang sagot sa isang di-makatwirang snapshot ng data, kakaibang asal ng library, o nakatagong default.
Parang pagtutol ito sa reproducibility, pero hindi. I-freeze ang run para maipaliwanag mo ito. Pagkatapos, sadyang baguhin ang mga palagay na hindi dapat magtakda sa resulta. Ginagawang naa-audit ng unang hakbang ang resulta; ipinapakita naman ng ikalawa kung may saysay ito.
Ano ba talaga ang pinatutunayan ng isang reproducible na backtest?
Kung magkapareho ang mga trade at metric kapag ginamit ang parehong code, data, configuration, at random seed, nakontrol mo ang isang mahalagang pinagmumulan ng kalituhan. Maihahambing ang “pagbuti” ng isang agent sa parent run nito. Maibubukod ang pag-aayos ng bug sa pagbabago ng iskedyul ng bayarin. Masusuri ng kasamahan ang parehong ledger at makikita ang parehong fill.
Pero nakabatay ang resulta sa lahat ng ni-freeze mo. Isipin ang isang estratehiya sa crypto na may mga one-minute bar sa makasaysayang file nito. Sine-save mo ang hash ng file, pini-pin ang code, at nakakakuha ka ng Sharpe na 1.4 sa bawat rerun. Kung magwawasto kalaunan ang vendor ng ilang candle, inilalarawan pa rin ng malinis na reproducibility na iyon ang lumang file. Hindi nito sinasabi kung gagana pa rin ang signal sa naiwastong kasaysayan, o kung ganoon nga ang anyo ng mga candle noong panahong iyon.
Kapaki-pakinabang ang hash: inilalantad nito ang dependency. Pero hindi ito patunay na walang masamang epekto ang dependency na iyon.
Panatilihing hindi nagbabago ang run; hamunin ang natuklasan
Mas gusto kong paghiwalayin ang dalawang tanong. Kaya ba nating buuing muli ang eksaktong run na ito? At nananatili ba ang konklusyon ng pananaliksik kapag gumawa tayo ng makatwirang pagbabago? Nangangailangan ang una ng hindi nababagong tala; nangangailangan naman ang ikalawa ng kontroladong pagbabago ng palagay, paisa-isa.
| Ano ang itatala | Ano ang babaguhin pagkatapos | Ano ang maaaring ibunyag nito |
|---|---|---|
| Bersyon ng raw data at mga checksum | Pagbabago ng vendor o pangalawang source | Pagdepende sa mga naiwastong value o value na partikular sa vendor |
| Code commit at mga bersyon ng package | Implementasyong katumbas sa numerikal na resulta | Pagkasensitibo sa pagkakasunod-sunod, pag-round, o library |
| Mga palagay sa bayarin, funding, at fill | Makatwirang saklaw ng gastos | Kung nangangailangan ang maliit na lamang ng di-pangkaraniwang paborableng execution |
| Universe at pagiging kabilang sa takdang panahon | Ibang panuntunan sa pagiging kwalipikado ng market | Pagdepende sa mga desisyong magsama o mag-alis |
Halimbawa, ipagpalagay na nagpapakita ang isang futures strategy ng 8% taunang sobrang kita sa baseline replay. Patakbuhin itong muli nang 25% mas mataas ang taker cost, inilipat ang funding sa susunod na settlement na naobserbahan, at inalis nang paisa-isa ang dalawang pinakamalaking nag-ambag. Hindi ito tatlong paraan para pagandahin ang modelo. Mga pagsubok ito: bawat isa ay nagtatanong kung may makatotohanang detalyeng siyang nagpapalaki sa pangunahing resulta.
Panatilihing magkakahiwalay ang bawat pagsubok. Kung sabay mong babaguhin ang data, iskedyul ng bayarin, at oras ng execution, kakaunti ang malalaman mo sa dahilan ng paglala ng resulta. At kung hindi makatotohanan ang isang pagsubok, lagyan ito ng label na stress case sa halip na ipakitang malamang na mangyari.
Huwag ipagkamali ang pagkakapareho ng bawat byte sa katumpakang numerikal
May mga kalkulasyong sensitibo sa pagkakasunod-sunod. Hindi associative ang pagdaragdag ng floating-point number, kaya maaaring magbago ang huling ilang digit kapag pinagsama sa ibang pagkakasunod-sunod ang maraming maliit na halaga ng P&L. Maaari ring makaapekto sa eksaktong output ang mga parallel reduction, hardware, at bersyon ng library. Karaniwan, wala itong epekto; pero kung minsan, binabago ng napakaliit na numerikal na pagbabago ang resulta ng isang threshold, binabago ang posisyon, at itinutulak ang natitira sa simulation sa ibang direksiyon.
Kaya pananatilihin ko kapwa ang eksaktong artifact at ang mga tolerance para sa paghahambing. Itala ang ledger ng mga trade, hindi lang ang huling Sharpe. Ihambing muna ang mga desisyon at cash flow, saka ang mga metric batay sa tinukoy na tolerance. Kung binabago ng isang sentimo kung isusumite ang order, suriin nang tahasan ang hangganang iyon.
Kabilang sa kapaki-pakinabang na tala ng run ang pagkakakilanlan ng data at code, configuration, random seed, execution environment, at sapat na intermediate output para masubaybayan ang metric pabalik sa mga fill at cash flow. Hindi reproducible na artifact ng pananaliksik ang huling score lamang.
Kailan ingay lang ang pagbabago, at kailan ito natuklasan
Hindi krisis ang bawat nagbagong numero. Maaaring hindi magbago ang mga trade kahit bahagyang naiba ang metric dahil sa ibang pagkakasunod-sunod ng reduction. Maaaring kailanganing suriin ang nagbagong trade na malapit sa threshold. May natututuhan ka tungkol sa kahinaan ng isang estratehiya kung nawawala ang halos buong resulta nito kapag binago ng isang vendor ang maliit na bahagi ng kasaysayan, kahit nananatiling eksaktong reproducible ang orihinal na run.
Tama ang mga tumututol sa robustness check sa isang bagay: madaling patuloy na baguhin ang mga palagay hanggang magmukhang matatag ang estratehiyang gusto mo, o tanggihan ang maayos na resulta dahil pumapalya ito sa sinadyang matinding sitwasyon. Itakda nang maaga ang mga makatwirang pagbabago, iulat ang buong hanay, at ibukod ang mga karaniwang alternatibo sa mga stress case. Pagkatapos, panatilihin ang baseline para eksaktong maulit ng ibang mananaliksik ang nakita mo.
Nagbibigay ang reproducibility ng maaasahang panimulang punto. Ang kasunod na kapaki-pakinabang na tanong: aling mga bahagi ng sagot ang nananatili kapag nagbago ang mga kondisyong nakapaligid sa run sa mga paraang makatwiran mong maaasahan?
← Lahat ng post
