Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンペ中のコード、どうしてる?
Search
Hidehisa Arai
June 03, 2021
Programming
3
1.4k
コンペ中のコード、どうしてる?
データ分析コンペにおけるコードの管理に関するスライドです
Hidehisa Arai
June 03, 2021
Tweet
Share
More Decks by Hidehisa Arai
See All by Hidehisa Arai
ICML2021論文読み会資料
koukyo1994
2
1.5k
【2019-06-19】アルゴリズム勉強会 - 最小全域木
koukyo1994
0
140
Kaggle昔?話
koukyo1994
2
2k
変数間の関係を捉えたいあなたへ
koukyo1994
3
1.2k
脱! Deepでポン🎶ハイパラチューニング芸人を卒業するために
koukyo1994
8
4k
鳥蛙コンペ反省会資料
koukyo1994
3
1.1k
6th place solution to Cornell Birdcall Identification Challenge
koukyo1994
0
110
鳥コンペ反省会資料
koukyo1994
2
5.4k
最近話題のStreamlitでデモツールを作る
koukyo1994
1
1.3k
Other Decks in Programming
See All in Programming
20240301_cocone_EMゆるミートアップvol6_LT資料
cocone
0
260
PHP 8.3で追加されたjson_validate()を徹底的に深掘りしてみよう
mashirou1234
0
630
ログラスの継続的なプロンプト改善のためのLLMOpsの今 / LLMOps at loglass now
rkaga
PRO
1
330
【KMC春合宿2024】実装視点で見るNeural Radiance Fields
runningoutrate
0
130
Laravel標準バリデーションでできること
hmb_ok
1
330
Deno に Web 標準 API を実装する / Implementing Web Standard API to Deno
petamoriken
0
310
軽率にVue 3で リアルタイム3Dアプリを作れる ライブラリを作ってみた/vue-with-3d-app
drumath2237
3
1.2k
Next.js で SPA を構築する際の辛み
hayatow
0
220
Kotlinを用いたDSL的な設計手法と使用上の注意
kohii00
2
490
PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes(Amazon EKS) に移行する取り組み〜
tshinowpub
1
170
一休.comレストランのRustバックエンド開発の様子
kymmt90
13
7.9k
UnityプログラミングバイブルR6号宣伝&Unity Logging小話
adarapata
0
110
Featured
See All Featured
Optimizing for Happiness
mojombo
369
69k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
39
4.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
101
6.6k
Facilitating Awesome Meetings
lara
39
5.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
153
14k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
1
1.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
8
8.2k
Infographics Made Easy
chrislema
237
17k
Designing for Performance
lara
601
67k
Agile that works and the tools we love
rasmusluckow
323
20k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
18
6.8k
Transcript
コンペ中のコード、どうしてる? 2021/6/2 @ ニッチな分析コンペLT会 Hidehisa Arai 1
自己紹介 2 • 21新卒で機械学習エンジニア • Kaggle歴は3年くらい • 音系のコンペによく出ている
• 学生時代は航空宇宙 https://www.kaggle.com/hidehisaarai1213 https://twitter.com/kaggle_araisan https://github.com/koukyo1994
はじめに 3 ⚠注意事項 • 本発表は個人の信条を含んだ意見が多数含まれます。ご了承ください。 • 全員がこうするべき!という主張ではなく、私はこう考えています、くらいの温度感ですのでご 承知おきください。
話すこと • コードの構成やTipsについて話します。 • そんなこと知っとるわ、という話ばかりかもしれませんがお付き合いください。 話さないこと • 具体的なコンペの話はしません。
Notebook vs Script 4 Notebook Script メリット メリット デメリット デメリット
• Kaggle Notebookと相性がいい • 実装を進めやすい • チームでの共有が容易 • Textエリアに実装の背景などを書ける • とっ散らかりやすい • 実行までに一手間入る • gitとの相性が悪い • GitHubのLanguageが汚れる • パイプライン化しやすい • コマンド1発で実行できる • git管理しやすい • linter, formatterなどを設定しやすい • 実装をインタラクティブに進めづらい • チームでの共有に一手間かかることも • Kaggle NotebookやColabでの実行はしづ らい • 実装の背景が伝わりづらい
Notebookでユーティリティは分けるべきか 5 • Kaggle NotebookではUtility Scriptという機能がある。 ◦ 自作ライブラリなどを切り出して他のノートブックからimportで きるようになる機能
• 個人的には一切使っていない ◦ わざわざ切り分ける意味がない、手間が増えるだけ ◦ 使い道があるとしたら、複数のコンペでスクリプトを使い回す場 合だが、共通化できるほど抽象化しきれていない • ローカルで学習する場合も同様
スクリプトにおける流儀 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
しっかりファイル分けする派 • pudae/kaggle-hpa(https://github.com/pudae/kaggle-hpa )などのスタイル • loss, optimizer, schedulerなど要素ごとに切り分ける 7 メリット
• 理想的にはconfigを書き換えるだけで実験が行える • 要素ごとに使い回しが効く(例: optimizerを他のコンペで使い回す、など) • ファイルごとに用途が切り分けられているため、どこになんの処理が書いてある か把握しやすい デメリット • 後方互換性(過去の実験が回せる保証をすること)を保ちづらい ◦ gitで管理していてもわざわざ過去のコミットに戻るのは手間 • 複数の要素に変更が生じると実装に手間がかかる ◦ 例えばSAM Optimizerを使うとoptimizersに加えてtrainersも改修する必要 あり • チームで共有する場合、チームメンバーのキャッチアップが大変
最低限のファイル分けする派 • koukyo1994/kaggle-birdcall-6th-place(https://github.com/koukyo1994/kaggle-birdcall-6th-plac e )などのスタイル • ある程度独立させられる要素(utilsなど)だけファイル分け • 切り分けをどれくらいするかは人による 8
メリット • 理想的にはconfigを書き換えるだけで実験が行える • 要素ごとに使い回しが効く(例: utilsを他のコンペで使い回す、など) • ファイルごとに用途が切り分けられているため、どこになんの処理が書いてある か把握しやすい • 独立した要素を切り分けているので変更が必要なファイルが少ない デメリット • 後方互換性(過去の実験が回せる保証をすること)を保ちづらい ◦ gitで管理していてもわざわざ過去のコミットに戻るのは手間 • チームで共有する場合、チームメンバーのキャッチアップが大変 • 独立した要素を切り分けるといいつつ、完全に独立した要素というのはほとんど ない(utilsくらい)
1実験1スクリプト派 • koukyo1994/kaggle-birdclef2021( https://github.com/koukyo1994/kaggle-birdclef2021 )などのスタイル • 実験ごとに1枚のスクリプトを作る派 • Araiはこのスタイルに落ち着いた
9 メリット • 過去の実験の再現可能性を保証できる • Notebookに移植しやすい ◦ Colab, Kaggle Notebookなどで計算も容易 • ひとつのファイルを実行するのに必要な要素が揃っているため共有やデバッグが 容易 デメリット • 実装が長い場合(1000行~)、だんだん見づらくなっていく • ノートブックでよくね感がある ◦ linter, formatterを使えるのでscriptの方がいいとは思っている ◦ 開発容易性はノートブックの方が高い • コンペ間で使い回しはしづらい
アライの取り組みについて 10 実験スクリプトと出力ディレクトリが一対一対応 セクション分けで検索性向上 get〇〇系メソッドを使いconfigを参照 するようにする
(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
(Tips)オススメの抽象化の仕方 12 • クラス、関数、メソッドなどを名前で管理できると便利だよ • getattr, __getattribute__を使うとメソッドやクラス名を文字列 で扱えるため、Configなどに書いておける
◦ Data AugmentationやLoss関数などをConfig管理す るのに便利 • globals()でグローバル変数を辞書として取るのもConfig管 理に向いている
(Tips)ファイルの階層について • データ置き場はinput/<コンペ名>/...のようにす るといいよ ◦ Kaggleの環境と合わせられる • スクリプトはinputと同じ階層にひとつフォルダ をおきその中に作成する
• 良く打つコマンドはMakefileなどにまとめておく 13