$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンペ中のコード、どうしてる?
Search
Hidehisa Arai
June 03, 2021
Programming
3
1.9k
コンペ中のコード、どうしてる?
データ分析コンペにおけるコードの管理に関するスライドです
Hidehisa Arai
June 03, 2021
Tweet
Share
More Decks by Hidehisa Arai
See All by Hidehisa Arai
生成AIの二大潮流と自動運転
koukyo1994
21
13k
ICML2021論文読み会資料
koukyo1994
2
1.5k
【2019-06-19】アルゴリズム勉強会 - 最小全域木
koukyo1994
0
190
Kaggle昔?話
koukyo1994
2
2.3k
変数間の関係を捉えたいあなたへ
koukyo1994
3
1.4k
脱! Deepでポン🎶ハイパラチューニング芸人を卒業するために
koukyo1994
8
4.4k
鳥蛙コンペ反省会資料
koukyo1994
3
1.3k
6th place solution to Cornell Birdcall Identification Challenge
koukyo1994
0
120
鳥コンペ反省会資料
koukyo1994
2
5.8k
Other Decks in Programming
See All in Programming
As an Engineers, let's build the CRM system via LINE Official Account 2.0
clonn
1
560
大規模サイトリビルドの現場から:成功と失敗のリアルな教訓 / Site Rebuild,Real Lessons Learned from Successes and Failures_JJUG Fall 2024
techtekt
0
190
watsonx.ai Dojo #4 生成AIを使ったアプリ開発、応用編
oniak3ibm
PRO
1
260
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
380
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
7
7.9k
Cognitoが大型アップデート!Managed Loginとパスワードレスログインを実際に使ってみた@しむそくRadio Special Day1
tmhirai
2
120
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
340
Jakarta EE meets AI
ivargrimstad
0
760
競技プログラミングで 基礎体力を身につけよう / You can get basic skills through competitive programming
mdstoy
0
130
PaaSとSaaSの境目で信頼性と開発速度を両立する 〜TROCCO®︎のこれまでとこれから〜
gtnao
5
5.6k
[KR] Open-Source Ecosystems
skydoves
0
110
PipeCDの歩き方
kuro_kurorrr
3
130
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
17k
Adopting Sorbet at Scale
ufuk
73
9.1k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Music & Morning Musume
bryan
46
6.2k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
KATA
mclloyd
29
14k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Visualization
eitanlees
145
15k
Teambox: Starting and Learning
jrom
133
8.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
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