Kaggle振り返り – Help Protect the Great Barrier Reef

数年ぶりにKaggle復帰してみようということで。
若い頃はKaggleに時間を奪われすぎていたのと、家庭を持ってからは個人活動の優先度が著しく下がったこともあり、実は2,3年前に一度退会して足を洗っていました。ただ、最近はKaggle Notebook環境がまぁまぁ使えて環境格差が昔よりはマシになったとか画像コンペが多くて楽しいとかそういう話をいろいろ聞いて、また一から始めてみようかなぁと。煙草とか酒とか麻薬と同じなんでしょうか。子育ての時間を削るのは良いことだとは全然思いませんが、本当にすみません。

さて、1月下旬くらいからこちらのコンペにソロで参加しました。別にTensorFlow縛りはありません。

最初のsubmitから数えると参加期間としては25日で3週間半、毎日最低1時間は確保し、Kaggle Notebook環境をフル活用してなんとか完走(?はしました。

結果から書くと、

  • Public LB: 309th / 2,109
  • Private LB: 258th / 2,109 (Top 12%)

(※ 2/15時点の暫定順位、このあとチーターとか不正ユーザーがLBから排除され最終順位が確定)

ということで普通に惨敗という結果に砕け散りました:( ものすごいshake downしたとかなら良いネタになるんですが、結果が地味すぎてネタにもならない感じが暖まりますね。

コンペ概要

動画(時系列画像)からオニヒトデをひたすら検出するタスクです。これは日本でも結構有名な環境問題の一つだと思いますが、オニヒトデが珊瑚礁を食べてしまって環境破壊になるのでなんとかしたいという話です。世界中のKagglerが電力とCO2排出量増加に貢献してると思うのでそっちの方もなんとかしたらいいのにとは思います。

特徴的なのは評価指標がF2-Scoreということ、F2は業務でも使った記憶が無いんですがFbetaは以下の通りです。

betaが2なので5pr / (4p + r) となり、recall重視でFPはそんなに気にしなくていいということになります。とにかくオニヒトデは一匹残らず駆逐するつもりのようです。あれ食べられないらしいし、人間にとっては別にいなくても大丈夫ということなんでしょうか。

手法

コンペ終了後の参加者の公開ソリューションを眺めていて、自分の手法や方向性はそれほど悪くなかったようで少し安心しました。このコンペはありがたいことに4つもfinal submissionを出せるので以下のバリエーションを選びました。

  • YOLOv5 + YOLOX 2 models Weighted Boxes Fusion (WBF) ensemble (Best Public LB)
  • YOLOv5 + Tracking
  • YOLOv5 3 models same resolution(3200px) WBF ensemble
  • YOLOv5 3 models different resolution(4800/5760/6400px) WBF ensemble (Private LB 258th solution)

僕が参加したときは多くの参加者がYOLOv5を使っている状況だったので僕も最後までYOLOシリーズ(YOLOv5とYOLOX)を使っていました。CVは共通してsubsequence(各fold内に偏り無く良い感じの数のヒトデがいる)と呼ばれていた切り方を使わせてもらいました。

コンペ全体のキーポイントとしては画像を高解像度で学習・推論するという点で、コンペの終盤は高解像度合戦が始まりました。そして案の定「このコンペGPU Warじゃないか!」ということでDiscussionがちょっと荒れてましたね。個人的にはKaggle NotebookはP100が使えるので昔に比べたら超高性能でありがたいのですが、週に30-40hという制限が地味に厳しかったです。1モデルにつきCV評価も含めて9時間めいっぱい使うと1週間で3個くらいしかモデルが試せないことになるし、ソロ参加なので実験数が足りないと、、。技術的にはバッチサイズが1か2じゃないとVRAMが足りず動かなかったので、Batch Normalizationが効きにくく学習が安定しないだろうなぁという不安はありました(実際は大きなバッチサイズで試せてないのでわからない)。

YOLOv5モデルのアンサンブル方針が超有名GMのChris Deotte氏と同じだったのはうれしかったです。WBF後にもconfidenceの閾値を設けて足切りするとちょっとFP減らせるよなぁと思って試したら効果があったので採用したのは良い選択でした。ただ、F2スコアへの貢献度から考えると、LB 200-300thくらいの位置でやる対策としては尚早だったということでしょうか。

上位のソリューションだと、CenterNet / FCOS / EfficientDet あたりを使っているチームもいました。Yoloしか試す余裕がなかったのでこれらのモデルもぜひ試してみたかったですね。

また、自身のBest Private LB ScoreだとF2=0.676で130thくらいの位置でした。全体で銅圏(ブロンズ)のsubが2つありましたが、なんといずれもシングルモデル。最終的にはアンサンブルモデルを提出したのでこれらはfinal subに選択しなかったということです。こういうのよくあるよね。

高解像度がなぜ効くのか

学習データの画像解像度が720p(1280x720px,時系列画像)で、これを例えば3200x1800pxにリサイズして学習・推論させるとLBスコアが上がるという現象がコンペ参加者の共通認識としてありました。感覚的にはそんなことある?と思った人は多かったんじゃないかと思いますが、実際効果はあったのでまぁみんなマネしますよね。YOLOv5の場合、アンカーのストライドの最小値が変換後の座標で固定されるので、元解像度(1280×720)座標上でのストライドも小さくなり、結果としてrecallが良くなるということのようです。つまり今回のデータセットのように小さいヒトデがたくさんいる場合はアンカーがぎちぎちに敷かれるおかげで取りこぼしにくいということでしょうか。解像度を上げつつアンカー周りのパラメータは変えずに学習するというのが良かったようです。知らんけど。
参考: アンカー ボックスによるオブジェクトの検出 – MATLAB & Simulink – MathWorks

敗因は

格ゲーでもFPSのランクマッチでも負け試合を公開できるかどうかで器量がわかるというものですが、強くなるために敗因分析をしてみます。

いつも結果論ではありますが、シンプルにTrust your CVを実践しきれていなかったのは大きいとは思います。シングルモデルのCVはきっちり測っていましたが、アンサンブル後のCVは前述した通りKaggleのGPU時間制限(30-40h/week)の都合上、全く測ってなかったのが致命的でした。

一方で、銅圏に入っていたsubはYOLOv5(yolov5s6とyolov5m6)のシングルモデルだったのですが、それらはCVも悪くないモデルでした。シングルモデルのCVはPrivate LBとまぁまぁ相関はあったので、シングルモデルの構築はそれなりに上手くできていたと思います。これは収穫です。結局、アンサンブルモデルのスコアはシングルモデルよりも低かったのですが、前述の通りアンサンブル後のCVを測っていれば各種パラメータの追加検討等ができるので方針は問題なかったと思います。シングルモデルのCVは信じることができていたので、それらのアンサンブルなら上手くいってるだろうという浅はかな考えでsubmitしたというだけです。ちなみにオブジェクトトラッキングの併用はあんまり上手くいきませんでした。

コンペ締め切りの3日前くらいからはNMSのconfidenceとIoUの閾値を脳死で弄るだけおじさんになっていたので、これ以上続けてもPublic LBにオーバフィットさせ続けていただろうなと思います。なので、悔しいですが順当な結果なので納得感はあります。

敗因をまとめると「シングルモデルの検証は丁寧にできたけど、アンサンブル後のCV評価を全くしていなかった」ということかなと。新しい課題ではなく、やっぱりCVは大切だよなという常識を再認識できたという点は良かったです。

感想

このコンペはRemek Kinas氏というヒーローがいて、狂ったように3点リーダー(…)を駆使するユーモアと高い技術力によりソロ参加者にとっては本当に励みになりました。公開されるNotebookは教育的観点も含めて良く構成されたものでそこから多くの学びを得ました。コンペ終了8日前くらいにハイスコアのNotebookが公開されてしまったため、Public LBの銅圏あたりにいた人達は顔真っ赤にして良い具合に暖まっていたようですが、GMの方々はもちろん、このRemek氏もいたおかげでコンペの雰囲気というか民度がなんとか保たれていたのだと思います。many thanks Remek.

数年ぶりのKaggleコンペ、結果は残念でしたが無課金でも十分楽しめるゲームでした。きっとこれからオニヒトデが駆逐されグレートバリアリーフは守られるのでしょう。しかし、今回のコンペのマネーゾーンの方々は黄色率高すぎませんかね。強すぎる。お金欲しい。

あわせて読む:

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です