今回は、KaggleのPublicスコアで初めてコンペ終了まで銅メダル圏内に残ることができました。しかしながら、Privateスコアでは一気に下がり、268位と大きくShakeDownすることになりました。
その原因の一つとして、現在の私のアプローチは、自身の知りうるデータの前処理、及びモデルを組み合わせて精度が上がる組み合わせを見つけるという実験的アプローチが主体であることがあります。
やはり、上位を目指すためには、コンペ自体の情報や、データの情報から、論理的に考えて効果が出るデータの前処理や、モデル選択が重要であることを再確認しました。
そこで、今回は、「鳥コンペ反省会」にて公開されている資料を拝見し、今後に活かしたい知見を自身のメモとして残していきたいと思います。
【目次】
1.鳥コンペ反省会 6位解法（Hidehisa Araiさん資料）
６位入賞で金メダルを獲得され、鳥コンペを主催くださいましたHidehisa Arai | Kaggleさんの資料です。
speakerdeck.com
この資料を拝見しての気づき。
・コンペで解決すべき課題を十分に理解しておく必要がある。
- TrainDataと、TestDataは、同じ条件下で取得、アノテーションされたデータであるとは限らない。→今回の場合、TrainDataとTestDataでは、入力の音声データが異なる性質をもつことはさることながら、ラベルの付け方に大きな差異があり、TrainDataの正解ラベルをそのまま使っても精度は上がらない。
- TrainDataのラベルが正しいとは限らない。→今回の場合、secondary_labelsというラベルがあったが、信頼性はない。（そもそも、ついていない場合もありました。）
・解決すべき課題を理解した上で、解決策は事象を分割して考える。
- 今回の場合は以下で対処されていた。
- TrainDataとTestDataの入力の性質の違い
→DataAugumentationでありうるバリエーションを網羅
- TrainDataとTestDataの正解ラベルの出現頻度の違い
→ラベル比率を変えたデータで学習させたモデルのアンサンブル
- TrainDataとTestDataのラベルの付け方の差異
→TrainDataのラベルを正しい（と予測される）ラベルに修正する。
・Discussionを重点的に目を通す。
- 参加者がやっていることを見るだけでなく、やっていないことを見つける上でも重要。
- 投稿することでも自分に有利になることがある。→議論を進める主導権を握ることで、コンペの流れを支配できる。
この資料を拝見して、私自身がまだまだ素人だと感じたことは、TrainData,TestDataは、同じ条件下で作成されている前提で取り組んでしまったことです。
また、コンペに取り組むにあたって、Overviewや、Dataの出自などを十分に確認せず、Discussionも余り目を通さず、データやモデルしかみていなかったことも良くなかったと反省しました。
これまでのコンペで、そこまで考慮していなかったのですが、通常の業務で考えたら、集められた手元のデータ（TrainData）と、これから解決すべき課題で使用するデータ（TestData）が異なる条件下のデータであることは、当たり前のように発生することを再認識いたしました。
2.鳥コンペで惨敗した話とコンペの取り組み方（fkubotaさん資料）
タイトルでは「惨敗」と記載されていましたが、最後までLBに惑わされずに取り組まれ、最終的にメダル圏外から大きく躍進して銅メダルを獲得されたfkubota | Kaggleさんの資料です。
speakerdeck.com
この資料を拝見しての気づき。
・コンペに対する心構え。
- 「Kaggleは長期戦」＝「情報戦」
- LBの上下に一喜一憂せず、愚直に知見を蓄積させる。
・アイデアの吐き出し場所を作る（issue boad）
- 思いついたらなんでも記録する。
- あとで読もうと思った論文や、DiscussionのURLを貼っておく。
- 読み返して、実装する。
→ 実施前の記録をつける
・やったことを書き残す（Kaggle日記）
- 作成したデータセットを記録する。
- やったことのログをかく。
- notebookの内容を関連するnotebookや、使ったデータセット、結果、感想などとともに記録しておく。
- 読んだ論文やDiscussionについても、反映したnotebookなどとともに記録しておく。
→ 実施後の記録をつける
- 記録した内容で思いついた内容は、issue boardに記録する。
- ５日に１度見返す。
この資料を拝見して、「Kaggleは情報戦」という見解は、目からウロコの見解でした。（何を今更とご指摘を受けるかもしれませんが・・・。）
これまで、答えがあることを前提（ラベルデータがキレイであることを前提）で、取り組んできましたが、答えがあっているとは限らないという前提に立つと、答えに近づくためにはどうしたらよいかという情報をいかに蓄積していくかということが重要だと再認識いたしました。
（これは、コンペに限らず、実業務においても同じだと思います。）
また、「Kaggle日記」は、これからKaggleに取り組むにあたって、非常に有効なツールであると思いました。私も実践してみたいと思います。
Kaggle日記の詳細解説はこちらに公開いただいています。
Kaggle日記という戦い方 | Zenn
3.鳥コンペ反省会（Takamichi Todaさん資料）
こちらも５００位以上大幅にShakeUpされ、鳥コンペでのモデルをWeb上にアプリも作成されていたTakamichi Toda | Kaggleさんの資料です。
docs.google.com
この資料を拝見しての気づき。
・計算リソースが確保できなくても工夫次第では取り組める。
- スペクトログラム画像をjpgで保存。
→情報が失われる、DataAugmentationが使えない等のデメリットを理解した上で進める。
・とにかくサブミットを実施して、検証する。
- サブミット回数１００回。
→私は２２回のみ・・・。
- 検証している手法も、CutMix, Denoise(SoundEnvelope, noisereduce), Transformer, WaveNet 等、多岐に渡る。
この資料を拝見して、これまで自分が試しているパターンは、全くもって足りていないと感じました。
量の面では、３桁は超えないとだめだと思いました。質の面では、２〜３の手法の組み合わせや、パラメータのパターンを試すのではなく、手法自体のパターンをたくさん試す必要があると思いました。
手法自体のパターンをたくさん試せるように、手持ちの手法を充実させていきたいです。
4.鳥コンペ振り返り（Takamichi Todaさん資料）
終了１ヶ月前から手をつけ始めて、１２２位に入賞し銅メダルを獲得された
ymicky | Kaggleさんの資料です。
docs.google.com
この資料を拝見しての気づき。
・コンペのフェーズ毎の戦略を分けていた。
- コンペ初期：Baselineカーネルからのパイプライン作成、信頼できるLocalCV作成の取り組み
- コンペ中盤〜終盤：公開notebookの改良、モデルの検証、DataAugmentation実施、画像サイズの拡大、secondary_labelの使用
この資料を拝見して、他の皆さんの資料にも共通して、コンペ初期は、まずコンペ自体を理解し、検証に使うための武器を準備されている期間を用意されていることに気づきました。
私は、この資料の中盤〜終盤で実施するようなことから着手し始めていて、闇雲に取り組んでいました。今後は、まずは、コンペ、データを理解し、戦略的にすすめて行きたいと思います。
5.63rd_Kaggle鳥コンペソリューション紹介（bird_musicチーム資料）
６３位に入賞し銀メダルを獲得されたjohann | Kaggleさん、nnnnio_pppira | Kaggleさん、Taro Masuda | Kaggleさん、yusuke_sato | Kaggleさんのチームでのご紹介いただいた資料です。
docs.google.com
この資料を拝見しての気づき。
・フィルタバンクをカスタマイズしていた。
- メルスペクトログラムは、人間の聴覚の解像度を模倣しているので、鳥が鳴いている周波数帯にフィルタバンクを変更していた。
・モデル自体は公開notebookのスキームをそのまま利用していた。
・アンサンブルにおいては、F1値が0.6未満と推測した上で、アンサンブル元となる予測ラベルを全部予測値に入れていた。
・今回のコンペだけでなく、過去のコンペのソリューション（CVの切り方など）を確認していた。
この資料を拝見して、公開notebookのスキームをそのまま利用するにあたっても、特性を理解した上で、それ以外のところで勝負したほうが良いと割り切った上で利用するのと、私のように闇雲に、いろいろ試した結果、公開notebookのモデルを超えられない状況で利用するのでは、ここまで差が大きくでるのかと思い知りました。
評価指標の特性を理解し、効果的な手法を選択しているところがすごいと感じました。
6.おわりに
今回、鳥コンペ反省会資料を拝見して一番大きく感じたのは、自分が、コードばかりに目を向けて教科書と照らし合わせて、精度を良くする手法の組み合わせや、パラメータ設定に重きをおいていたのに比べ、上位の皆様は、コンペの主題や、解決すべき課題に目を向け、取り組んでらっしゃった点です。
これは、コンペに限らず、実業務でも自身の作っているシステムの不具合やバグばかりに目が行きがちですが、本来の目的や、解決すべき課題に目を向ける必要があることを、再認識いたしました。
本当に、この鳥コンペは学びの多いコンペでした。
今後も、いろいろなコンペに参加して、精進していきたいと思います。
【これまでの道のり】
oregin-ai.hatenablog.com
