Kaggle Days Championship @ Barcelona に参加しました

こんにちは。ウォンテッドリーでデータサイエンティストをしている合田です。2022年10月28、29日にスペイン・バルセロナにて開催された Kaggle Days Championship Final Event に招待されて参加してきました。オフラインでKagglerたちと交流し、またコンペで競い合うことができて非常に有意義な時間を過ごすことができました。今回はこのイベントについて紹介しようと思います。なおイベントは業務として参加することができました。国際学会やKaggle Daysといったイベントへの参加を推進してくれる弊社ウォンテッドリーに感謝します。

Kaggle Days Championship Final Evnet とは

Kaggle Days Championship Final EventはLogicAIとKaggleが主催するイベントです。普段はオンライン上でKaggleのコンペに参加しているKagglerたちがオフラインで交流して競い合う場を提供してくれます。このイベントは参加条件が設定されており、2021年11月から2022年7月の間でオンラインで実施された計12回の予選イベントのいずれかで上位入賞する必要があります。私が所属するチームは2022年1月に開催された3回目の予選にて3位となり、出場権を得ることができました。

※ 画像は https://kaggledays.com/championship/finals/ から引用しています。

イベントの開催場所は、スペイン・バルセロナの本イベントスポンサーであるHPのオフィスでした。日本国外、しかもヨーロッパとかなり遠い場所での開催となりましたが、イベント主催者による渡航費や滞在費のサポートもあって参加することができました。予選での参加者は計5321人であり、本戦であるFinal Eventの参加はそのうち77人、24チームとなりました。

※ 画像はFinal Eventのコンペページ https://www.kaggle.com/competitions/stary-stary-night/leaderboard から引用。24のチームが白熱した競争を繰り広げました。

本イベントは2日間に渡って開催され、1日目にワークショップやプレゼンなどのコンテンツ、2日目に目玉コンテンツであるコンペティションが実施されました。以降では、私が参加したプレゼンやワークショップ、コンペの内容について紹介します。

Opening remarks by Kaggle

イベント1日目の始めには、KaggleのCEOであるD. SculleyさんがKaggleというプラットフォームの素晴らしさについて話していました。近年、MLやデータサイエンス領域の研究開発は爆発的な成長を遂げており、毎年約1万件ほどの論文が投稿されています。このような勢いがある一方で、研究分野に存在するいくつかの問題を指摘しています。例えば新しい手法を提案する論文が大半を占めるというNovelty Bias、ポジティブな結果を示す論文しか採択されないというPositive Result Bias、単一のベンチマークを使った評価が繰り返されることで汎化性の低い結果に導かれるというSingle Benchmark Bias、計算量が多い研究の方が一般的には有利というResource Biasなど、様々なバイアスによって適切な問題設計や解法から外れてしまう可能性があります。

これらの問題を対処するためには大きなコミュニティが必要だと述べています。学問的なインセンティブにとらわれない大勢の人が同じ問題に対して情熱を持って取り組むことができるような構造を作り上げることで、競争の中で生まれたアイデアや論文として公開されている提案手法がどのように機能してどんな結果になるのかを客観的な基準に基づいて評価することができ、最も重要なポイントである「何がうまく機能するか」を学べる環境を実現することができます。

またコミュニティを成長させていくためにはコミュニティ内の知識共有を促進することが重要だと述べており、Kaggleではフォーラムの健全性や情報共有の効率化など様々な観点でのコミュニティの改善を進めています。

Presentation - DetHub - Open source object detection experiments hub

HPのアンバサダーである大越拓実さんによる講演では、OSS開発のモチベーションと開発を進めているOSSのDetHubが紹介されました。

大越さんは以前は一人でMLパイプラインを開発していましたが、開発と運用を進めていくにつれていくつかの問題にぶつかりました。開発スピードやアイデアに限界があることやコードやテストの品質が低いことを課題として認識し、これらに対処するためにOSSの開発に着手されています。自前のコードをOSS化することで、世界中のコントリビューターによってコードやテストの品質を高く保ちつつ多くの新しいアイデアを迅速に実装・検証できるようにしています。

大越さんが開発を進めているDetHubは、Object Detection / Instance Segmentationのタスクをベースに様々なデータセットで提案手法の性能評価を実施できるExperiment Hubです。ベースラインとなるモデルや評価に利用するデータセットなどをそれぞれ複数種類サポートしており、簡単な設定で実験できるようになっています。今後の開発ではデータセットやモデル、対応タスクの拡充を予定されています。

Presentation - Winners team presentation

この講演では予選で総合優勝を果たしたチームSSSSによる短期間コンペの取り組み方が紹介されました。計12回実施された予選では順位に応じてポイントが付与される形式になっており、予選における累計ポイントが最も高かったチームが総合優勝となります。つまり総合優勝というのは予選でコンスタントに上位入賞できた証でもあり、その秘訣がこの講演で共有されました。現時点ではスライド資料が公開されていないため、以下には概要だけを書きます。

予選ではテーブル形式、NLP、CVと異なるデータ形式のコンペがバランス良く登場していました。チームSSSSは短い時間で効率よくスコアを上げるために短期間コンペならではのチームの動き方を決めて実践しており、またどの形式のコンペが来ても対応できるように想定されたデータ形式ごとにEDA、モデリング、実験の効率的なアプローチを確立させてコンペに取り組んでいたそうです。講演では動き方やアプローチの具体的な内容について共有されました。

Competition

コンペの概要

FINAL EVENTでは非常に面白いコンペ形式が採用されました。チームの条件人数は4人、コンペ期間は11時間であり、時間内に2種類のコンペを取り組む必要がありました。2種類のコンペはそれぞれ異なる特徴を持っており、1つ目のコンペである「Starry Starry Night!(以降コンペ1と呼称)」は Time Series + 欠損データ + NLP、2つ目のコンペである「Time isn't the main thing, it's the only thing(以降コンペ2と呼称)」は NLP + Regression という特徴を持っていました。

コンペ毎に順位に基づいたスコアがチームに与えられ、各コンペのスコアの合計で最終順位を競い合います。上位3チームにはGPU A6000が、更に優勝チームにはモバイルワークステーションが授与されることになっており、発表時には会場では大きな驚きが巻き起こっていました。

私達のチームの取り組み

私達のチームは4人で構成されており、効率よく取り組むために1つのコンペにつき2人ずつ割り当てて作業を進めていきました。私はコンペ2の方に取り組んでいたので、この記事ではコンペ2側の取り組みについて紹介します。

コンペ Time isn't the main thing, it's the only thing は、Kaggle の公開notebookの情報が与えられ、そのnotebookの総実行時間を予測するというタスクです。与えられたデータセットはnotebookのセルごとのコードと実行時間、そしてnotebookごとの入出力ファイル情報（ファイルのカラム数やレコード数、サイズや拡張子など）があります。評価指標はRMSEで、ターゲットとなる総実行時間の分布は値が小さい領域に鋭いピークを持ち、少数の総実行時間の大きいサンプルを正しく予測できるかどうかでスコアが大きく変動します。

コンペ序盤は、NLPコンペで恒例の事前学習済みTransformerベースモデルで取り組んでいました。具体的には、セルごとにコードを入力として実行時間を予測するモデルを学習して、セルごとの予測結果をnotebook単位に集約して総実行時間を求めていました。ただこの形式での学習結果はナイーブな予測（例えば平均値予測）とほぼ変わらず、事前学習済みモデルの利用が本質的に重要でないことが分かりました。

次に予実の乖離が大きいサンプルを定性的に評価し、有効なアプローチを探してみました。今回のコンペのKaggle notebookのデータは普段Kaggleを取り組んでいる私達にとって非常に馴染み深いものであり、予測を大きく外していたサンプルの中にはチームメンバーが作成したnotebook（もしくはその公開されたnotebookをforkして作成されたもの）もあったりして、総実行時間の予測は直感的には簡単そうに思えました。例えば Random Forestモデルを学習しているnotebookであれば実行時間は短そうですし、逆にDeep Learningモデルの学習を行っているnotebookであれば実行時間は非常に長くなりそうです。そこで試しにnotebookにおけるmodule名（例えば、torchやtensorflowなど）の登場回数を特徴量に採用してgbdtモデルで学習してみたところ、スコアを大きく改善できました。

あとは、Kaggle notebookに詳しい私達のドメイン知識を頼りに、総実行時間の長さを判断できそうなワードを採用してnotebookごとの登場回数を計算するだけです。ここからはチームメンバーと関連しそうなワードを出していくだけの作業でしたが、実際やればやるほどスコアが伸びていくのは楽しかったです。より詳細なソリューションは以下のdiscussionにまとめているのでご覧ください。具体的にどういうワードを採用して特徴量を作っていたか、どのようなワードの重要度が高かったかを記載しています。

このコンペ2では、最終的にPublic LB3位に着地しました。もう片方のコンペもPublic 6位となり、両コンペの結果を合わせた最終順位もかなり良い位置になるんじゃないかとソワソワしていました。

※ 画像はコンペ中盤のときのPublic LBの様子で、私達のチームの順位が最も良かったタイミングでした（チーム名 sowasowa）。11時間じゃなくて6時間コンペだったら良かったのに、と思ってました。

コンペの結果

最終結果ですが、期待に反して私達のチームは最終順位3位以内には入れませんでした。コンペ2ではPublic 3位からPrivate 11位と大きくshake downしてしまいました。少数の総実行時間の大きいサンプルの影響が強く、他のチームと比べてPrivate Test Datasetでいくつかのサンプルの予測を外してしまったことが原因だと考えています。また結果論ではありますが、より安定性が高かったコンペ1にリソースを多く割くべきでした。

現地の様子

最後に現地での様子をいくつか紹介します。Kaggle Days Championship はHPの広大なオフィスで実施され、そこで多くのKagglerと交流をしたりコンペしたりと充実した時間を送ることができました。また初めてのバルセロナ滞在を経験し、多くの日本との違いを味わうことができました。

画像は2日目のコンペの様子

バルセロナ滞在中はひたすらパエリアを食べました

最後に

Kaggleのオフラインイベントは2019年以来の参加となりました。やはりオフラインでの交流は何者にも代えがたいものだと感じましたし、Kaggleや英語のモチベーションを大きく上げることができました。Kaggle Days Championshipは来年以降も開催を検討しているみたいなので、ぜひ次回以降も参加して今回のリベンジを果たしたいと思っています。