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
2.2k
コンペ中のコード、どうしてる?
データ分析コンペにおけるコードの管理に関するスライドです
Hidehisa Arai
June 03, 2021
Tweet
Share
More Decks by Hidehisa Arai
See All by Hidehisa Arai
生成AIの二大潮流と自動運転
koukyo1994
22
23k
ICML2021論文読み会資料
koukyo1994
2
1.6k
【2019-06-19】アルゴリズム勉強会 - 最小全域木
koukyo1994
0
250
Kaggle昔?話
koukyo1994
2
2.5k
変数間の関係を捉えたいあなたへ
koukyo1994
3
1.7k
脱! Deepでポン🎶ハイパラチューニング芸人を卒業するために
koukyo1994
7
4.7k
鳥蛙コンペ反省会資料
koukyo1994
3
1.4k
6th place solution to Cornell Birdcall Identification Challenge
koukyo1994
0
150
鳥コンペ反省会資料
koukyo1994
2
6.3k
Other Decks in Programming
See All in Programming
🔨 小さなビルドシステムを作る
momeemt
3
670
基礎から学ぶ大画面対応(Learning Large-Screen Support from the Ground Up)
tomoya0x00
0
400
Swift Updates - Learn Languages 2025
koher
2
470
ユーザーも開発者も悩ませない TV アプリ開発 ~Compose の内部実装から学ぶフォーカス制御~
taked137
0
140
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
210
アプリの "かわいい" を支えるアニメーションツールRiveについて
uetyo
0
220
サーバーサイドのビルド時間87倍高速化
plaidtech
PRO
0
720
「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
taitotnk
0
830
Android 16 × Jetpack Composeで縦書きテキストエディタを作ろう / Vertical Text Editor with Compose on Android 16
cc4966
0
170
Putting The Genie in the Bottle - A Crash Course on running LLMs on Android
iurysza
0
140
Go言語での実装を通して学ぶLLMファインチューニングの仕組み / fukuokago22-llm-peft
monochromegane
0
120
Oracle Database Technology Night 92 Database Connection control FAN-AC
oracle4engineer
PRO
1
440
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
RailsConf 2023
tenderlove
30
1.2k
Unsuck your backbone
ammeep
671
58k
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
BBQ
matthewcrist
89
9.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Balancing Empowerment & Direction
lara
3
620
Producing Creativity
orderedlist
PRO
347
40k
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