Optymalizacja walk-forward ma opinię uczciwego sposobu strojenia strategii i w pełni na nią zasługuje — w porównaniu z optymalizowaniem na całych danych i podziwianiem wyniku. Ale technika ta ma ciche tryby awarii, a każdy z nich produkuje ten sam artefakt: raport walidacyjny z napisem „odporna" przypięty do strategii, która taka nie jest. Oto trzy, przeciwko którym musieliśmy się zabezpieczyć, uporządkowane według szkód, jakie zostawiają.
Awaria pierwsza: przeciek między oknami
Jak nie należy: stroisz na styczniu-czerwcu, walidujesz na lipcu, a potem pozwalasz, by cokolwiek z lipca wpłynęło na drugie podejście — powtórka po zobaczeniu wyniku out-of-sample, „drobna korekta" siatki parametrów, cecha normalizowana na całej serii. Każde z osobna wygląda niewinnie. Razem zamieniają okno out-of-sample w dane in-sample z opóźnieniem.
Szkody: Sharpe out-of-sample, który w tajemniczy sposób podąża za Sharpe'em in-sample. Prawdziwe wyniki out-of-sample są zaszumione i rozczarowujące; podejrzanie gładka relacja IS/OOS oznacza, że informacja płynie wstecz. Obserwujemy ten stosunek wprost — in-sample ponad 3x wyższy niż out-of-sample flaguje przebieg, a out-of-sample na poziomie zera lub poniżej zabija go niezależnie od tego, jak ładnie wygląda in-sample.
Awaria druga: dobieranie metryki między oknami
Uruchamiasz trzy okna walk-forward, dostajesz trzy zaszumione wyniki, a potem je podsumowujesz: średni Sharpe? Mediana? Odrzucić najgorsze okno z powodu „zmiany reżimu"? Każdy taki wybór to stopień swobody, a zdeterminowany optymalizator (człowiek albo bayesowski) znajdzie takie podsumowanie, w którym ta strategia wygląda najlepiej. Siedemdziesiąt pięć prób Optuny na okno to siedemdziesiąt pięć szans na dopasowanie się do szumu — razy tyle podsumowań, ile jesteś skłonny rozważyć.
Szkody: strategia, która przechodzi walidację, a potem dostarcza na żywo wynik najgorszego okna, bo najgorsze okno było jedynym uczciwym. Nasza zasada: sposób agregacji jest zapisany w konfiguracji przed uruchomieniem, budżet prób jest ustalony, a analityk czyta wyniki per okno wraz z pokazanym rozrzutem. Strategia, która potrzebuje przychylnego podsumowania, żeby przejść — nie przechodzi.
Awaria trzecia: holdout, który przestał nim być
Holdout działa dokładnie raz. Za drugim razem, gdy ocenia się na nim strategię — po poprawce parametru, korekcie sygnału, „sprawdźmy tylko" — to już nie jest holdout; to powolny zbiór walidacyjny. Piętnaście nietkniętych dni brzmi banalnie łatwo do zachowania, dopóki nie pojawi się presja iteracji, a ponowne sprawdzenie nie zacznie wydawać się nieszkodliwe.
Szkody są subtelne: wyniki na holdoucie, które poprawiają się z kolejnymi iteracjami tej samej strategii. Świeże dane out-of-sample nie mają powodu, by nagradzać trzecią iterację bardziej niż pierwszą, a gdy to robią, oznacza to, że holdout został wyeksploatowany. Egzekwujemy zasadę jednego strzału mechanicznie: holdout jest oceniany raz na przebieg pipeline'u, wynik trafia do rekordu, a strategia potrzebująca kolejnego podejścia przechodzi cały tor przeszkód od nowa — z nowymi oknami włącznie. Musi zachować co najmniej 70% Sharpe'a out-of-sample z walk-forward i nie ma drugiego rzutu tą kostką.
Sygnał, który przetrwa wszystkie trzy
Zanim cokolwiek z tego się wydarzy, robimy zwykły przegląd wrażliwości: ruszamy każdy parametr o ±20% i patrzymy na metryki. Prawdziwa przewaga degraduje się łagodnie; przypadek spada z klifu. To najtańszy test w całym pipelinie i wetuje strategie, które przepłynęłyby przez wszystko powyżej — bo klif parametryczny to właśnie tak wygląda przeoptymalizowanie, zanim dasz mu szansę ukryć się w maszynerii walidacyjnej.
Nic z tego nie czyni optymalizacji bezpieczną. Sprawia jedynie, że tryby awarii stają się głośne — a to najwięcej, czego można uczciwie oczekiwać od procesu walidacji.
← Wszystkie wpisy