I-restart ang strategy sa kalagitnaan ng backtest. Naaalala ba nito kung ano ang hawak nito?

Walang kinalaman sa paghahanap ng mas mahusay na parameter ang isang kapaki-pakinabang na pagsubok sa backtest: ihinto ang proseso sa kalagitnaan, ibalik ito, at tapusin ang parehong replay. Kapag pareho ang mga input at kontrolado ang execution simulator, dapat magkatugma ang mga desisyon, order, at equity nito sa tuloy-tuloy na run.

Kung hindi, nakakita ka ng problema sa pamamahala ng estado. Umaasa ang strategy sa isang bagay na hindi mo na-save o hindi mo kayang buuing muli. Mahalaga ang pag-asa rito kapag ipinagpapatuloy ang mga research run, pinapalitan ang mga worker, o nagde-deploy ng bagong code ang isang paper-trading service.

Gusto ko ang pagsubok na ito dahil napakalinaw ng inaasahang sagot. Walang pagtatalo kung nagbago ang market. Parehong market ang natatanggap ng dalawang run.

Narito ang 3 maling paraan ng pag-restart. Halimbawa lamang ang mga numero; maaaring mangyari ang bawat pagkabigo sa isang sistemang deterministic naman sa ibang aspeto.

1. Mag-load muli ng ilang bar at ipagpalagay na warm na ang mga indicator

Ipagpalagay na gumagamit ang isang strategy ng exponential moving average na may 100 period. Ganito ang update nito:

alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previous

Ipinagpapatuloy ng prosesong hindi naantala ang naipong EMA. Kumukuha ang na-restart na proseso ng 100 bar, sinisimulan ang EMA sa unang close, at ipinapalagay na kailangan ng 100 obserbasyon ang isang 100-period na indicator.

Napagkakamalan ng palagay na iyon ang smoothing parameter ng indicator bilang takdang haba ng memorya. Patuloy na nag-aambag ang paunti-unting nababawasan na bahagi mula sa panimulang estado ng EMA. Kung nagsimula ang 2 bersyon na may diperensiyang 10 price unit sa EMA, ganito kababa ang diperensiyang iyon kapag magkapareho ang mga sumunod na presyo:

Ganito ang kalkulasyon: 10 * (99 / 101)^k. 99 update lang ang makukuha mo sa pagkuha ng 100 bar kung ang unang obserbasyon ang gagamiting panimulang halaga.

Karaniwang lumilitaw ang problema malapit sa hangganan ng isang desisyon. Nakikita ng isang run na nasa ibabaw ng EMA ang presyo; nakikita naman ng isa na nasa ilalim ito. Nagdudulot ng isang dagdag na trade ang maliit na pagkakaibang numerikal. Kapag nangyari iyon, maaari ring magkaiba ang mga cooldown, magagamit na cash, at mga susunod na desisyon.

I-save ang recursive indicator state nito, kung nasimulan na ito, at ang huling naprosesong event. Maaari ka ring mag-replay mula sa isang kilalang panimulang estado. Maaaring magbigay ng katanggap-tanggap na pagtatantiya ang mas mahabang warm-up, pero piliin ang haba nito batay sa tahasang tolerance sa error at tiyaking hindi nito mababago ang mga desisyon. Kombensiyon lang ang “limang ulit ng period,” hindi ito patunay.

At hindi lang mga indicator ang bumubuo sa buong history. Kailangan ng rolling percentile ang window nito. Maaaring kailanganin ng online model ang estado ng optimizer nito. Kailangang tandaan ng tuntuning naghihintay ng 3 bar pagkatapos ng pagkalugi ang pagkalugi at ang counter.

2. I-save ang mga position at kalimutan ang mga order na hindi pa tapos

10 unit ang target position mo. Napunan na ang 4 sa buy order na 10, kaya 6 pa ang nakabinbin. Ise-checkpoint mo ang position bilang 4, magre-restart, at magsusumite ng panibagong buy para sa kulang na 6.

Kung mapunan ang orihinal na natitira at ang pamalit na order, 16 ang magiging hawak mo.

Madalas nakatago ang bersiyon ng bug na ito sa backtest dahil tahimik na binubura ng pag-restart sa fill engine nito ang mga aktibong order. Sa paper trading, maaaring panatilihin ng simulator o panlabas na service ang mga iyon. Magkakaiba ang exposure na ilalabas ng parehong recovery code, depende sa kung aling component ang nakaligtas.

Ang makikita mong problema ay sunod-sunod na order na walang malinaw na paliwanag kaagad pagkatapos ng pagbawi. Minsan nadodoble ang exposure. Minsan isinasara nito ang position kahit aktibo pa ang proteksiyon nitong order, kaya maaari pang magbukas ng bagong position ang order na iyon sa kalaunan.

Kailangan ng checkpoint na magtala ng pagkakakilanlan at lifecycle state ng mga order, bukod sa mga position. Dapat itugma ng pagbawi ang mga rekord na iyon sa execution system bago gumawa ng mga bagong aksiyon. Kailangang imbestigahan ang order na hindi alam ang kinalabasan; kapag itinuring na “hindi naisumite” ang “walang naka-save na kumpirmasyon,” doon nagmumula ang mga dobleng order.

Nakakatulong ang matatag na client order identifier para alamin mo kung ano ang nangyari. Napipigilan lang ng mga ito ang mga duplicate kapag talagang ipinapatupad ng tumatanggap na sistema ang kinakailangang uniqueness o idempotency rules. I-persist din ang mga naprosesong execution identifier para hindi madoble ang pagdagdag sa position kapag ni-replay ang isang fill.

May espesyal akong pagkagusto sa nakakabagot na screen ng status ng order. Sa araw ng pag-restart, biglang nagiging pinakakawili-wiling interface sa gusali ang maliliit nitong hanay.

3. Ibalik ang position at magsimula ng bagong P&L ledger

Isaalang-alang ang isang spot na halimbawang walang leverage at walang bayad. Magsimula sa $10,000 na cash, bumili ng 10 unit sa halagang $100 bawat isa, at mag-checkpoint kapag umabot sa $110 ang mark.

Ang tamang estado ay $9,000 na cash at position na nagkakahalaga ng $1,100: equity na $10,100. Kung ibinalik ng recovery ang 10 unit pero ni-reset ang cash sa orihinal na $10,000, $11,100 ang iuulat nito. Nakalikha ka ng $1,000 sa simpleng pag-restart ng proseso.

Hindi gaanong kapansin-pansin ang ibang bersiyon. Napapanatili ng recovery ang equity pero nire-reset ang entry price sa $110. Maaaring manatiling tama ang kabuuang equity habang nagbabago ang paghahati sa realized at unrealized. Kung nakabatay sa entry price ang stop o kundisyon sa pag-exit, nababago na ngayon ng shortcut sa accounting ang asal ng trading.

O kaya nakakalimutan ng sistema ang dating pinakamataas na equity. Ipagpalagay na umabot sa $10,600 ang pinakamataas na equity bago bumaba sa $10,100. Humigit-kumulang 4.72% ang drawdown nito. I-reset ang pinakamataas na marka sa pagbawi at biglang iisipin ng strategy na 0 ang drawdown nito. Kakakuha lang ng hindi awtorisadong reset ng anumang risk control na batay sa drawdown.

Kaya maaaring lumitaw ang problema bilang biglang pagtalon o pagbaba ng equity, kahina-hinalang pagbuti ng drawdown, o risk rule na hindi na gumagana pagkatapos ng deployment. Panatilihin ang ledger at ang estadong nakadepende sa accounting ng strategy: mga galaw ng cash, mga position, naaangkop na cost basis, mga naipong singil, at memorya ng risk control. Itugma ang naibalik na equity sa ledger gamit ang parehong oras ng valuation.

Sa research harness, patatakbuhin ko ang isang replay bilang sanggunian nang tuluy-tuloy, tapos magre-restart ako ng pangalawang run sa mga sadyang alanganing punto: habang sinisimulan ang indicator, pagkatapos ng bahagyang fill, at habang aktibo ang isang limitasyon sa risk. Gamitin ang parehong pagkakasunod-sunod ng event at panatilihin ang anumang random state ng simulator. Ihambing ang unang desisyon pagkatapos ng pagbawi, ang mga rekord ng order at fill, at ang takbo ng equity. Maaaring itago ng magkatugmang huling balanse ang magkakasalungat na error.

Para sa crash na nangyari pagkatapos magsumite pero bago makatanggap ng kumpirmasyon, kailangan ding panatilihin ng harness ang estado ng execution service nang hiwalay sa proseso ng strategy. Kung hindi, binubura nito ang kawalang-katiyakang sinusubukan mong suriin.

Bahagi ng espesipikasyon ng strategy ang mga naaalala nito. Gawing sapat na tahasan ang memoryang iyon para mapatay mo ang proseso sa kalagitnaan ng replay at maipakita kung paano ito makakabalik sa trabaho.