Optimizarea walk-forward are reputația de a fi metoda onestă de a regla o strategie și o merită — comparativ cu a optimiza pe toate datele și a admira rezultatul. Dar tehnica are moduri de eșec discrete, iar fiecare produce același artefact: un raport de validare care spune „robust", capsat de o strategie care nu este. Iată cele trei împotriva cărora a trebuit să ne apărăm prin inginerie, organizate după dezastrul pe care îl lasă în urmă.
Eșecul unu: ferestrele se scurg una în alta
Varianta greșită: reglezi pe ianuarie-iunie, validezi pe iulie, apoi lași orice din iulie să influențeze o a doua trecere — o re-rulare după ce ai văzut cifra out-of-sample, o „mică ajustare" a grilei de parametri, o caracteristică normalizată pe toată seria. Fiecare pare inofensivă. Împreună, transformă fereastra out-of-sample în date in-sample cu întârziere.
Dezastrul: un Sharpe out-of-sample care urmărește misterios Sharpe-ul in-sample. Rezultatele out-of-sample reale sunt zgomotoase și dezamăgitoare; o relație IS/OOS suspect de netedă înseamnă că informația curge înapoi. Urmărim raportul explicit — in-sample mai mare de 3x față de out-of-sample marchează rularea, iar un out-of-sample zero sau negativ o omoară, oricât de frumos ar arăta in-sample.
Eșecul doi: alegerea convenabilă a metricii între ferestre
Rulezi trei ferestre walk-forward, obții trei rezultate zgomotoase, apoi le rezumi: Sharpe mediu? Median? Elimini cea mai proastă fereastră invocând o „schimbare de regim"? Fiecare alegere e un grad de libertate, iar un optimizator hotărât (om sau bayesian) va găsi rezumatul sub care strategia asta arată cel mai bine. Șaptezeci și cinci de încercări Optuna per fereastră înseamnă șaptezeci și cinci de ocazii de a fita zgomot, înmulțite cu câte rezumate ești dispus să iei în calcul.
Dezastrul: o strategie care trece validarea și apoi livrează în realitate performanța celei mai proaste ferestre, pentru că fereastra cea mai proastă era singura onestă. Regula noastră: agregarea e fixată în config înainte de rulare, bugetul de încercări e fixat, iar analistul citește rezultatele per fereastră cu dispersia afișată. O strategie care are nevoie de rezumatul prietenos ca să treacă nu trece.
Eșecul trei: holdout-ul care a încetat să mai fie holdout
Un holdout funcționează exact o dată. A doua oară când o strategie e evaluată pe el — după o mică ajustare de parametru, o modificare de semnal, un „hai să verificăm doar" — nu mai e holdout; e un set de validare lent. Cincisprezece zile neatinse par banal de păstrat, până apare presiunea iterării și re-verificarea începe să pară inofensivă.
Dezastrul e subtil: rezultate pe holdout care se îmbunătățesc de la o iterație la alta a aceleiași strategii. Datele out-of-sample proaspete nu au niciun motiv să răsplătească iterația a treia mai mult decât prima, iar când o fac, holdout-ul a fost exploatat. Impunem regula „o singură dată" mecanic: holdout-ul evaluează o dată per rulare de pipeline, rezultatul se scrie în evidență, iar o strategie care are nevoie de o altă încercare trece din nou prin tot traseul — ferestre noi cu tot. Trebuie să păstreze cel puțin 70% din Sharpe-ul out-of-sample walk-forward și nu există o a doua aruncare a zarului.
Semnul care supraviețuiește tuturor celor trei
Înainte de toate acestea, rulăm o baleiere simplă de sensibilitate: împingem fiecare parametru cu ±20% și urmărim metricile. Un avantaj real se degradează treptat; o coincidență cade în prăpastie. E cel mai ieftin test din pipeline și respinge strategii care ar fi trecut lin prin tot ce e mai sus — pentru că un prag abrupt pe un parametru e exact cum arată supraoptimizarea înainte să-i dai ocazia să se ascundă în mașinăria de validare.
Nimic din toate astea nu face optimizarea sigură. Face însă modurile de eșec zgomotoase — iar asta e maximul pe care îl poți cere onest de la un proces de validare.
← Toate articolele