Restartujte strategii uprostřed backtestu. Pamatuje si, co vlastní?

Užitečný test backtestu nesouvisí s hledáním lepšího parametru: zastavte proces v polovině, obnovte ho a dokončete stejné přehrávání. Při totožných vstupech a řízeném simulátoru provádění by se rozhodnutí, příkazy i hodnota účtu měly shodovat s nepřerušeným během.

Pokud se neshodují, odhalili jste problém se správou stavu. Strategie závisí na něčem, co jste neuložili nebo nedokázali zrekonstruovat. Na této závislosti záleží, když se obnovují výzkumné běhy, nahrazují pracovní procesy nebo se do paper tradingu nasazuje nový kód.

Tenhle test se mi líbí, protože očekávaný výsledek je neobvykle jasný. Nemusíme se dohadovat, jestli se trh změnil. Oba běhy dostávají stejný trh.

Tady jsou tři chybné způsoby restartu. Čísla jsou ilustrativní; každé z těchto selhání může nastat i v jinak deterministickém systému.

1. Načtěte několik svíček a považujte indikátory za připravené

Předpokládejme, že strategie používá exponenciální klouzavý průměr se 100 periodami. Aktualizuje se takto:

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

Nepřerušený proces průběžně uchovává dosavadní hodnotu EMA. Restartovaný proces načte 100 svíček, inicializuje EMA první zavírací cenou a předpokládá, že indikátor se 100 periodami potřebuje 100 pozorování.

Tento předpoklad zaměňuje parametr vyhlazování indikátoru za konečné okno paměti. EMA si uchovává postupně slábnoucí vliv počátečního stavu. Pokud se počáteční hodnoty EMA ve dvou verzích liší o 10 cenových jednotek, další shodné ceny toto rozdílové zkreslení zmenšují následovně:

Výpočet je 10 * (99 / 101)^k. Načtením 100 svíček získáte jen 99 aktualizací, pokud první pozorování slouží k inicializaci.

Problém se obvykle projeví poblíž rozhodovací hranice. Jeden běh vidí cenu nad EMA, druhý pod ní. Malý číselný rozdíl vyvolá celý obchod navíc. Tím se mohou rozcházet i doby blokace, dostupná hotovost a další rozhodnutí.

Ukládejte rekurzivní stav indikátoru, informaci o jeho inicializaci a poslední zpracovanou událost. Případně přehrávejte data od známého počátečního stavu. Delší zahřívací období může poskytnout přijatelný odhad, ale jeho délku stanovte podle výslovné tolerance chyby a ověřte, zda tato tolerance může změnit rozhodnutí. „Pětinásobek periody“ je konvence, nikoli důkaz.

A indikátory nepředstavují celou historii. Klouzavý percentil potřebuje své okno. Online model může potřebovat stav optimalizátoru. Pravidlo, které po ztrátě čeká 3 svíčky, si musí pamatovat ztrátu i čítač.

2. Uložte pozice, ale zapomeňte na rozpracované příkazy

Cílová pozice je 10 jednotek. Nákupní příkaz na 10 se vyplnil zčásti, v objemu 4, a zbývá vyřídit 6. Uložíte kontrolní bod s pozicí 4, restartujete proces a zadáte další nákup chybějících 6 jednotek.

Pokud se vyplní původní zbytek i náhradní příkaz, budete vlastnit 16 jednotek.

V backtestu tato chyba často zůstane skrytá, protože restartovací modul pro párování obchodů potichu smaže aktivní příkazy. Při paper tradingu je může simulátor nebo externí služba zachovat. Stejný kód pro obnovu pak vytvoří jinou expozici podle toho, která komponenta přežila.

Problémem je nevysvětlená záplava příkazů hned po obnově. Někdy zdvojnásobí expozici. Jindy uzavře pozici, přestože její ochranný příkaz stále čeká na vyřízení a může později otevřít novou pozici.

Kontrolní bod musí vedle pozic obsahovat také identitu příkazů a jejich stav v životním cyklu. Před vytvořením nových akcí musí obnova tyto záznamy sladit se systémem provádění. U příkazu s neznámým výsledkem je potřeba zjistit, co se stalo; předpoklad „nemáme uložené potvrzení“ = „příkaz nebyl nikdy zadán“ vede ke vzniku duplicitních příkazů.

Stabilní klientské identifikátory příkazů vám pomohou dohledat, co se stalo. Duplicitám zabrání pouze tehdy, když přijímající systém skutečně vynucuje požadovanou jedinečnost nebo idempotenci. Ukládejte také identifikátory již zpracovaných provedení, aby opakované přehrání vyplnění nezvýšilo pozici dvakrát.

Mám slabost pro tu nudnou obrazovku se stavy příkazů. V den restartu se její nenápadné řádky najednou stanou nejzajímavějším rozhraním v celé budově.

3. Obnovte pozici a začněte znovu s účetní knihou P&L

Uvažujte spotový příklad bez finanční páky a bez poplatků. Začněte s hotovostí $10,000, kupte 10 jednotek za $100 a uložte kontrolní bod ve chvíli, kdy oceňovací cena dosáhne $110.

Správný stav tvoří $9,000 v hotovosti a pozice v hodnotě $1,100: celková hodnota účtu je $10,100. Pokud obnova načte 10 jednotek, ale hotovost vrátí na původních $10,000, vykáže $11,100. Restartem procesu jste si vytvořili $1,000.

Jiné varianty jsou méně nápadné. Obnova zachová celkovou hodnotu účtu, ale nastaví vstupní cenu znovu na $110. Celková hodnota může zůstat správná, zatímco se změní rozdělení na realizovaný a nerealizovaný zisk či ztrátu. Pokud se stop nebo podmínka výstupu odvíjí od vstupní ceny, tahle účetní zkratka teď mění chování obchodování.

Nebo systém zapomene předchozí maximum hodnoty účtu. Představme si, že hodnota účtu dosáhla vrcholu $10,600 a pak klesla na $10,100. Drawdown činí přibližně 4.72%. Resetujte při obnově dosavadní maximum a strategie najednou považuje svůj drawdown za nulový. Každý rizikový limit založený na drawdownu tak právě dostal neoprávněný reset.

Problém se tedy může projevit skokem v hodnotě účtu, podezřele nižším drawdownem nebo rizikovým pravidlem, které po nasazení přestane reagovat. Zachovejte účetní knihu i stav strategie závislý na účetnictví: pohyby hotovosti, pozice, příslušnou pořizovací cenu, naběhlé poplatky a paměť řízení rizik. Obnovenou hodnotu účtu slaďte s účetní knihou ke stejnému okamžiku ocenění.

V testovací infrastruktuře pro výzkum bych ponechal test, který spustí jedno nepřerušené referenční přehrávání a pak restartuje druhý běh v záměrně nepříhodných okamžicích: během inicializace indikátoru, po částečném vyplnění a při aktivním rizikovém limitu. Použijte stejné pořadí událostí a zachovejte veškerý náhodný stav simulátoru. Porovnejte první rozhodnutí po obnově, záznamy příkazů a vyplnění i průběh hodnoty účtu. Shoda konečného zůstatku sama o sobě může skrývat chyby, které se navzájem vyrušily.

Pro havárii po odeslání příkazu, ale před potvrzením, musí testovací infrastruktura nezávisle na procesu strategie zachovat také stav služby provádění. Jinak smaže právě tu nejistotu, kterou se snažíte otestovat.

Specifikace strategie zahrnuje i to, co si pamatuje. Popište tuto paměť dostatečně přesně, abyste mohli proces uprostřed přehrávání ukončit a přesně ukázat, jak se znovu pustí do práce.