Walk-forward optimeerimisel on maine kui ausal viisil strateegiat häälestada, ja see maine on välja teenitud — vähemalt võrreldes sellega, kui optimeerid kõigi andmete peal ja imetled tulemust. Kuid tehnikal on vaikseid vearežiime ja igaüks neist toodab sama artefakti: valideerimisraporti, millel seisab "robustne", klammerdatuna strateegia külge, mis seda ei ole. Siin on kolm, mille vastu oleme pidanud insenertööd tegema, järjestatuna selle järgi, millise laastamistöö nad maha jätavad.
Viga üks: aknad lekivad
Vale tee: häälesta jaanuar-juuni peal, valideeri juuli peal ja lase siis millelgi juulist mõjutada teist ringi — kordusjooks pärast out-of-sample numbri nägemist, "väike näpuotsaga muudatus" parameetrivõrgus, tunnus, mis on normaliseeritud kogu seeria ulatuses. Iga üksik neist näib süütu. Koos muudavad nad out-of-sample akna viivitusega in-sample andmeteks.
Laastamistöö: out-of-sample Sharpe, mis salapärasel kombel järgib in-sample Sharpe't. Päris out-of-sample tulemused on mürarikkad ja pettumust valmistavad; kahtlaselt sile IS/OOS suhe tähendab, et info voolab tagurpidi. Me jälgime seda suhet eksplitsiitselt — in-sample üle 3x out-of-sample märgistab jooksu ja out-of-sample nullis või alla selle tapab selle sõltumata sellest, kui ilus in-sample välja näeb.
Viga kaks: mõõdikute valimine üle akende
Jooksuta kolm walk-forward akent, saa kolm mürarikast tulemust ja tee siis kokkuvõte: keskmine Sharpe? Mediaan? Viska halvim aken välja, sest "režiim muutus"? Iga selline valik on vabadusaste ja otsustavalt meelestatud optimeerija (inimene või Bayesi oma) leiab selle kokkuvõtte, mille all see strateegia parim välja näeb. Seitsekümmend viis Optuna katsetust akna kohta on seitsekümmend viis võimalust müra külge sobitada, korrutatuna sellega, mitut kokkuvõtet oled valmis kaaluma.
Laastamistöö: strateegia, mis läbib valideerimise ja pakub siis live'is halvima akna tootlust, sest halvim aken oli ainus aus. Meie reegel: agregeerimine fikseeritakse konfiguratsioonis enne jooksu, katsetuste eelarve on fikseeritud ja analüütik loeb aknapõhiseid tulemusi koos näidatud hajuvusega. Strateegia, mis vajab läbisaamiseks sõbralikku kokkuvõtet, ei saa läbi.
Viga kolm: holdout, mis lakkas holdout olemast
Holdout töötab täpselt üks kord. Teine kord, kui strateegiat selle vastu hinnatakse — pärast parameetri nügimist, signaali näpuotsaga muutmist, "vaatame lihtsalt korraks üle" — ei ole see enam holdout; see on aeglane valideerimishulk. Viisteist puutumata päeva tundub triviaalselt lihtne säilitada, kuni saabub iteratsioonisurve ja ülekontrollimine hakkab tunduma kahjutu.
Laastamistöö on peen: holdout-tulemused, mis sama strateegia iteratsioonide lõikes paranevad. Värsketel out-of-sample andmetel pole mingit põhjust premeerida kolmandat iteratsiooni esimese ees, ja kui nad seda teevad, on holdout läbi kaevandatud. Me jõustame ühekordsuse mehaaniliselt: holdout hindab üks kord pipeline'i jooksu kohta, tulemus kirjutatakse kirjesse ja strateegia, mis vajab uut katset, läheb tagasi läbi kogu kadalipu — uute akendega ja kõigega. See peab säilitama vähemalt 70% walk-forward out-of-sample Sharpe'ist ja seda täringut teist korda ei veereta.
Äratundmismärk, mis peab vastu kõigile kolmele
Enne kõike seda teeme lihtsa tundlikkusläbimängu: nügi iga parameetrit ±20% ja vaata mõõdikuid. Päris eelis laguneb sujuvalt; juhus kukub kaljult alla. See on pipeline'i odavaim test ja see paneb veto strateegiatele, mis oleksid kõigest ülalpool kirjeldatust läbi purjetanud — sest parameetrikalju on see, milline ülesobitamine välja näeb enne, kui oled andnud talle võimaluse valideerimismasinavärgis peitu pugeda.
Miski sellest ei tee optimeerimist ohutuks. See teeb vearežiimid valjuks — ja see on kõige rohkem, mida valideerimisprotsessilt ausalt küsida saab.
← Kõik postitused