鳥コンペで惨敗した話とコンペの取り組み方

Transcript

1. 鳥コンペに惨敗した話
 と
 コンペの取り組み方
 fkubota

2. 自己紹介 fkubota (twitter, Kaggle) - Kaggle Expert - 沖縄出身(東京に出てきて2年半) - 物理学科出身(強相関電子系) - プログラミング歴は2年弱ぐらい - 趣味 - 早起き(4時半起床) - Kaggle - コーヒー、ビール、ウィスキー - 読書、物理、哲学 - Kaggler と飲みたい(早起きより飲み会優先 ) Kaggle歴 (これまであまり積極的ではなかったが、鳥コンペで とうとう沼に落ちた) - 初参加 - 分子コンペ - ソロ銅メダル(234/2749位) - 2回目 - イオンコンペ - ソロ銀メダル(22/2618位) - 3回目(画像系のコンペ初挑戦 ) - 鳥コンペ - チーム銅メダル(114/1390位)
3. チーム紹介 チーム名: We_don’t_like_nocall 2人とも画像系のコンペ初参戦のクソザコ
4. 鳥コンペに惨敗した話
5. 鳥コンペとは(ざっくり) 音ファイルが与えられる ---> 5secごとにどの鳥が鳴いているか当てる birdA birdB nocall birdC, birdD birdE 鳴いていないという選 択肢もある 5sec以内に複数羽鳴 くこともある
6. トレーニングデータの構成 aldfly ameavo amebit yetvir … … … … … train_audio/ - 264種類の鳥 - ファイルの長さは統一されてない (1sec以下もあ る) - 鳥ごとにファイル数も異なる train.csv - 音ファイルのメタ情報 - カラム数 = 35 - 例えば - rating: 集音の質 - duraion: 音データの長さ - location: 集音した場所 - secondary_labels: 他に鳴いている鳥 - などなど
7. 鳥コンペが難しいとされる理由 ノイジーな トレーニングデータ トレーニングデータと テストデータの 本質的な違い
8. ノイジーなトレーニングデータ ラベルと違う鳥 ラベル通りの鳥 - 他の鳥が複数羽混ざってることがある - secondaly_label として他の鳥が混ざっ ていることがわかっているデータもある がわかっていないデータもある - 学習時にランダムクロップを行なうが鳥 の鳴き声が入らないことがある 他の鳥の鳴き声も入る 鳴いていない場所もかなり多い 背景雑音
9. トレーニングデータとテストデータの本質的な違い aldfly ameavo amebit yetvir … … … … … 264クラスの分類を 行なうモデル こんな問題だったら簡単だった - 1羽だけ鳴く ---> 264クラス分類 今回の問題 - 同時に複数羽鳴くことも - 鳴いていない(nocall)場合も - nocallはデータとして与えられて いない Test Data Training Data 今回は、この複数羽鳴くことに対して行った処理から 惨敗した理由に至るまでを話します
10. どうやって複数羽を特定するのか？ aldfly ameavo amebit yetvir … … … … … 264クラスの分類を 行なうモデル(ResNet) このコンペで最もスタンダードな方法 (araiさんのノートブック) Training Inference ResNet 全結合層の出力を sigmoidで0~1にし て出力 aldfly ameavo amebit yetvir … thresholdを上回るもの提出 1つも上回らなければ nocallとする
11. 複数羽推論の疑問 1羽 1羽 2羽 aldfly ameavo amebit yetvir … aldfly ameavo amebit yetvir … aldfly ameavo amebit yetvir … 本当にこういう動作してくれ るの？
12. 複数羽推論の疑問 調べてみると... aldfly ameavo amebit yetvir … 理想 aldfly ameavo amebit yetvir … 現実 全体的にぼやけた出力に → nocall を出しやすくなる
13. 対策としてstride mask(とチームでは呼んでる) を適用 original stride mask 1. maskする(maskされた部分の画像の 値を0にする) 2. maskされた画像をモデルに入力 3. maskをずらす 4. 1~3を繰り返す これで複数羽もいけるはず！
14. original stride mask stride maskの動作 aldfly ameavo amebit yetvir … … … … … … nocall ameavo ameavo nocall yetvir yetvir ameavo yetvir
15. 複数羽推論に対して評価したい 1bird data set some birds data set が必要 どうやって作る？
16. 評価 評価用データセットの作成 - 1bird: 1羽だけ鳴いている - some birds: 複数羽鳴いている all file - len(second_labels) == 0 - duration < 7 - len(second_labels) != 0 - duration < 7 - 1羽だけ鳴いている音がほしいので、 len(second_labels)==0 で絞る - クロップした5sec内にはかならず鳴き声が含まれて いてほしい。duration < 7 のファイルから5secをラン ダムにクロップすれば、鳴き声は含まれているだろう という期待。 - 複数羽鳴いている音がほしいので、 len(second_labels)!=0 で絞る - クロップした5sec内にはかならず鳴き声が含まれて いてほしい。duration < 7 のファイルから5secをラン ダムにクロップすれば、鳴き声は含まれているだろう という期待。 抽出 1bird some birds
17. 1bird some birds original 0.591036 0.402058 stride mask 0.607843 0.473956 評価結果F1_score(row_wise) 大きく向上 しかしpublicLBでは... 0.563 ----> 0.554 めっちゃ下がった - nocallを評価していないことが原因 - 外部データセットを擬似的にnocallとして評価したとこ ろ、stride maskの評価はやはり低かった
18. トレードオフ - nocallデータセットと鳥データセット (1bird, some birds)の評価値はトレードオフの関係にある threshold nocall 1bird, some birds nocall: threshold=0でf1_score=0をとり、threshold=1でf1_score=1をとる 鳥データセット: thresholdが低いと多くの鳥を過剰に検知していまう。 thresholdが高すぎると、ほとんどを nocallだと判断してしまうので スコアが低くなる。 同時に 評価したい
19. publicLBに連動した評価を行なう このコンペでこれができた人は ほとんどいないはず ... nocall(54.4%) 鳥データ(55.6%) test(public) データセット - これを再現する - nocallは外部データセットを使う - 鳥データは、1birdとsome birdsに分ける - site3はスコアに大きく依存していないので無視 nocall(54.4%) 鳥データ(55.6%)---> 1bird, some birds
20. scoreの計算方法 nocall(54.4%) 鳥データ(55.6%)---> 1bird, some birds パラメータ - α: nocallは外部データの為、スコアが高く出やすい (nocallだと判断しやすい) と考えたため、nocall scoreを低く見積もりたい。 0~1の値を取る。 - r_s: some_birds ratio(これがもし低ければ、 stride maskの試行錯誤に時間 をかける理由がなくなる ) これがLB_scoreと 近いようにしたい それぞれのデータセットで計 算したスコア
21. パラメータの決定 1. α、r_sを固定 2. あるモデルで、nocall, 1bird, some_birds のスコアを計算 3. 固定したα、r_sでall_scoreを計算 4. distance = (LB_score - all_score)**2 を計算 5. 持っている全てのモデルで distanceを計算し合計する 6. αとr_sを変更し、1~5を繰り返す。 7. distance の合計値が最小となる α、r_s を採用する これを最小にする αとr_sを決める
22. publicLBにOverfitするけどいいの？ - 問題ない。 - この評価がうまくいけば、いろいろと検証が捗る。 - 例) - privateLBでnocallの比率が変わった時にスコアにどのよう な影響が出るか見積もれる。 - thresholdの変化に頑健なモデルを追求できる。 - などなど...
23. 結果は？ LB_score, all_score 決定したαとr_sで計算した all_score例 - 正直微妙な結果。 - all_scoreが最大になるような モデルとthresholdを見積もっ てサブしてみたけど失敗。 - この後、nocallのデータセット の拡充など行ったがこれも失 敗に終わる。
24. うまくいかなかったけど - コンペベースライン付近(publicで)0.560 ~ 0.570 の性能は殆ど変わらないだろう という知見が得られた。 - その程度の差は、publicとprivateのnocall比率の僅かな変化で吹き飛ぶ。 - それを前提にシェイク対策をすれば、メダル圏内に大幅シェイクで入るのは難しく ないと考えた。 public LBを少しずつ駆け上がる事はせず、 大胆な実験を多く行い金メダルを目指す作戦にした (水増しなど他の多くの参加者がかならずやることは後回 し)
25. 最終的に - 惨敗した。 - アイデアは当たらなかった。 - 当たっていたとしてもnocallにうまく対処できなかったために効果が出て いなかったのかもしれない。 - コンペラスト3日で作ったシェイクアップ対策のクソおもんないアンサンブ ルをsubmitして466人抜いて銅メダル。 敗因 - nocallに対処するのが遅かった。 - これが全て。 そしてチーム名が We don’t like nocall に
26. fkubotaのコンペの取り組み方
27. 取り組み方を紹介する動機 - 1年前kaggle初心者で右も左もわからなかったけれども、いろんな人の記事に助 けられた(カレーさんの本とかやばい) - ---> ので、僕もコミュニティーに貢献したい - 「Kaggleは長期戦」 = 「情報戦」 だと思っているので「取り組み方」それ自体も大事 なテクニックだと考えている
28. メダルを取るコツ(個人的な経験から) - 最後まで戦う - LBの上下に一喜一憂するだけではなく、知見を蓄積させる 長期戦に備える
29. 長期戦対策 - アイデアの吐き出し場所を作る - ファイル名で管理しない - 個人的には必ず破綻すると思っている - Kaggle日記を付ける(今回pdfにして55ページほどの大きさになりました。 ) 恥をさらすことになりますが 全部公開します
30. アイデアの吐き出し場所を作る - 鳥コンペではgithubのissueに作った(project boardに書いた) - とりあえずなんでもかんでも書く。今回は試してないアイデアはまだ47個ぐらいある(使えなさそうなのもたくさ ん)。 - 実装中に、ディスカッションを読んでいる最中に、twitterをダラダラ見ている時に思いついた事をなんでも書き 込む。 - あとで読もうと思った論文やdiscussionのurlを貼ったりしています。 - 1ヶ月前に思いついたアイデアを使うことなんてよくある。 issueはここ。
31. ファイル名で管理しない - 長期戦になれば、後半はソースの数が多くなりファイル名での管理は必ず破綻す る(個人的な経験)。 - なので、はじめからファイル名で管理しない。 ファイル名だけでは、何しているかわからない。 いちいち開いて確認するの？ もちろん NO!!!
32. Kaggle日記をつける すべての情報はここに 作成したデータセットのことだったり 読んだ論文読みたい論文をまとめたり やったことのlogを書いたり ↓にあります。 - 分子コンペ - イオンコンペ - 鳥コンペ
33. Kaggle日記の利点 - 迷子にならない - コンペ中、50以上のノートブックを作成したり、大量の discussionを見たりす るが、常にある程度把握しており迷子にならない - やったことはここに書いているので、ノートブックなどをファイル名管理していなくて も問題ない - 膨大なインプットを脳内で管理しなくていい - ノートブックを開かなくてもやったことは大体わかる 5日に1回程度見返す
34. 取り組み例1 新しくnotebookでモデルを作成する 名前は 030_create_model_resnest.ipynb kaggle日記には 以下のように記入 後日メモを見て - nb029ってなんだっけ？ ---> kaggle日記にあるよ - SpectrogramEventRmsDatasetってな んだっけ？ ---> kaggle日記にあるよ ノートブック番号も 知ってるよ - nb030をベースにノイズ処理いれたらどうか な？ ---> issueとしてアイデアを書いておこう
35. 取り組み例2 いい感じのdiscussion発見 とりあえずkaggle日記にメモ アイデア思いついた。 ---> issue board へ こういった雑記(kaggle日記)をす べて5日に1回程度見返す。 雑記程度だけど、1ヶ月後に 自分へのヒントになることも
36. とにかく - できるだけ毎日コミットする - discussion読むだけでもいいと思う 論文見つけた いい感じのディス カッション見つけ た ノートブックで実 験してみた Kaggle日記へ 小さいけど アイデア思いついた issue boardへ やったことを蓄積し、仮説 検証を繰り返す あとは最後までやり通せばメダルは取れると思う
37. - 偉そうなこと言いましたが、僕自身この方法がベストだとは思ってません。 - 少なくとも、kaggleは長期戦で続けるのはそれなりに大変なのでそれに対処するテク ニックも考えるべきということが伝えたかったことです。 - 他の人の工夫した取り組み方も見たい！教えてください！
38. 御清聴ありがとうございました