Walk-forward-optimering har rykte om sig att vara det ärliga sättet att trimma en strategi, och det ryktet är förtjänat — jämfört med att optimera på all data och sedan beundra resultatet. Men tekniken har tysta felmoder, och var och en producerar samma artefakt: en valideringsrapport som säger "robust" häftad vid en strategi som inte är det. Här är de tre vi har fått konstruera oss runt, sorterade efter vraket de lämnar efter sig.
Fel ett: fönstren läcker
Det felaktiga tillvägagångssättet: trimma på januari–juni, validera på juli, och låt sedan något från juli påverka en andra omgång — en omkörning efter att ha sett out-of-sample-siffran, en "liten justering" av parametergridden, en feature som normaliserats över hela serien. Var för sig ser de oskyldiga ut. Tillsammans förvandlar de out-of-sample-fönstret till in-sample-data med fördröjning.
Vraket: en out-of-sample-Sharpe som mystiskt följer in-sample-Sharpe. Riktiga out-of-sample-resultat är stökiga och nedslående; ett misstänkt jämnt IS/OOS-förhållande betyder att information flödar baklänges. Vi bevakar kvoten explicit — in-sample mer än 3x out-of-sample flaggar körningen, och out-of-sample på eller under noll dödar den oavsett hur fint in-sample ser ut.
Fel två: mätvärdesshopping mellan fönster
Kör tre walk-forward-fönster, få tre stökiga resultat och sammanfatta sedan: medelvärdes-Sharpe? Median? Stryka det sämsta fönstret på grund av "regimskifte"? Varje val är en frihetsgrad, och en tillräckligt målmedveten optimerare (mänsklig eller bayesiansk) hittar den sammanfattning där just den här strategin ser bäst ut. Sjuttiofem Optuna-försök per fönster är sjuttiofem chanser att anpassa sig till brus, gånger hur många sammanfattningar du är villig att överväga.
Vraket: en strategi som klarar valideringen och sedan levererar det sämsta fönstrets prestanda i skarpt läge, eftersom det sämsta fönstret var det enda ärliga. Vår regel: aggregeringen fastställs i konfigurationen före körningen, försöksbudgeten är fast, och analytikern läser resultat per fönster med spridningen synlig. En strategi som behöver den snälla sammanfattningen för att klara sig, klarar sig inte.
Fel tre: holdouten som slutade vara en holdout
En holdout fungerar exakt en gång. Andra gången en strategi utvärderas mot den — efter en parameterjustering, en signaljustering, ett "vi kollar bara snabbt" — är den inte längre en holdout; den är ett långsamt valideringsset. Femton orörda dagar låter trivialt att bevara ända tills iterationstrycket kommer och en till koll känns ofarlig.
Vraket är subtilt: holdout-resultat som förbättras över iterationer av samma strategi. Färsk out-of-sample-data har ingen anledning att belöna iteration tre framför iteration ett, och när den gör det har holdouten brutits. Vi upprätthåller engångsprincipen mekaniskt: holdouten utvärderas en gång per pipelinekörning, resultatet skrivs till journalen, och en strategi som behöver ett nytt försök får gå igenom hela spögatan igen — nya fönster och allt. Den måste behålla minst 70% av walk-forward-körningens out-of-sample-Sharpe, och det finns inget andra tärningskast.
Kännetecknet som överlever alla tre
Före allt detta kör vi ett rakt känslighetssvep: knuffa varje parameter ±20% och se på mätvärdena. En verklig edge degraderas mjukt; ett sammanträffande faller utför ett stup. Det är det billigaste testet i pipelinen och det lägger in veto mot strategier som hade seglat igenom allt ovanstående — för ett parameterstup är hur överanpassning ser ut innan du gett den en chans att gömma sig i valideringsmaskineriet.
Inget av detta gör optimering säker. Det gör felmoderna högljudda — vilket är det mesta man ärligt kan begära av en valideringsprocess.
← Alla inlägg