Plan walidacji strategii: dowody, wersje i decyzje

Walidacja strategii to zbieranie dowodów dotyczących konkretnej wersji reguł, danych i wykonania. Przydaje się plan zapisany przed oceną wyników: co sprawdzasz, jakie pliki zachowujesz i co oznacza błąd wymagający przerwania pracy. Sam zestaw etapów nie gwarantuje zysku ani gotowości do handlu.

Oddziel pytania, na które odpowiadają testy

Poprawność programu, jakość danych, wynik historyczny i działanie na rachunku to różne kwestie. Program może wiernie realizować nierentowny pomysł. Rentowny raport może z kolei pochodzić z błędnej implementacji. Nie zamykaj wszystkich pytań jednym polem „test zaliczony”.

Zapisz cel badania w sprawdzalnej formie. Przykładowo: „czy zlecenie powstaje dopiero po zamknięciu świecy?”, „czy prowizja obejmuje obie strony?” albo „czy wynik pozostaje dodatni po określonym pogorszeniu kosztu?”. Odpowiedź na jedno z tych pytań nie rozstrzyga pozostałych.

Rozpocznij od dokumentu z numerem wersji. Wpisz instrument, sesję, sygnał, wyjście, wielkość pozycji oraz ograniczenia liczby zleceń. Dodaj zachowanie przy luce, utracie połączenia i restarcie. Jeżeli opis dopuszcza dwie interpretacje, rozstrzygnij je przed porównaniem wykresów kapitału.

Przygotuj prostą kartę dowodów

Poniższa tabela jest propozycją organizacji pracy. Kryteria powinny odpowiadać strategii i zakresowi badania; nie stanowią certyfikatu bezpieczeństwa. Każdy etap może zakończyć się odrzuceniem pomysłu albo powrotem do poprawienia specyfikacji.

W kolumnie z wynikiem wpisuj także „nie sprawdzono” i „brak danych”. To lepsza informacja niż domyślne zaliczenie. Oddziel błąd techniczny od niekorzystnego wyniku ekonomicznego: oba są istotne, ale wymagają innej diagnozy.

Do przykładowych przypadków technicznych dobierz udane wejście, stratę, brak sygnału, zlecenie odrzucone i granicę sesji. Sama zgodność jednej dochodowej transakcji nie sprawdza wyjścia awaryjnego, naliczania kosztów ani działania przy już otwartej pozycji.

Zadbaj o możliwość odtworzenia raportu

Zapisz wersję kodu, parametry, program i jego ustawienia, identyfikator danych, daty testu oraz strefę czasu. Zachowaj listę transakcji i komunikaty, nie tylko obraz krzywej kapitału. Dla danych zmienianych przez dostawcę przydaje się archiwum lub suma kontrolna użytego pliku.

Opisz model wykonania i brakujące elementy: Bid/Ask, poślizg, prowizję, finansowanie, wielkość kontraktu i ograniczenia wolumenu. Weryfikacja wymaga zgodnych jednostek. Punkt indeksu, pip walutowy i tick kontraktu nie mają jednej wspólnej wartości pieniężnej.

Różnica między dwoma raportami nie musi oznaczać zmiany strategii. Dostawca mógł uzupełnić historię, program zmienić model albo użytkownik wybrać inny rachunek. Bez zapisanych ustawień trudno odróżnić te sytuacje. Szczegółowe przygotowanie opisuje poradnik backtestu.

Kontroluj także decyzje podejmowane poza testerem

Prowadź rejestr wszystkich badanych wersji, również nieudanych. Dodanie filtra, usunięcie pary, przesunięcie daty początku czy wybór lepszego podziału danych są decyzjami badawczymi. Nie znikają z procesu dopasowania tylko dlatego, że wykonano je ręcznie.

Własny przykład: wersja 1.0 ma ustalony test na latach 2024–2025. Po obejrzeniu strat z poniedziałków usuwasz te dni i zapisujesz wersję 1.1. Ponowny wynik na 2024–2025 pokazuje efekt zmiany, ale nie jest już niezależnym sprawdzianem nowej wersji. Informacja z tego okresu wpłynęła na regułę.

Poprawka literówki w opisie nie zmienia modelu. Poprawka błędu w obliczaniu kosztów już może zmienić wnioski i wymaga ponownego przeliczenia. Zachowaj oba raporty oraz powód zmiany; nie zastępuj starego wyniku bez śladu.

Dobierz zakres danych do pytania

Nie istnieje obowiązkowa liczba lat dla każdej strategii ani próg stu transakcji zapewniający wiarygodność. Krótka historia może nie obejmować istotnych warunków, a długa łączyć okresy o innych zasadach wykonania. Potrzebujesz uzasadnienia zakresu, a nie samej długości.

Strategia przeznaczona do konkretnego stanu rynku może być spójna, jeśli stan rozpoznajesz według reguły dostępnej w czasie decyzji. Problemem jest dopisanie etykiety „trend” dopiero po obejrzeniu całego wykresu i pominięcie wszystkich niewygodnych okresów.

Nie traktuj spadku wyniku OOS jako automatycznego dowodu przedopasowania. Sprawdź koszty, błędy danych, zmienność i niepewność próby. Jednocześnie nie tłumacz każdego niepowodzenia zmianą rynku. Kryteria oceny zapisz wcześniej, a odstępstwa jawnie opisz.

Sprawdź obsługę w czasie rzeczywistym

Demo lub obserwacja bez wysyłania zleceń pozwala porównać bieżące sygnały z założeniami. Rejestruj czas sygnału, zlecenia i odpowiedzi, symbol, wolumen oraz błędy. Utrata połączenia i restart powinny mieć określoną procedurę, która ogranicza ryzyko podwojenia pozycji.

Historyczny tryb Forward w testerze MT5 wydziela późniejszy fragment danych. Nie jest tym samym co obserwacja przyszłych notowań na demo. Z kolei poprawne działanie demo nie potwierdza identycznych warunków realizacji na rachunku rzeczywistym.

Nie wyznaczaj automatycznego przejścia na live po trzech czy sześciu miesiącach. Potrzebne obserwacje zależą od częstości sygnałów i sposobu działania. Brak transakcji w danym miesiącu może być zgodny z regułą, a sam upływ czasu nie sprawdza obsługi rzadkich zdarzeń.

Porównując raporty historyczne i demo, wyrównaj daty, sygnały oraz wielkość pozycji. Większe obsunięcie z dłuższego okresu nie jest bezpośrednio porównywalne z krótszą próbą. Ustal, czy różnica powstała przy generowaniu sygnału, wysyłaniu zlecenia czy wycenie wykonania. Lista samych zamkniętych transakcji może nie pokazać sygnałów pominiętych przez awarię.

Archiwum powinno pozwalać odpowiedzieć na proste pytanie: która wersja działała danego dnia? Numer w nazwie raportu powiąż z kodem i parametrami. Dzięki temu nie przypiszesz starej konfiguracji wyniku uzyskanego po ręcznej zmianie ustawień.

Ponowienie zlecenia sprawdzaj względem pozostałego celu

Test awarii potrzebuje oczekiwanego stanu końcowego, nie tylko komunikatu „robot wznowił pracę”. Rozważ hipotetyczny cel: kupić 0,20 lota. Przed zerwaniem połączenia wykonano 0,08 lota, a pozostałe zlecenie zostało później potwierdzone jako anulowane. Nie ma innych pozycji ani aktywnych zleceń tego pomysłu.

Pierwszy wariant przekracza cel o 0,08 lota, czyli o 40%. Drugi oblicza brakującą część: 0,20 − 0,08 = 0,12. Dopisz taki przypadek do karty dowodów, wraz z historią potwierdzeń i identyfikatorem pomysłu. To pozwala wykryć błąd, którego nie pokaże poprawny wynik strategii na wykresie.

Warunek anulowania jest kluczowy. Przy nieznanym statusie stara reszta może nadal zostać wykonana; samo odjęcie dotychczasowych transakcji nie wystarczy. Wtedy oczekiwanym zachowaniem testu jest wstrzymanie ponowienia i uzgodnienie stanu. Ten przykład sprawdza obsługę konkretnej awarii, nie gwarantuje niezawodności całego systemu.

Ustal, kiedy zatrzymać i ponownie zbadać wersję

Oddziel granice ryzyka od sygnałów do analizy. Przekroczenie ustalonego limitu ekspozycji lub niekontrolowane powielanie zleceń to problem operacyjny. Pogorszenie średniego wyniku wymaga oceny okresu, liczby obserwacji i warunków; jedna dowolna różnica profit factor nie diagnozuje przyczyny.

Jeśli w ogóle rozważasz handel realny, wylicz ryzyko najmniejszego dostępnego wolumenu według kontraktu. Mikrolot w standardowej konwencji FX oznacza 0,01 lota, czyli 1000 jednostek waluty bazowej. Nie oznacza jednej dziesiątej Twojej docelowej pozycji ani automatycznie małego ryzyka pieniężnego.

Rezultatem walidacji może być decyzja o nieuruchamianiu strategii. Dalsze narzędzia, takie jak walk-forward i Monte Carlo, pomagają stawiać kolejne pytania, ale nie zastępują uczciwego rejestru założeń i ograniczeń.

Sprawdź, czy rozumiesz

Jedno krótkie ćwiczenie

Po obejrzeniu OOS dodajesz filtr poniedziałkowych transakcji. Czy ponowny test na tym samym OOS jest niezależny?

Sprawdź odpowiedź

Nie. Wynik z tego okresu wpłynął na wybór reguły. Zachowaj wersje i oznacz wykorzystanie danych; dalszy sprawdzian wymaga danych niewykorzystanych do tego wyboru.

Następny temat: Walk-forward: okna testu, przeciek danych i WFE →