Hindi sapat ang naka-freeze na snapshot ng market data para pagkatiwalaan ang isang backtest. Maaari nitong ulitin ang parehong resulta habang itinatago na binago ng vendor ang mga input na pinagmulan ng resultang iyon.
Itago ang snapshot. Pagkatapos, magtago ng tala ng mga pagbabago na makapagsasabi kung ano ang nagbago, kailan ito nagbago, at kung mahalaga ba iyon sa estratehiya. Pinakamahalaga ito kapag gumagamit ang pananaliksik natin ng mga itinamang trade, nirebisang fundamental, muling binuong funding, o kasaysayang tahimik na nire-refresh ng vendor.
Bakit maaari pa ring makapanlinlang ang isang nauulit na backtest?
Ipagpalagay na nag-download ka ng limang taong hourly bar noong Lunes at nagpatakbo ng estratehiya. Pagsapit ng Biyernes, inayos na ng vendor ang isang maling trade, inayos ang isang corporate action, o pinunan ang isang puwang sa data. Eksakto pa ring ibinibigay ng na-save mong file ang resulta noong Lunes. Nauulit iyon. Pero kung patatakbuhin mo ulit gamit ang kasalukuyang kasaysayan ng vendor, maaaring iba na ang resulta at wala kang rekord kung bakit.
Hindi lang malalaking pagwawasto ang problema. Maaaring mag-trigger ng stop ang isang binagong high; maaaring itawid ng nirebisang close ang isang indicator sa threshold nito. Sa malawak na universe, maaaring magbago ang ranggo ng isang symbol dahil sa pagbabago sa kasaysayan nito at mapaalis ang ibang asset sa portfolio. Maaaring magbago ang Sharpe sa huli kahit magkapareho ang code at configuration ng estratehiya.
Sinasabi ng hash ng file na magkaiba ang dalawang file. Hindi nito sinasabi kung binago ng adjustment sa stock split ang 40 taong halaga ng presyo, kung nagtama ang vendor ng tatlong trade, o kung ginawang zero ng parser ang isang walang lamang field.
Ano ang dapat isama sa tala ng mga pagbabago sa market data?
Itala ang mga pagbabago sa pinakamaliit na kapaki-pakinabang na yunit, kasama ang sapat na konteksto para maulit ang apektadong pananaliksik. Para sa bar feed, karaniwang kailangan ang instrumento, pagitan ng oras, oras ng pangyayari, luma at bagong halaga, pinagmulan, at oras kung kailan mo napansin ang update. Itago ang orihinal na payload kung nagbibigay nito ang vendor.
| Itala | Bakit ito itatago | Halimbawa |
|---|---|---|
| Bersyon ng pinagmulan o oras ng pagkuha | Tinutukoy nito ang ginamit na estado ng vendor | Kinuha ang snapshot noong 2026-11-02 08:15 UTC |
| Binagong field at luma/bagong halaga | Ipinapakita nito kung ano talaga ang nagbago | ETHUSDT 1h high: 3,412.10 → 3,418.60 |
| Pag-uuri ng pagbabago | Pinaghihiwalay nito ang mga pagkukumpuni at pagbabago sa proseso | Huling pagwawasto sa trade, adjustment sa stock split, backfill |
| Bersyon ng pipeline at schema | Ibinubukod nito ang mga pagbabago ng pinagmulan sa sarili mong pagproseso | Normalizer v7, adjusted-bar schema v3 |
Para sa malalaking dataset, mag-imbak ng mga hindi nababagong snapshot at isang maikling manifest ng mga checksum, bersyon ng pinagmulan, at oras ng pagkuha ng mga ito. Magdagdag ng mga diff sa antas ng row para sa mga partisyong nagbago. Praktikal na gitnang solusyon ito: posible pa rin ang buong replay nang hindi isinusulat ang bawat row na hindi nagbago sa pangalawang audit table.
Paano ko susukatin kung mahalaga ang isang pagwawasto?
Huwag tumigil sa pagbibilang ng mga row na nagbago. Patakbuhin ulit ang apektadong estratehiya gamit ang luma at bagong data sa ilalim ng parehong code, parameter, bayarin, at palagay sa execution. Ihambing ang mga desisyon at ang landas patungo sa resulta.
- Tukuyin mula sa diff ang mga apektadong instrumento at oras ng pangyayari.
- Alamin kung aling feature, signal, order, o timbang ng portfolio ang gumagamit sa mga rekord na iyon.
- Ulitin ang pinakamaliit na wastong window, kasama ang lookback at estado ng mga bukas na posisyon.
- Ihambing ang mga order, fill, exposure, turnover, drawdown, at panghuling performance.
Halimbawa, maaaring umabot sa isang milyong row ang pagwawasto ng vendor na nagbabago ng high sa 1-minute bar nang $0.02, pero wala itong epekto sa pang-araw-araw na estratehiya ng momentum. Maaaring mas mahalaga ang isang itinamang bar na tumapat sa antas ng stop. Sukatin ang epekto sa mga desisyon; hindi maaasahang panukat nito ang bilang ng mga rekord na nagbago.
Paghiwalayin ang dalawang tanong: “Mauulit ko ba ang resulta gamit ang data na na-save ko?” at “Available kaya sa estratehiya noon ang bersyong ito ng data?” Nakakatulong ang tala ng mga pagbabago para sagutin ang dalawa, pero kailangan din ng mga rekord ng availability sa takdang panahon para masagot ang pangalawa.
Magkano ang gastos nito, at kailan ito sulit?
Nangangailangan ng dagdag na storage, trabaho sa pag-ingest, at mga pasyang operasyonal ang pagsubaybay sa mga pagbabago. Maaaring walang matatag na bersyon na ibinibigay ang mga vendor, at may ilang makasaysayang feed na pana-panahong binubuo muli nang walang malinaw na abiso ng pagwawasto. Hindi mo maitatala ang pagbabagong hindi mo napansin.
Magsimula sa mga rebisyong maaaring magbago sa mga konklusyon ng pananaliksik: mga bar na ginagamit ng stop logic, mga equity na inayos para sa corporate action, point-in-time fundamental, at mga serye ng funding o open interest na muling binubuo. Maaaring sapat na ang pang-araw-araw na manifest at mga checksum ng partisyon para sa malalawak at matatag na dataset. Magdagdag ng mga diff sa antas ng field kung madalas ang mga update o sensitibo ang mga desisyon sa trade sa bawat rekord.
Tama ang mga kritiko na maaaring magastos ang kumpleto at walang-hanggang arkibo ng bawat tugon ng vendor, at mabigo pa ring makuha kung ano ang alam ng pinagmulan noong panahong iyon. Ang solusyon ay limitahan ang audit sa data at mga desisyong mahalaga, at idokumento ang mga puwang. Pinapahintulutan ka ng snapshot na ulitin ang isang eksperimento. Pinapahintulutan ka ng tala ng mga pagbabago na ipaliwanag kung bakit nagbago ang sagot ng eksperimento.
← Lahat ng post
