Kaggle Days Championship Final 参加記（majimekunチーム）

はじめに

こんにちは。 Kaggle Days Championship というイベントにmajimekunチームとして参加しました。メンバーは若月、翁、桑原の3人です。

このイベントは、全12回のオンライン予選（短時間のKaggleコンペ）のいずれかで上位の成績を収めたチームが、オンサイトの決勝イベントに招待され、交流およびコンペを行うイベントです。我々は4回程予選に参加し、そのうちの一つで上位に入ることができ、決勝イベントへ招待されました。

この記事では、予選と決勝のコンペの取り組み内容および決勝イベントについて紹介します。

予選

予選は1ヶ月に1回くらいの間隔で全12回開かれて、ある回で上位3チームに入っていれば決勝に出られることになっていました。コンテストは世界各地の都市の現地時間を基準に開催され、夕方から4時間でした。データとしてはテーブル、自然言語、画像など色々な形式が出題されていました。自然言語系や画像系のタスクに対しては何も準備していないと4時間では時間が足りなさそうなので、途中からは典型的なタスクに対してend-to-endで実行できるようなコードの簡単なテンプレートを作っておくようにしました。このおかげで、コンテストを有利に進められたと思います。

majimekunチームは第8回のニューヨーク回で優勝して決勝出場の権利を得ました。ニューヨークの回は日本時間朝の6時から開始だったので睡眠調整をしてから臨みました。

ニューヨーク回のタスクとしてはシンプルで、本の情報、ユーザーの情報、ユーザーが本に対してつけた10段階の評価が与えられ、未知のユーザーと本の組に対して評価を推測するという問題でした。問題としてはシンプルですが、4時間という短い時間の中で色々な手法を試す必要があり、普段の長期間のコンペとは違って瞬発力が試されました。簡単な解法はKaggleの Discussion に書きました。

決勝

2022年10月28日、29日の2日間で本イベントスポンサーであるHPのバルセロナオフィスで開催されました。予選で上位に入り決勝へ参加する権利を得たチームの内、24チームが参加しました。オンサイトのみでの開催だったので、都合が合わず、参加できないチームもあったようです。

1日目

イベントの主催者、スポンサー、Kagglerなどによるプレゼンテーションやワークショップがありました。以下に印象に残ったものを記載します。

Opening remarks by LogicAI & Kaggle

LogicAIのCEOは、今回のイベントの規模、開催趣旨などについて話していました。オンラインではなくオンサイトで開催したのは、とにかく参加者同士で交流して欲しいからだと言っていたのが印象的で、Kaggleというコミュニティーを盛り上げたいという強い意思を感じました。

KaggleのCEOは、Kaggleというプラットフォームの特徴について話していました。機械学習の研究分野には、特定のベンチマークとなるデータセットに対してのみモデルの性能が評価されるというSingle Benchmark Biasや良い結果だけが論文に投稿されるというPositive Result Biasなどのいくつかのバイアスがあります。 Kaggleでは、様々なデータセットに対してモデルの評価が行われ、その結果がNotebookやDiscussionを通してうまくいかなかったものも含めて共有されるため、それらのバイアスの解消に貢献しているようです。よくある競技プログラミングのコンペと違ってコンペ中に情報共有できるようにしていることに違和感を感じていましたが、今回の話を聞いて納得しました。

Winners team presentation

予選で優勝したチーム（12回の予選の累計ポイントが最も高かったチーム）によるプレゼンテーションでは、それぞれのコンペの概要と上位の解法が紹介されていました。画像、自然言語、テーブルコンペそれぞれにおいて、最近よく使われるているモデルや手法を知ることができ、とても参考になりました。また、予選は4時間という短い時間のコンペだったので、ここで紹介された解法や短期間コンペへの取り組み方は、長期コンペのベースラインを作成する際に参考になると思いました。スライドは、こちらで公開されているようです。

ワークショップ

ワークショップの一つでは、Kaggle Grandmasterにより、シミュレーション系コンペの取り組み方が紹介されていました。

Connect X というゲームを題材に、エージェントを作成し、それをローカルで比較・可視化するテクニックや、エージェントの様々な作成方法（ルールベース、ゲーム木探索、教師あり学習、強化学習など）が紹介されていて、シミュレーション系のコンペに参加する際には参考になるかと思いました。 Notebookはこちらで公開されています。

2日目

2種類のコンペが同時に開催されました。コンペ時間は11時間で、それぞれのコンペの順位に応じたスコアの合計で最終順位が決まります。我々は担当する問題を完全に分けて、それぞれのコンペに取り組みました。

1問目

問題： Starry Starry Night!

光害（不要な光によって夜空が見えづらくなること）の度合いを推測するという問題でした。日時、緯度経度や標高、センサーを読み取った値、空の様子や観測値に関するコメントが情報として与えられます。 1日目の終わりの発表によると、タスクはtime series, imputation, NLPの要素を含むという情報があり、特にNLPはそんなに準備していなかったので心配していましたが、使える情報のごく一部であることがわかり一旦安心しました。

実際に取り組んだ流れを時系列順に示します。

問題を読んだ。チーム内の担当は問題で完全に分けていたが一応共有した。
time seriesデータはtrainとtestは期間で重複がないように割られていることが多いが、ごちゃ混ぜになっていることを確認した。
緯度経度に関してもtrainとtestで分布が特に違わないことを確認した。完全に一致する点もある程度含まれていることを確認した。
バリデーションデータの作成：データを見た感じではtrainとtestの分割方法がわからないので、ひとまず時系列性や緯度経度を考慮せずランダムに分割することにした。
ベースラインの作成：カテゴリカル変数のカーディナリティは低いのでラベルエンコーディングをして、GBDTによるベースラインを作成した。予選で書いたコードがそのまま使い回せることに途中で気付いてタイムロス。
コメント系カラムはひとまずtf-idfを通したものを入れたが、スコアがあまり改善しないことを確認した。これ以降筆者の中でのコメントカラムの重要度が下がる（これが大きな間違い）。
センサー値の特徴量重要度が高く、欠損率も高く、実際にラベルとの相関が強く、コンペにはimputationの要素があるというので、センサーの値をうまく補完することが重要と推測する（これも間違い）。
緯度経度が近いレコードのセンサー値の統計量を出し、それを特徴量に加えて微改善。
Public順位表で他チームとのスコア差が大きいことをみて、致命的な見落としがないか気にしだす。
チームメイトと議論するも行き詰まる。
センサー値の他にラベルもリークを気にしながら入れるもリークさせてしまい、trainとtestの分け方もわかっていないので行き詰まる。
コンテスト時間終了。

結果は惨敗でした。上位の解法やコンペ終了後に他の参加者から聞いた情報によると、コメントを使うのが重要だったようです。tf-idfでもそうですし、学習済みのトランスフォーマー系モデルの出力を特徴量に加えるとスコアが大きく伸びたようです。筆者はtf-idfを少し試してそれほど大きくスコアが改善せず、見た目的にも効かなさそうといって初期の段階で捨ててしまったのが良くなかったです。限られたコンペ時間とはいえ、もう一回見直すことができれば良かったと思います。今回は全然だめでしたが、また同じような形式のコンペに出る場合は今回の反省を踏まえてリベンジしたいです。

2問目

問題： Time isn’t the main thing, it’s the only thing

2問目はKaggle Notebookにおける実行時間を予測する問題でした。具体的には以下のようなデータが与えられました。

train/testのnotebook_idごとの総実行時間
各Notebookの作者のKaggle上のtier（Novice, Expert, Master, Grandmaster etc.）
各Notebookで使われるdatasourceの情報
- ファイル名、ファイルサイズ、拡張子、行数/列数
各Notebookの各Cellのソースコード
（訓練データのみ）各Cellごとの実行時間

notebook_idごとの総実行時間を予測しRoot Mean Squared Errorで評価を行うタスクとなっていました。

以下のような時系列順で問題に取り組みました。

まずはLightGBMを使ったベースラインの作成に着手しました。セルごとの実行時間を予測するモデルを作り、最後に和を取る方法を取りました。特徴量としてはそれぞれの Notebookで使われるファイルのファイルサイズの総和、ファイル数、各拡張子の出現頻度、Cell内のソースコードをtf-idfでベクトル化したものを使いました。
初回のsubmitで下から2番目の順位と、上位と大きく差が開いてる状態となりました。
次に以下の2点に着目して改善を行いました。
- Cellごとに予測するとNotebook内のグローバルな情報（どのようなライブラリ使ってるか、エポック数をいくつに設定してるか）が活用出来ないと考え、最初から Notebook全体の実行時間を予測するように変更。
- また、画像や自然言語処理等の深層学習を用いたNotebookの方が実行時間が長い傾向になるだろうと予測し、Notebook内でTensorFlowやPyTorchが使われているかをフラグとして持たせるよう特徴量エンジニアリング。
これらの変更に加え K-Foldでモデルを複数学習しアンサンブルすることで中盤1位に浮上することが出来ました。

leaderboard — 中盤でPublic1位になった時のLeaderboard

その後は効きそうなフラグを追加する等、細かいチューニングを加えるも大きくスコアを伸ばすことは出来ず、またPublic順位表に過適合したsubmissionを選んでしまったこともあり、最終的には6位に終わりました。

コンペ終了後に他チームの解法も聞きましたが、概ね我々と同じ手法を使っていた印象でした。上位のチームは様々な損失関数を使ったり、複数種類のモデルをアンサンブルすることによってPrivate順位表でも安定するよう工夫していました。惜しくも上位に入ることは出来ませんでしたが、今回学んだことを糧に次回はより上位に入れるよう精進したいです。