分析コンペLT会 #1 に参加しました
以下の 分析コンペLT会 に参加しました. とっても楽しかったです!
本当はアドベントカレンダーとの兼ね合いもあって書くか迷ってたのですが,
まだ出してないのに😇
— 俵 (@tawatawara) November 30, 2019
頑張ります
運営の方に予めお礼を言われてしまったので振り返りも兼ねて書くことにしました.
いつもながらバラバラと書いてますが, 資料のまとめ + こういう感想持つ人も居るんだなくらいの気持ちでゆるりとご覧ください.
- Talk 一覧
- Opning Talk ~分析コンペ LT会を開いた理由~ by currypurin さん
- 学習・推論パイプラインを構築する上で大切にしていること by takapy さん
- 初手が爆速になるフレームワークを作ってコンペ設計した話 by nyker_goto さん
- LightGBMTunerを使ってみた by wakame1367 さん
- テーブルコンペと比べて分かる画像コンペ入門 by sinchir0 さん
- 会場スポンサートーク by aki_honmono さん
- 実践 PyTorch-Lightning by fam_taro さん
- AutoML はお好きですか? by 紺 さん
- Play with Kaggle discussion's text data by kaerururu さん
- Target Encoding はなぜ有効なのか by hakubishin さん
- 分析コンペ用のオンプレマシン選定・構築について by mhiro2 さん
- おわりに
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 にしてその順に並べるのはコンペにおける管理方法としてはかなり良さそうだと思いました. これも自動でやるのか気になっていたのですが,
subはAPI使ってますが、Publicのスコアつけてる部分は手動です...汗
— takapy | たかぱい (@takapy0210) December 1, 2019
とのこと.
初手が爆速になるフレームワークを作ってコンペ設計した話 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編) みたいなやつ欲しい.
kaggle 本(画像コンペ編) が求められている。画像つよつよ勢に書いて欲しい... #かぐるーど
— 俵 (@tawatawara) November 30, 2019
— takapy | たかぱい (@takapy0210) November 30, 2019
会場スポンサートーク by aki_honmono さん
追記: スポンサーさんの名前を誤記していたので訂正しました(×日経DP → 〇日経BP)。大変失礼致しました。
概要
- 話者は日経メディカルを担当している方
- 「皆さん、日経BPってご存知ですか?」=> 「おかしいな~ご存知ないならどうやってここ(会場)にたどり着いたんでしょうか?笑」
- 日経BPさんは様々な媒体で出版を行い, そのデータを活かして何か出来ないか検討している
※すみません、ちょっと内容がうろ覚えなのと、会場 only 情報みたいなのもあったので超ざっくりとしか書けないです。 メンバー募集中
スポンサーからのお土産: 日経コンピューター 最新号
ついた #かぐるーど pic.twitter.com/JbWUmkEkWr
— 俵 (@tawatawara) November 30, 2019
- この会場について:エンジニアの勉強会に無料貸出を行っている
スポンサーセッションで説明ありそうだけど、この会場無料で借りれるそうな #かぐるーど pic.twitter.com/40ihqh0MFb
— 俵 (@tawatawara) November 30, 2019
感想
kaggle系の勉強会のスポンサートークは大体DSとかエンジニアがやってるイメージだったので斬新でした. 今回のLT会の内容はどんなふうに見えていたんだろう...
実践 PyTorch-Lightning by fam_taro さん
資料: SpeakerDeck
概要
- 気胸コンペで Gold やったー! => よっしゃこれ使いまわそう => 絶望. 「誰だよこのコード書いたの💢」「俺(自分)だよ💢」
- オレオレ Trainer Class だとメンテもしんどいしちょうどいい奴ないかな => PyTorch Lightning
- Multi-GPU サポート(選択肢は限られている)や gradient accumulation が簡単に使えるのも利点
- まだ stable version ではないことに注意 !
感想
(chainer には Trainer があるんやで... https://t.co/7srxVRdsTQ) #かぐるーど
— 俵 (@tawatawara) November 30, 2019
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 で更なる比較を行って頂けるそうなので期待.
PyTorch 三国志(Ignite・Catalyst・Lightning)について簡単な比較をしてみようと思います!
— ふぁむたろう (@fam_taro) November 25, 2019
kaggle その2 Advent Calendar 14日目に参加しました #Qiita https://t.co/2Z8pCL3tGJ
AutoML はお好きですか? by 紺 さん
資料: SpeakerDeck
概要
- AutoML はお好きですか?
AutoML も突き詰めたら只のパイプラインなんだけどな #かぐるーど
— 紺 (@Y_oHr_N) November 30, 2019
- 今年は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 も使ってみたが性能は芳しくなかった
感想
最初のメッセージ刺さる... ちゃんと貢献しなきゃ.
「単語の意味は discussion のメダルに貢献してないかも?」
— 俵 (@tawatawara) November 30, 2019
"useful links" とか言ってリンクだけ貼ってる場合もあるし、すごいいいこと書いてる場合は情報量が沢山あるから分の長さとかから結構図れるのかも?
#かぐるーど
話者が仰っていたように単純に言葉の意味とメダルの有無は直結して無さそうだなと思いました.
これも kaggle advent calendar 2019 に出されるらしいので期待.
LT 相変わらず緊張したけど楽しかった。
— かえるるる (@kaeru_nantoka) November 30, 2019
アドカレではもっと進化させてから up したい
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, メモリなどの選択について 話者のおススメを紹介.
感想
オンプレは初期投資さえすれば資産になるので... #かぐるーど
— 俵 (@tawatawara) November 30, 2019
オンプレマシン買おうとすると「結局全部いいやつにしろ」ってなるやつだこれ #かぐるーど
— 俵 (@tawatawara) November 30, 2019
僕も「変にケチって後悔するよりはお金出した方が良い」と思っています. (もちろん財布との相談ですが.)
ただGPU 高いんですよね. 24GB/枚 の Titan RTX がめちゃ使いやすいので欲しいのですが, 30万ぽんと出せるかと言うと少し苦しい...
おわりに
AutoWSL の話も含めて. パイプライン構築的な話が何個か出てきました. 実際強い kaggler は学習・推論のパイプラインがしっかりしていて, 実験と改善のサイクルがめっちゃ速い印象です. (Kaggle Tokyo Meetup #6 での Auto Phalanx が未だに忘れられない.)
僕も最近ここらへんをどうにかしようと作業してるところだったりします. 何とか KaggleDaysTokyo までに間に合わせたいな...