Walk-forward-optimalisatie staat bekend als de eerlijke manier om een strategie af te stemmen, en die reputatie is terecht — vergeleken met optimaliseren op álle data en het resultaat bewonderen. Maar de techniek heeft stille faalmodi, en elk ervan levert hetzelfde product op: een validatierapport dat "robuust" zegt, vastgeniet aan een strategie die dat niet is. Dit zijn de drie waartegen wij hebben moeten bouwen, geordend naar de ravage die ze achterlaten.
Faalmodus één: de vensters lekken
De verkeerde aanpak: afstemmen op januari–juni, valideren op juli, en vervolgens iets uit juli laten doorwerken in een tweede ronde — een herhaalde run nadat je het out-of-sample-getal hebt gezien, een "kleine aanpassing" aan het parametergrid, een feature die genormaliseerd is over de volledige reeks. Elk voor zich ziet er onschuldig uit. Samen maken ze van het out-of-sample-venster in-sample data met vertraging.
De ravage: een out-of-sample Sharpe die op mysterieuze wijze de in-sample Sharpe volgt. Echte out-of-sample-resultaten zijn rommelig en teleurstellend; een verdacht gladde IS/OOS-verhouding betekent dat er informatie achterwaarts stroomt. Wij bewaken die ratio expliciet — in-sample meer dan 3x out-of-sample markeert de run, en een out-of-sample van nul of lager maakt hem af, hoe fraai in-sample er ook uitziet.
Faalmodus twee: metrics shoppen over vensters heen
Draai drie walk-forward-vensters, krijg drie rommelige resultaten en vat ze dan samen: gemiddelde Sharpe? Mediaan? Het slechtste venster laten vallen wegens "regimewissel"? Elke keuze is een vrijheidsgraad, en een vastberaden optimizer (mens of bayesiaans) vindt heus wel de samenvatting waaronder deze strategie er het best uitziet. Vijfenzeventig Optuna-trials per venster zijn vijfenzeventig kansen om ruis te fitten, maal het aantal samenvattingen dat je bereid bent te overwegen.
De ravage: een strategie die de validatie doorstaat en vervolgens live de prestatie van het slechtste venster levert, omdat dat slechtste venster het enige eerlijke was. Onze regel: de aggregatie ligt vóór de run vast in config, het trial-budget ligt vast, en de analist leest de resultaten per venster inclusief de spreiding. Een strategie die de vriendelijke samenvatting nodig heeft om te slagen, slaagt niet.
Faalmodus drie: de holdout die er geen meer was
Een holdout werkt precies één keer. De tweede keer dat een strategie eraan wordt getoetst — na een parameterduwtje, een signaalaanpassing, een "even checken" — is het geen holdout meer; het is een trage validatieset. Vijftien onaangeroerde dagen bewaren klinkt triviaal, tot de iteratiedruk komt en nog een keer checken onschuldig aanvoelt.
De ravage is subtiel: holdout-resultaten die beter worden over iteraties van dezelfde strategie heen. Verse out-of-sample-data heeft geen enkele reden om iteratie drie te belonen boven iteratie één, en als dat tóch gebeurt, is de holdout uitgemolken. Wij dwingen eenmaligheid mechanisch af: de holdout evalueert één keer per pipeline-run, het resultaat gaat de administratie in, en een strategie die nog een poging wil, gaat opnieuw door het hele parcours — nieuwe vensters en al. Hij moet minstens 70% van de walk-forward out-of-sample Sharpe behouden, en die dobbelsteen rolt geen tweede keer.
Het signaal dat alle drie overleeft
Nog vóór dit alles draaien we een simpele gevoeligheidssweep: elke parameter ±20% verschuiven en kijken wat de metrics doen. Een echte edge degradeert geleidelijk; toeval valt van een klif. Het is de goedkoopste test in de pipeline en hij blokkeert strategieën die overal hierboven moeiteloos doorheen waren gezeild — want een parameterklif is hoe overfitting eruitziet voordat je het de kans hebt gegeven zich te verstoppen in de validatiemachinerie.
Niets hiervan maakt optimalisatie veilig. Het maakt de faalmodi luidruchtig — en dat is het meeste wat je eerlijk gezien van een validatieproces mag vragen.
← Alle artikelen