Wynik backtestu opcji może się zmienić, choć w kodzie strategii nie zmieniła się ani jedna linijka. Dostawca poprawia błędne kwotowanie, dodaje opóźnioną transakcję, aktualizuje metadane kontraktu albo zmienia filtr dla rynku z krzyżującymi się kwotowaniami. Ponownie uruchamiasz strategię dla tych samych dat i dostajesz inne wykonanie, inną pozycję, a może nawet inny Sharpe. Niekoniecznie oznacza to błąd strategii. Zmieniły się dane, na podstawie których ją testowano.
Aby backtest opcji dało się odtworzyć, traktuj dane rynkowe jako wejście z określoną wersją. Zapisuj, którego zrzutu danych użyto, zachowuj surowe obserwacje, które wpłynęły na każdą decyzję, i porównuj zmienione wyniki na poziomie kontraktu i znacznika czasu, zanim zaufasz nowemu wynikowi zbiorczemu.
Dlaczego zmienił się mój backtest opcji, skoro kod pozostał bez zmian?
Rekordy opcji są wyjątkowo podatne na korekty, ponieważ pozorna możliwość zawarcia transakcji na danym kontrakcie zależy od kilku pól zmieniających się jednocześnie: bidu, asku, wielkości, ceny instrumentu bazowego, terminu wygaśnięcia, ceny wykonania oraz mnożnika lub składnika świadczenia kontraktu. Skorygowane kwotowanie może zmienić pozorną okazję w rynek z krzyżującymi się kwotowaniami. Poprawka metadanych może zmienić znaczenie mnożnika pozycji.
Wyobraź sobie strategię, która kupuje call, gdy ask jest niższy niż $2.00. Przy pierwszym pobraniu danych kwotowanie z 10:14 wynosi $1.95 ask, $1.90 bid, a wielkość to 5. Późniejsza rewizja dostawcy zmienia ask na $2.05 po uzgodnieniu opóźnionej wiadomości z giełdy. Jedna obserwacja zmienia sygnał. Jeśli ten kontrakt był jedyną transakcją strategii tego dnia, niewielka korekta danych może zaważyć na wyniku dnia.
Znaczenie ma też filtrowanie kwotowań. Dostawcy mogą usuwać nieaktualne kwotowania, odrzucać rynki z krzyżującymi się kwotowaniami albo inaczej normalizować znaczniki czasu. Takie zasady mogą być uzasadnione, ale stanowią część tożsamości zbioru danych. „Opcje SPY, od stycznia do marca” nie określają historii, którą da się odtworzyć.
Czym jest wersja danych opcyjnych?
Wersja danych to dokładna wersja historycznych obserwacji dostępnych podczas danego przebiegu badawczego. Zapisuj nazwę dostawcy i zbioru danych, czas pobrania, zakres dat, wersję schematu oraz wszelkie reguły czyszczenia i filtrowania. Jeśli dostawca udostępnia identyfikatory zrzutów lub znaczniki czasu rewizji, również je zapisuj.
Dla każdej symulowanej decyzji zachowuj wystarczające informacje o pochodzeniu danych, by odpowiedzieć na pytania: który kontrakt rozważano, które kwotowanie wybrano, kiedy je opublikowano lub otrzymano i jaka reguła decydowała o jego kwalifikacji? Liczą się zarówno rekord surowy, jak i pochodny. Oczyszczony NBBO bez źródłowych znaczników czasu może ukryć, czy kwotowanie było nieaktualne albo dotarło po symulowanej decyzji.
| Rekord do zachowania | Dlaczego jest ważny | Przykład |
|---|---|---|
| Zrzut źródłowy | Identyfikuje historię użytą w przebiegu | Identyfikator rewizji dostawcy i znacznik czasu pobrania |
| Pochodzenie kwotowania | Wyjaśnia, który rynek wybrano | Giełda, czas zdarzenia, czas odbioru, bid/ask i wielkości |
| Warunki kontraktu | Określają, co reprezentowała opcja | Cena wykonania, termin wygaśnięcia, mnożnik i składnik świadczenia |
| Zasady czyszczenia | Pokazują, które obserwacje wykluczono | Próg nieaktualności i sposób obsługi kwotowań krzyżujących się |
Jak sprawdzić, czy rewizja dostawcy zmieniła moje wyniki?
Uruchom tę samą strategię i konfigurację na obu zrzutach danych. Najpierw porównaj liczbę kwalifikujących się obserwacji i kontraktów dla każdej daty. Następnie porównaj decyzje i wykonania: które sygnały się pojawiły lub zniknęły, które kwotowanie uległo zmianie i czy nowy rekord zmienił modelowaną cenę wykonania.
Nie ograniczaj się do łącznej stopy zwrotu. Śledź zmiany liczby transakcji, cen wejścia i wyjścia, odrzuconych sygnałów oraz udział P&L pochodzący z transakcji występujących tylko w jednej wersji danych. Sharpe może pozostać podobny, mimo że poszczególne transakcje zostały zastąpione; główna statystyka nie pokaże, że leżąca u jej podstaw historia się zmieniła.
Aby audyt był miarodajny, nie zmieniaj strategii, opłat ani założeń dotyczących wykonania. Jeśli zmienisz kilka rzeczy naraz, nie ustalisz, czy rozbieżność wynika z korekty dostawcy, czy z Twojego eksperymentu.
Czy zawsze używać najnowszej historii opcji?
Korzystaj z najnowszej historii, gdy chcesz oprzeć się na najlepszej, aktualnej rekonstrukcji dostawcy. Zachowaj stary zrzut, gdy musisz odtworzyć wcześniejszy wynik albo ustalić, jakie informacje miał wówczas Twój system badawczy. To odpowiedzi na różne pytania.
W badaniach point-in-time skorygowany rekord może być dziś dokładniejszy, a jednocześnie niedostępny dla strategii w przeszłości. Jeśli to możliwe, zachowuj czasy publikacji i odbioru; w przeciwnym razie jasno opisz to ograniczenie. Współczesna rekonstrukcja nie jest automatycznie historycznym zbiorem informacji.
Gdy zmienia się backtest opcji, pierwsze pytanie powinno brzmieć: „Które obserwacje uległy zmianie?”. Pytanie „Który przebieg jest prawidłowy?” zadaj dopiero wtedy, gdy potrafisz na to odpowiedzieć.
Co zapisywać przy każdym backteście?
Obok wyników zapisuj zwięzły manifest: dostawcę danych i zrzut, czas pobrania, wersje schematu i zasad czyszczenia, źródło metadanych kontraktów, commit strategii, założenia dotyczące wykonania oraz konfigurację przebiegu. Każdą transakcję powiąż z rekordami kwotowań, które ją uzasadniały.
Taki niewielki zapis zamienia tajemnicze ponowne uruchomienie w różnicę, którą można sprawdzić. Historia opcji będzie nadal podlegać korektom. Proces badawczy powinien uwidaczniać każdą korektę, aby lepsze archiwum poprawiało jakość danych bez cichego przepisywania eksperymentu.
← Wszystkie wpisy
