Backtesting a dziennik tradingowy: dlaczego potrzebne są oba
Backtesting symuluje strategię na historycznych danych, zanim zaryzykuje się kapitał; dziennik zapisuje, co naprawdę wydarzyło się przy realnych zleceniach. Dlaczego te dwie praktyki się uzupełniają, a nie zastępują, i jak łączyć je razem.
Ostatnia aktualizacja:
W skrócie. Backtesting symuluje strategię na historycznych danych cenowych, zanim jakikolwiek kapitał zostanie narażony na ryzyko; dziennik tradingowy zapisuje, co naprawdę się wydarzyło, gdy zlecenia były już realne. Odpowiadają na różne pytania i żadne z nich nie zastępuje drugiego: backtest pokazuje, czy zestaw reguł miał historycznie sens, ale tylko dziennik pokazuje, czy trader jest w stanie faktycznie go zrealizować, z prawdziwym poślizgiem cenowym, prawdziwymi opłatami i prawdziwą psychologią po drodze.
Traderzy mają tendencję do polegania na jednym z tych narzędzi i pomijania drugiego. Ktoś przepuszcza strategię przez backtest, widzi czystą krzywą kapitału i zaczyna handlować nią na żywo, zakładając, że backtest już udowodnił słuszność pomysłu. Ktoś inny skrupulatnie prowadzi dziennik każdej transakcji na żywo, ale nigdy nie sprawdził na danych historycznych, czy sam pomysł ma w ogóle jakikolwiek sens statystyczny. Oba nawyki tworzą ślepy punkt, który druga praktyka by wychwyciła.
Co backtesting naprawdę testuje
Backtest stosuje ustalony zestaw reguł wejścia i wyjścia do historycznych danych cenowych i mierzy, co by się wydarzyło: zysk lub stratę netto, win rate, obsunięcie kapitału i inne statystyki wyników, obliczone bez ryzykowania choćby grosza (Corporate Finance Institute, "Backtesting"). Dzięki temu jest tani w przeprowadzeniu i szybki do iterowania: pomysł na reguły można przetestować na latach historii cen, dopracować i przetestować ponownie, zanim jeszcze wyjdzie choć jedno realne zlecenie. Platformy detaliczne, takie jak Strategy Tester w MetaTrader, istnieją właśnie po to: symulują wykonanie zautomatyzowanej strategii na zapisanych historycznych danych cenowych, aby można było sprawdzić logikę, zanim dotknie ona konta realnego lub demo (MetaQuotes, dokumentacja MQL5, "Testing Trading Strategies").
Wartość backtestu jest wąska i konkretna: odpowiada, czy określony zestaw reguł dałby dodatni wynik w wybranym okresie historii. Nie odpowiada, czy ten konkretny trader w realnych warunkach rynkowych jest w stanie faktycznie przestrzegać tych reguł.
Czego backtest nie widzi
Backtest działa na czystych danych historycznych i symulowanym wykonaniu przy każdym sygnale. Nie ma dostępu do tego, co dzieje się między regułą a realnym zleceniem: pół sekundy wahania przed kliknięciem kup, stop, który zostaje przesunięty, bo transakcja "wydaje się" zła, pozycja zamknięta zbyt wcześnie z nerwów albo ta trzymana zbyt długo w nadziei na odbicie. Nic z tego nie pojawia się w symulacji, bo symulacja nie ma nerwów.
Backtest ma też tendencję do zaniżania realnych kosztów handlu. Historyczne wykonania w backteście często zakłada się dokładnie po cenie sygnału, podczas gdy realne zlecenie wykonuje się po cenie, jaką rynek oferuje chwilę później, plus spread i prowizja. Poślizg cenowy na płynnym instrumencie może wynosić ułamek procenta; na cieńszym rynku może znacznie przekroczyć jeden procent, a nawet niewielkie założenie poślizgu potrafi zamienić przewagę widoczną w backteście w stratę na żywo, jeśli zastosuje się je konsekwentnie do każdej transakcji.
Ważne. Backtest, który nigdy nie uwzględniał realistycznego poślizgu cenowego, prowizji i wykonań, nie mierzy strategii, której trader naprawdę doświadczy na żywo. Czystą krzywą backtestu warto traktować jako wstępną hipotezę, a nie gwarancję.
Co zamiast tego rejestruje dziennik tradingowy
Dziennik tradingowy rejestruje transakcję, która naprawdę została otwarta: realną cenę wejścia i wyjścia, realny rozmiar, realny wynik po kosztach, a jeśli dziennik to uwzględnia, stan psychiczny przed i po transakcji. To jedyny zapis, który pokazuje różnicę między regułą na papierze a regułą w wykonaniu.
Właśnie w tej różnicy często kryje się prawdziwa historia. Setup może mieć czysty win rate 55% w backteście i mimo to tracić pieniądze na żywo, nie dlatego, że setup był zły, ale dlatego, że realne wykonanie konsekwentnie oddaje kilka punktów bazowych na transakcję poślizgowi cenowemu, wahaniu albo wyjściu zamkniętemu o świecę za wcześnie. Prowadzenie dziennika każdej transakcji z tagiem setupu to właśnie to, co w ogóle umożliwia takie porównanie; bez tego żywa seria strat i zepsuty pomysł wyglądają od środka identycznie.
Ślepy punkt, jaki ma każda metoda z osobna
| Pytanie | Tylko backtesting | Tylko dziennik tradingowy |
|---|---|---|
| Czy ten zestaw reguł w ogóle miał sens? | Odpowiada wprost, tanio, na podstawie lat danych | Nie może odpowiedzieć bez wcześniejszego ryzykowania realnych transakcji |
| Czy jestem w stanie faktycznie zrealizować tę regułę na żywo? | Nie może odpowiedzieć; zakłada idealne, bezemocjonalne wykonanie | Odpowiada wprost, transakcja po transakcji |
| Czy moje koszty (poślizg, prowizje) są uwzględnione? | Tylko jeśli celowo wliczone, i często zaniżone | Zawsze obecne, bo już się wydarzyły |
| Czy seria strat jest normalna, czy oznacza zanik przewagi? | Brak danych na żywo do porównania | Brak historycznego punktu odniesienia do porównania |
Praktyczny proces pracy: najpierw backtest, potem dziennik luki wykonania
Obie praktyki działają najlepiej jako sekwencja, a nie wybór jednej z nich. Najpierw przeprowadzić backtest pomysłu na wystarczająco długim odcinku historii i w więcej niż jednych warunkach rynkowych, aby odsiać reguły, które nigdy nie miały sensu, zanim zaangażuje się jakikolwiek kapitał. Jeśli backtest się broni, handlować pomysłem na żywo zmniejszonym rozmiarem i prowadzić dziennik każdej transakcji pod osobnym tagiem, łącznie z ceną wejścia i wyjścia, rozmiarem i wynikiem po kosztach.
Po zebraniu znaczącej liczby transakcji na żywo pod tym tagiem porównać zarejestrowany w dzienniku win rate i średni wynik z wynikami backtestu dla tego samego zestawu reguł. Bliska zgodność, w granicach tego, co wyjaśniałyby koszty i normalna zmienność, jest sygnałem, że strategia przetrwała kontakt z realnym wykonaniem. Szeroka, stała luka wskazuje na realny problem: koszty zaniżone w backteście albo reguły, których faktycznie nie przestrzega się tak, jak zapisano, gdy w grę wchodzą prawdziwe pieniądze i prawdziwe emocje. Regularny przegląd zestawienia strategii dla tego tagu, a nie tylko wtedy, gdy setup "wydaje się", jakby przestał działać, to właśnie to, co utrzymuje to porównanie uczciwym.
Odczytywanie żywej serii strat na tle punktu odniesienia z backtestu
Serię strat na żywym, prowadzonym w dzienniku setupie łatwo błędnie odczytać bez backtestu do porównania. Jeśli test historyczny już pokazywał odcinki pięciu lub sześciu kolejnych strat jako normalną część wzorca zwrotu tej strategii, żywa seria strat o podobnej długości nie jest nową informacją; to strategia zachowuje się zgodnie z oczekiwaniami. Bez tego punktu odniesienia ta sama seria może wyglądać na dowód, że pomysł przestał działać, a traderzy porzucają setupy, które nigdy nie były zepsute, albo dokładają do takich, które po cichu są.
To inny rodzaj błędu niż ocena przewagi na podstawie zbyt małej próby na żywo, co jest problemem wielkości próby. Tutaj problem polega na braku jakiegokolwiek punktu odniesienia dla tego, jak wygląda "normalność" dla tej konkretnej strategii, ponieważ pominięto etap backtestu. Expectancy, liczona w ten sam sposób zarówno w backteście, jak i w dzienniku na żywo, to liczba, która czyni to porównanie konkretnym, a nie odczuciem.
Co logować, aby porównanie faktycznie działało
Porównanie backtestu z wynikami na żywo działa tylko wtedy, gdy dziennik rejestruje wystarczająco dużo szczegółów, aby zestawić je z wynikiem samego backtestu. Wpis w dzienniku, który zapisuje tylko wygraną lub przegraną, nie da się porównać z backtestem, który raportuje win rate, średni wynik i obsunięcie kapitału; oba zbiory danych muszą mówić tym samym językiem.
Minimum to nazwa setupu, cena wejścia i wyjścia, wielkość pozycji, wynik po kosztach oraz data dla każdej transakcji na żywo pod danym tagiem, aby te same statystyki (win rate, średni wynik, maksymalne obsunięcie kapitału dla tego tagu) można było policzyć po obu stronach i zestawić obok siebie. Przykłady dzienników tradingowych zbudowane na tym poziomie szczegółowości zamieniają to porównanie w pięciominutowe sprawdzenie zamiast ręcznej rekonstrukcji na podstawie wyciągów brokerskich po fakcie.
Typowe błędy
- Handel pomysłem sprawdzonym w backteście na żywo bez porównywania wyników na żywo z backtestem. To porównanie to cały sens; pominięcie go zamienia backtest w jednorazowe ćwiczenie zamiast bieżącej kontroli.
- Zakładanie, że wykonania i koszty w backteście odpowiadają warunkom na żywo. Nierealistyczne założenia dotyczące poślizgu cenowego i prowizji regularnie zamieniają przewagę z backtestu w stratę na żywo.
- Prowadzenie dziennika transakcji na żywo dla pomysłu, który nigdy nie został przetestowany na danych historycznych. Nie da się odróżnić normalnej serii strat od zepsutego pomysłu bez punktu odniesienia.
- Porzucanie strategii po serii strat, która pokrywa się z jej własnym wzorcem obsunięcia z backtestu. Porównać z backtestem, zanim wyciągnie się wniosek, że przewaga zniknęła.
- Traktowanie pojedynczego uruchomienia backtestu jako trwałego dowodu. Warunki rynkowe się zmieniają; zestaw reguł, który dobrze wypadł rok temu, wymaga okresowej ponownej weryfikacji na świeżych danych, tak samo jak przewaga na żywo.
Ten artykuł ma charakter wyłącznie edukacyjny i nie stanowi porady finansowej ani inwestycyjnej. Handel z dźwignią wiąże się z wysokim ryzykiem utraty środków. Wyniki historyczne, czy to z backtestu, czy z historii na żywo, nie gwarantują przyszłych rezultatów.
Porównuj oczekiwania z backtestu z realnymi, zarejestrowanymi w dzienniku wynikami automatycznie dzięki dziennikowi tradingowemu BitStat, zamiast prowadzić dwa osobne arkusze i zgadywać różnicę między nimi.