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

by Yamaguchi Takahiro

Slide 1

Slide 1 text

初手が爆速になるフレームワークを作ってコンペ設計した話 2019/11/30 分析コンペLT会 @かぐるーど

Slide 2

Slide 2 text

Hello! 山口貴大 twitter @nyker_goto atma(アートマ)株式会社取締役 / DS / ふろんと / ばっくえんど / いんふら京都大学大学院最適化数理卒 SGDが好き Kaggle Master kaggle.com/nyk510 2

Slide 3

Slide 3 text

3 とつぜんですが

Slide 4

Slide 4 text

4 atmaCup ご存知ですよね?

Slide 5

Slide 5 text

#atmaCupとは atma株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp ● 実際に会場に集まり、準備されたデータをテーマに沿って分析・予測を行いその精度を競うイベント ● 全員で一斉にスタートし短い時間で決着するため参加者のスキルがオンラインのデータコンペより強く結果に表れます。 5

Slide 6

Slide 6 text

atmaCup#2@11/23 ● #2(第3回) 全参加者: 39人 ● カレーさんを筆頭に強い人がいっぱい来てくれた!! ありがとうございますmm ● paoさんがshape-upで優勝! 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

#atmaCupとは atma 株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp ● 実際に会場に集まり、準備されたデータをテーマに沿って分析・予測を行いその精度を競うイベント ● 全員で一斉にスタートし短い時間で決着するため参加者のスキルがオンラインのデータコンペより強く結果に表れます。 8 短い時間で決着するため

Slide 9

Slide 9 text

#atmaCupとは atma 株式会社が主催するオンサイトデータコンペ https://atma-cup.atma.co.jp ● 実際に会場に集まり、準備されたデータをテーマに沿って分析・予測を行いその精度を競うイベント ● 全員で一斉にスタートし短い時間で決着するため参加者のスキルがオンラインのデータコンペより強く結果に表れます。 9 時間がないのです

Slide 10

Slide 10 text

時間がない戦い × オンサイトコンペはとにかく時間がない atmaCup: 8時間弱 × 時間が短い分初手の動きがとても大事短い時間の中での立ち回りが重要 × 将棋で言うところの「研究」でほぼ決まる 10

Slide 11

Slide 11 text

11 そこで初手爆速のため (主には仕事用ですが)

Slide 12

Slide 12 text

12 Myライブラリを作っています

Slide 13

Slide 13 text

13 お前はコンペ出ないやろという声が聞こえそうですが

Slide 14

Slide 14 text

14 実はコンペ作る側のメリットもあるのです (後で説明します)

Slide 15

Slide 15 text

15 Vivid っていう名前です一応 pip でも install できます pip install git+https://gitlab.com/nyker510/vivid

Slide 16

Slide 16 text

SaleS Point!! 爆速!! 初手はVividで決まり居飛車穴熊ぐらい堅い Baselineモデルができる 16

Slide 17

Slide 17 text

17 初手(開始30分ぐらい)でこれができます特徴量 ● 指定カラムの Count Encoding ● 指定カラムの OneHotEncoding ● 集計系の特徴量モデル ● Single Model (LightGBM/XGBoost/RandomForest…) ● Optuna での parameter tuning ● Seed averaging ● 上記モデルのEnsemble・Stacking (Ridge/LightGBM/XGBoost)

Slide 18

Slide 18 text

Slide 19

Slide 19 text

● 必要なことだけ書く API 特徴・モデルのロジックと関係性にだけ集中できるような設計 ● テンプレート的な特徴作成の提供 ● スタッキング・アンサンブル対応 Features !! 19

Slide 20

Slide 20 text

20 たとえば: XGBoost

Slide 21

Slide 21 text

21 実体はこれパラメータと使うモデルのクラス指定のみ

Slide 22

Slide 22 text

22 1.学習モデルを fold ごとに保存 2.Fold ごとの feature importance 3.Log と OutOfFold, そのスコアの保存やってくれること

Slide 23

Slide 23 text

23 大枠は Base Class で定義 ● Fold ごとの学習・予測 ● target/input の scaling ● Early Stopping ● Optunaでのチューニング ● Metric・feature importance の出力 ...

Slide 24

Slide 24 text

24 色々Stacking

Slide 25

Slide 25 text

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 モデルのアンサンブル

Slide 26

Slide 26 text

26 モデルごとに学習時のデータを保存 ● Metric ● 重要度 ● Optuna log ● Foldごとのmodel

Slide 27

Slide 27 text

27 Good Points ● 共通部分の見える化そのプロジェクト固有のコードと汎用部分を意識してコーディングするようになるので自ずと見やすくなる ● Version 管理できる昔のプロジェクトでも問題なく使える改良部分がわかりやすい(コピペだと何が良くなったかわからなくなりがち) ● テストが容易 (GitlabCI で master merge ごとにテスト)

Slide 28

Slide 28 text

28 ちょっとコンペの話に戻ります

Slide 29

Slide 29 text

29 コンペ開催に必要なことってなんでしょう

Slide 30

Slide 30 text

● データの選定 ● 課題の設計 ● システムの作成・運用 ● 会場の用意 ● 募集などの広報 30

Slide 31

Slide 31 text

● データの選定 ● 課題の設計 ● システムの作成・運用 ● 会場の用意 ● 募集などの広報 31 < 今からはこの話

Slide 32

Slide 32 text

32 課題の設計大きく分けると3要素 1. Target の設計 2. train/private/publicの設計 3. 予測がどのぐらいできるかの見積もり

Slide 33

Slide 33 text

課題設計: 大きく3つの要素 Targetの選定 ● そもそもどのカラムを予測する? 加工はいらない? ● 回帰? 分類? Train/Public/Private の設定 ● 時系列で切る? ユーザーIDで切る? 何も考えないで切る? 実際に解いたときのスコアの見積り ● ほんまに予測できるの? privateで破綻してたりしない? ● 予測が無理だと「コンペとしては」成立しない (仕事ならわからないでもOKだけど) 33

Slide 34

Slide 34 text

atmaCup#2の場合 Target候補: 16種類 ● アンケートのカラム (x5) ● コンディション (atmaCup#2で採用したもの含む) 切り方 (train/private/public)候補: 6種類 ● User で分離する・時系列で分離する・testの割合モデル: 10種類ぐらい ● みんな本気で来るのでモデリングも手は抜けない… 34

Slide 35

Slide 35 text

課題の設計 Target候補: 8種類ぐらい ● アンケートのカラム (x5) ● コンディション (atmaCup#2で採用したもの)... 切り方 (train/private/public)候補 6種類ぐらい ● User で分離する・時系列で分離する・割合モデル: 5種類ぐらい ● みんな本気で来るのでモデリングも手は抜けない… 35 16x6 = 96種類のデータセットに対して特徴量とモデルx10を作成して Target と切り方ごとに性能評価やらなあかんこと

Slide 36

Slide 36 text

36 ふつうにやったら管理で死ぬ

Slide 37

Slide 37 text

そこでVivid!! 37

Slide 38

Slide 38 text

Vividを使ってよかったこと!! ● 爆速でのモデリング ● データが変わっても対応しやすいコンペのような train/test のsetが変わる条件に強い ● ログが勝手に残る安心感どの条件でスコアがどのぐらいかの振り返りが容易 ● Gitで管理しやすい atmaCupのコードだけ管理すればOK 38

Slide 39

Slide 39 text

イケてないこと ● バグを踏みがちオレオレフレームワークだからね… ● 柔軟性に乏しい(ちょっともりもりにしすぎた Kaggleで使うのは向いてないかもとはいえ実務ではメリットが上回るかなとも思ってます ● ドキュメント、なし!! テストはすこしあるので許してほしいまだまだ未熟なのでコメントとかもらえるとめっちゃ嬉しいです 39

Slide 40

Slide 40 text

まとめ ● Vividで初手は爆速になる学習条件が変わるような設定のときもめっちゃ便利 ● 拡張に若干難あり普通と違うことは作りにくい ● バランス取れた設計にしていきたい 40