俵言

しがない社会人が書く、勉強とかのこと。最近は機械学習や kaggle 関連がメイン。

分析コンペLT会 #1 に参加しました

イベント参加メモ kaggle data science competition

以下の 分析コンペLT会 に参加しました. とっても楽しかったです!

kaggle-friends.connpass.com

本当はアドベントカレンダーとの兼ね合いもあって書くか迷ってたのですが,

運営の方に予めお礼を言われてしまったので振り返りも兼ねて書くことにしました.

いつもながらバラバラと書いてますが, 資料のまとめ + こういう感想持つ人も居るんだなくらいの気持ちでゆるりとご覧ください.

Talk 一覧

Opning Talk ~分析コンペ LT会を開いた理由~ by currypurin さん

概要

  • 何故このLT会を開こうと思ったのか ? 自分が楽しいしアウトプットすることはすごく良いこと、というのもあるが...
  • 日本の kaggle コミュニティってめっちゃすごい ! 身近にめっちゃ強い人が居るのが本当にありがたい !
  • kaggler の唯一の弱点: kaggle 好きすぎ => kaggle に全ての時間を注ぐ => 他のアウトプットが中々出来ない
  • じゃあアウトプットしやすいゆるふわなLT会をやろう !

感想

最近 kaggle やらずにお気持ちブログばっか書いててごめんなさいという気持ちにちょっとなってしまいました. ちゃんと kaggle 取り組んだ上で次回は発表枠で参加したいです.

学習・推論パイプラインを構築する上で大切にしていること by takapy さん

資料: SpeakerDeck

概要

  • この間の Connehito Marché vol.6 での発表と少し重複があるが、今回は特徴量管理よりも学習・推論パイプラインに重みを置いた話
  • NoteBook で無管理に分析をしていると、 めっちゃ良いスコアが出た際に再現が非常につらくなる
  • 学習の再現性を保つために大切にしているもの： 3DONNA(特徴量,パラメータ,CV)
  • 実験設定の記述を1ファイルで完結させ、3DONNNA の内容控え及び feature importance を実験ディレクトリ(これも自動生成)に吐き出させる
  • 実験ディレクトリは {public score}-{使用モデル}_{月日}_{年} の形の命名を行う

感想

現在僕も前回イベントの内容を参考にしながら特徴量管理を進めており, 今回もとても参考になりました.

NN の学習に関しては実験ごとにディレクトリ分けて管理してるのですが, 仰っていたように実験開始専用のファイルを作っておいてそれを編集・実行 => 実験ディレクトリと設定ファイルを生成の方が管理が楽そうなので実践したいです.

また, 実験ディレクトリの先頭を public score にしてその順に並べるのはコンペにおける管理方法としてはかなり良さそうだと思いました. これも自動でやるのか気になっていたのですが,


とのこと.

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

資料: SpeakerDeck

概要

  • 本名は"後藤"ではない
  • オンサイトコンペ(例えば atmaCup !)は短い時間で決着する => 時間がない！初手の動きがとても大切.
  • そこで初手爆速のためのオレオレライブラリ vivid を作っている
    • テンプレートでの特徴量作成, Fold 切り, いくつかのモデルでの学習,・ハイパラ tuning, スタッキング・アンサンブル 等を一気にやってくれるやばいやつ
  • コンペを設計する際にも target の設計や data の切り方、複数モデルでのBM評価のために多数の実験が必要。このときにも Vivid !
  • atmaCup#3 の準備が進行中.

Q . 「コンペを開催するメリットは？」
A . 「本音: 僕が開催してて楽しいから（建前：値段を押さえて様々なML強者の意見がもらえる会として提供元に納得して頂いている）」

感想

資料も発表も完成度がめちゃ高い. あと後藤さんだとガチで思ってたのでめっちゃ驚きました.

vivid は AutoML ならぬ Fast-AutoGoto みたいな感じで, staking まで一気に行うのは中々衝撃的でした.

御本人も仰っていたように柔軟性は低いものの, 初期分析でさっとやるにはかなり有効そう. 懇親会のときに 「KaggleDaysTokyo で使えるのでは？」という話があったとか無かったとか.

LightGBMTunerを使ってみた by wakame1367 さん

資料: GoogleDocs
※google docs は埋め込みが作者以外無理っぽかったので埋め込みなしです.

概要

  • PyData.Tokyo Meetup #21 で LightGBMTuner の紹介があり, どんなものか使ってみることにした
  • Stepwise Tuning を行っているが, その順番や範囲に関しては開発者のノウハウがかなり入っている
  • Kaagle コンペの公開カーネルに適用したところ、概ね良い結果を得られた
  • LightGBM の tuning 初心者にとっては良いツール

感想

まさにこの LightGBM 初心者なので使ってみたいと思いました.

発表中に Stepwise Tuning と聞いて「順番とかどうなんだろう？」と思ってましたが開発者のノウハウが入ってると聞いて納得と言えば納得.

テーブルコンペと比べて分かる画像コンペ入門 by sinchir0 さん

資料: SlideShare

概要

  • 初めて画像コンペに臨んだ時、(知識不足もあって)EDAカーネルを見ても何が何だかわからなかった
  • 経験のあったテーブルコンペと比較することで画像コンペの性質を整理してみる
  • まだまだ理解できてないところもたくさんある.「kaggle で勝つデータ分析の技術 ～画像コンペ編～」 が切実に欲しい!

感想

僕は逆に画像コンペから本格参入した口なのでテーブルコンペ全然わからんのですが、比較表と説明がとてもわかりやすくてありがたかったです。

一番最初の画像コンペ(SIGNATE 台風コンペ) に取り組んでた際に 「Data Augmentation? 何それおいしいの?」「学習率とかどう調整するの?」「TTA?」ってなって各種 ResNet 論文とか iwiwi さんの記事 とか読み漁ってたのでとっても共感しました.

これ個人的にとても良いと思った点なのですが, ここは理解できていてここは理解できてなくてってちゃんと明確にして発表するのは少しずつアウトプットをしていくという意味でめちゃ大切だなと思いました. こまめなアウトプットが出来る人間になりたい.

kaggle 本(画像編)は確かにめっちゃ欲しいです. TL上で「NLP編も欲しい」って言ってる方も居たのでまとめて kaggle本(NN編) みたいなやつ欲しい.

会場スポンサートーク by aki_honmono さん

追記: スポンサーさんの名前を誤記していたので訂正しました(×日経DP → 〇日経BP)。大変失礼致しました。

概要

  • 話者は日経メディカルを担当している方
  • 「皆さん、日経BPってご存知ですか？」=> 「おかしいな～ご存知ないならどうやってここ(会場)にたどり着いたんでしょうか?笑」
  • 日経BPさんは様々な媒体で出版を行い, そのデータを活かして何か出来ないか検討している
    ※すみません、ちょっと内容がうろ覚えなのと、会場 only 情報みたいなのもあったので超ざっくりとしか書けないです。

  • メンバー募集中

  • スポンサーからのお土産: 日経コンピューター 最新号

  • この会場について：エンジニアの勉強会に無料貸出を行っている

感想

kaggle系の勉強会のスポンサートークは大体DSとかエンジニアがやってるイメージだったので斬新でした. 今回のLT会の内容はどんなふうに見えていたんだろう...

実践 PyTorch-Lightning by fam_taro さん

資料: SpeakerDeck

概要

  • 気胸コンペで Gold やったー！ => よっしゃこれ使いまわそう => 絶望. 「誰だよこのコード書いたの💢」「俺(自分)だよ💢」
  • オレオレ Trainer Class だとメンテもしんどいしちょうどいい奴ないかな => PyTorch Lightning
  • Multi-GPU サポート(選択肢は限られている)や gradient accumulation が簡単に使えるのも利点
  • まだ stable version ではないことに注意 !

感想

chainer でやる場合でも Multi-GPU まわりはちょい面倒です. gradient accumulation が簡単に使用できるのはすごい便利そう.

Validation に対する score を単一の GPU で計算しないといけない問題は chainer も同様で(Evaluator という validation のための class があるが そもそもこいつが multi-gpu 対応ではない), 並列数が多いほど validation score の計算が学習時間のボトルネックになるのがつらい.

それなりの epoch 数回すのであれば数 epoch ごとでいいのかなあと思って実際そうしてたことがあります. (これは僕が CosineAnealing 派なので結局回す epoch 数を決めてしまっているのと, どうせアンサンブルするからというのがある).

kaggle その2 advent calendar 2019 で更なる比較を行って頂けるそうなので期待.

AutoML はお好きですか？ by 紺 さん

資料: SpeakerDeck

概要

  • AutoML はお好きですか？

  • 今年はAutoML系のコンペが豊作
  • 通常のMLコンペとの大きな違いとして複数のデータセットに対して予測することや, 予測性能&計算時間で競うこと(醍醐味) が挙げられる
  • 話者は同僚と参加しており, 今回紹介する AutoWSL では 8位, AutoSpeech @ NeurIPS2019では 3位 を達成している
  • approach としては SSL でラベルを付けるなどして Noisy Classifier に食わせる問題設定に落とし込む

Q1 , A1 : すみません, 内容度忘れしました
Q2 . 一位の手法はどのようなものだったのか？
A2. 一位はそもそも train の unlabeled data を一切使わない方針だった. Noisy Label に関しては Linear Model で分類してクリーニングするアプローチをとっていた.
※この部分理解が間違ってたらすみません.

感想

3位めっちゃすごいんですが, AutoML系コンペへの戸惑いもあっていい反応が返せなくてすみませんでした.

コンペだと WSL と扱ってこの枠組みで解くってこと中々無いので, 分類とかアプローチの点でとても勉強になりました.

「pseudo labeling って SSL じゃないん？」って話もあるのですが, Kaggle Tokyo Meetup #6 の OUMed チームの発表 で触れられてたように academic と kaggle で pseudo labeling が指すものが異なるので, 純粋にSSL でやるって見たことない気がする.

Play with Kaggle discussion's text data by kaerururu さん

資料: SlideShare

概要

  • discussion で情報共有していますか? discussion にどんなイメージをお持ちですか？(discussion に貢献してますか？)
  • meta kaggle の data を加工して, discussion 本文からメダルを獲得したかを予測する
  • BERT も使ってみたが性能は芳しくなかった

感想

最初のメッセージ刺さる... ちゃんと貢献しなきゃ.

話者が仰っていたように単純に言葉の意味とメダルの有無は直結して無さそうだなと思いました.

これも kaggle advent calendar 2019 に出されるらしいので期待.

Target Encoding はなぜ有効なのか by hakubishin さん

資料: SpeakerDeck

概要

  • Target Encoding の有効性について、話者の解釈をシンプルな実例を使って紹介
  • GBDT を例に考えると, Target Encoding を行うことで木構造がシンプルになる
  • 分岐増やしまくったらいけるんじゃない？という考えもあるが(過学習の話は置いとくとして), 明らかに良いとわかっている情報は渡した方がモデルが効率化するだろう

Q . 水準数(カテゴリ数)がどれ位なら Label Encoding ではなく Target Encoding に踏み切るとかあります？
A . 1000 とか 1万ならもう Target Encoding すると思う。結局学習時間の問題なので、100 とかなら取りあえず入れてみて学習させた結果を見つつ(削るなど)判断する.
※これは Label Encoding or Target Encoding の文脈の話なので、もちろん他の Encoding を行うとか 集約特徴を使うといった別手段も考えられそう。

感想

Target Encoding 実は一回もやったことないのですが(正しく使わないと危険だということだけは様々な人から伝え聞いている), 例がシンプルでとても分かりやすかったです.

質問もさせて頂いたのですが, 水準数がめっちゃ多い場合の選択肢としてはまず挙がるものなのでテーブルコンペで使っていきたい.

分析コンペ用のオンプレマシン選定・構築について by mhiro2 さん

資料: SlideShare

概要

  • Kaggle kernel(Notebook) の制限がどんどん厳しくなり, オンプレマシンの需要が高まっている(気がする?)
  • 無くても勝てる人は勝てるが, 選択肢が増える(参加できるコンペ, 特徴量の数, 試行回数, ... etc.) のは重要
  • 「kaggle は 所詮オンラインゲー」なので, GPU クラウドで月数万飛ぶのはしんどい. オンプレマシンならダメだった時の傷も(気分的に)浅い
  • CPU, GPU, メモリなどの選択について 話者のおススメを紹介.

感想

僕も「変にケチって後悔するよりはお金出した方が良い」と思っています. (もちろん財布との相談ですが.)
ただGPU 高いんですよね. 24GB/枚 の Titan RTX がめちゃ使いやすいので欲しいのですが, 30万ぽんと出せるかと言うと少し苦しい...

おわりに

AutoWSL の話も含めて. パイプライン構築的な話が何個か出てきました. 実際強い kaggler は学習・推論のパイプラインがしっかりしていて, 実験と改善のサイクルがめっちゃ速い印象です. (Kaggle Tokyo Meetup #6 での Auto Phalanx が未だに忘れられない.)

僕も最近ここらへんをどうにかしようと作業してるところだったりします. 何とか KaggleDaysTokyo までに間に合わせたいな...