Walk-forward-optimalisering har rykte på seg for å være den redelige måten å finjustere en strategi på, og det fortjener den — sammenlignet med å optimalisere på alle dataene og beundre resultatet. Men metoden har stille feilmoduser, og hver av dem gir samme utslag: en valideringsrapport som sier «robust», heftet sammen med en strategi som ikke er det. Her er de tre vi har måttet bygge beskyttelse mot, ordnet etter skadene de etterlater.
Feil én: vinduene lekker
Feil fremgangsmåte: finjuster på januar–juni, valider på juli, og la deretter noe fra juli påvirke en ny runde — en ny kjøring etter at du har sett out-of-sample-tallet, en «liten justering» av parametergridet eller en variabel normalisert over hele serien. Hver ting virker uskyldig. Samlet gjør de out-of-sample-vinduet til in-sample-data med forsinkelse.
Skaden: out-of-sample-Sharpe som på mystisk vis følger in-sample-Sharpe. Reelle out-of-sample-resultater er støyete og skuffende; et mistenkelig jevnt IS/OOS-forhold betyr at informasjon lekker bakover. Vi følger forholdstallet eksplisitt — in-sample på mer enn 3x out-of-sample flagger kjøringen, og out-of-sample på eller under null forkaster den uansett hvor pent in-sample ser ut.
Feil to: måltallshopping på tvers av vinduer
Kjør tre walk-forward-vinduer, få tre støyete resultater, og oppsummer så: gjennomsnittlig Sharpe? Median? Droppe det dårligste vinduet på grunn av «regimeskifte»? Hvert valg gir en ny frihetsgrad, og en målbevisst optimizer (menneskelig eller bayesiansk) finner oppsummeringen som får strategien til å se best ut. Syttifem Optuna-forsøk per vindu gir syttifem muligheter til å tilpasse seg støy, ganget med så mange oppsummeringer som du vil vurdere.
Skaden: en strategi som består valideringen, men deretter leverer resultatet fra det dårligste vinduet i livehandel, fordi det dårligste vinduet var det eneste ærlige. Vår regel: Aggregeringen fastsettes i konfigurasjonen før kjøringen, forsøksbudsjettet er fast, og analytikeren leser resultatene per vindu med spredningen synlig. En strategi som trenger den vennligsinnede oppsummeringen for å bestå, består ikke.
Feil tre: holdouten som sluttet å være en holdout
En holdout fungerer nøyaktig én gang. Andre gang en strategi evalueres mot den — etter en parameterjustering, en signalendring eller et «la oss bare sjekke» — er den ikke lenger en holdout; den er et langsomt valideringssett. Femten urørte dager høres enkelt ut å bevare helt til presset om å iterere melder seg, og en ny sjekk virker harmløs.
Skaden er subtil: holdout-resultater som blir bedre gjennom iterasjoner av samme strategi. Nye out-of-sample-data har ingen grunn til å belønne iterasjon tre fremfor iterasjon én, og når det skjer, har holdouten blitt utvunnet. Vi håndhever engangsevaluering mekanisk: holdouten evalueres én gang per pipeline-kjøring, resultatet føres inn i loggen, og en strategi som trenger et nytt forsøk, går gjennom hele løpet på nytt — med nye vinduer og alt. Den må beholde minst 70% av walk-forward-out-of-sample-Sharpe, og det blir ingen ny sjanse.
Tegnet som består alle tre testene
Før alt dette kjører vi en enkel følsomhetstest: juster hver parameter med ±20% og følg med på måltallene. En reell fordel svekkes gradvis; et sammentreff stuper. Det er den billigste testen i pipelinen, og den setter veto mot strategier som ellers ville ha kommet seg gjennom alt ovenfor — for et parameterstup er slik overtilpasning ser ut før du har gitt den sjansen til å skjule seg i valideringsopplegget.
Ingenting av dette gjør optimalisering trygg. Det gjør feilmodusene tydelige — det meste du med ærlighet kan forvente av en valideringsprosess.
← Alle innlegg
