第6回関東kaggler会資料: 時系列コンペのtips / tips of time-series kaggle competition

第6回関東kaggler会資料: 時系列コンペのtips

Transcript

1. 第6回関東kaggler会 LT資料: 時系列コンペのtips 望月 正弘 2026/8/7
2. 自己紹介 • 望月 正弘 (Masahiro Mochizuki) / m_mochizuki • Kaggle Competition Master • 博士 (理学) • 専門は分子生物学、バイオインフォマティクス、データサイエンス • 今の所属はアヘッド・バイオコンピューティング株式会社 • 過去に参加した時系列コンペ (一部): • (SIGNATE)日本取引所グループ ファンダメンタルズ分析チャレンジ: 1位 • (SIGNATE)第２回NEXCO東日本 渋滞予測チャレンジコンテスト: 19 位 • G-Research Crypto Forecasting: 31位 • JPX Tokyo Stock Exchange Prediction: 32位 • 今やっているコンペ: • AI Agent Security - Multi-Step Tool Attacks ←何も分からん
3. 時系列コンペとその魅力 • ここでは、過去の履歴から未来を予測するコードコンペを指して、 時系列コンペと呼ぶ。 • 典型的には、株式やコモディティ等のマーケット予測 • マーケット以外だと、SIGNATEの渋滞予測コンペとかもほぼ当てはまる。 • おことわり: 本日の話がすべての”時系列コンペ”に当てはまるとは限らない。 • 私の考える時系列コンペの魅力: 1. 未来というホストも含めて誰にも知り得ないことをめぐる競争であること。 2. マーケット系のタスクの場合には、市場の効率性のために予測の難易度が高く、 挑戦し甲斐があること。 3. 評価期間に自分のモデルの予測の途中経過を観戦できること
4. 時系列コンペに潜む罠の数々 罠1: Public LBが当てにならないことがある。 罠2: 時系列的なリークが起こりやすい。 罠3: Deadline後の評価期間にエラーでまさかの脱落。(私は脱落したことありません。) 罠3: Deadline後の評価期間にエラーでまさかの脱落。(大事なことなので2回。) Deadline後のdiscussionを読むと、これらの罠に引っかかっているっぽい人が散見。 逆にいえば、これらをすべて回避すればそこそこ上位にいけるかも?
5. 罠1: Public LBが当てにならないことがある • 普通のコンペでは、Public LBの評価用と訓練用に提供されるデータは重複しないことが 一般的。 • 時系列コンペでは、Public LBの評価用データが訓練用データに包含されていることがあ る。 • その結果リークによって、現実にはありえない高精度のスコアがLB上位に並ぶことになりがち。 時間の流れ 提供されたデータ Public LBデータ Private LB データ • したがって、時系列コンペでは”Trust CV”の精神がより重要になる。
6. 当てにならないPublic LBとの向き合い方 時間の流れ 提供されたデータ Public LBデータ Private LB データ • 序盤では、public LBデータ以前のデータのみを訓練に用いることで リークの影響を受けていないスコアを確認するのがおすすめ。 • これがCVのスコアとある程度一致していなければ何かがおかしい。 • 終盤では、全データで訓練することを検討すべき。 • Public LBのスコアは当てにならなくなるが、Private LBでスコアを改善するにはデータが多い方が有 利と考えられる。 • 併せて、 この状況を逆手にとって、ローカルでPublic LBを完全再現できるようにすると メリットあり: • 完全再現することでスコア計算ロジックについての自分の理解が正しいことを確認できる。 • submitしてpublic LBを確認するほぼ必要がなくなるので、submit数を節約できる。
7. 罠2: 時系列的なリークが起こりやすい • 未来の情報を予測に使うと時系列特有のリークが起きる。 • このリークを起こさないためには、下記の2原則を遵守する必要がある。 原則1: バリデーションにおいて、訓練データはテストデータよりも過去になるように分割すること。 時間の流れ 訓練データ テストデータ 原則2: 訓練データであれテストデータであれ、特徴量生成において、現在か過去の情報のみ参照すること。 • 原則1は比較的簡単に遵守できるが、原則2は行を跨いだ処理を多用すると、 うっかり破りがち。
8. リークしない時系列特徴量の作り方 • 行をまたぐ処理は時系列的にリークする恐れがある。 • 時系列順に昇順ソートしてから処理するのが大前提。 • DataFrameにmean()等の集約関数をそのまま適用するのはだいたい危ない。 • 代わりにrolling().mean()やexpanding().mean()等を使うと簡潔かつリークしない集約 が可能になる。 • 標準化なども内部的にmeanやstdを使っているので、 rollingやexpandingを組み合わせ て自前で計算する必要がある。 標準化後 = (x - expand_mean) / expand_std 標準化前 expand_mean expand_std 2026-07-06 912 912.0 NaN NaN 2026-07-07 765 838.5 103.9 -0.7071 2026-07-08 671 782.7 121.5 -0.9193 2026-07-09 801 787.3 99.6 0.1381 日付
9. 罠3: Deadline後の評価期間にエラーで脱落 • 例えばMITSUI&CO. Commodity Prediction Challengeでは、最終ラウンドまでに 3割以上の参加者が脱落していた。非常にもったいない。 • データ依存で一定頻度で発生するエラーは、 public LBで発現しなくても、private LBで 運悪く発生する場合があるというのがポイント • 初歩的なバグであっても、deadline後にはデバックできないので、クリティカルになる。 主なエラーの原因と対策 原因 対策 特徴量のカラム構成・順序の訓練時からの変化 (後述) 訓練時のカラムの構成と順番を保持しておいて、 推論時も変化がないようにする。 各特徴量のdtypeの訓練時からの変化 (特にdeep learningの場合にクリティカル) 変化する場合があるので、明示的にcastする。 Mixed typeが生じないように前処理する。 予期せぬ欠損値の発生 (欠損を許容しないモデルでクリティカル) 欠損値が生じる可能性がある場合には補間処理 を予防的に入れる。 RAM不足・制限時間違反 Private LBの評価時に最大のRAM使用量と処理 時間を見積もって、収まるように調整する。
10. 特徴量のカラム構成の訓練時からの変化する例 One-hot vector 生データ 日付 訓練と public LB時 日付 1Q 2Q 3Q FY 2024-08-10 1Q 2024-08-10 1 0 0 0 2024-11-11 2Q 2024-11-11 0 1 0 0 2025-02-09 3Q 2025-02-09 0 0 1 0 2025-05-11 FY 2025-05-11 0 0 0 1 日付 Private LBで エラーとなる例 会計期間の種類 会計期間の種類 日付 1Q 2Q 3Q 4Q FY 2025-08-09 1Q 2025-08-09 1 0 0 0 0 2025-11-11 2Q 2025-11-11 0 1 0 0 0 2026-02-10 3Q 2026-02-10 0 0 1 0 0 2026-05-11 4Q 2026-05-11 0 0 0 1 0 2026-07-20 FY 2026-07-20 0 0 0 0 1 • 上記のようにカラムが増えるケースに加えて、減るケースもエラーになるので注意 • 順番が変わる場合は、エラー or 精度低下
11. 罠2のリークと罠3のエラーに共通の対策としての 特徴生成の試験 特徴生成の一括処理 特徴生成の逐次処理 時間の流れ 生のデータ 特徴量データ • CV時は速度が早い一括処理で訓練データを生成するのが合理的。 • 一方、LBの評価時は、一日ごとに新たなデータが提供されるため、 逐次処理が走ることになる。 • 両者を同一のデータに適用した場合、アウトプットである特徴量データは完全一致するはず。 • 一致しなければリーク等のバグの可能性あり。 • 特に後者でエラーが出たり、速度要件を満たせなければ評価時にエラー発生の可能性あり。 • 提供されたデータセット全体でこの試験をして、バグを出し切ることを推奨。
12. 終
13. おまけ: 時系列コンペのチェックリスト pPublic LBの評価に使われる以前のデータで訓練した場合に、合理的なスコアが得られる ことを確認した。(Public LB期間のデータが提供されている場合) pローカルでPublic LBが再現できることを確認した。 (同上) pデータによらず特徴量のカラム構成と順序が一定となることを確認した。 pデータによらずdtypeが一定となることを確認した。 p欠損値の発生に堅牢なコード・モデルになっていることを確認した。 p特徴生成の一括処理と逐次処理で結果が一致することを確認した。 pprivate LBの評価時にRAMが不足しないであろうことをデータとモデルのRAM使用量の 見積もりから確認した。 pprivate LBの評価が制限時間内に完了するであろうことを逐次処理の速度から確認した。 p想定外の例外が発生したら固定値を予測結果として出力するフェイルセーフの処理を実 装した。