コンペ中のコード、どうしてる？

データ分析コンペにおけるコードの管理に関するスライドです

Transcript

1. コンペ中のコード、どうしてる？
 2021/6/2 @ ニッチな分析コンペLT会
 Hidehisa Arai
 1
2. 自己紹介
 2 • 21新卒で機械学習エンジニア 
 • Kaggle歴は3年くらい 
 • 音系のコンペによく出ている 
 • 学生時代は航空宇宙 
 https://www.kaggle.com/hidehisaarai1213 https://twitter.com/kaggle_araisan https://github.com/koukyo1994
3. はじめに
 3 ⚠注意事項
 • 本発表は個人の信条を含んだ意見が多数含まれます。ご了承ください。 
 • 全員がこうするべき！という主張ではなく、私はこう考えています、くらいの温度感ですのでご 承知おきください。
 
 話すこと
 • コードの構成やTipsについて話します。 
 • そんなこと知っとるわ、という話ばかりかもしれませんがお付き合いください。 
 
 話さないこと
 • 具体的なコンペの話はしません。 

4. Notebook vs Script
 4 Notebook
 Script
 メリット
 メリット
 デメリット
 デメリット
 • Kaggle Notebookと相性がいい 
 • 実装を進めやすい
 • チームでの共有が容易 
 • Textエリアに実装の背景などを書ける 
 • とっ散らかりやすい
 • 実行までに一手間入る 
 • gitとの相性が悪い
 • GitHubのLanguageが汚れる 
 • パイプライン化しやすい 
 • コマンド1発で実行できる 
 • git管理しやすい
 • linter, formatterなどを設定しやすい 
 • 実装をインタラクティブに進めづらい 
 • チームでの共有に一手間かかることも 
 • Kaggle NotebookやColabでの実行はしづ らい
 • 実装の背景が伝わりづらい 

5. Notebookでユーティリティは分けるべきか
 5 • Kaggle NotebookではUtility Scriptという機能がある。 
 ◦ 自作ライブラリなどを切り出して他のノートブックからimportで きるようになる機能
 
 • 個人的には一切使っていない 
 ◦ わざわざ切り分ける意味がない、手間が増えるだけ 
 ◦ 使い道があるとしたら、複数のコンペでスクリプトを使い回す場 合だが、共通化できるほど抽象化しきれていない 
 
 • ローカルで学習する場合も同様 

6. スクリプトにおける流儀
 6 1実験1スクリプト派
 しっかりファイル分けする派 
 最低限ファイル分ける派 
 https://github.com/koukyo1994/kaggle-bengali-ai https://github.com/koukyo1994/kaggle-birdcall-resnet-baseline-training https://github.com/koukyo1994/riadd-competition
7. しっかりファイル分けする派
 • pudae/kaggle-hpa(https://github.com/pudae/kaggle-hpa )などのスタイル
 • loss, optimizer, schedulerなど要素ごとに切り分ける
 7 メリット
 • 理想的にはconfigを書き換えるだけで実験が行える 
 • 要素ごとに使い回しが効く(例: optimizerを他のコンペで使い回す、など) 
 • ファイルごとに用途が切り分けられているため、どこになんの処理が書いてある か把握しやすい
 デメリット
 • 後方互換性(過去の実験が回せる保証をすること)を保ちづらい 
 ◦ gitで管理していてもわざわざ過去のコミットに戻るのは手間 
 • 複数の要素に変更が生じると実装に手間がかかる 
 ◦ 例えばSAM Optimizerを使うとoptimizersに加えてtrainersも改修する必要 あり
 • チームで共有する場合、チームメンバーのキャッチアップが大変 

8. 最低限のファイル分けする派
 • koukyo1994/kaggle-birdcall-6th-place(https://github.com/koukyo1994/kaggle-birdcall-6th-plac e )などのスタイル
 • ある程度独立させられる要素(utilsなど)だけファイル分け
 • 切り分けをどれくらいするかは人による
 8 メリット
 • 理想的にはconfigを書き換えるだけで実験が行える 
 • 要素ごとに使い回しが効く(例: utilsを他のコンペで使い回す、など) 
 • ファイルごとに用途が切り分けられているため、どこになんの処理が書いてある か把握しやすい
 • 独立した要素を切り分けているので変更が必要なファイルが少ない 
 デメリット
 • 後方互換性(過去の実験が回せる保証をすること)を保ちづらい 
 ◦ gitで管理していてもわざわざ過去のコミットに戻るのは手間 
 • チームで共有する場合、チームメンバーのキャッチアップが大変 
 • 独立した要素を切り分けるといいつつ、完全に独立した要素というのはほとんど ない(utilsくらい)

9. 1実験1スクリプト派
 • koukyo1994/kaggle-birdclef2021( https://github.com/koukyo1994/kaggle-birdclef2021 )などのスタイル
 • 実験ごとに1枚のスクリプトを作る派 
 • Araiはこのスタイルに落ち着いた 
 9 メリット
 • 過去の実験の再現可能性を保証できる 
 • Notebookに移植しやすい 
 ◦ Colab, Kaggle Notebookなどで計算も容易 
 • ひとつのファイルを実行するのに必要な要素が揃っているため共有やデバッグが 容易
 デメリット
 • 実装が長い場合(1000行~)、だんだん見づらくなっていく 
 • ノートブックでよくね感がある 
 ◦ linter, formatterを使えるのでscriptの方がいいとは思っている 
 ◦ 開発容易性はノートブックの方が高い 
 • コンペ間で使い回しはしづらい 

10. アライの取り組みについて
 10 実験スクリプトと出力ディレクトリが一対一対応 
 セクション分けで検索性向上 
 get〇〇系メソッドを使いconfigを参照 するようにする

11. (Tips)パラメータチューニングの履歴をどうとるか
 11 実験管理ツール(MLFlow, wandbなど)はRunごとにスクリプトなどを保存できる 
 MLFlow
 https://mlflow.org/docs/latest/python_api/mlflow.html#mlflow.log_artifact wandb
 https://docs.wandb.ai/guides/track/advanced/save-restore
12. (Tips)オススメの抽象化の仕方
 12 • クラス、関数、メソッドなどを名前で管理できると便利だよ 
 • getattr, __getattribute__を使うとメソッドやクラス名を文字列 で扱えるため、Configなどに書いておける 
 ◦ Data AugmentationやLoss関数などをConfig管理す るのに便利
 • globals()でグローバル変数を辞書として取るのもConfig管 理に向いている

13. (Tips)ファイルの階層について
 • データ置き場はinput/<コンペ名>/...のようにす るといいよ
 ◦ Kaggleの環境と合わせられる 
 • スクリプトはinputと同じ階層にひとつフォルダ をおきその中に作成する
 • 良く打つコマンドはMakefileなどにまとめておく
 13