Backtesting to historyczna symulacja reguł handlowych lub decyzyjnych z jednoznacznie określonymi danymi, kolejnością czasową i założeniami realizacji. Pozwala sprawdzić zachowanie reguły w przeszłej próbie, ale wartość informacyjna wyniku zależy od konstrukcji całego testu.
Backtesting odtwarza reguły na danych historycznych i oblicza, jaki wynik przyniosłyby przy wybranych założeniach. Bailey i współautorzy opisują go jako historyczną symulację strategii algorytmicznej, a jednocześnie ostrzegają przed ryzykiem fałszywych odkryć. Nasze zastrzeżenie redakcyjne: wynik dotyczy konkretnej wersji reguł, danych i modelu realizacji. Nie dowodzi, że ktoś rzeczywiście przeprowadził te transakcje. Odtwarzalne obliczenie może ujawnić błąd lub nietrafiony pomysł, ale samo nie zmienia przeszłości w wiarygodną prognozę. [Bailey et al. — The Probability of Backtest Overfitting]
QuantConnect opisuje zniekształcenie, w którym symulacja wykorzystuje przyszłe informacje, na przykład dane księgowe przed ich publikacją lub ich późniejsze korekty. Nasza własna zasada czasowa wymaga określenia dla każdej danej wejściowej chwili jej dostępności, a nie tylko daty okresu, którego dotyczy. Sygnał z zamkniętej świecy nie może bez dodatkowego założenia prowadzić do transakcji po cenie, z której nie można już było skorzystać. W naszym przykładzie poprzednie ceny zamknięcia wykorzystuje się dopiero w następnym okresie, a model jednoznacznie określa realizację po jego cenie otwarcia. [QuantConnect — Research Guide]
QuantConnect zwraca uwagę na testowanie wyłącznie papierów wartościowych, które przetrwały do końca okresu, oraz na stosowanie dzisiejszego składu indeksu do przeszłości. Nasze bardziej ogólne pytanie brzmi, czy zbiór historyczny zachowuje również instrumenty dostępne wówczas, które później zniknęły. Trzeba udokumentować brakujące dane, zmiany metodologii i wybór rynków. W symulacji bitcoinowej nie można automatycznie uznać ceny z jednej usługi za cenę osiągalną w innej usłudze. Czystość danych oznacza możliwość prześledzenia korekt, a nie usuwanie niewygodnych wyników. [QuantConnect — Research Guide]
Dokumentacja QuantConnect oddziela sygnał i zlecenie od modelu określającego cenę oraz ilość realizacji. Wskazuje również różnicę między częściową realizacją w rzeczywistym handlu a założeniem pełnej realizacji w gotowych modelach. Nasz własny wymóg to opisanie, kiedy zlecenie może zostać zrealizowane, co dzieje się przy niewystarczającej płynności i jak traktuje się nieaktualną cenę. Samo dotknięcie poziomu cenowego w danych historycznych nie dowodzi dostępności kontrahenta dla zlecenia o dowolnej wielkości. Wynik modelu realizacji pozostaje założeniem symulacji. [QuantConnect — Trade Fills: Key Concepts]
QuantConnect opisuje Slippage jako różnicę między oczekiwaną a rzeczywistą ceną realizacji i wskazuje wpływ opóźnień, połączenia oraz warunków rynkowych; odchylenie może być korzystne lub niekorzystne. Nasza własna kontrola kosztów oddziela opłaty, cenę realizacji oraz ewentualne inne koszty utrzymywania pozycji lub finansowania. Kosztu już uwzględnionego w cenie realizacji nie wolno odejmować ponownie. Wartość zerowa jest konkretnym założeniem modelu, a nie dowodem istnienia rynku bez kosztów. Wrażliwość na wyższe koszty pomaga ustalić, czy niewielki historyczny zysk zależy od optymistycznych ustawień. [QuantConnect — Slippage: Key Concepts]
Dokumentacja TimeSeriesSplit wyjaśnia podział uporządkowany w czasie, aby model nie był trenowany na przyszłości i oceniany na przeszłości. Nasz własny wymóg metodologiczny to wyznaczenie okresu do opracowania reguł i okresu do ich późniejszej weryfikacji jeszcze przed zapoznaniem się z wynikami. Jeżeli po niepowodzeniu reguły ponownie dostosuje się do okresu weryfikacyjnego, okres ten już wpłynął na rozwój. Sam podział chronologiczny nie rozwiązuje problemu wycieku informacji z przetwarzania wstępnego, nakładających się zmiennych docelowych ani wielokrotnego wyboru wariantów. Trzeba opisać zarówno procedurę, jak i granice zbiorów danych. [scikit-learn — TimeSeriesSplit]
Bailey i współautorzy pokazują, że wielokrotne poszukiwanie najlepszej konfiguracji na tych samych danych zwiększa ryzyko fałszywych odkryć i dopasowania do przeszłego szumu. Nasza własna zasada raportowania wymaga przedstawienia historii prób, a nie tylko zwycięskiej krzywej. Obejmuje to zmiany parametrów, okresów i doboru instrumentów. Wynik wybrany po wielu próbach nie ma tej samej wartości informacyjnej co reguła ustalona z góry i niezmieniana. Ich metoda szacowania prawdopodobieństwa przeuczenia nie jest stosowana w naszym prostym przykładzie ani zastępowana pojedynczym podziałem danych. [Bailey et al. — The Probability of Backtest Overfitting]
NFA ostrzega, że hipotetyczne wyniki nie odzwierciedlają rzeczywistego handlu, mogą korzystać z wiedzy po fakcie i niedoskonale modelować płynność, poślizg cenowy lub zachowanie podczas rzeczywistej straty. Nasz własny raport powinien zatem zachować wersję danych i kodu, reguły, założenia realizacji, uwzględnione koszty i pełną listę symulowanych transakcji. Łączna stopa zwrotu wymaga kontekstu ryzyka oraz porównania przy takich samych warunkach; wybrany atrakcyjny wykres nie wystarcza. Nawet bezbłędna implementacja testu historycznego nie gwarantuje wykonalności ani stopy zwrotu na przyszłym rynku. [NFA — Use of Promotional Material Containing Hypothetical Performance Results]
Sygnał z poprzedniego okresu, realizacja w następnym
Pełniejszy obraz uzyskasz, czytając to hasło razem z Trading Plan, Trading Journal, Slippage, Overfitting, Walk-forward Analysis. Do tego hasła prowadzą również odsyłacze z Technical analysis, OHLCV, Timeframe, Candlestick chart.
01Czy zyskowny backtest dowodzi, że strategia będzie zarabiać?+
Nie. Wynik może zależeć od konkretnych danych, kosztów, modelu realizacji lub wyboru najlepszego wariantu. Trzeba zweryfikować poprawność czasową, założenia i procedurę wyboru; nawet wtedy nie ma gwarancji przyszłej stopy zwrotu.
02Czy wystarczy odjąć opłaty dopiero od końcowego zysku?+
Tylko jeśli taki sposób dokładnie odpowiada modelowi i nie wpływa na dostępny kapitał ani dalsze decyzje. Zwykle trzeba księgować koszty przy odpowiednich zdarzeniach, rozróżniać cenę realizacji i opłaty oraz zapobiegać podwójnemu odejmowaniu.