【要約】バックテストを78%削減した — LightGBMサロゲートモデルで仮想通貨Bot候補を事前フィルタリングする実装 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
筆者が運用するGMO coin向けシステムにおいて、バックテストがボトルネックとなっている。
- 毎夜15の戦略候補を生成し、IS/OOS評価を実施している。
- しかし、合格率は約2.75%と極めて低い。
- つまり、97.25%の候補はバックテストを実行しても不合格となる。
- この不合格な候補への計算リソース投入が、開発の大きな損失となっている。
- 計算コストを削減できれば、同じ計算資源でより多くの候補を探索できるはずである。
- 現状では、合格しない97本のBT時間が丸ごと無駄になっている。
- 毎夜15の戦略候補を生成し、IS/OOS評価を実施している。
- しかし、合格率は約2.75%と極めて低い。
- つまり、97.25%の候補はバックテストを実行しても不合格となる。
- この不合格な候補への計算リソース投入が、開発の大きな損失となっている。
- 計算コストを削減できれば、同じ計算資源でより多くの候補を探索できるはずである。
- 現状では、合格しない97本のBT時間が丸ごと無駄になっている。
// Approach
筆者は、過去のBT結果を学習し、実行前に候補を絞るサロゲートモデルを採用した。
- 特徴量として、戦略タイプ、通貨ペア、時間足の3つのカテゴリ変数のみを使用。
- LightGBMを用い、scale_pos_weightで不均衡データに対応。
- 閾値を0.30と低く設定し、合格候補を見逃さない再現率重視の設計とした。
- これにより、安価な予測で事前に候補をフィルタリングする仕組みを構築した。
- 精度よりも、合格候補を逃さないことを最優先している。
- BT前の時点ではBT結果は存在しないため、構造的なパターンを学ぶ設計とした。
- 特徴量として、戦略タイプ、通貨ペア、時間足の3つのカテゴリ変数のみを使用。
- LightGBMを用い、scale_pos_weightで不均衡データに対応。
- 閾値を0.30と低く設定し、合格候補を見逃さない再現率重視の設計とした。
- これにより、安価な予測で事前に候補をフィルタリングする仕組みを構築した。
- 精度よりも、合格候補を逃さないことを最優先している。
- BT前の時点ではBT結果は存在しないため、構造的なパターンを学ぶ設計とした。
// Result
この手法を導入した結果、計算リソースの浪費を抑え、探索効率を劇的に向上させた。
- 候補の78.5%をバックテスト前に棄却。
- 合格候補の再現率は100%を維持。
- 探索効率が理論上約5倍向上した。
- 15の候補に対し、実際に実行するバックテストは約3.2件まで削減された。
- 蓄積されるデータ量が増えるほど、モデルの精度向上も期待できる。
- 閾値0.30の設定により、合格候補を1本も見逃さない運用を実現した。
- 候補の78.5%をバックテスト前に棄却。
- 合格候補の再現率は100%を維持。
- 探索効率が理論上約5倍向上した。
- 15の候補に対し、実際に実行するバックテストは約3.2件まで削減された。
- 蓄積されるデータ量が増えるほど、モデルの精度向上も期待できる。
- 閾値0.30の設定により、合格候補を1本も見逃さない運用を実現した。
Senior Engineer Insight
> 計算コストの高いシミュレーションを伴う開発において、精度を捨てて再現率を優先する設計は極めて実戦的である。合格候補を逃さないことで探索の質を担保しつつ、無駄な計算を削る思想はスケーラビリティ確保の定石だ。ただし、pickleによるモデルの受け渡しは、実行環境のライブラリ依存という運用リスクを伴う。CI/CDやデプロイフローにおいて、依存関係の整合性を厳格に管理することが実戦投入の条件となる。