Indítsd újra a stratégiádat a backteszt közepén. Emlékszik rá, mije van?

Egy hasznos backtesztelési próba nem egy jobb paraméter megtalálásáról szól: állítsd le a folyamatot félúton, állítsd helyre, majd fejezd be ugyanazt a visszajátszást. Azonos bemenetek és szabályozott végrehajtási szimulátor mellett a döntéseinek, megbízásainak és saját tőkéjének egyeznie kell egy megszakítás nélküli futás eredményével.

Ha nem egyeznek, állapotkezelési problémát találtál. A stratégia olyasmire támaszkodik, amit nem mentettél el, vagy nem tudtál újra előállítani. Ez a függőség akkor számít, amikor folytatjuk a kutatási futásokat, lecseréljük a feldolgozókat, vagy új kódot telepítünk egy papíralapú kereskedési szolgáltatásba.

Azért szeretem ezt a tesztet, mert szokatlanul egyértelmű az elvárt eredmény. Nem lehet azon vitatkozni, hogy megváltozott-e a piac. Mindkét futás ugyanazt a piacot kapja.

Íme három hibás újraindítási módszer. A számok szemléltető jellegűek; mindegyik hiba előfordulhat egy egyébként determinisztikus rendszerben.

1. Tölts be néhány gyertyát, és tekintsd bemelegítettnek az indikátorokat

Tegyük fel, hogy egy stratégia 100 periódusú exponenciális mozgóátlagot használ. A frissítése:

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

A megszakítás nélkül futó folyamat továbbviszi a felhalmozott EMA-értéket. Az újraindított folyamat lekér 100 gyertyát, az első záróárral inicializálja az EMA-t, és abból indul ki, hogy egy 100 periódusú indikátorhoz 100 megfigyelés kell.

Ez a feltételezés összekeveri az indikátor simítási paraméterét a véges memóriájú ablakkal. Az EMA egyre csökkenő súllyal megőrzi a kezdeti állapot hatását. Ha két változat EMA-értéke kezdetben 10 áregységgel tér el, akkor azonos későbbi árak mellett ez az eltérés így csökken:

A számítás képlete: 10 * (99 / 101)^k. 100 gyertya lekérésével csak 99 frissítésed lesz, ha az első megfigyelés adja a kezdőértéket.

A baj rendszerint egy döntési határ közelében jelentkezik. Az egyik futás szerint az ár az EMA fölött van, a másik szerint alatta. Egy kis numerikus eltérés egy teljes extra ügyletet eredményez. Utána a lehűlési idők, a rendelkezésre álló készpénz és a későbbi döntések is eltérhetnek.

Mentsd el a rekurzív indikátor állapotát, annak inicializálási státuszát és az utolsó feldolgozott eseményt. Másik lehetőségként játszd vissza az adatokat egy ismert kezdőállapotból. Hosszabb bemelegítéssel elfogadható közelítést kaphatsz, de az időtartamát kifejezett hibahatár alapján válaszd meg, és ellenőrizd, hogy ez a határ befolyásolhatja-e a döntéseket. Az „ötszörös periódus” bevett ökölszabály, nem bizonyíték.

És az indikátorok nem jelentik a teljes előzményt. Egy gördülő percentilishez szükség van az ablakára. Egy online modellnek szüksége lehet az optimalizáló állapotára. Annak a szabálynak pedig, amely veszteség után három gyertyát vár, emlékeznie kell a veszteségre és a számlálóra.

2. Mentsd el a pozíciókat, és felejtsd el a folyamatban lévő megbízásokat

A célpozíciód 10 egység. Egy 10 egységre szóló vételi megbízásból 4 teljesült, így 6 egység még függőben van. A checkpointban 4-re mented a pozíciót, újraindítasz, majd beküldesz egy újabb vételt a hiányzó 6 egységre.

Ha az eredeti maradék és a pótlólagos megbízás is teljesül, 16 egység lesz a birtokodban.

Backtesztben ez a hiba gyakran rejtve marad, mert a töltési motor újraindítása észrevétlenül törli az aktív megbízásokat. Papíralapú kereskedésnél a szimulátor vagy a külső szolgáltatás megtarthatja őket. Ugyanaz a helyreállító kód így attól függően eredményez eltérő kitettséget, hogy melyik komponens maradt működésben.

A bajt a helyreállítás után közvetlenül megjelenő, megmagyarázhatatlan megbízáshullám jelzi. Néha megduplázza a kitettséget. Máskor lezár egy olyan pozíciót, amelyhez még aktív védőmegbízás tartozik; ez a megbízás később új pozíciót nyithat.

A checkpointnak a pozíciók mellett a megbízások azonosítóját és életciklus-állapotát is tartalmaznia kell. Új műveletek létrehozása előtt a helyreállításnak egyeztetnie kell ezeket az adatokat a végrehajtási rendszerrel. Az ismeretlen kimenetelű megbízást ki kell vizsgálni; ha a „nincs elmentett visszaigazolás” azt jelenti, hogy „sosem küldtük be”, abból születnek a duplikált megbízások.

A stabil, kliensoldali megbízásazonosítók segítenek utánanézni, mi történt. Csak akkor akadályozzák meg a duplikációt, ha a fogadó rendszer valóban betartatja a szükséges egyediségi vagy idempotencia-szabályokat. A feldolgozott végrehajtási azonosítókat is mentsd el, hogy a visszajátszott teljesülés ne növelje meg kétszer a pozíciót.

Különösen kedvelem az unalmas megbízásállapot-képernyőt. Az újraindítás napján a kis sorai hirtelen az épület legérdekesebb felületévé válnak.

3. Állítsd helyre a pozíciót, és indíts új P&L-főkönyvet

Nézzünk egy tőkeáttétel nélküli azonnali piaci példát díjak nélkül. Induláskor 10 000 $ készpénzed van, veszel 10 egységet 100 $-ért, majd akkor készítesz checkpointot, amikor az értékelőár eléri a 110 $-t.

A helyes állapot 9 000 $ készpénzből és egy 1 100 $ értékű pozícióból áll: a saját tőke 10 100 $. Ha a helyreállítás visszaállítja a 10 egységet, de a készpénzt visszateszi az eredeti 10 000 $-ra, 11 100 $-t mutat. Egy folyamat újraindításával 1 000 $-t teremtettél.

Más változatok kevésbé látványosak. A helyreállítás változatlanul hagyja a saját tőkét, de a bekerülési árat 110 $-ra állítja. A teljes saját tőke helyes maradhat, miközben megváltozik a realizált és nem realizált eredmény felosztása. Ha egy stop vagy kilépési feltétel a bekerülési áratól függ, a könyvelési rövidítés már a kereskedési viselkedést is módosítja.

Az is előfordulhat, hogy a rendszer elfelejti a korábbi saját tőke csúcsértékét. Tegyük fel, hogy a saját tőke 10 600 $-on tetőzött, mielőtt 10 100 $-ra csökkent. A visszaesés körülbelül 4.72%. Ha a helyreállításkor nullázod a csúcsértéket, a stratégia hirtelen úgy véli, hogy a visszaesés nulla. Az eséshez kötött kockázatkezelő szabály így illetéktelenül alaphelyzetbe áll.

A baj tehát lehet ugrás a saját tőkében, gyanúsan javuló visszaesési mutató vagy olyan kockázati szabály, amely telepítés után nem aktiválódik többé. Őrizd meg a főkönyvet és a stratégia minden, könyveléstől függő állapotát: a készpénzmozgásokat, pozíciókat, az alkalmazandó bekerülési értéket, a felhalmozott díjakat és a kockázatkezelés memóriáját. A helyreállított saját tőkét egyeztesd a főkönyvvel, ugyanarra az értékelési időpontra vonatkozóan.

A kutatási tesztkeretben megtartanék egy próbát, amely először megszakítás nélkül lefuttat egy referencia-visszajátszást, majd egy második futást szándékosan kellemetlen pontokon indít újra: az indikátor inicializálása közben, részleges teljesülés után, valamint aktív kockázati limit mellett. Használd ugyanazt az eseménysorrendet, és őrizd meg a szimulátor esetleges véletlenállapotát. Hasonlítsd össze az első helyreállítás utáni döntést, a megbízás- és teljesülési rekordokat, valamint a saját tőke alakulását. Az egyező végső egyenleg önmagában elfedheti az egymást kiegyenlítő hibákat.

A beküldés és a visszaigazolás közötti összeomlás teszteléséhez a tesztkeretnek a végrehajtási szolgáltatás állapotát is meg kell őriznie, a stratégiafolyamattól függetlenül. Különben éppen azt a bizonytalanságot törli el, amelyet vizsgálni próbálsz.

A stratégia specifikációjához az is hozzátartozik, mire emlékszik. Tedd ezt a memóriát annyira egyértelművé, hogy félúton leállíthasd a folyamatot egy visszajátszás során, és pontosan megmutathasd, hogyan folytatja a munkát.