A walk-forward optimalizálásnak az a híre, hogy ez a stratégiahangolás becsületes módja — és ezt meg is érdemli, legalábbis ahhoz képest, hogy az összes adaton optimalizálunk, majd megcsodáljuk az eredményt. A technikának azonban vannak csendes hibamódjai, és mindegyik ugyanazt a végterméket állítja elő: egy validációs jelentést, amire az van írva, hogy „robusztus", odatűzve egy stratégiához, amelyik nem az. Íme az a három, amely ellen mérnöki munkával kellett védekeznünk, aszerint rendezve, hogy milyen roncsot hagynak maguk után.
Első hibamód: szivárognak az ablakok
A rossz megközelítés: hangolás januártól júniusig, validálás júliuson, majd hagyjuk, hogy bármi júliusból befolyásolja a második kört — újrafuttatás azután, hogy már láttuk a mintán kívüli számot, egy „apró igazítás" a paraméterrácson, egy olyan feature, amit a teljes idősoron normalizáltunk. Mindegyik ártatlannak tűnik. Együtt viszont késleltetett mintán belüli adattá változtatják a mintán kívüli ablakot.
A roncs: mintán kívüli Sharpe, amely rejtélyes módon együtt mozog a mintán belülivel. A valódi mintán kívüli eredmények zajosak és kiábrándítóak; a gyanúsan sima IS/OOS viszony azt jelenti, hogy az információ visszafelé áramlik. Az arányt kifejezetten figyeljük — ha a mintán belüli több mint 3-szorosa a mintán kívülinek, az megjelöli a futást, és a nullán vagy az alatt lévő mintán kívüli eredmény kivégzi, bármilyen szép is a mintán belüli.
Második hibamód: metrikavadászat az ablakok között
Lefuttatunk három walk-forward ablakot, kapunk három zajos eredményt, aztán összegzünk: átlagos Sharpe? Medián? Dobjuk ki a legrosszabb ablakot „rezsimváltásra" hivatkozva? Minden döntés egy szabadsági fok, és egy elszánt optimalizáló (ember vagy bayesi) meg fogja találni azt az összegzést, amelyben ez a stratégia a legjobban fest. Ablakonként hetvenöt Optuna-próba hetvenöt lehetőség a zaj illesztésére — szorozva azzal, ahány összegzést hajlandók vagyunk mérlegelni.
A roncs: egy stratégia, amely átmegy a validáción, aztán élesben a legrosszabb ablak teljesítményét hozza, mert a legrosszabb ablak volt az egyetlen őszinte. A mi szabályunk: az aggregáció a futás előtt rögzítve van a konfigban, a próbakeret rögzített, az elemző pedig ablakonkénti eredményeket olvas, a szórással együtt kimutatva. Az a stratégia, amelynek a barátságos összegzés kell az átmenéshez, nem megy át.
Harmadik hibamód: a holdout, amely megszűnt annak lenni
Egy holdout pontosan egyszer működik. Amikor másodszor is kiértékelünk vele egy stratégiát — egy paraméterigazítás, egy jelfinomítás, egy „csak megnézzük" után —, az már nem holdout, hanem lassított validációs halmaz. Tizenöt érintetlen nap megőrzése triviálisnak hangzik, egészen addig, amíg meg nem érkezik az iterációs nyomás, és az újraellenőrzés ártalmatlannak nem tűnik.
A roncs finom: holdout-eredmények, amelyek ugyanannak a stratégiának az iterációi során javulnak. Friss mintán kívüli adatnak semmi oka nincs a harmadik iterációt az elsővel szemben jutalmazni, és ha mégis megteszi, akkor a holdoutot kibányászták. Az egyszeri használatot gépiesen kényszerítjük ki: a holdout pipeline-futásonként egyszer értékel, az eredmény bekerül a nyilvántartásba, és az a stratégia, amelynek újabb nekifutás kell, végigmegy az egész akadálypályán — új ablakokkal együtt. Meg kell tartania a walk-forward mintán kívüli Sharpe legalább 70%-át, és azt a kockát nem lehet újra elgurítani.
Az árulkodó jel, amely mindhármat túléli
Mindezek előtt lefuttatunk egy egyszerű érzékenységi sweepet: minden paramétert elmozdítunk ±20%-kal, és nézzük a metrikákat. A valódi edge fokozatosan romlik; a véletlen egybeesés leesik a szikláról. Ez a pipeline legolcsóbb tesztje, és megvétóz olyan stratégiákat, amelyek a fenti mindenen simán átcsúsztak volna — mert a paraméterszikla az, ahogy a túlillesztés kinéz, mielőtt esélyt adtunk volna neki, hogy elbújjon a validációs gépezetben.
Ettől még az optimalizálás nem lesz biztonságos. Attól lesz, hogy a hibamódok hangosak — és ennél többet őszintén nem is lehet elvárni egy validációs folyamattól.
← Összes bejegyzés