初手が爆速になるフレームワークを作ってコンペ設計した話

Transcript

1. 初手が爆速になる フレームワークを作って コンペ設計した話 2019/11/30 分析コンペLT会 @かぐるーど
2. Hello! 山口貴大 twitter @nyker_goto atma(アートマ)株式会社 取締役 / DS / ふろんと / ばっくえんど / いんふら 京都大学大学院 最適化数理卒 SGDが好き Kaggle Master kaggle.com/nyk510 2
3. 3 とつぜんですが
4. 4 atmaCup ご存知ですよね?
5. #atmaCupとは atma株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp • 実際に会場に集まり、準備されたデータをテーマに沿って 分析・予測を行いその精度を競うイベント • 全員で一斉にスタートし短い時間で決着するため参加者のスキ ルがオンラインのデータコンペより強く結果に表れます。 5
6. atmaCup#2@11/23 • #2(第3回) 全参加者: 39人 • カレーさんを筆頭に強い人がいっぱい来てくれた!! ありがとうございますmm • paoさんがshape-upで優勝! 6
7. #atmaCupとは atma株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp • 実際に会場に集まり、準備されたデータをテーマに沿って 分析・予測を行いその精度を競うイベント • 全員で一斉にスタートし短い時間で決着するため参加者のスキ ルがオンラインのデータコンペより強く結果に表れます。 7
8. #atmaCupとは atma 株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp • 実際に会場に集まり、準備されたデータをテーマに沿って 分析・予測を行いその精度を競うイベント • 全員で一斉にスタートし短い時間で決着するため参加者のスキ ルがオンラインのデータコンペより強く結果に表れます。 8 短い時間で決着するため
9. #atmaCupとは atma 株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp • 実際に会場に集まり、準備されたデータをテーマに沿って 分析・予測を行いその精度を競うイベント • 全員で一斉にスタートし短い時間で決着するため参加者のスキ ルがオンラインのデータコンペより強く結果に表れます。 9 時間がないのです
10. 時間がない戦い × オンサイトコンペはとにかく時間がない atmaCup: 8時間弱 × 時間が短い分初手の動きがとても大事 短い時間の中での立ち回りが重要 × 将棋で言うところの「研究」でほぼ決まる 10
11. 11 そこで 初手爆速のため (主には仕事用ですが)
12. 12 Myライブラリ を作っています
13. 13 お前はコンペ出ないやろ という声が 聞こえそうですが
14. 14 実はコンペ作る側の メリットもあるのです (後で説明します)
15. 15 Vivid っていう 名前です 一応 pip でも install できます pip install git+https://gitlab.com/nyker510/vivid
16. SaleS Point!! 爆速!! 初手はVividで決まり 居飛車穴熊ぐらい堅い Baselineモデルができる 16
17. 17 初手(開始30分ぐらい)でこれができます 特徴量 • 指定カラムの Count Encoding • 指定カラムの OneHotEncoding • 集計系の特徴量 モデル • Single Model (LightGBM/XGBoost/RandomForest…) • Optuna での parameter tuning • Seed averaging • 上記モデルのEnsemble・Stacking (Ridge/LightGBM/XGBoost)
19. • 必要なことだけ書く API 特徴・モデルのロジックと関係性にだけ 集中できるような設計 • テンプレート的な特徴作成の提供 • スタッキング・アンサンブル対応 Features !! 19
20. 20 たとえば: XGBoost
21. 21 実体はこれ パラメータと使うモデルのクラス指定のみ
22. 22 1.学習モデルを fold ごとに保存 2.Fold ごとの feature importance 3.Log と OutOfFold, そのスコアの保存 やってくれること
23. 23 大枠は Base Class で定義 • Fold ごとの学習・予測 • target/input の scaling • Early Stopping • Optunaでのチューニング • Metric・feature importance の出力 ...
24. 24 色々Stacking
25. 25 色々Stacking 1. XGBoost 2. Optuna で tuning するXGBoost 3. SeedAveraging するXGBoost 4. 1~3+特徴量のstacking + Optuna で tuning する Ridge 5. 1~3+特徴量のstacking する XGBoost 6. Stacking モデルのアンサンブル
26. 26 モデルごとに学習時 のデータを保存 • Metric • 重要度 • Optuna log • Foldごとのmodel
27. 27 Good Points • 共通部分の見える化 そのプロジェクト固有のコードと汎用部分を意識して コーディングするようになるので自ずと見やすくなる • Version 管理できる 昔のプロジェクトでも問題なく使える 改良部分がわかりやすい(コピペだと何が良くなったかわから なくなりがち) • テストが容易 (GitlabCI で master merge ごとにテスト)
28. 28 ちょっとコンペの 話に戻ります
29. 29 コンペ開催に 必要なことって なんでしょう
30. • データの選定 • 課題の設計 • システムの作成・運用 • 会場の用意 • 募集などの広報 30
31. • データの選定 • 課題の設計 • システムの作成・運用 • 会場の用意 • 募集などの広報 31 < 今からはこの話
32. 32 課題の設計 大きく分けると3要素 1. Target の設計 2. train/private/publicの設計 3. 予測がどのぐらいできるかの見積もり
33. 課題設計: 大きく3つの要素 Targetの選定 • そもそもどのカラムを予測する? 加工はいらない? • 回帰? 分類? Train/Public/Private の設定 • 時系列で切る? ユーザーIDで切る? 何も考えないで切る? 実際に解いたときのスコアの見積り • ほんまに予測できるの? privateで破綻してたりしない? • 予測が無理だと「コンペとしては」成立しない (仕事ならわからないでもOKだけど) 33
34. atmaCup#2の場合 Target候補: 16種類 • アンケートのカラム (x5) • コンディション (atmaCup#2で採用したもの含む) 切り方 (train/private/public)候補: 6種類 • User で分離する・時系列で分離する・testの割合 モデル: 10種類ぐらい • みんな本気で来るのでモデリングも手は抜けない… 34
35. 課題の設計 Target候補: 8種類ぐらい • アンケートのカラム (x5) • コンディション (atmaCup#2で採用したもの)... 切り方 (train/private/public)候補 6種類ぐらい • User で分離する・時系列で分離する・割合 モデル: 5種類ぐらい • みんな本気で来るのでモデリングも手は抜けない… 35 16x6 = 96種類のデータセットに対して 特徴量とモデルx10を作成して Target と切り方ごとに性能評価 やらなあかんこと
36. 36 ふつうにやったら 管理で死ぬ
37. そこでVivid!! 37
38. Vividを使ってよかったこと!! • 爆速でのモデリング • データが変わっても対応しやすい コンペのような train/test のsetが変わる条件に強い • ログが勝手に残る安心感 どの条件でスコアがどのぐらいかの振り返りが容易 • Gitで管理しやすい atmaCupのコードだけ管理すればOK 38
39. イケてないこと • バグを踏みがち オレオレフレームワークだからね… • 柔軟性に乏しい(ちょっともりもりにしすぎた Kaggleで使うのは向いてないかも とはいえ実務ではメリットが上回るかなとも思ってます • ドキュメント、なし!! テストはすこしあるので許してほしい まだまだ未熟なのでコメントとかもらえるとめっちゃ嬉しいです 39
40. まとめ • Vividで初手は爆速になる 学習条件が変わるような設定のときもめっちゃ便利 • 拡張に若干難あり 普通と違うことは作りにくい • バランス取れた設計にしていきたい 40
41. 41 さいごに
42. 12月頃には詳細のアナウンスができるかも?! atmaCup #3
43. THANKS! Arigato Gozaimashita !! 43