ウォークフォワード最適化は戦略を正直にチューニングする手法だという評判があり、それは妥当だ——全データで最適化して結果に見とれるのに比べれば。しかしこの手法には静かな失敗モードがあり、そのどれもが同じ産物を生む。「ロバスト」と書かれた検証レポートが、ロバストでない戦略にホチキス留めされているのだ。ここでは、我々が対策を組み込まざるを得なかった3つを、残す爪痕ごとに整理して紹介する。
失敗その1: ウィンドウが漏れる
やってはいけない方法。1〜6月でチューニングし、7月で検証し、そのうえで7月の情報が2周目に影響することを許してしまう——アウトオブサンプルの数字を見てからの再実行、パラメータグリッドへの「ちょっとした調整」、系列全体で正規化した特徴量。どれも単体では無害に見える。だが合わさると、アウトオブサンプルのウィンドウは遅れてやってきたインサンプルデータに変わる。
残る爪痕。アウトオブサンプルのSharpeが、なぜかインサンプルのSharpeに追随する。本物のアウトオブサンプル結果はノイジーで期待外れなものだ。IS/OOSの関係が不自然なほど滑らかなら、情報が逆流している。我々はこの比率を明示的に監視している——インサンプルがアウトオブサンプルの3倍を超えればそのランにフラグを立て、アウトオブサンプルがゼロ以下なら、インサンプルがどれだけ美しかろうと却下する。
失敗その2: ウィンドウをまたいだ指標のつまみ食い
ウォークフォワードのウィンドウを3つ回して、ノイジーな結果を3つ得る。さてどうまとめるか。Sharpeの平均? 中央値? 「レジーム転換だから」と最悪のウィンドウを落とす? どの選択も自由度であり、粘り強い最適化器(人間であれベイズであれ)は、この戦略が最も良く見える集計方法を必ず見つけ出す。ウィンドウあたり75回のOptunaトライアルは、ノイズにフィットする機会が75回あるということであり、それに検討する気になった集計方法の数が掛かる。
残る爪痕。検証を通過したのに、ライブでは最悪のウィンドウの成績しか出さない戦略。最悪のウィンドウこそが唯一正直だったからだ。我々のルールはこうだ。集計方法はランの前にconfigで固定し、トライアル予算も固定し、アナリストはウィンドウごとの結果をばらつき込みで読む。都合の良い集計に頼らないと通らない戦略は、通らない。
失敗その3: ホールドアウトでなくなったホールドアウト
ホールドアウトが機能するのはきっかり一度だけだ。ある戦略が二度目に——パラメータを微調整したあと、シグナルをいじったあと、「ちょっと確認するだけ」のあとに——それで評価された時点で、もうホールドアウトではない。動きの遅いバリデーションセットだ。手つかずの15日間を守るなど造作もないように聞こえる。イテレーションの圧力がかかり、再チェックが無害に思えてくるまでは。
爪痕は分かりにくい。同じ戦略のイテレーションを重ねるにつれてホールドアウトの結果が良くなっていく、というものだ。新鮮なアウトオブサンプルデータが、イテレーション1よりイテレーション3を優遇する理由はない。それが起きているなら、ホールドアウトは掘り尽くされている。我々はワンショットを機械的に強制している。ホールドアウトの評価はパイプライン実行あたり一度きり、結果はレコードに書き込まれ、もう一度挑戦したい戦略は関門を丸ごとやり直す——ウィンドウも全部新しくして。ウォークフォワードのアウトオブサンプルSharpeの70%以上を維持しなければならず、そのサイコロを振り直すことはできない。
3つすべてを生き延びる兆候
そのすべてに先立って、我々は素朴な感応度スイープを回す。各パラメータを±20%動かして指標を見るだけだ。本物のエッジはなだらかに劣化する。偶然の産物は崖から落ちる。パイプラインの中で最も安いテストでありながら、上に挙げたすべてを涼しい顔で通過してしまう戦略に拒否権を行使する——パラメータの崖こそ、検証機構の中に隠れる機会を与える前の過剰最適化の姿だからだ。
これで最適化が安全になるわけではない。失敗モードが騒がしくなるだけだ——そしてそれが、検証プロセスに正直に求められる限界でもある。
← 記事一覧