はじめに
こんにちは!Gunosy Tech Lab の石川(@takaishikawa42)です。
この記事は Gunosy Advent Calendar 2019、12日目の記事です。
昨日の記事は id:mgi さんによるグノシーにおける AWS Transit Gateway 活用事例 でした。
12月11日・12日の2日間の日程で六本木の Google Japan のオフィスで開催された Kaggle Days Tokyo に参加してきたので、本記事ではそのレポートを書きたいと思います。普段趣味で Kaggle を楽しんでいる身として Kaggle Days が東京で開催されることを知り、前のめりで参加してきました。
当日の様子は Twitter のハッシュタグ #kaggledaystokyo で呟かれており、togetter でもまとめられています。*1
- はじめに
- Kaggle Days について
- タイムテーブル
- プレゼンテーション
- "Leveling-up Kaggle Competitions"
- Essential techniques for tabular competition
- Hosting Kuzushiji the Competition
- Joining NN Competitions (for beginners)
- Imputation Strategy
- How to encode categorical features for GDBT
- 専業Kagglerの1年半 & LANL Earthquake Prediciton 3rd place solution
- ML Modeling with AutoML Tables
- My Journey to Grandmaster: Success & Failure
- ワークショップ
- 朝食・ランチ・コーヒーブレイク
- おわりに
Kaggle Days について
Kaggle とは機械学習のコンペティションプラットフォームで、企業や研究機関などが提供するデータについて、世界中のデータサイエンティストらが機械学習モデルの性能を競います。また、Kaggle Days とはそのような Kaggle の参加者らがオフラインで集まり、Kaggle に関する発表やワークショップなどが行われるイベントで2018年から世界中で開催されています。今回はその6回目のイベントが東京で開催されました。*2
Kaggle や Kaggle Days について、詳しくは本イベントで開催されるオフラインのコンペティションでデータを提供する日本経済新聞社のブログ記事を参照するのが一番分かりやすいと思います。
また、イントロダクションのセッションで今回のイベントに関するいくつかの数値が共有されました。以下のような内容でした。
- 日本は5番目に大きい Kaggle コミュニティである
- Kaggle Days Tokyo のイベントチケットは2日で売り切れ
- 240人の募集人数に対して465人以上の申し込みがあった
- 参加者は多様性が意識された
- 8 GMs, 37 Masters, 65 Experts
- 12カ国以上の参加者
- 社員・エグゼクティブ・学生・研究者...
タイムテーブル
初日はプレゼンテーショントラックとワークショップトラックに分かれていて、2日目はイベント参加者限定のコンペティションが開催されます。初日は国内外の Kaggle Master や Kaggle Grandmaster、また Google や Kaggle の中の人やコンペ主催者など様々な人々が Kaggle に関連する話題について発表したり、実際に手を動かすワークショップが行われました。(発表者一覧はこちら)
本記事では初日に行われたプレゼンテーションの一部と、自身が参加したワークショップの内容についてまとめます。
プレゼンテーション
"Leveling-up Kaggle Competitions"
Presented by Ben Hamner, Kaggle CTO
何についての話か?
- Kaggle のコンペティションの設計についての話
発表のポイントは?
- Kaggle プロダクトの改善のプロセスの話
- 様々な機械学習モデル・手法が検証・一般化されてきた
- 最近はコンピュータリソース等に制約を設けたコンペティションを開催して成功を収めている
- 強化学習のコンペティションを準備中
Essential techniques for tabular competition
Presented by GM Kazuki Onodera
どんな話?
- データをどう見るかという話
発表のポイントは?
- ID ごとにサブセットを分けてデータを見る
- ユーザーがどういう行動をしているかを想定しながら見る
- ソートの使い方で隠れた特徴量を見つける(広義のリークを見つける)
詳しく
- コンペ開始直後にすること
- とりあえず統計量を取る
- 特に #Null, #Uniques はそのカラムがどれだけ使えるかが分かる
- カテゴリの Top10 value を見る
- feature vs. target の分布を見る
- feature のカテゴリごとの Target の平均値
- train/test でどの程度同じカテゴリが共通で存在しているか
- とりあえず統計量を取る
- subset by ID
- Instacart コンペを例に
- id ごとにサブセットを作って目で見て比較する
- あるユーザーについて、product * order_number の表
- instacart は Reorder が多いサービスっぽい
- データを見るだけでは、Coke の代わりに Fridge pack coke を買ったのか、Muffin を買ったのかは分からない(モデルは理解できない)
- 連続したオーダーをバイグラム的に捉えて、それを key にしてオーダーされた回数・発生頻度・どの程度同時に購買されるか等を見た
- ある商品を購入した後に別の商品を購入した場合、それは代替品かどうかを知るには共起したかどうかを見る(共起しない -> ほぼ同時に買われていない = 代替品と考えられる)
- あるユーザーについて、product * order_number の表
- id ごとにサブセットを作って目で見て比較する
- KDDCUP2015 を例に(MOOC dropout prediction)
- どういう順番で授業を視聴しているかが分かる
- あるオブジェクトが何番目に見られるかが分かる(mean: 傾向、std: バラツキ)
- Instacart コンペを例に
- Sorting
- Home Credit コンペ を例に
- 過去の申請履歴等を使って、デフォルトするかどうかを予測する
- ある列でソートすると同じような申請履歴に見えるものが存在する
- 申請履歴IDだと異なるユーザーに見えるが、ソートして見えてくるレコードから真のユーザーIDが浮かび上がる
- 同じユーザーをどのように発見するか(誕生日・子供の数...)
- Home Credit コンペ を例に
Hosting Kuzushiji the Competition
Presented by Tarin Clanuwat
どんな話?
- Kuzushiji コンペをホストした話
発表のポイントは?
- ROIS-DS人文学オープンデータ共同利用センター*3 がくずし字認識コンペを開催した
- 日本の企業・団体主催のコンペとしては3例目(リクルート・メルカリに次いで)
- コンペのホスト側の見解についての話を聞ける珍しい発表だった
詳しく
- コンペ開催の背景
- 300万冊の本・1億の歴史的文書が保存されているが、くずし字で書かれているので有効活用できていない
- これを現代文字に変換する(翻刻)ことができたら、もっと多くの人が古文書にアクセスできる
- コンペをホストするためには
- ホスト側でベースラインを用意する
- タスクやメトリクスを理解しやすくする
- 誰でも参加ができるようなルールにする(ex. 日本語を読める読めないに関わらず参加できるように)
- 評価手法
- 文字の位置推定と、ラベルの両方を評価するF1スコア
- バウンディングボックスの推定ではなく文字の中心部を当てるくらいにする
- 結果的にはF1 スコアではなく、不均衡データなので少数のラベルを強く重みづけて評価するメトリクスでも良かった気がすると反省
- 文字の位置推定と、ラベルの両方を評価するF1スコア
- 順位結果
- 1位から順に中国・ロシア・日本だったので「誰でも参加ができるようなルールにする」は期待通りだった
- ソリューション概観
- 物体検知アルゴリズムは大体結構うまくいった(YOLO は微妙だった)
- End-to-End あるいは 文字検知 -> 文字分類の2stageで解くパターン のいずれかだった
- Data Augmentation
- 3rd place solution: Mixup + Random erasing
- Albumentations library の利用
- Winning solution から学んだこと
- Detection は簡単、分類が難しい
- うまくいったこと
- Pseudo-labeling
- ImageNet / COCO の学習済みモデル
- うまくいかなかったこと
- 言語モデル
- flip, rotate 等の augmentation
Joining NN Competitions (for beginners)
Presented by Master Tomohiro Takesako
どんな話?
- 初心者向けの画像コンペ解説
発表のポイントは?
- ベースラインは時間がかかっても自分で書き上げることが重要
- とにかく実践あるのみ
- Detail が重要(他人の設定値が役立つとは限らない)
詳しく
- かなりのコンピュータリソースを要求されるものもあるけど、興味があるのに参加しよう
- 当初知りたかったこと
- モデル選択の基準
- 10 epoch をまず見る
- augmentations の選び方
- 目視で注意深く確認する(flip とか rotate とか)
- 他人の実験結果の再現
- 他人の前処理・学習プロセス・ハイパーパラメータ等は個々人で異なることが多いのであまり当てにしなくていい
- モデル選択の基準
- どうやってモデルを改善していくか?
- バリデーション戦略を確立する
- train/test の分布を確認する
- random seed を固定する
- validation のデータセットを固定する
- 標準的なやり方を知る:大勢の人がしていることは把握しておく
- 論文を読む
- ディスカッションを読む
- カーネルを読む
- 似たコンペのソリューションを読む
- バリデーション戦略を確立する
- 実際のコンペに参加して学んだ教訓
- Loss の選択は重要
- 画像コンペでもデータをよく見ることは重要(EDA)
- ex. アスペクト比をプロットして外れ値のデータを確認してノイズになりそうなものを除いた
- モデルが重要(複雑なモデルほどスコアが良かった)
- Loss, Optimizer, Learning_rate, Batch_size...など細かい所のチューニングは人それぞれだった
Imputation Strategy
Presented by Master Yuji Hiramatsu
どんな話?
- 欠損値補完の話
発表のポイントは?
- 欠損値補完をなぜやるか?
- 欠損値の統計学的な扱い
- GBDTモデルではどうか?
- MICE と Xgboost の欠損値補完に関する実験
詳しく
- kaggle では欠損値補完はあまりされず、そのままモデルに突っ込まれることが多い(特にツリーベースのモデル)
- 欠損値それ自体に情報が含まれているからうまくいくのではないかと考えられる
- 欠損値がどのように発生されるか?
- MCAR: Missing Completely At Random
- 完全にランダムに欠損
- MAR: Missing At Random
- 観察可能なある一変数に依存した形で欠損
- NMAR: Not Missing at Random
- 観察できない変数にも依存した形で欠損(?)
- MCAR: Missing Completely At Random
- 補完の手法
- LD(Listwise Detection) / PD(Pairwise Detection): 一つでも欠損したケースがあれば落とす・相関を計算したいペアだけ見て使えるデータをすべて使う*4
- 単一代入法:平均値とか回帰とかで埋める。不確実性を過小評価する問題を孕む。
- 多重代入法:不確実性を過小評価する問題を解消する。
- Xgboost では欠損値がどのように扱われているか?
- まず NA を除いて Loss を最適化する閾値を求める。その後、NA 全てを左か右かに振り分けたとき Loss が小さくなる方向に NA を割り振る。
- 実験
- MICE vs. Xgboost
- Xgboost は NA であることを特徴としてうまく利用している(Target との関係を考慮できる)
- ラウンドごとに代入される値が変わるイメージ(多重代入法っぽい)
- NAフラグをつけると MICE スコアが改善する
- Xgboost は NA フラグをすでに上で来ているので MICE ほどの改善幅はない
- MICE vs. Xgboost
How to encode categorical features for GDBT
Presented by Master Ryuji Sakata
どんな話?
- GBDTに対してカテゴリカル変数をどのようにエンコーディングするのが良いかを様々実験した話
発表のポイントは?
- 基本的なエンコーディング手法の確認
- 人工データに対して各種エンコーディング手法のパフォーマンスを実験
詳しく
- エンコーディング手法の概観
- 基本的なエンコーディング手法
- onehot encoding
- 水準数が多いと次元爆発で大変
- label encoding
- target encoding
- リーケージに注意
- OOF で Fold ごとに適用することが重要(諸説あり...?)
- onehot encoding
- LightGBM の categorical features support*5
- ドキュメントを見ると
sort the categories according to the training objective
と書かれている- 基本的な考え方は Target Encoding と一緒
- ただし
each split
と書かれている通り、Objective はダイナミックに変わっていく - とはいえリーケージのリスクはあるので High Cardinality な場合は
min_data_per_group
,cat_smooth
などのハイパーパラメータを調整することが勧められている
- ドキュメントを見ると
- その他のエンコーディング手法
- feature hashing
- frequency encoding
- embedding
- 基本的なエンコーディング手法
- 人工データを使った実験(変数間に交互作用は無い・カテゴリカル変数の分布に偏りはないという前提)
- 実験の背景
- Label Encoding/Target Encoding が GBDT でよく使われるけど、データセットの特性に応じてどのように使い分けることができるか?
- Encoding 手法による特徴
- One-hot Encoding
- カテゴリカル変数が High Cardinality なほどパフォーマンスは悪化する
- Label Encoding
- One-hot Encoding より過学習気味
- Target Encoding
num_leaves
の違いによるパフォーマンスの差異は比較的小さい- Hight cardinality かつ複雑な木構造を使いたいとき Target encoding はベターな戦略に思われる。
- LGBM Encoding
- Target Encoding に似ている
- 単純な木構造の場合は LGBM Encoding の方が良く、複雑な場合は Target Encoding の方が良かった
- One-hot Encoding
- 収束の仕方
- Label Encoding の収束が最も遅く、Target Encoding は早い
- 前者は Label の数だけ Split が必要だからかもしれない
- 後者は値の大小関係に意味があるから Split する際に有効に働くのかもしれない
- Label Encoding の収束が最も遅く、Target Encoding は早い
num_leaves
が大きいときの傾向- Hight cardinality のとき
num_leaves
が大きくても Target Encoding の方が Label encoding より悪化しづらい num_leaves
が大きいときは Target Encoding の方が LGBM Encoding より良い
- Hight cardinality のとき
- 不要なカテゴリカル変数が多数存在する場合
- Target Encoding は影響を受けにくい
- 実験の背景
専業Kagglerの1年半 & LANL Earthquake Prediciton 3rd place solution
Presented by Master Hideki Murata (currypurin)
どんな話?
- 専業Kaggler として一年半の話
- 地震コンペのソリューションの話
発表のポイントは?
- 公務員を辞めて1年半の間、Kaggle 関連のことだけをして生活していた人の話(妻子持ち)
- データリークと LB Probe を利用して Validation 戦略を緻密に設定した
ML Modeling with AutoML Tables
Presented by Tin-Yun Ho & Da Huang
どんな話?
- AutoML Tables の紹介の話*6
発表のポイントは?
- 特徴について
- 最新のアップデートについて
- デモ
詳しく
- 特徴はこの辺り
構造化データに対する高速かつ大規模な機械学習
機械学習モデルのビルドや構造化データへのデプロイを自動化できます
料金はコンピューティングとメモリの使用量に基づき、実際にご利用いただいた分だけのお支払いとなります。
- カスタマーの要望に応えてアップデートを継続中
- 安くして! -> Early Stopping の実装・小規模データに対してより高速に
- 様々なデータに使いたい! -> 1000行くらいの小さなデータや、500クラスまでの多クラス分類に対応
- 中身はどうなってるの? -> 全ての特徴量やアーキテクチャを確認できるようにした
- 説明性がほしい! -> SHAP の実装
- モデルを使いまわしたい! -> モデルをカスタムコンテナとして出力可能に
- デモ
- Auto Preprocessing
- categorical / numerical / text / timestamp 等の様々なデータタイプに対して、典型的な特徴量生成手法を全て自動で適応して前処理を行う
- Auto Modeling
- 複数のモデルを同時に試し、交差検証・バギング・アンサンブルを行い、最終的な一つのモデルを構築するまでを自動で行う
- Auto Preprocessing
- データサイエンティストにとっての利点
- 素早くベースラインモデルを作れること
- AutoML の結果からアイデアを得られること
- これによって より良いモデルを作れるようになる(ハズ)
My Journey to Grandmaster: Success & Failure
Presented by GM Jin Zhan
www.slideshare.net
どんな話?
- 自己紹介とコンペ遍歴
- 成功と失敗から学んだ Kaggle に関する様々な教訓
発表のポイントは?
- 安定した Validation 戦略が大事
- 様々な非線形変換は前処理で良い役割を果たす事が多い
- ドメイン知識をもとに行う特徴量生成が強力
- 特徴選択は精度と過学習防止に役立つ
- ツリーモデルが大体良いけれど、NNや線形モデルも忘れずに試すべき
- Stacking は local cv と public が連動するときは重要
詳しく
- Validation
- Feature Engineering
- ドメイン知識をもとに、どのような特徴量が効きそうかよく考える
- 粗い aggregation だけでなく、精緻な aggregation も重要
- テーブルデータでも購買履歴をシークエンスとして捉えて NLP ライクな処理で特徴表現することもできる
- Feature Selection
- Null Importance を利用*7
- Modeling
- LightGBM, NN 両方試している。シングルモデルだとテーブルコンペだと LightGBM > NN の傾向がある
ワークショップ
Feature engineering for events data (transactions, user actioins on websites/games)
Presented by Pawet Jankiewicz
どんな話?
- イベントデータ(transcation, user log)に対する特徴量生成について
- RecSys2019 Challenge*8 で1位になったソリューションについて
発表のポイントは?
- 過去履歴データのみを利用してリークしないように工夫した自作の関数を実装した*9
朝食・ランチ・コーヒーブレイク
朝食・ランチは Google Japan 六本木オフィスのカフェテリアでビュッフェ形式でした。さすがの Google ですね。朝食まで食べれるのはすごい。
コーヒーブレイクも美味しいお菓子まで提供されていて充実していました。
おわりに
1日中 Kaggle に関する膨大な情報に触れて大変刺激的な時間でした。ここで知ったことを早く色々試してみたい気持ちでいっぱいです。
本記事を書いている今日、2日目(12/12(木))はイベント参加者限定のオフラインコンペが開催される予定なので、それも楽しみです。上述の通り、データ提供者は日本経済新聞社で、どのようなコンペ内容になるのかが今から楽しみです。
以上です。明日は竹中さんのノリで使っていたGoLandをちゃんと使うです。お楽しみに。
*1:https://togetter.com/li/1441679
*2:https://hack.nikkei.com/blog/kaggle_days_tokyo/
*3:http://codh.rois.ac.jp/competition/kaggle/
*4:http://www.sigmath.es.osaka-u.ac.jp/~kano/research/seminar/others/KSPmissingWEB.pdf
*5:https://lightgbm.readthedocs.io/en/latest/Advanced-Topics.html#categorical-feature-support
*6:https://cloud.google.com/automl-tables/?hl=ja
*7:https://www.kaggle.com/ogrellier/feature-selection-with-null-importances
*8:https://recsys.acm.org/recsys19/challenge/
*9:https://github.com/logicai-io/recsys2019/blob/master/src/recsys/data_generator/accumulators.py