Standard testu bota: 12 miesięcy, 52 starty tygodniowe i wersja w wyniku

W skrócie: dwa wyniki da się porównać tylko wtedy, gdy powstały w tych samych warunkach. Dla każdego bota robię więc ten sam test: ostatnie dwanaście miesięcy, pięćdziesiąt dwa starty co tydzień, konto 10 tysięcy dolarów. Przy wyniku zapisuję wersję kodu i dokładny plik ustawień. Wynik bez tych dwóch rzeczy traktuję jak anegdotę.

Co wchodzi do standardu

Okno: ostatnie 12 miesięcy. Okno przesuwam po zakończeniu każdego miesiąca. Po końcu miesiąca nowy test liczę na bieżącym oknie, nie na starym, i przy porównaniu ze starym wynikiem zaznaczam, że okno się przesunęło. Przesunięcie o jeden miesiąc potrafi zmienić wynik bota (artykuł o przesuwaniu okna co miesiąc).
52 starty tygodniowe. Ten sam bot uruchamiam w pięćdziesięciu dwóch wariantach różniących się tygodniem startu symulacji konta prop. Dzięki temu widać, ile z tych startów kończy się zaliczeniem, a ile oblaniem, a nie tylko wynik jednego, szczęśliwego początku (szczegóły w artykule o odporności na moment startu).
Konto 10 tysięcy. Stałe saldo i stałe ryzyko na transakcję pozwalają zestawić boty o różnych strategiach i różnych instrumentach.
Model OHLC z minutowych świec. Tryb wolniejszy z prawdziwymi tikami uruchamiam tylko wtedy, gdy mam konkretny powód (opisałem to w artykule o OHLC kontra tiki).

Wynik “dwunastu miesięcy” to po prostu przebieg ze startem w dniu zerowym tego samego sweepu, więc osobnego testu na to nie robię: ten sam okres, kod i ustawienie dają identyczny wynik.

Co zapisuję przy każdym przebiegu

Skrypt uruchamiający test dopisuje wiersz do pliku wyników. Zawiera on między innymi: czas testu, bota, wersję kodu, identyfikator zatwierdzenia w repozytorium, informację, czy w kodzie bota i biblioteki były niezatwierdzone zmiany, symbol, interwał, okres, model testu, serwer, saldo, ryzyko, odcisk pliku ustawień, liczbę przejść i oblań, współczynnik zysku, liczbę transakcji, zysk, spadek kapitału, numer wersji terminala i raport. Dwie rzeczy z tej listy są dla mnie najważniejsze:

Wersja kodu i zatwierdzenie. Bez nich nie wiem, czy zmiana wyniku wynika z nowej wersji, czy z innych danych.
Odcisk pliku ustawień. Ten sam bot z dwoma różnymi ustawieniami to dwa różne wyniki, nawet jeśli nazwa pliku jest podobna.

Znacznik niezatwierdzonych zmian w kodzie ma jeden cel: wynik z “brudnego” katalogu nie powinien zostać uznany za wynik wersji z repozytorium.

Czego nie robię

Nie wpisuję na stronę wyników wszystkich przebiegów siatki optymalizacji. Zatwierdzam jeden, najlepszy spełniający standard: mniej oblań, potem więcej przejść, potem wyższy współczynnik zysku.
Nie biorę ostatniego testu za aktualny wynik. Ostatni nie znaczy najlepszy.
Nie porównuję wyniku sprzed zmiany okna z wynikiem po zmianie bez zaznaczenia tej różnicy.
Nie liczę liczby transakcji z logów. Dane biorę z pliku wyników.

Szerzej o tym, jak AI może pomóc w analizie takiej tabeli i gdzie się myli, jest w artykule AI jako analityk wyników backtestu.

[DO UZUPEŁNIENIA: jedna konkretna sytuacja, w której porównanie dwóch wyników bez wspólnego standardu dało błędny wniosek]

Checklista

Okno to ostatnie 12 miesięcy, przesunięte po końcu miesiąca.
Uruchomiłem 52 starty tygodniowe, nie jeden.
Saldo i ryzyko są takie jak w standardzie, na koncie 10 tysięcy.
W wyniku jest wersja kodu, zatwierdzenie i odcisk ustawienia.
Wiem, czy w kodzie były niezatwierdzone zmiany.
Zatwierdzam najlepszy wynik, nie najnowszy.

Powiązane

Przesuwanie okna testu co miesiąc
Optymalizacja dat startu
OHLC kontra prawdziwe tiki
Lista transakcji zamiast sumy
Słowniczek: standard testu; skorowidz: skorowidz

Ostrzeżenie: wynik backtestu nie gwarantuje zysku na koncie. Standard testu służy do porównań, nie jest prognozą. Handel CFD wiąże się z wysokim ryzykiem utraty kapitału.