テスト駆動Kaggle

Transcript

1. あああ 関西Kaggler会 in Osaka 2025 #2 ISAKA Tsuyoshi
2. 自己紹介 名前：ISAKA Tsuyoshi（ねぼすけAI） 所属：ダイキン工業株式会社 趣味：Kaggle、Qiita、将棋、自作PC、 ポケポケ、ピクミン、フットサル 計算資源：RTX 5090、OpenAI API、RunPod 好きなコンペ ：LLMコンペなどの エンジニアリング要素が強いコンペ Kaggle：@isakatsuyoshi GitHub：@Isaka-code Qiita ：@Isaka-code X ：@AInebosuke Opinions are my own. I just came here as a Kaggler. 2 結果待ち：「Konwinski Prize」、「OpenAI to Z Challenge」 参加中：「NeurIPS - Open Polymer Prediction 2025」など
3. Kaggleで勝つために 他の人がしていない 　＆　価値があること 　をやる （皆がやっていて価値があることをやるのに加えて） → ソフトウェアテスト 3
4. Kaggleで一番辛い時 手元では動くコードが、サブミッション時はエラーを吐く時...。 
 エラーメッセージ無しでどうやってデバッグすれば良いのやら 
 原因は色々考えられますが... 
 「想定外の入力形式」「メモリ不足」「実行時間制限超過」など 
 → テストコード があれば救えたサブミッションがあったかも 
 友情出演：kprizeでチームを組んでくれたyawanagoさん（出身研究室の先輩） 4
5. エラーの原因 (推測) イタレーション ごとの実行時間制限を
 超えたことが原因のようでした。
 
 テストコードでこういったエラーを
 事前に潰しておきたい。 
 5
6. こんな経験ありませんか？ • ⚠止まらないエラー（APIのエラーメッセージが不親切） • ⏰長時間格闘したエラーの原因が、些細なことだった (例: ndarrayのshape) • 📉なぜかスコアが下がったと思ったら、バグを埋め込んでいた • 🔃再現性が取れなくなった • 💣何もしてないのにコードが壊れた 6
7. ソリューション そもそもKaggle環境でデバッグしたくない。 コードがバグったらすぐに気がつけるようにしたい。 → テストコードを書きながらKaggleに参加しよう！（テスト駆動 Kaggle） 7
8. 先ほどのエラーの後日談 実は、先ほどのエラーからすぐに原因を特定し、迅速なデバッグに成功しています。
 なぜか？ → エラーの箇所以外はテストコードを書いていたから！
 • 不具合: インターバルリミットでタイムアウト
 • 対策: タイムマネジメントクラスを実装
 • 予防: タイムマネジメントクラスのテストコードを作成
 テストコードのおかげで、実行時間超過の不具合は以降は発生しませんでした。
 不具合が生じてからテストコードを追加しても間に合います。むしろ、 そこはテストを書くべき重点領域 です。
 8
9. 機械学習における 3つのテスト対象 1. モデル 2. データ 3. コード←今日はこれの話 1. モデルのテストとは モデルが期待通りの性能を発揮しているか検証するこ と。精度だけでなく、予測の一貫性や異常なケースでの 挙動も確認する。「Trust CV」という言葉はKaggleにお いてあまりにも有名。 2. データのテストとは 学習・推論データの品質と整合性をチェックすること。欠 損値・外れ値・データ型などを検証する。EDA（探索的 データ分析）とも呼ばれる。 3. コードのテストとは 作成したコードが要件を満たしているかを検証すること。 機械学習プロジェクトでは、前処理関数、特徴量エンジ ニアリング関数、評価指標を計算する関数など、さまざ まなコードが対象になる。 9
10. src/utils/metrics.py tests/utils/test_metrics.py テストコードの具体例 プロダクトコードとは ： 普通のソースコードのこと テストコードとは ： プロダクトコードをテスト するコードのこと 10
11. テストコードの実行と自動化 ターミナルでのテスト実行 ：pytest [テスト対象ディレクトリ] [オプション] GitHub Actionsでの自動テスト ：例えばPushした時に自動でテストを走らせる。 11
12. テストコードを書くと何が嬉しいのか 🛡バグリスクの低減 人間のミスは避けられません。特にコンペ終盤の時間的プレッシャー下では、テスト コードが輝きます。 🤝チーム開発の効率化 コード品質が向上し、レビュー負荷が軽減。チームマージに対する心理的障壁が下が ります。 ⚡開発スピードの向上 テストというガードレールがあるので、安心して開発のストライドを大きく できます。AIコーディング支援ツールとの相性も抜群です。 ✨ 副次的効果 ソフトウェアエンジニアの方と仲良くなれるかも...？ 12
13. Kaggle参加時にテストコードを書く方法 簡単な方法：「ロジックはUtility Scriptに分離し、Notebookは呼び出しのみ」 1. Notebookにベタ書きからの卒業（関数やクラスに分割） 2. Utility Scriptに処理を切り出し （コードをGitHubに連携させ、開発はローカルで行う） 3. 切り出したスクリプトのテストコードを作成 4. 提出用Notebookからスクリプトをimport ＋αその1：上記の2で、Kaggle APIを用いて、ローカルの スクリプト群をDatasetとしてアップロードすることもできます ＋αその2：テストコードをプロダクトコードより先に書く手法は 「テスト駆動開発」と呼ばれます 13
14. (想像上の)FAQ「テストコードを書いている時間 がもったいなくないですか？」 • 経験上、数週間以上参加する場合は、時間的にもペイします。 • バグの心配がない状態でタスク理解にリソースを割けることが大きいです。 • 生成AIでプロダクトコードからテストケースを容易に作成できます。 • 全てのコードに書く必要はありません。コスパが良いところから始めましょう。 適切な書き方をすれば、損益分岐点は想像よりずっと小さいです。 14
15. テストコードを書く コスパが良い領域 まずは書きやすくて、効果が大きい分野を狙いましょう！ メトリクスや入出力処理がおすすめです。 なので、モデルコードから入出力の処理を分離すると◎ （テストが書きやすい≒良いコード） テストしやすい　＆　効果大 - メトリクス（基本的に変わらないので） - 入出力処理 (正規表現など ) テストしにくい　＆　効果大 - GPUが必要なモデル - タイムマネジメント テストしやすい　＆　効果小 - コンフィグやプロンプトは自明なので 効果は限定的 15
16. コンペでテストコードが特に役に立った事例の紹介① LLM 20 Questions (9位・solo gold medal) - 言葉当てゲーム「20 Questions」をプレイできるAIを開発するコンペ - 正規表現のスクリプト、各種アルゴリズム全てのテストコードを作成 - エンジニアリング力を武器にソロ金メダルを獲得 16
17. コンペでテストコードが特に役に立った事例の紹介② Konwinski Prize (Public 4位・Private N位) ※評価期間延長のため発表日時点ではPrivate順位未確定 - GitHubリポジトリにある実際のIssueをAIに解決させるコンペ - I/O系、タイムマネジメント、選択アルゴリズムなどのテストコードを作成 - サブミッション時エラーは1件のみ 17
18. どんなケースでソフトウェアテストが有効か？ 有効なコンペ - 1日のサブ数が少ない - 入出力処理が多い - 期間が長い - コード提出コンペ おすすめの人 - うっかりミスが多い人（私） - エラーで時間を溶かしたく ない人 - 本質部分に集中したい人 書くべきシチュエーション - デバッグに苦しんでいるとき - コードを共有するとき - 重めの計算を回す直前 - リファクタリング前 18
19. 何から始めるべきか？ - Python VTuberのサプーさんの動画と紙の書籍の『テスト駆動Python』がオススメです！ - 生成AIに聞きながら実装するのも良いと思います。 - もしよろしければ自分が書いた『機械学習のためのソフトウェアテスト入門』 という記事をご覧いただければ嬉しいです！（宣伝） 19
20. Thank you for listening, and happy Kaggling! 20