銀_画像分類コンペ_202109_probspace 宗教画テーマの分類

勉強会用の資料です。

Transcript

1. DATE 1/xx • suguuuu
2. このコンペ活動について • スタート: – 2021/5月～ メンバ3人 ⇒ 2021/7月 メンバ6人 • 参加したコンペ: – パナソニック株式会社 間取り図解析アルゴリズム作成 | SIGNATE - Data Science Competition – 2021/9 : 宗教画テーマの分類 | ProbSpace ←今日はこれの参加報告 Phase1 : ~2021/7 Phase2:~2021/12 Phase3 : ~2022/3 目的: 有名なNetを構築し、提出までの フローを学ぶ 成果物: Tensorflow2でベースネット構築 周辺ライブラリの調査 提出フォーマットへの変換 目的: いくつかのNetを構築し、性能改 善のための施策を学ぶ kaggleを調査し、性能改善のた めの施策を学ぶ 成果物: ・複数のNet構築 ・アンサンブルなどのテクニック取得 目的: 効率的な検討・開発を行い、上 位に入り込む 成果物: ・kubeflowによる自動学習環境 の構築 ほぼ素人たちが、雰囲気ゆるゆるな感じで、半年くらいでコンペ上位を目指す活動です。
3. 機械学習コンペとは?? • 2021/09現在openの画像系コンペ – RSNA-MICCAI Brain Tumor Radiogenomic Classification | Kaggle • MRIの画像から神経膠芽腫の遺伝的サブタイプを分類 – NFL Health & Safety - Helmet Assignment | Kaggle • NFL動画から誰のヘルメットが強い衝撃を受けたか予測 – Nishika - ケーブルコネクタの種類判別 • ケーブルが写った画像から、どのUSBのタイプ(typeC?など)が写っているかを予測 目的:特定のタスクに関して、ある期間内でアルゴリズムを開発し、 テストデータに対して良い精度を出す!! 神経膠芽腫の 遺伝的サブタイプ分類 誰のヘルメットが 強い衝撃を受けたか予測 どのUSBのタイプ(typeCなど) が写っているか予測
4. 補足:機械学習コンペってどういう風に進めるの??? • Public Leaderboard(Public LB) – 実施期間中、テストデータの一部で評価された暫定順位表 • Private Leaderboard(Private LB) – それ以外のデータで評価された順位表。すべてのデータで評価するので順位が入れ替わる!! 実施期間中は、”Public Leaderboard”に表示される順位を見ながら着手 最終順位はPrivate Leaderboardで確定 Privateで最終順位が変わる可能性！ Publicを過信せず、汎化性能が必要 Public Leaderboard（実施期間中見れる順位） Private Leaderboard（最終確定の順位）
5. 今回行ったコンペの内容: 受胎告知 キリストの降誕 聖家族 羊飼いの礼拝 東方三博士の礼拝 エジプトへの逃避 イエスの洗礼 最後の晩餐 茨の冠 キリストの磔刑 キリストの嘆き ラザロの復活 最後の審判 13クラスを DNNで分類 画像データから宗教画のテーマをクラス分類できるアルゴ(DNN)を開発! ＃テーマは13クラス!見るからに宗教画っぽいですね!
6. 本コンペの難しかったポイント: 受胎告知 キリストの降誕 聖家族 羊飼いの礼拝 東方三博士の礼拝 エジプトへの逃避 イエスの洗礼 最後の晩餐 茨の冠 キリストの磔刑 キリストの嘆き ラザロの復活 最後の審判 テーマ 絵画の詳細(一例) データ数 受胎告知 処女マリアがキリストを妊娠したことを告 げられる 60 キリストの降 誕 イエス・キリストが誕生する 42 聖家族 幼少年時代のイエス・キリスト、養父ヨセ フ、聖母マリア 132 羊飼いの礼拝 イエス・キリストを目にするために羊飼い が訪れる 42 東方三博士の 礼拝 マリアとイエス・キリストを拝み、乳香、 没役、黄金を捧げる 42 エジプトへの 逃避 養父ヨセフは、ヘロデ王のたくらみを避け て、マリアとともにエジプトへと逃れる 60 イエスの洗礼 ヨルダン川で洗礼者ヨハネからイエスは洗 礼を受ける 48 最後の晩餐 イエスが処刑される前夜、十二使徒と共に 食事をしている。使徒の一人が裏切者であ ることが告げられる 30 茨の冠 笞打ちの刑となったイエスが、兵士から茨 でできた冠をかぶせられあざ笑われる 30 キリストの磔 刑 イエスは十字架に磔となって処刑される 66 キリストの嘆 き キリストの体が十字架から剥がされ、その 体をイエスの友人たちが悼む 30 ラザロの復活 ラザロの墓の前で、イエスが祈った直後、 イエスの友人であるラザロが蘇生する 42 最後の審判 再臨したイエスが死者に裁きを下し、天国 と地獄へと振り分けられる 30 学習データ合計 654枚 テストデータ 497枚 ①画像だけでテーマの特徴が分かりづらい・・・? ②しかもデータ数が少なく、偏りがある!!
7. 今回の結果は・・・? 219チーム中、14位・・・・! ＃上位5%くらい! いやーもっといろいろやりたかったけど、時間足りねーわ ←言い訳 Kaggleでいうメダルの範囲感
8. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 8月2日 8月7日 8月12日 8月17日 8月22日 8月27日 9月1日 9月6日 9月11日 スコア Public Private アプローチとスコアの変化 ①初期モデル作成 交差検証の枠組み実装 ②imagenet事前学習モデル、 Augmentationの利用 150近く様々なNetを学習し、 学習パラメータも大枠探索 ③学習データの偏り調整対策 1. Imbalanced samplerの利用 2. Label smootherの利用 ⑤データ不足対策 事前学習をwikiartで実施 時間足りずSwin-transfomer のワンモデルで最終提出 ④Augmentationの調整 テストデータにあった パラメータに最適化 様々な取り組みをしていくなか、大きく分けて5つの取り組みで精度が変化! ＃実は、ここに書いてない数多くの取り組みが存在しています・・・
9. ②imagenet事前学習モデル、Augmentationの利用 • ②でやった内容 – ライブラリ(Pytorch Image models)にある事前学習されたバックボーンモデルをひたすら学習 • パラメータを変えつつ150近く学習を実施。 • そこそこ性能が出た、EfficientNet-B4とswin-transfomerにターゲットを絞る – Augmentationの探索 • テストデータのドメインを考慮し、ライブラリ（Albumentations）を利用 – 左右上下反転、セピア化、BrightnessContrastが精度向上に寄与 – Randam Erase、cut out、mix upとかは効果が無かった・・・ • なぜ②を行ったか – imagenet事前学習モデルの利用 • 事前学習無しの場合、データの偏りの影響をもろに受けていた – データ量が相対的に多いクラス２としか予測できない。 – Augmentationの探索 • データが少ないので、とりあえずデータを水増し ①の結果：クラス２として しか予測できない
10. やりたかったこと • 自己教師あり学習による事前学習の強化! – 概要: • 最高性能を出しているTransfomerでも実施されている、2020年大流行りしたワークフロー • 画像データのみで、backboneの事前学習をできちゃう! – なんでやりたかったの?: • Wikiartの2クラス分類による事前学習で性能の向上があったので、これをやりたかった・・・ • たぶんえぐいほど性能出たはず・・・ – 備考: • MRIなどimagenetと大きく異なるドメインで認識させたい場合に超有効らしい • Optunaを利用したハイパーパラメータの自動探索! – 概要: • Preferred networkで開発されたハイパーパラメータ探索ツール – なんでやりたかったの?: • パラメータ探索が全然詰めれてなかった・・・ • Grad-camによる学習特性の分析 – 概要: • Explainable AIの走りだし、なんでこのクラスに分類されたかが分かるフレームワーク – なんでやりたかったの?: • どこかを注目して分類しているか、、、とかを判断したかった。なんとなく。
11. DATE 11/xx その他メモ:あとで読んでね • このコンペをやるにあたって参考にした過去のコンペ – [Kaggle]キャッサバコンペ振り返り (zenn.dev) – #11 [初心者歓迎! / 画像編] atmaCup (guruguru.science) • その他得られた知見 – モデルに応じて最適化手法が異なるぜ。（Transfomer系:SGD、CNN:Adam） – ひたすら実験を行えるような環境構築が重要。そこそこ実装できた。 – データが少ない時は、CVやLBの結果に左右されず、性能が出るハズ、、、と思う学習をさせるべし。←スライドでは触れなかったけど超重要知見 • 今回45位からshake upして14位になったのは、少量の学習・テストデータに過学習させない学習方法を取ったから。 • やってみたけど、うまく行かなかったこと – 間違えやすいラベルをまとめて、2段階で推論（2クラス分類→9クラス分類みたいな感じで多段DNN） – アンサンブルは精度が低下した。おそらくデータの偏りに耐えられなかった。（CVは性能向上したが、LBダメ） – Augmentation（mixup, cutout,Randam grid shuffle）。むずいわパラメータ探索。。。 • Albumentationsのaugmentationをひたすら動かす - Qiita – テストデータの推論結果を利用した半教師あり学習:CVは性能あがったがLBダメダメ。ワンモデルの精度が低いのでダメなのかも。 • やらなかったこと – ラベルノイズ対策:ラベルノイズは含まれてないと思うので未実施 – スタッキング:Ave.Ensemble失敗したし、挑戦してもダメそうだったのでやらなかった。そもそもワンモデルの精度低いし・・・ – AutoAug、RandAug:着手する時間無し。。。
12. DATE 12/xx Appendix
13. コンペなんて意味あるの?数％精度向上目指すだけじゃん・・・ “引き出しの広さ”と”スピード感”こそ、Kaggle人材の魅力 • Kaggleをやっている人たちに対して、「0.001ポイント程度の小さい精度を争っても意味がないので は?」と批判をする人がいますが、実務においてわずかな精度を追求することを目的としてKagglerを集 めているわけではありません。 • Kagglerの魅力は、幅広い機械学習問題への取り組み経験から得られる引き出しの広さと、限られた 時間で高いレベルのアウトプットを生み出せるスピード感にあります。 • また実務では、限られた時間の中でクイックに分析結果を出して次の業務の方向性を決める必要があ ります。分析アウトプットを出すまでの圧倒的なスピードが、Kagglerの大きな武器であり、非常に高速な PDCAサイクルを回すことが可能です。 第1回：なぜDeNAは「Kaggler」を集めているのか？ - ZDNet Japan 会社での開発は、いろんなステークホルダーに確認しながら進めなくてはいけないのでマジで遅い 実力をつけるには、結果を短期間で出さなきゃいけない。つまりコンペだ!
14. 会社（俺がやってた仕事）でのDNN開発と、コンペの違い（ワイ視点、弊社全体ではない） • 会社でのDNN開発:下図でいう青色のところがメイン – ニーズに合わせて、データセットの構築から入る ←ここに、ほぼほぼ工数がかかる – ぶっちゃけ、クライテリア次第でデータセットの構築でおおよその性能が満たせる – R&Dとかからベースをもらってくることが多いので、大きな変更が入れづらい。。。 – エッジ前提のため、演算規模を度外視して性能を上げるための工夫は知らなくていい。。。 • Kaggle等コンペ:下図でいう緑色のところがメイン – データセットが固定されてるため、開発の部分がメイン – 回帰問題で解くのか、などの課題に対してのアプローチを検討できる。 会社では、環境構築＆データセット構築の作業がメインな感じがする コンペは、データセットが固定されてるためネットワーク、データセットの工夫がメイン DNNワークフロー概要:会社では青メイン、コンペでは緑メイン 会社での DNN開発 ここがメイン コンペでの DNN開発 ここがメイン
15. 初めてコンペに取り組んで感じた難しさ • 自分の手札の少ねえ!! – データを増やす、パラメータを微調節というアプローチでしか改善させたことがなかった。。。 • 分類?回帰? • アンサンブル?TTA（test-time augmentation）?複数のモデルで? • 時間ねえ!! – 3か月あるから余裕っしょ・・・⇒やべえ、業務に時間とられて全然できないぞ、、、⇒精度出ないわ・・・ – 普通に0から学習しても行けるっしょ⇒精度出ないやん・・・⇒TF配布のモデル使って転移学習しよ⇒間に合わ ねえ・・・ • ライブラリわかんねえ!! – 業務ではTF1.14での学習がメインだったため、最新の知識が不足だった • Tfboard、評価のスクリプト、Augmentationのライブラリが使えるようになった! • 普通に技術分かんねえ!! – セマセグ、keypointは後処理含めて理解していたが、Bounding BOXの認識の原理の理解がなかった。。。 言い訳