Przydatny test backtestu nie polega na szukaniu lepszego parametru: zatrzymaj proces w połowie, przywróć go i dokończ to samo odtwarzanie. Przy identycznych danych wejściowych i kontrolowanym symulatorze realizacji zleceń decyzje, zlecenia i kapitał powinny być takie same jak w nieprzerwanym przebiegu.
Jeśli tak nie jest, znaleźliśmy problem z zarządzaniem stanem. Strategia zależy od czegoś, czego nie zapisaliśmy albo nie potrafimy odtworzyć. Ta zależność ma znaczenie, gdy wznawiamy przebiegi badawcze, zastępujemy procesy robocze albo wdrażamy nowy kod w usłudze handlu papierowego.
Lubię ten test, bo oczekiwana odpowiedź jest wyjątkowo jasna. Nie ma sporu o to, czy rynek się zmienił. Oba przebiegi korzystają z tych samych danych rynkowych.
Oto trzy błędne sposoby ponownego uruchamiania. Liczby są poglądowe; każda z tych awarii może wystąpić w systemie, który poza tym działa deterministycznie.
1. Wczytaj kilka świec i uznaj wskaźniki za rozgrzane
Załóżmy, że strategia korzysta z 100-okresowej wykładniczej średniej kroczącej. Jej aktualizacja wygląda tak:
alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previousNieprzerwany proces przenosi dalej skumulowaną wartość EMA. Po ponownym uruchomieniu proces pobiera 100 świec, inicjuje EMA ceną zamknięcia pierwszej z nich i zakłada, że wskaźnik 100-okresowy wymaga 100 obserwacji.
To założenie myli parametr wygładzania wskaźnika z oknem o skończonej pamięci. EMA zachowuje malejący z czasem wkład stanu początkowego. Jeśli początkowa różnica między dwiema wersjami EMA wynosi 10 jednostek ceny, kolejne identyczne ceny zmniejszają ją w następujący sposób:
| Aktualizacje od inicjalizacji | Pozostała różnica | Część błędu początkowego |
|---|---|---|
| 100 | 1.353 | 13.53% |
| 250 | 0.0674 | 0.674% |
| 500 | 0.000454 | 0.00454% |
Obliczenie wygląda tak: 10 * (99 / 101)^k. Pobranie 100 świec daje tylko 99 aktualizacji, jeśli pierwsza obserwacja służy jako wartość początkowa.
Problem zwykle ujawnia się w pobliżu granicy decyzyjnej. Jeden przebieg widzi cenę powyżej EMA, drugi poniżej. Niewielka różnica liczbowa powoduje dodatkową transakcję. Wtedy rozbieżności mogą objąć też okresy oczekiwania, dostępne środki i kolejne decyzje.
Zapisuj rekurencyjny stan wskaźnika, informację o jego inicjalizacji i ostatnie przetworzone zdarzenie. Możesz też odtwarzać przebieg od znanego stanu początkowego. Dłuższy okres rozgrzewania może dać wystarczająco dobre przybliżenie, ale dobierz jego długość na podstawie jawnej tolerancji błędu i sprawdź, czy błąd w tych granicach może zmienić decyzje. „Pięć razy dłużej niż okres” to konwencja, nie dowód.
Wskaźniki nie wyczerpują historii. Percentyl kroczący potrzebuje swojego okna. Model online może wymagać stanu optymalizatora. Reguła, która czeka trzy świece po stracie, musi pamiętać o stracie i liczniku.
2. Zapisz pozycje i zapomnij o zleceniach w toku
Docelowa pozycja strategii to 10 jednostek. Zlecenie kupna na 10 zostało zrealizowane w ilości 4, a pozostałe 6 nadal czeka. Zapisujesz pozycję jako 4, uruchamiasz proces ponownie i składasz kolejne zlecenie kupna brakujących 6.
Jeśli pierwotna pozostała część i nowe zlecenie zostaną zrealizowane, posiadasz 16 jednostek.
W backteście ten błąd często pozostaje ukryty, bo ponowne uruchomienie silnika realizacji po cichu usuwa aktywne zlecenia. W handlu papierowym symulator albo zewnętrzna usługa może je zachować. Ten sam kod odzyskiwania skutkuje wtedy różną ekspozycją, zależnie od tego, który komponent przetrwał.
| W chwili ponownego uruchomienia | Rzeczywisty stan | Co widzi odzyskiwanie wyłącznie z pozycji |
|---|---|---|
| Docelowa pozycja | 10 | 10 |
| Zrealizowana pozycja | 4 | 4 |
| Ilość oczekującego zlecenia kupna | 6 | 0 |
| Dodatkowa potrzebna ilość | 0 | 6 |
Problem objawia się niewytłumaczalnym nagłym napływem zleceń tuż po odzyskaniu stanu. Czasem podwaja ekspozycję. Czasem zamyka pozycję, której zlecenie ochronne nadal jest aktywne i może później otworzyć nową pozycję.
Punkt kontrolny powinien przechowywać tożsamość i stan cyklu życia zleceń, a także pozycje. Przed wygenerowaniem nowych działań proces odzyskiwania musi uzgodnić te zapisy z systemem realizacji zleceń. Nieznany wynik zlecenia wymaga sprawdzenia; uznanie, że „brak zapisanego potwierdzenia” oznacza „nigdy nie wysłano”, prowadzi do powielania zleceń.
Stabilne identyfikatory zleceń klienta pomagają sprawdzić, co się wydarzyło. Zapobiegają duplikatom tylko wtedy, gdy system odbierający rzeczywiście egzekwuje wymagane zasady unikalności lub idempotencji. Zapisuj też identyfikatory przetworzonych realizacji, aby ponowne odtworzenie realizacji nie zwiększyło pozycji dwukrotnie.
Mam słabość do nudnego ekranu ze statusami zleceń. W dniu ponownego uruchomienia jego niepozorne wiersze nagle stają się najciekawszym widokiem w całym biurze.
3. Przywróć pozycję i zacznij od nowa prowadzić księgę zysków i strat
Rozważmy przykład rynku spot bez dźwigni i opłat. Zaczynamy z gotówką w wysokości $10,000, kupujemy 10 jednostek po $100 i zapisujemy punkt kontrolny, gdy wycena osiąga $110.
Prawidłowy stan to $9,000 gotówki i pozycja warta $1,100, czyli kapitał własny wynoszący $10,100. Jeśli podczas odzyskiwania przywrócimy 10 jednostek, ale gotówkę zresetujemy do początkowych $10,000, system pokaże $11,100. Samym ponownym uruchomieniem procesu stworzyliśmy $1,000.
Inne warianty są mniej spektakularne. Odzyskiwanie zachowuje kapitał własny, ale resetuje cenę wejścia do $110. Łączny kapitał może pozostać prawidłowy, a mimo to zmieni się podział na zyski zrealizowane i niezrealizowane. Jeśli stop albo warunek wyjścia odwołuje się do ceny wejścia, ten rachunkowy skrót zmienia teraz zachowanie strategii.
Albo system zapomina poprzednie maksimum kapitału. Załóżmy, że kapitał osiągnął szczyt na poziomie $10,600, zanim spadł do $10,100. Obsunięcie wynosi około 4.72%. Jeśli podczas odzyskiwania zresetujemy maksimum, strategia nagle uzna, że obsunięcie wynosi zero. Każda kontrola ryzyka oparta na obsunięciu została właśnie nieuprawnienie zresetowana.
Problem może więc objawić się skokową zmianą kapitału, podejrzanie mniejszym obsunięciem albo regułą ryzyka, która przestaje działać po wdrożeniach. Zachowaj księgę i stan strategii zależny od rozliczeń: przepływy gotówkowe, pozycje, właściwą podstawę kosztową, naliczone opłaty i pamięć kontroli ryzyka. Uzgodnij przywrócony kapitał z księgą przy tym samym znaczniku czasu wyceny.
Punkt kontrolny musi odpowiadać spójnemu momentowi. Zapisanie gotówki po realizacji zlecenia, ale ilości pozycji sprzed tej realizacji, daje stan, który nigdy nie istniał. Zapisuj powiązane dane razem albo utrwalaj sekwencję zdarzeń, z której można je odtworzyć. Zapisz wraz ze stanem kursor zdarzeń, aby podczas odzyskiwania nie pominąć realizacji ani nie zastosować jej dwukrotnie.
W środowisku badawczym zostawiłbym test, który uruchamia nieprzerwany przebieg referencyjny, a następnie ponownie uruchamia drugi przebieg w celowo kłopotliwych momentach: podczas inicjalizacji wskaźnika, po częściowej realizacji zlecenia i przy aktywnym limicie ryzyka. Użyj tej samej kolejności zdarzeń i zachowaj stan generatora losowego symulatora. Porównaj pierwszą decyzję po odzyskaniu, zapisy zleceń i realizacji oraz przebieg kapitału. Zgodne saldo końcowe może ukryć błędy, które wzajemnie się znoszą.
Aby przetestować awarię po wysłaniu zlecenia, ale przed otrzymaniem potwierdzenia, środowisko testowe musi też zachować stan usługi realizującej zlecenia niezależnie od procesu strategii. W przeciwnym razie usunie niepewność, którą próbujemy zbadać.
Specyfikacja strategii obejmuje to, co pamięta. Opisz tę pamięć na tyle jasno, by można było zatrzymać proces w połowie odtwarzania i dokładnie pokazać, jak wraca do pracy.
← Wszystkie wpisy
