Kaggle PLAsTiCC Astronomical Classification competition まとめ
先日終了したPLAsTiCC Astronomical Classification | Kaggleコンペ。上位のチームの解法のまとめ。自分は1097チーム中247位でした。Coursera で Kaggle コースをとったあとに途中から参加したコンペで、力及ばずだったので何が足りなかったのか知るためのまとめ。
できなかったこと・やらなかったこと
- 天文系の domain knowledge 勉強
- gradient boost 系のモデル。NN のみに集中した。
- trivial でない feature engineering.
知りたいこと
- domain knowledge はどの程度必要だったのか？
- NN はどこまで健闘できたのか？
- feature engineering はどの程度がんばればよいのか？
Top 5
1位
- Overview of 1st place solution | Kaggle
- 超新星宇宙論を研究している天文学者。
- single LGBM model with 5-fold cross-validation
- Gaussian processes to predict the lightcurves
- Measured 200 features on the raw data and Gaussian process predictions.
- Class 99 は LB probe した
2位
- 2nd-Place Solution Notes | Kaggle
- NN 7 modelss, LG 2 models の ensembling.
- Augmenting the training set.
- Class 99 は LB probe した
3位
- 3rd Place Part I -CNN | Kaggle
- LGB + CatBoost + CNN
- CNN is a Fully 1D Convolutional Neural Network with 256 * 8,5,3 convolution kernels followed by a GlobalMaxPulling
- time series data と meta feature を handle する複数の NN
4位
- 4th Place Solution with Github Repo | Kaggle
- trained a model to predict hostgal specz using training set+ test set with hostgalspecz. Then used this model's predictions as a feature.
- blend of LGB, NN and several stacking model
- Class 99 は LB probe した
5位
- Solution #5 tidbits | Kaggle
- lightgbm + NN models, RNN and MLP.
結果
- domain knowledge はどの程度必要だったのか？
- データが何であるかを説明できるくらいには必要だった
- NN はどこまで健闘できたのか？
- 上位に NN モデル多し。詳細は Kernel を見たい。
- feature engineering はどの程度がんばればよいのか？
- モデルによるが大量の feature の人達もいる
Kaggle 今後の方針
Kaggle を初めて少し時間が経っていろいろ分かってきたので今後の方針をここで書きながら考える。
学び
- Feature Engineering がんばらないと勝てないコンペ多い。
- Tabular data だと NN よりも XGBoost 勢が人気で強い。
- Kernel 書くとフィードバックもらえる
- Kernel 読むの勉強になる。特に終わったコンペの上位 Kernel。
- すぐにコピペできる資産が溜まってくると楽になる。Cross Validation, Hyper parameter tuning 等々。
始めた動機
- DNN 周りですぐに手を動かすことができるように
- RNN/LSTM 以外も詳しくなりたい
- 毎日触る機会として使う
今後の方針
- 入賞は nice to have
- 1つのコンペに集中
- Kernel を読んでその手法を取り入れる・理解するプロセスを繰り返す
- ある程度コピペ資産が溜まったら整理する
- 重点トピック
- Cross Validation と高速化
- Hyper parameter tuning の勘所
- Keras API はほとんど理解できるように
- Blog ドリブンで。
ホモ・デウス
ホモデウス読了。前作サピエンス全史同様に作者の深い洞察と鋭いマクロ視点が好き。特に人間の意識の話が面白かった。おすすめ。これからの世代は大変そうだ。
- 作者: ユヴァル・ノア・ハラリ,柴田裕之
- 出版社/メーカー: 河出書房新社
- 発売日: 2018/09/05
- メディア: 単行本
- この商品を含むブログ (7件) を見る
Clouderizer + Google Colab for Kaggle
HoxoMaxwell ❄️さんのツイートで見かけてToDoに入っていた Clouderizer + Google Colab を試した。手順は Kaggle Competition on Google Colab — how to easily import datasets and local files and access… にある通り。
この手の Cloud Service をラップするやつを使うのは初めてだが良いと思ったのは以下の点。
- pip などで追加で入れるライブラリをプロジェクトテンプレートで指定できる。
- とにかく Kaggle のデータが自動で設定されるのがとても便利。必要なのはプロジェクト名だけ。
- Google Drive と連携するとファイルの persistence も面倒見てくれるっぽいので Colab のライフサイクル問題もそこまで辛くない。
- 200 project hours まで無料 。登録にクレジットカード必要なかった。
Install google.colab library for local colabratory
cd /tmp git clone https://github.com/googlecolab/colabtools.git cd colabtools python setup.py bdist_wheel pip install dist/google_colab-0.0.1a1-py2.py3-none-any.whl
Deep Learning training の待ち時間にすべきこと
Deep Learning の training 時間は短いものでは数十分、長いものでは数日に及ぶ。その training が走っている間は、何をすると1番プロダクティブだろうか。いくつかの候補とそれぞれの利点と欠点を以下にまとめてみた。
SNS やメールのチェック
コーディング時には後回しにしていた、返事をするのも良いだろう。欠点はもちろん皆さんご存知の通り。気づいたらあっという間に時間を吸い取られること。そしてプロジェクトへのフォーカスが失われることだ。
リファクタリング
コードを常にクリーンに保つことは、プロジェクト全体のプロダクティビティ向上に通じる。ただし機械学習のコードはテストが書けない場合が多いので注意が必要。テストによって支えられていないリファクタリングでは必ず IDE の助けを借りよう。リファクタリングの欠点は2つ。1つ目は現在走っているコードと、リファクタリングによって改善された head のコードが離れてしまうことだ。training 用のコードにバグが見つかったら、どちらを編集すべきだろうか？などと考えないといけない。2点目は、リファクタリングは重要だがプロジェクトを前に進めるものではないということだ。そもそも現在流している training コードが向いている方向が間違っていたらリファクタリングに特に意味はない。
Self code review
個人プロジェクトの場合、誰かにコードをレビューされることはない。時間が空いたときに落ち着いて、最近書いたコードを読み直してみるのも良いだろう。これは先述のリファクタリングとほぼ同様の利点・欠点がある。
プランニング
空いている時間に、プロジェクトの方向性や次の一手などを見つめ直すのも良いだろう。コードから視点を上げて、プロジェクトがうまく行っているか見つめることは、全体のプロダクティビティ向上に大きく役立つだろう。ただし多くの場合、次の一手は今走っている training に依存するので効果は限定的な場合もある。
関連論文・ブログを読む
機械学習では、論文を読むことは避けられない作業である。関連研究やトレンドなどを追うことで、プロジェクトの成功率を高めることができるだろう。欠点は（これは筆者だけかもしれないが）、数時間もぶっ続けで論文を読めないことだ。Training の空き時間中、ずっと論文読むのは無理だ。
プロジェクトの別タスク
理想的にはプロジェクト内に 2-3 個の別タスクがあるのが望ましい。ブロックされたら残りのタスクに並行して取り組むのだ。プロジェクトへのフォーカスを失うことなく、プロダクティビティを上げることができる。難しいのは別タスクがそもそもあるかどうか。それらが良い感じに独立しているかどうかだ。
別プロジェクト
空き時間に全く別のプロジェクトに取り組むのも一つの手だ。training とは完全に独立している。メインプロジェクトが失敗した場合のバックアップにもなる。欠点は完全なコンテキストスイッチが必須になることだ。training 後にタスクを resume するときに若干の苦労を要する。
