Anim na linggo matapos kaming magpatakbo ng backtest, muli namin itong pinatakbo gamit ang parehong code, configuration, at saklaw ng petsa. Iba ang ending equity. Hindi naman malaki ang diperensya, pero sapat ito para bumaba ang Sharpe ratio mula 1.31 tungo sa 1.08 at magbago kung aling set ng parameter ang mukhang pinakamahusay.
Hindi nagbago ang strategy. Ang makasaysayang datos ang nagbago. Binago ng vendor ang ilang araw ng trades at bars, at hindi namin naitago sa unang run ang eksaktong input snapshot. Ginugol namin ang mga sumunod na araw para alamin kung ang bagong resulta ay pagwawasto ng datos, bug sa pipeline, o proseso ng research na hindi namin kayang ulitin nang pareho.
Lunes: hindi nagtugma ang muling pagtakbo
Ang unang palatandaan ay maliit na agwat sa isang likidong spot pair. Nasa 62,418 ang high sa orihinal naming bar. Sa muling pagtakbo, 62,431 naman. Mukhang walang gaanong epekto ang diperensyang iyon hanggang matunton namin ang entry ng strategy: nasa pagitan ng dalawang presyong iyon ang threshold nito. Dahil sa ilang nagbagong bar, nag-iba ang mga signal, kaya nag-iba rin ang mga position makalipas ang ilang araw.
Inihambing namin ang bilang ng trades bawat araw at nakita naming nagsimula ang hindi pagtutugma sa iisang petsa. Pagkatapos, inihambing namin ang mga raw row na ginamit para sa petsang iyon. May ilang itinamang trade at binagong aggregate bar sa kasalukuyang tugon ng vendor. Walang kalakip na change log sa tugong ginamit namin noon.
Karaniwan ang ganitong asal ng datos. Nagtatama ng mga rekord ang mga exchange; pinupunan ng mga vendor ang mga puwang, itinatama ang mga maling print, at binabago ang lohika ng aggregation. Maaaring magbalik ng ibang sagot sa Marso ang query para sa “datos ng Enero.”
Martes: nakita namin ang nawawalang resibo
Itinatala namin sa run record ang pangalan ng vendor, symbol, at saklaw ng petsa. Hindi namin itinago ang mismong tugon o content hash para sa bawat input partition. Ibig sabihin, mapatutunayan namin kung ano ang hiniling namin, pero hindi kung anong mga byte ang ibinalik ng vendor.
Kinuha namin ang pinakalumang naka-cache na mga file na makita namin at inihambing ang mga ito sa kasalukuyang tugon. Hindi ito dahil sa split adjustment o timezone conversion. Maliit na pangkat ito ng itinamang trade record na dumaan sa bar builder namin. Napawalang-bisa nito ang isang paliwanag, pero hindi kumpleto ang cache kaya hindi pa rin namin eksaktong mabuo muli ang bawat naapektuhang bar.
| Mga itinago namin | Mga nasagot nito | Mga kulang |
|---|---|---|
| Vendor, symbol, saklaw ng petsa | Aling request ang ginawa ng run | Ang laman ng tugon |
| Bersyon ng pipeline | Aling code ang bumuo ng mga bar | Ang eksaktong mga input row |
| Timestamp ng run | Kailan namin pinatakbo ang trabaho | Aling rebisyon ng vendor ang available noon |
Ipinagpalagay naming ang “parehong query” ay katumbas ng “parehong datos.” Dahil sa palagay na iyon, nagmukhang mas madaling ulitin ang eksperimento kaysa sa totoo.
Miyerkules: binago ng pagwawasto ang kuwento
Muli naming pinatakbo ang mga apektadong petsa gamit ang parehong bersyon ng available na datos. Inalis ng binagong mga bar ang dalawang entry at inusog nang isang bar ang isang exit. Ang tatlong trade na iyon ang dahilan ng malaking bahagi ng pagbabago sa Sharpe. Sensitibo ang strategy sa ilang obserbasyong malapit sa trigger nito, kahit halos magkapareho ang kabuuang serye ng presyo kapag tiningnan sa chart.
Hindi ibig sabihin nito na mapanlinlang ang orihinal na resulta o awtomatikong mas mahusay ang binagong resulta. Ibig sabihin, kailangang tukuyin ang saklaw ng pahayag: inilalarawan ng lumang run ang snapshot ng datos na mayroon kami noon, samantalang inilalarawan ng muling pagtakbo ang kasalukuyang kasaysayan ng vendor. Hindi namin matapat na matatawag na pag-uulit ng isa ang isa pa.
Huwebes: binago namin ang research record
Nagdagdag kami ng mga hindi nababagong input snapshot sa mga bagong research run. Bawat partition ay may content hash, at itinatala sa run manifest ang source, oras ng pagkuha, bersyon ng schema, patakaran sa adjustment, at bersyon ng transformation code. Para sa malalaking dataset, iniimbak namin ang mismong mga file sa content-addressed storage para mapagsaluhan ang magkakaparehong partition nang hindi napapatungan ang mga naunang bersyon.
Kapag hindi kami pinapayagan ng mga tuntunin sa storage o lisensya na panatilihin ang raw data, itinatago namin ang pinakamainam na patunay na pinahihintulutan ng mga tuntunin: mga hash, parameter ng request, identifier ng rebisyon ng source, at maliit na sample ng mga na-parse na row para sa pagsusuri. Hindi kayang ibalik ng hash ang datos, pero masasabi nito kung magkaibang byte ang ginamit ng dalawang run.
Kailangan ng backtest na maaaring ulitin nang pareho ng pagkakakilanlan ng input, hindi lang ng data URL. Itala kung ano ang dumating, kailan ito dumating, at kung paano ito naging mga row na ginamit ng strategy mo.
Biyernes: mga hindi na namin uulitin sa susunod
Hindi na namin ihahambing ang mga pangunahing metric lang. Ipinapakita ng nagbagong Sharpe na may nagbago, pero hindi nito tinutukoy ang sanhi. Magsimula sa bilang ng mga row at hash ng mga partition, saka hanapin ang unang petsa ng input na nagkakaiba. Mula roon, ihambing ang mga transformed row, signal, order, at fill ayon sa pagkakasunod na iyon.
Hindi na rin namin tahimik na papalitan ang lumang datos ng itinamang kasaysayan. Kapaki-pakinabang ang mga pagwawasto, pero dapat manatiling nakatali ang mga lumang run sa orihinal nilang input. Dapat gumawa ng bagong run ang bagong dataset, na may malinaw na ugnayan sa nauna.
Simple na ang praktikal naming tuntunin: kung layunin ng muling pagtakbo na ulitin ang isang eksperimento, i-pin ang data snapshot. Kung layunin nitong makinabang sa itinamang kasaysayan, itala ito bilang bagong eksperimento. Ilang araw ang itinagal bago namin natutuhan ang pagkakaibang ito, at isang linya lang ito sa run manifest.
← Lahat ng post
