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

Transcript

1. 鳥コンペに惨敗した話

   と

   コンペの取り組み方

   fkubota

   

   View Slide

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

   View Slide

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

   View Slide

4. 鳥コンペに惨敗した話
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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と
    近いようにしたい
    それぞれのデータセットで計
    算したスコア
    

    View Slide

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を決める
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

26. fkubotaのコンペの取り組み方
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide