【要約】競馬予想 ML でデータリーケージを正攻法で潰した話 — race_date フィルタを4箇所に入れて気づいたこと [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
UmaScoreの開発者が、バックテストの評価指標が現実離れして高すぎる問題に直面した。原因は、学習データに未来の情報が混入するデータリーケージであった。この問題は、時系列予測において評価指標を過大評価させ、実運用での失敗を招く致命的なバグとなる。
- ・走力指数の算出に、予測対象レース以降の走破タイムが混入する。
- ・コース実績の集計に、予測対象レース当日以降のデータが含まれる。
- ・血統情報のJOIN時に、結合先テーブルの未来データが混入する。
- ・推論関数への日付引数の渡し忘れが発生する。
// Approach
開発者は、集計クエリのWHERE句に必ず
race_date < ? を挿入する単一の規律を導入した。これにより、あらゆる集計経路で未来情報の混入を物理的に遮断する。- ・
calculate_base_ability_index関数にて、SQLのWHERE句に日付フィルタを実装。 - ・コース実績集計時、空間軸（距離）と時間軸（日付）の両面でフィルタを適用。
- ・血統情報のJOINクエリにおいて、結合先テーブルの
race_dateを明示的に制限。 - ・推論パイプラインの入口で
race_dateを一度だけ取得し、各関数へ一貫して渡す。 - ・呼び出し箇所を1ファイルに集約し、引数の渡し忘れを防止する。
// Result
リーク防止策を適用した結果、バックテストの数値が現実的な範囲に収まった。これにより、モデルの真の性能を把握することが可能となった。
- ・EV >= 1.5 戦略において、16ヶ月間の回収率が118.4%を記録。
- ・月次での収支変動（プラス10ヶ月、マイナス6ヶ月）を含む、実運用に近い挙動を確認。
- ・「数値が下がることは、モデルの品質確認として正常である」という評価基準を確立。
- ・フォワードテストの公開により、実運用とのギャップ検証フェーズへ移行。
Senior Engineer Insight
> 時系列MLにおいて、リークは「注意」で防げるものではなく「仕組み」で防ぐべき問題である。本記事の「JOIN先の時間軸も独立して制限する」という規律は、複雑なリレーショナルデータを取り扱う現場で極めて重要だ。実装コストは増すが、バックテストと実運用の乖離を防ぐための必須投資といえる。