Slide 1

Slide 1 text

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


Slide 2

Slide 2 text

自己紹介 fkubota (twitter, Kaggle) - Kaggle Expert - 沖縄出身(東京に出てきて2年半) - 物理学科出身(強相関電子系) - プログラミング歴は2年弱ぐらい - 趣味 - 早起き(4時半起床) - Kaggle - コーヒー、ビール、ウィスキー - 読書、物理、哲学 - Kaggler と飲みたい(早起きより飲み会優先 ) Kaggle歴 (これまであまり積極的ではなかったが、鳥コンペで とうとう沼に落ちた) - 初参加 - 分子コンペ - ソロ銅メダル(234/2749位) - 2回目 - イオンコンペ - ソロ銀メダル(22/2618位) - 3回目(画像系のコンペ初挑戦 ) - 鳥コンペ - チーム銅メダル(114/1390位)

Slide 3

Slide 3 text

チーム紹介 チーム名: We_don’t_like_nocall 2人とも画像系のコンペ初参戦のクソザコ

Slide 4

Slide 4 text

鳥コンペに惨敗した話

Slide 5

Slide 5 text

鳥コンペとは(ざっくり) 音ファイルが与えられる ---> 5secごとにどの鳥が鳴いているか当てる birdA birdB nocall birdC, birdD birdE 鳴いていないという選 択肢もある 5sec以内に複数羽鳴 くこともある

Slide 6

Slide 6 text

トレーニングデータの構成 aldfly ameavo amebit yetvir … … … … … train_audio/ - 264種類の鳥 - ファイルの長さは統一されてない (1sec以下もあ る) - 鳥ごとにファイル数も異なる train.csv - 音ファイルのメタ情報 - カラム数 = 35 - 例えば - rating: 集音の質 - duraion: 音データの長さ - location: 集音した場所 - secondary_labels: 他に鳴いている鳥 - などなど

Slide 7

Slide 7 text

鳥コンペが難しいとされる理由 ノイジーな トレーニングデータ トレーニングデータと テストデータの 本質的な違い

Slide 8

Slide 8 text

ノイジーなトレーニングデータ ラベルと違う鳥 ラベル通りの鳥 - 他の鳥が複数羽混ざってることがある - secondaly_label として他の鳥が混ざっ ていることがわかっているデータもある がわかっていないデータもある - 学習時にランダムクロップを行なうが鳥 の鳴き声が入らないことがある 他の鳥の鳴き声も入る 鳴いていない場所もかなり多い 背景雑音

Slide 9

Slide 9 text

トレーニングデータとテストデータの本質的な違い aldfly ameavo amebit yetvir … … … … … 264クラスの分類を 行なうモデル こんな問題だったら簡単だった - 1羽だけ鳴く ---> 264クラス分類 今回の問題 - 同時に複数羽鳴くことも - 鳴いていない(nocall)場合も - nocallはデータとして与えられて いない Test Data Training Data 今回は、この複数羽鳴くことに対して行った処理から 惨敗した理由に至るまでを話します

Slide 10

Slide 10 text

どうやって複数羽を特定するのか? aldfly ameavo amebit yetvir … … … … … 264クラスの分類を 行なうモデル(ResNet) このコンペで最もスタンダードな方法 (araiさんのノートブック) Training Inference ResNet 全結合層の出力を sigmoidで0~1にし て出力 aldfly ameavo amebit yetvir … thresholdを上回るもの提出 1つも上回らなければ nocallとする

Slide 11

Slide 11 text

複数羽推論の疑問 1羽 1羽 2羽 aldfly ameavo amebit yetvir … aldfly ameavo amebit yetvir … aldfly ameavo amebit yetvir … 本当にこういう動作してくれ るの?

Slide 12

Slide 12 text

複数羽推論の疑問 調べてみると... aldfly ameavo amebit yetvir … 理想 aldfly ameavo amebit yetvir … 現実 全体的にぼやけた出力に → nocall を出しやすくなる

Slide 13

Slide 13 text

対策としてstride mask(とチームでは呼んでる) を適用 original stride mask 1. maskする(maskされた部分の画像の 値を0にする) 2. maskされた画像をモデルに入力 3. maskをずらす 4. 1~3を繰り返す これで複数羽もいけるはず!

Slide 14

Slide 14 text

original stride mask stride maskの動作 aldfly ameavo amebit yetvir … … … … … … nocall ameavo ameavo nocall yetvir yetvir ameavo yetvir

Slide 15

Slide 15 text

複数羽推論に対して評価したい 1bird data set some birds data set が必要 どうやって作る?

Slide 16

Slide 16 text

評価 評価用データセットの作成 - 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

Slide 17

Slide 17 text

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の評価はやはり低かった

Slide 18

Slide 18 text

トレードオフ - nocallデータセットと鳥データセット (1bird, some birds)の評価値はトレードオフの関係にある threshold nocall 1bird, some birds nocall: threshold=0でf1_score=0をとり、threshold=1でf1_score=1をとる 鳥データセット: thresholdが低いと多くの鳥を過剰に検知していまう。 thresholdが高すぎると、ほとんどを nocallだと判断してしまうので スコアが低くなる。 同時に 評価したい

Slide 19

Slide 19 text

publicLBに連動した評価を行なう このコンペでこれができた人は ほとんどいないはず ... nocall(54.4%) 鳥データ(55.6%) test(public) データセット - これを再現する - nocallは外部データセットを使う - 鳥データは、1birdとsome birdsに分ける - site3はスコアに大きく依存していないので無視 nocall(54.4%) 鳥データ(55.6%)---> 1bird, some birds

Slide 20

Slide 20 text

scoreの計算方法 nocall(54.4%) 鳥データ(55.6%)---> 1bird, some birds パラメータ - α: nocallは外部データの為、スコアが高く出やすい (nocallだと判断しやすい) と考えたため、nocall scoreを低く見積もりたい。 0~1の値を取る。 - r_s: some_birds ratio(これがもし低ければ、 stride maskの試行錯誤に時間 をかける理由がなくなる ) これがLB_scoreと 近いようにしたい それぞれのデータセットで計 算したスコア

Slide 21

Slide 21 text

パラメータの決定 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を決める

Slide 22

Slide 22 text

publicLBにOverfitするけどいいの? - 問題ない。 - この評価がうまくいけば、いろいろと検証が捗る。 - 例) - privateLBでnocallの比率が変わった時にスコアにどのよう な影響が出るか見積もれる。 - thresholdの変化に頑健なモデルを追求できる。 - などなど...

Slide 23

Slide 23 text

結果は? LB_score, all_score 決定したαとr_sで計算した all_score例 - 正直微妙な結果。 - all_scoreが最大になるような モデルとthresholdを見積もっ てサブしてみたけど失敗。 - この後、nocallのデータセット の拡充など行ったがこれも失 敗に終わる。

Slide 24

Slide 24 text

うまくいかなかったけど - コンペベースライン付近(publicで)0.560 ~ 0.570 の性能は殆ど変わらないだろう という知見が得られた。 - その程度の差は、publicとprivateのnocall比率の僅かな変化で吹き飛ぶ。 - それを前提にシェイク対策をすれば、メダル圏内に大幅シェイクで入るのは難しく ないと考えた。 public LBを少しずつ駆け上がる事はせず、 大胆な実験を多く行い金メダルを目指す作戦にした (水増しなど他の多くの参加者がかならずやることは後回 し)

Slide 25

Slide 25 text

最終的に - 惨敗した。 - アイデアは当たらなかった。 - 当たっていたとしてもnocallにうまく対処できなかったために効果が出て いなかったのかもしれない。 - コンペラスト3日で作ったシェイクアップ対策のクソおもんないアンサンブ ルをsubmitして466人抜いて銅メダル。 敗因 - nocallに対処するのが遅かった。 - これが全て。 そしてチーム名が We don’t like nocall に

Slide 26

Slide 26 text

fkubotaのコンペの取り組み方

Slide 27

Slide 27 text

取り組み方を紹介する動機 - 1年前kaggle初心者で右も左もわからなかったけれども、いろんな人の記事に助 けられた(カレーさんの本とかやばい) - ---> ので、僕もコミュニティーに貢献したい - 「Kaggleは長期戦」 = 「情報戦」 だと思っているので「取り組み方」それ自体も大事 なテクニックだと考えている

Slide 28

Slide 28 text

メダルを取るコツ(個人的な経験から) - 最後まで戦う - LBの上下に一喜一憂するだけではなく、知見を蓄積させる 長期戦に備える

Slide 29

Slide 29 text

長期戦対策 - アイデアの吐き出し場所を作る - ファイル名で管理しない - 個人的には必ず破綻すると思っている - Kaggle日記を付ける(今回pdfにして55ページほどの大きさになりました。 ) 恥をさらすことになりますが 全部公開します

Slide 30

Slide 30 text

アイデアの吐き出し場所を作る - 鳥コンペではgithubのissueに作った(project boardに書いた) - とりあえずなんでもかんでも書く。今回は試してないアイデアはまだ47個ぐらいある(使えなさそうなのもたくさ ん)。 - 実装中に、ディスカッションを読んでいる最中に、twitterをダラダラ見ている時に思いついた事をなんでも書き 込む。 - あとで読もうと思った論文やdiscussionのurlを貼ったりしています。 - 1ヶ月前に思いついたアイデアを使うことなんてよくある。 issueはここ。

Slide 31

Slide 31 text

ファイル名で管理しない - 長期戦になれば、後半はソースの数が多くなりファイル名での管理は必ず破綻す る(個人的な経験)。 - なので、はじめからファイル名で管理しない。 ファイル名だけでは、何しているかわからない。 いちいち開いて確認するの? もちろん NO!!!

Slide 32

Slide 32 text

Kaggle日記をつける すべての情報はここに 作成したデータセットのことだったり 読んだ論文読みたい論文をまとめたり やったことのlogを書いたり ↓にあります。 - 分子コンペ - イオンコンペ - 鳥コンペ

Slide 33

Slide 33 text

Kaggle日記の利点 - 迷子にならない - コンペ中、50以上のノートブックを作成したり、大量の discussionを見たりす るが、常にある程度把握しており迷子にならない - やったことはここに書いているので、ノートブックなどをファイル名管理していなくて も問題ない - 膨大なインプットを脳内で管理しなくていい - ノートブックを開かなくてもやったことは大体わかる 5日に1回程度見返す

Slide 34

Slide 34 text

取り組み例1 新しくnotebookでモデルを作成する 名前は 030_create_model_resnest.ipynb kaggle日記には 以下のように記入 後日メモを見て - nb029ってなんだっけ? ---> kaggle日記にあるよ - SpectrogramEventRmsDatasetってな んだっけ? ---> kaggle日記にあるよ ノートブック番号も 知ってるよ - nb030をベースにノイズ処理いれたらどうか な? ---> issueとしてアイデアを書いておこう

Slide 35

Slide 35 text

取り組み例2 いい感じのdiscussion発見 とりあえずkaggle日記にメモ アイデア思いついた。 ---> issue board へ こういった雑記(kaggle日記)をす べて5日に1回程度見返す。 雑記程度だけど、1ヶ月後に 自分へのヒントになることも

Slide 36

Slide 36 text

とにかく - できるだけ毎日コミットする - discussion読むだけでもいいと思う 論文見つけた いい感じのディス カッション見つけ た ノートブックで実 験してみた Kaggle日記へ 小さいけど アイデア思いついた issue boardへ やったことを蓄積し、仮説 検証を繰り返す あとは最後までやり通せばメダルは取れると思う

Slide 37

Slide 37 text

- 偉そうなこと言いましたが、僕自身この方法がベストだとは思ってません。 - 少なくとも、kaggleは長期戦で続けるのはそれなりに大変なのでそれに対処するテク ニックも考えるべきということが伝えたかったことです。 - 他の人の工夫した取り組み方も見たい!教えてください!

Slide 38

Slide 38 text

御清聴ありがとうございました