Kaggle M5 Forecasting - Accuracy 42nd place solution

Kaggle M5コンペのSolution紹介@M5コンペ反省会（2020/7/19）

・Competition
https://www.kaggle.com/c/m5-forecasting-accuracy/overview

Transcript

1. Kaggle M5 Forecasting - Accuracy 42nd place solution Shirokane_friends nino_pira shaoroon hiro
2. チーム紹介 – shirokane_friends 2 同じ会社（Brain Pad）のメンバーで結成 にのぴら@nino_pira • 下町データサイエンティスト • テーブル・画像・強化学習 etc 何でもできるすごい人 • Kaggle Expert hiro • 新卒入社 • 学生時代は株価予測の研究 • Kaggle初参戦 しゃおろん@syaorn_13 • 見習いデータサイエンティスト • Brainpadは中途入社（前職はSE） • Kaggle Expert
3. Agenda 3 1. Introduction （はじめに） 1. Comptetition Overview (コンペ概要) 2. Result (結果) 2. Solution（解法） 1. Validation （評価） 2. Feature（特徴量） 3. Model（モデル） 4. Objective（目的関数） 5. Recursive（再帰的予測） 6. Ensemble（アンサンブル） 3. Summary（まとめ） 1. Thoughts（感想） 2. Learned（学び）
4. 1. Introduction（はじめに）
5. ウォルマート（米大手スーパーマーケット）における商品の売上予測 • アメリカの3つの州（10店舗）が対象 • 商品数は30,490 • 提供データは約6年分（2011年~2016年） • 過去の売上 • 価格 • 日付 • イベントの有無 Comptetition Overview （コンペ概要） 5 Input • 将来28日間の売上 Output 典型的な「時系列」の「需要予測」
6. Result（結果） 6 42nd / 5,558 (Top 1%) で銀メダル獲得！ 同時開催のUncertainty（分布予測）でも銀メダルを獲得！（32nd） ※以降の話はAccuracyに関するものです
7. 2. Solution（解法）
8. Validationを決めるため、コンペ初期はEDAに時間をかけた Validation（評価） 8 Privateと相関が高い月（28日） 商品カテゴリ×月ごとの相関チェック 対象3州の天気 類似コンペにおけるValidation調査
9. Validation（評価） 9 Privateの過去3か月がValidationとして最適と判断 • 直近（1~3か月前）が一番Private期間と相関が高かった • 3か月以上だと学習時間が長すぎるので諦めた • 過去のコンペでも同様のValidation手法が多い Private月と相関が高い月（過去4年分の平均） • 直近（1~3か月前）の相関が高い • 1年前の同じ時期の相関は高くない • 季節の影響はさほど大きくない
10. Validation（評価） 10 過去3か月分のWRMSSEを加重平均してValidationとした • 直近の月を重視する形でWeightをつけた（EDAの結果に従った） • 1つの月が良くても、他が悪化するモデルは採用しない Validation CV1 3か月前 Weight1 0.27 CV2 2か月前 Weight2 0.33 CV3 1か月前 Weight3 0.40
11. Feature (特徴量) 11 公開カーネルにあったような、基本的な特徴量がほとんど • 全部で70個ほど • オリジナリティがありそうなのは「カテゴリ内の相対価格」や「イベントまでの日数」など • Magicと言えるほど効果的な特徴量はなかった • 州 • 店舗 • 商品カテゴリ • 商品ID Category • 直近n週間の売上 • 直近nか月の売上 • 前年の同時期の売上 Sales • 現在の価格 • 先週からの価格増減率 • 同一店舗＆カテゴリ内での 相対価格 Price • 月・曜日・日 • 週番号（月） • イベントフラグ • イベントまでの日数 Date
12. Model (モデル) 12 LightGBM & Day by Dayでモデル作成 • recursiveは使わない Content Our Solution Model モデル LightGBM Model split モデルの分割 Day by day Modeling • n日先予測ごとにモデルを分ける • 3fold × 28day = 84model • Store_idやdept_id単位では分けない Objective 目的関数 RMSE • WeightとScaleは別途調整 Data Period データ期間 約4年（2013年~2016年） • 2011年は傾向が違うため使わない • ラグ特徴量で過去1年分使うので、2012年のデータも削除 Preprocess 前処理 売上0期間のデータを削除 • クリスマス • 発売前 ▪モデル概要
13. Objective (目的関数) 13 WRMSSEを（可能な限り）最適化するよう工夫した • WRMSSE = Weigted & Scaled & RMSE • ObjectiveはRMSEを使い、前処理を行ってWeightとScale部分を調整した Scaleは「目的変数 / Scale」で調整 • id単位でscaleを計算 • 学習前に目的変数をScaleで割る Scale RMSE
14. Objective (目的関数) 14 WeightはLightGBMのWeightで調整 • 12Lv全てのWeightを各idに割り当て、idごとに12Lvの平均Weightを計算 • lightgbm.datasetのweightに指定 id（行単位）で weightの平均を計算
15. Recursive (再帰的予測) 15 https://www.kaggle.com/c/m5-forecasting-accuracy/discussion/153963 Recursiveは検証した結果、使うべきではないと判断した • CV1・CV2でのスコアが大幅に下がったため • Recursiveは予測が上振れしやすい可能性 CV1 CV2 CV3 WRMSSE 0.6817 0.6287 0.4915 Good Bad Bad 上位SolutionにRecursiveは存在するので、モデリング次第では有効かもしれない
16. Ensemble (アンサンブル) 16 （大きく分けて）2モデルのアンサンブル • ninopiraモデルとshaoroonモデル • seed変更など細かいものを含めると6モデル CVが一番良くなるEnsembleの割合を調べた • 0.01刻みで調査 • 最終的に「ninopira： shaoroon = 0.24:0.76」になった
17. 3. Summary（まとめ）
18. Thoughts（感想） 18 総じて難しいコンペだった。参加された皆様お疲れさまでした。  private期間が短すぎる • 1か月でモデルの性能を測るのは難しい  データ量が多い • メモリの制限＆学習時間の長さ（day by dayだと特に）  1subしか選べない • 直近の異様な上昇トレンドが続くかどうか、判断が難しい  評価指標（WRMSSE）が難しい • 商品単位（Lv12）で改善しても、他のLvが悪化することがある
19. Learned（学び） 19 難しかったが学びも多かった。参加してよかった。  Validtionは大事 • Trust LBだとメダルは難しかった • 過去コンペ（DSB2019）での経験が活きた  LeaderBoardは大事 • モチベーションの維持という意味で • LB崩壊後の1か月は、盛り上がりに欠けたと思う  自分の頭で考えることが大事 • 安易にrecursiveを使わず、きちんと検証できたのは収穫
20. Thank you for listening！ ありがとうございました！