kaggle-RANZCR

Kaggleの RANZCR CLiP - Catheter and Line Position Challenge コンペのリポジトリです。
nbというディレクトリに、今回使用したNotebookをおいてあります。
ただし、下の方針にもある通り、今回はKaggle上でほぼ完結させているため、gitは使用していません。ですので、nbの中に全てのversionのNotebookがあるわけではないです。ver名がないものに関しては最新のverになります。

最終結果

- Public: 0.96864
- Private: 0.97142
- rank: 91/1547 (Top6%)
- 初メダルゲット！！！！！

方針

• 基本的にはKaggle上で実験を行い、quotaが切れたらローカルのGPUで実験を行う。
• Version名は常にVersion〇〇に統一して、変更などはKaggle日記(このリポジトリのREADME.md)に書き込む。
  

Paper

• 参考にした論文の一覧。決して全てを理解してるわけではない。
  

No	Name	Detail	Date	link
01	Focal Loss for Dense Object Detection	Cross Entropy Loss において、比較的うまく分類できているものの損失を小さく抑えることにより、不均衡データでうまく学習ができる。(もともとはRCNを対象に開発された。)	7 Feb 2018	link
02	Dual Attention Network for Scene Segmentation	画像の各位置、チャンネル方向の２つに対してSelf Attentionを適用する手法。(もともとはSegmentationのための手法。)	21 Apr 2019	link
03	Robust Deep AUC Maximization: A New Surrogate Loss and Empirical Studies on Medical Image Classification	従来のAUC最適化用の損失関数(AUC square loss)の代わりにAUC margin lossを用いることにより、大規模データでも安定してAUC最適化を行えるようにした手法。	6 Dec 2020	link
04	Data Augmentation Revisited: Rethinking the Distribution Gap between Clean and Augmented Data	augmentationを使ってモデルを学習させた後、augmentationを外してfine tuning することにより精度を上げる手法。	21 Nov 2019	link

• その他に参考にしたサイトなど。
  
  • 評価指標がAUCであるとき、アンサンブルの際に各モデルの予測をn(>1)乗してWeight Averageを取ることで精度が上がるという話(link)。ただし、lateサブしたらスコアが悪化した。
    
  • roc starという、Deep AUC とはまた違うAUC用の損失関数(githubのlink)。こちらも実際に試したら精度が悪化した。
    

Basics

Overview(Deepl)

深刻な合併症は、患者のラインやチューブの位置を間違えた結果として発生する可能性があります。医師や看護師は、患者を管理する際にプロトコルに従っていることを確認するために、救命器具を配置するためのチェックリストを頻繁に使用しています。しかし、これらの手順には時間がかかることがあり、特に病院の収容人数が多いストレスの多い状況では、人為的なミスが発生しやすい。

入院患者は入院中にカテーテルやラインを挿入されることがありますが、位置を誤ると重篤な合併症を引き起こす可能性があります。経鼻胃管の気道内への位置ずれは、症例の最大3％で報告されており、これらの症例の最大40％が合併症を示しています[1-3]。手術室外で挿管された成人患者の気道チューブの位置異常は、最大25％の症例で報告されています[4,5]。合併症の可能性は、手技者の経験レベルと専門性の両方に直接関係している。位置がずれたチューブを早期に発見することは、危険な合併症（死に至ることもある）を防ぐ鍵であり、何百万人ものCOVID-19患者がこれらのチューブやラインを必要としている現在ではなおさらである。

ラインとチューブの位置を確認するためのゴールドスタンダードは胸部X線写真である。しかし、医師や放射線技師は、ラインやチューブが最適な位置にあるかどうかを確認するために、これらの胸部X線写真を手動でチェックしなければならない。これはヒューマンエラーの可能性を残すだけでなく、放射線技師は他のスキャンの報告に忙しくなるため、遅延が生じることもよくあります。ディープラーニングアルゴリズムは、カテーテルやラインの位置が間違っていることを自動的に検出することができるかもしれない。警告が出れば、臨床医は命に関わる合併症を避けるために、カテーテルの位置を変更したり、除去したりすることができる。

Royal Australian and New Zealand College of Radiologists（RANZCR）は、オーストラリア、ニュージーランド、シンガポールの臨床放射線技師と放射線腫瘍医のための非営利の専門組織である。RANZCRは、不適切な位置に置かれたチューブやラインを予防可能なものとして認識している世界の多くの医療機関（NHSを含む）の一つである。RANZCRは、そのようなエラーがキャッチされる安全システムの設計を支援しています。

このコンペティションでは、胸部レントゲン上のカテーテルやラインの存在と位置を検出します。機械学習を使用して、40,000枚の画像上でモデルをトレーニングしてテストし、不適切な位置にあるチューブを分類します。

データセットには、ラベル付けとの整合性を確保するために、一連の定義でラベル付けを行いました。正常カテゴリには、適切に配置され、再配置を必要としない線が含まれます。境界線のカテゴリには，理想的には多少の再配置を必要とするが，ほとんどの場合，現在の位置でも十分に機能するであろう線が含まれる．異常カテゴリーには、直ちに再配置を必要とするラインが含まれる。

成功すれば、臨床医の命を救うことができるかもしれない。COVID-19の症例が急増し続ける中、位置がずれたカテーテルやラインを早期に発見することはさらに重要である。多くの病院では定員に達しており、これらのチューブやラインを必要としている患者が増えています。カテーテルやラインの配置に関する迅速なフィードバックは、臨床医がこれらの患者の治療を改善するのに役立つ可能性がある。COVID-19以外にも、ラインやチューブの位置を検出することは、多くの病 院患者にとって常に必要なことである。

data(DeepL)

このコンテストでは、胸部レントゲン上のカテーテルやラインの存在と位置を検出します。機械学習を使用して、40,000枚の画像上でモデルを訓練してテストし、配置の悪いチューブを分類してください。

What files do I need?

トレーニング画像とテスト画像が必要です。このコンテストはコードのみのコンテストなので、隠れたテストセット（約4倍の大きさで14k枚の画像）もあります。
train.csvには画像ID、バイナリラベル、患者IDが含まれています。
TFRecordsは訓練とテストの両方で利用可能です。(これらは隠れたテストセットでも利用可能です)。
train_annotations.csvも含まれています。これらは、それを持つ訓練サンプルのセグメンテーションアノテーションです。これらは，競合他社のための追加情報としてのみ含まれています

Files

• train.csv - 画像ID、バイナリラベル、患者IDが格納されています． sample_submission.csv - 正しいフォーマットのサンプル投稿ファイルです．
• test - テスト画像 train - トレーニングイメージ

Columns

• StudyInstanceUID - 各画像に固有のID
• ETT-異常-気管内チューブ留置異常
• ETT - 境界線 - 気管内チューブ留置境界線異常
• ETT - 正常 - 気管支内チューブの装着は正常です。
• NGT-異常-経鼻胃管留置異常
• NGT - 境界線 - 経鼻胃管留置境界線異常
• NGT - 画像化が不完全 - 画像化のために経鼻胃管留置が決定的ではない
• NGT - 正常 - 経鼻胃管留置は正常の境界線上にある。
• CVC - 異常 - 中心静脈カテーテル留置異常
• CVC - ボーダーライン - 中心静脈カテーテル留置境界異常
• CVC - 正常 - 中心静脈カテーテルの配置は正常です。
• スワンガンツカテーテルプレゼント
• PatientID - データセット内の各患者の一意のID

Log

20210223

• join!!!
  
• cassavaコンペのリベンジ。まだ3週間はあるので色々できるはず。
  
• nb001(EDA)
  
  • 自力でEDAを行った。
  • キャッサバコンペに比べて画像データがかなり大きい。512×512ぐらいに縮小してもいいとは思う。
  • 画像データは3チャネルあったが、3チャネル全てが同じであるため、平均をとって1チャネルの白黒画像にしても全く同じになる。それなら1チャネルだけの方が軽くていいと思う。
    
  • 適当に閾値を設定して、それ以下の値のピクセルを全部0するのも良さそう。
    
  • アノテーション画像を使うなら、画像データの縮小に合わせてアノテーション画像も縮小させる必要がある。(まだどう使えばいいのかよくわかってないけど...)
    
  • クラスの割合が予想以上に不均衡だった。MoAコンペでは、ほとんどが0のクラスは、罰則を小さくすることしか学習できていなかったため、今回も気をつける必要があるかもしれない。
    
  • とりあえず、trainingデータの平均でsample_submissionの表を埋めてsubmitしてみた。->LBは0.500だった。AUCだから当然か。
    
• nb002(create_model_ResNext)
  
  • ver1
    
    • 再び、Y.NakamaさんのNotebookを写経。cassavaのときとほぼ一緒なのですぐ理解できた。汎用性が高いとはこういうことか。お陰様でいいスタートダッシュが切れた。感謝感謝。
      
    • TrainDatasetまで書いた。いい復習になっている。
      

20210224

• このNotebookを見ると、ETT -Abnormalのうちの一つがラベルが違うらしく、正確にはCVC - Abnormalらしい。EDAを見る限りでもそうっぽい。比較実験したい。
  

• [このNotebook]の一番下のコメントで、timmとpytorch.xla_(だったっけ)のバージョンの齟齬の解消法が提案されてた。とりあえず、pytorch-image-modelsを使い続けて、xlaのバージョンを変えることにする。
  

• どうやら、annotationを使うには、3stepでtrainingを行う必要があるらしい。
  

• nb002
  

  • ver2
    
    • どうやら画像データのデータセットは自分で作らないといけないらしい。384×384で作ってから学習時に600×600にするのは、学習が早いかららしい。勉強のため、そうした場合と直接600×600に圧縮した場合の比較をしてみたい。恐らく、補完の際に若干崩れるため前者の精度は若干落ちると考えられる。
      
    • 書き終わったので一旦quick saveした。
      
  • ver3
    
    • 公開Notebookとパラメータを同じにして動かした。
      
    • ただし、時間短縮のため、foldは0のみにしてある。
      

    • CV	LB	train_loss	valid_loss
      0.9325	0.939	0.1152	0.1556

    • CVはほぼ同じなので、恐らく再現できてる。
  • ver4
    
    • ミスラベリングと議論されているデータを外した。また、全てのepochでモデルをセーブするようにした。
      

• nb003(inference_ResNext)
  

  • ver1
    
    • 同じくY.NakamaさんのNotebookを写経した。
      
    • 書き終わったので一旦quick saveした。
      
  • ver2
    
    • nb002_ver3の推論をしようとしたが、Internetを切り忘れた。
      
  • ver3
    
    • これ以降、trainingの方のNotebookに全て情報を書くため、このNotebookは登場させない。
      

• nb004
  

  • ver1
    
    • 384×384の画像のデータセットを作るためのNotebook。nb002の元のNotebookにあったコメント通りにzipファイルにしてみた。
      
    • 5GBもあるデータをいちいちローカルに落としてunzipして再びKaggleにあげ直すのは大変なので、Notebookの中でunzipして一つのファイルに入れるまでを行う。
      
  • ver2
    
    • unzipまで行った。
      
    • データが取り出せない。なぜ。
      
  • ver3
    
    • 恐らく写真が多すぎるので諦めた。3stepの学習Notebookでは、画像サイズは普通に512だったため、そっちにする。
      

• nb005(training_ResNeXt_step1)
  

  • [Y,Nakamaさんのstep1]の写経。
    
  • ver1
    
    • TPUにとても苦戦する。よくわからんけど苦戦する。よくわからんから苦戦するのか。
      
    • 一応全てのepochでモデルを保存するようにしておいた。
      
    • 間違えてdebugをTrueにしたまま回してしまった。
      
  • ver2
    
    • debugをFalseに直した。
      

20210225

• nb002
  
  • ver4
    
    • ミスラベリングの疑いがあった、ETT - Abnormalクラスのデータを一つ外したところ、ETT - Abnormalクラスのaucが0.9336->0.9617と上がったので、恐らく指摘に間違いはない。その他のクラスのaucが若干下がってるのが気になるが、誤差としか考えられない。
      
    • epoch5, 6を使うようにして、TTAを各5回にしたところ、LBが0.710まで落ちた。これは恐らく、学習の段階でaugmentationがRandomResizedCropとHorizontalFlipしかないことが原因だと思われる。
      
    • TTAなどの変更は全て戻してsibmitした。
      

    • CV	LB	train_loss	valid_loss
      0.9308	0.941	0.1305	0.1551

    • train_lossが高いのは、valid_lossが一番低いepochが手前にズレたから。
      
    • やはり、ラベリングは間違っていたとみていいと思う。
      
  • ver5
    
    • Augmentationを増やしてみた。LB0.965を出しているこのNotebookや、tawaraさんのスレッドでもAugmentationを増やすと精度が上がっているため、恐らく間違いない。
      
    • 1epochは最終層以外固定した。本当はこのように複数の変更を同時に行うべきではないが、時間がないので仕方がない。前回のコンペで効いているので入れる。
      
    • どちらがより大きい影響を及ぼしているかがわからないが、学習が遅くなってる。もうちょいepochを増やせばCVはまだ上がりそう。このnbの工夫はそのままnb006あたりに生かしたい。
      
  • ver6
    
    • lossがうまく下がらなかった。たとえ時間がなくても一気に二つ以上変更を加えてはいけない。これからは守る。
      
  • ver8(ver7は失敗)
    
    • augmentationを多めに入れた。
      

    • CV	LB	train_loss	valid_loss
      0.9332	0.936	0.1312	0.1530

    • CVはよくなってるけどLBが悪くなっている。
      
  • ver9
    
    • ver4から、1epochは出力層以外を凍結するように変更した。
      

    • CV	LB	train_loss	valid_loss
      0.9292	0.936	0.1189	0.1563

    • どちらも悪化してしまった。Cassavaコンペで効いたことがこっちでも一様に効くわけではないらしい。
      
• nb006(ResNeXt_step2)
  
  • ver3(ver1, ver2は失敗)
    
    • 動かした。
      
• nb007(ResNeXt_step3)
  
  • ver5(ver1はquick save, ver2, ver3, ver4は失敗)
    
    • とりあえず写して動かした。
      

    • CV	LB	train_loss	valid_loss
      0.9530	0.951	0.1107	0.0.1359

• nb009(公開Notebook)
  
  • ver1
    
    • 公開されている状態から、TTAを8回に増やした。
      
    • その後に、inferenceの関数内でモデルを5fold分ロードする形にしてみたところ、実行速度がかなり遅くなった。ボトルネックは恐らくモデルを毎回ロードしなければいけないところだと考えられる。loaderがボトルネックだと勝手に思い込んでいたが、実は違うらしい。工夫次第では他のNotebookもさらに早くなるかもしれない。
      
    • LBは0.955だった。TTAを無闇に入れてもダメなのか。aucとaccuracyでは勝手が違うので難しい。
      
  • ver3(ver2)は失敗
    
    • 公開Notebook通りに戻した。LBは0.965。それはそうだ。
      
  • ver4
    
    • vertical flipだけ入れてみた。
      
    • LBは0.965だが、表示桁以下は若干上がっている。
      
  • ver6(ver5は失敗)
    
    • verticalとhorizontalを同時にひっくり返すものも入れた。
      
    • 0.963に下がった。よくわからんなあ...
      
  • ver8(ver7は失敗)
    
    • ver4から、RandomResizedCropを入れた。
      
    • LBは0.964だった。
      
  • ver9
    
    • ver8から、ShiftScaleRotateを入れた。
      
    • LBは0.964だった。この取り組み、意味あるのかな...
      

20210226

• nb002
  
  • ver9(ver8は失敗)
    
    • ver4から、augmentationを追加した。nb005のaugmentationにverticalflipを追加したもの。
      

20210227

• 予測確率を1.1乗したりすれば、aucがよくなったりするのかと思っていたが、aucに関係するのは予測確率の順序だけであるため、全く意味がなかった。aucを大きく誤解していた。反省。ということは、最初の方にやった、trainデータの平均で各列を埋めたサブミットはaucが0.5になって当然となる。(閾値を変えても、FPR=TPR=0とFPR=TPR=1にしかならないため、左下と右上の角を結ぶことになるため当然面積は0.5になる。)
  
• nb009
  
  • ver8(ver7は失敗)
    
    • ver4から、RandomResizedCropを入れた。
      
    • LBは0.964だった。
      
  • ver9
    
    • ver8から、ShiftScaleRotateを入れた。
      
    • LBは0.964だった。この取り組み、意味あるのかな...
      
• nb010(training_ViT)
  
  • ver1
    
    • Cassavaコンペ3位のモデルを参考に、672x672の画像を9分割して224x224のViTにそれぞれ突っ込んで、attentionでweight averagingをするモデルを作ってみた。
      
    • 全然ダメだった。特にCVCクラスがひどすぎる。画像を切ってしまうと複数の画像にカテーテルが跨ってしまうのがよくないんだろうな...
      
  • ver2
    
    • 画像を448×448にして、４等分にしてみたけど同じくダメだった。この案はボツ。
      

20210301

• 鳥蛙コンペの反省会にお邪魔させていただいた。てっきり音声データは全く異質なことをしているのかを思いきや割と画像コンペの側面が強かったよう。色々勉強させていただいた。
• nb011
  
  • nb002_ver4をEfficientNetB3nsでやってみる。
    
  • 伸びが明らかによくなかった。DiscussionでもEfficientNetを使っている人はほとんどいないようなので、大人しくResNet200Dを使おうと思う。
    

20210302

• Discussionを色々みた結果、一番強そうなのはやはりResNet200Dだった。また、4stage trainingが強そうだった。
  
• annotationをどう使うかが今回の鍵になっていそう。一つの案としては、4stageにおける、3stageと4stageを交互に繰り返していくことがあげられる。そうすることで、よりteacherモデルの重みに近づけることができると予想。ちなみに、着想は鳥蛙コンペ5位のチームがやっていたcycle pseudo labelingから得た。
  
• ひらさんとマージした！！！ yukies爆誕！！！ 頑張るぞ〜
• nb005
  
  • ver5
    
    • 4stageのモデルは画像サイズを640にしていたため、teacherモデルも画像サイズを640にした。
      
• nb006
  
  • ver4
    
    • nb005_ver5の2stage。画像サイズを640x640にしたため、バッチサイズを16から8に落とした。本来は学習率も一緒に落とすが、そのままでもいけそうなのでそのままにした。epochを10に伸ばした。
      
    • 少し動かした感じだと、学習率はやはり小さくするべきだった。あと、epochは10だと長すぎる。
      
  • ver5
    
    • 学習率を落として、epochも戻した。ほぼ公開Notebookのまま。やはり最初はそうしないと比較ができない。対照実験を守るべし。
      

    • CV	train_loss	valid_loss
      0.9380	2.0690	0.1601

    • valid_lossが一番低いのがepoch2なのが気になる。学習率を落とした方がいいっぽい。
      

20210303

• annotationが間違ってる画像があるという意見がある。このディスカッションに書かれていた。外した方がスコアが高い可能性もなくはない。
  
• CVCのスコアはこのコンペの一つに鍵になっていると思う。ただ、このディスカッションによると、CVCのAUCスコアが低いのはモデルが苦戦しているからではなく、CVCがほぼ全てのデータに入っているからだそう。このディスカッションに外部データがある。使えるかも。
  
• nb006
  
  • ver6 ~ ver8
    
    • 学習率を変える実験をしたので色々書く(ver5から載せる)
      

    • learning rate (ver)	CV	train_loss	valid_loss
      2.5e-4(ver5)	0.9380	2.0690	0.1601
      1e-4(ver6)	0.9454	1.7504	0.1573
      5e-5(ver7)	0.9486	1.7765	0.1492
      3e-5(ver8)	0.9507	1.9575	0.1360
      2e-5(ver10)	0.9513	1.9946	0.1353
      1e-5(ver9)	0.9525	2.2128	0.1306

    • 公開KernelのCVが0.9234であることを考えるとかなりよくなっている(一旦全てのstageを通過させたモデルなので単純比較はできないけど)。
      
    • 学習率を落とすとepoch1のCVが高くなるが、それはもともとの重みが反映されているだけ。ここでの目的は親モデルの重みに近づけることであるため、train_lossもしっかり下がっているやつを選びたい。
      
    • 2e-5, 1e-5に関しては上記の理由でepoch5のモデルを取っている。
      
    • 以上から、ver10のモデルを採用する。
      
    • ちなみに、この時点でsubするとLBは0.953だった。
      
• nb007
  
  • ver9(ver6, ver7, ver8は失敗)
    
    • nb006_ver10_epoch5のモデルを使う。ハイパラは全て同じ。
      

    • CV	LB	train_loss	valid_loss
      0.9582	0.954	0.0884	0.1318

    • 学習率が大きく、完全に過学習している。
      
    • 公開Notebookではvalid_lossが一番低いモデルが使われていたが、今回はCVが一番いいモデルを使った。このディスカッションを見ると意見が割れているが、lossが小さい方を選ぶのは多数派で、AUCが良い方だけを見るとoverfitするらしい。今回は学習率が高すぎるので、次回以降に両方試してみる。
      

20210304

• 今実験しているサイクルに使っているモデルは、公開Notebookからそのまま取ってきただけのモデルであるため、今のfoldの切り方と同じ切り方で訓練した保証がなく、リークしている可能性がある。このdatasetで提供されている重みを使って、サイクル一周目からfold1を使ってモデルを作ろうと思う。そうしておいた方が後々全foldでモデルを作るときに手間も減る。
• nb005
  
  • ver6
    
    • fold1にした。また、重みの初期値をこの公開Datasetに変えた。
      
    • 結果があまりよくなかった。そもそも、stage1での重みは変えなくて大丈夫だった。
      
  • ver7
    
    • 重みを戻した。
      
    • ほぼCVが1まで上がり切ったので、こっちを採用する。
      
• nb006
  
  • ver11
    
    • fold1にした。ハイパラは全て同じ。
      
    • 間違えてLB0.965のpretrainedを使ってしまっていた。
      
  • ver12
    
    • 子モデルの初期重みを直した。結果、重みを大きく学習しなければいけなくなったため、学習率を元の5e-4に戻すことにした。
      
    • lossがかなり大きく、減りづらい。原因として、親モデルはImage Netの重みを使っているのに対して子モデルは医療画像用の重みを使っていることが考えられる。親モデルも後者にすべきだと考えたので、nb006_ver6の重みに変更してみる。
      
    • 学習率を2e-5に戻した。
      

    • CV	train_loss	valid_loss
      0.9272	1.7101	0.1547

    • valid_lossが一番低かったepochを書いた。
      
  • ver13
    
    • 学習率を1e-5にした。
      

    • CV	train_loss	valid_loss
      0.9092	1.8908	0.1717

    • 悪化したので、2e-5を採用する。
      
• nb007
  
  • ver9, ver10, ver11, ver12, ver13
    
    • 学習率を変える実験を行った。
      

    • learning rate (ver)	CV	LB	train_loss	valid_loss
      2.5e-4(ver9)	0.9582	0.954	0.0884	0.1318
      1e-4(ver10)	0.9614	0.961	0.1142	0.1222
      5e-5(ver11)	0.9670	0.964	0.1157	0.1126
      2e-5(ver12)	0.9708	0.966	0.1002	0.1058
      1e-5(ver13)	0.9711	0.965	0.0955	0.1041

    • 1e-5と2e-5ではほとんど差がなかった。nb006と同じ2e-5を採用することにする。
      

20210305

• Focal Lossの原論文とQiita記事に目を通した。実装は鳥蛙コンペのディスカッションにあった。
  
• 他の論文で、AUCを微分可能な関数で近似して直接最大化する手法が紹介されていた。メラノーマコンペなどで有効性が示されているらしい(論文のリンク)。実装してみたいがあまりに大変そうなので後回しにする。
  
• nb005
  
  • ver8
    
    • 医療画像のpretrainedでfold2の親モデルを作った。
      
• nb007
  
  • ver14
    
    • Focal Lossを試す。とりあえず、alpha=1(alphaの設定の仕方が原論文と違うが、alpha=1は、alphaは使用しないのと等価)、gamma=0.1にした。
      
    • ミスラベルの疑いがあるデータを外すことを忘れていたことに気がついた。これだけのために対照実験するのはあまりにも手間であることに加え、本来は外すべきものだったため、外しておく。
      

    • CV	LB	train_loss	valid_loss
      0.9708	0.964	0.0927	0.1053

    • LBが若干下がった。逆効果なのかもしれない。
      
    • epoch4の途中でlossが急にnanになってしまい、ストップしてしまった。Focal Lossは数値的な安定性に若干かけている印象を受ける。実装の仕方の問題であろうが、注意しなければならない。
      
  • ver15
    
    • gammaを0.5にした。
      
    • ローカルのGPUを使ったため、バッチサイズが8になって、学習率が1e-5になっている。
      

    • CV	LB	train_loss	valid_loss
      0.9709	0.966	0.1006	0.1085

    • LBはほぼ同じだが、表示桁以下は下がっている。僅差であるため、リークが完全にないモデルを作ってからもう一度試す価値はありそう。
    • valid_lossが一番低いモデルとCVが一番高いモデルを合わせてみたが、特に意味はなかった。伸びたとしても表示桁以下の違いにしかならなさそう。
      

20210306

• 最初からサイクルの2周目に色々な工夫を入れようとしたが、まずはサイクルの2周目でモデルの精度が改善されるかを確認する方が先だと思ったのでそうする。別の工夫は、モデルを作る段階(2・3stageの一周目)で取り組む。
• nb006
  
  • ver14
    
    • ver12から、ResNet200dにDual Attentioinを追加した。参考にしたNotebookのリンク。
      
    • メモリに乗り切らなかったため、バッチサイズを8に落としたが、学習率を変え忘れてたのでボツ。
      
  • ver15
    
    • バッチサイズを16->8にして学習率を 2e-5 -> 1e-5 に変えた(前はバッチサイズが16だったと勘違いしていたが、実はずっと8だった。なので、これからも学習率は1e-5にする)。
      

    • CV	train_loss	valid_loss
      0.9505	1.8525	0.1333

    • めちゃめちゃ強い。Publicの完成品をfine tuneした時と変わらない精度が出てる。
      
  • ver16
    
    • SAMを導入した。そのため、scalerは外している(apexを使いながらSAMを使う方法がわからなかった)。
      
    • foldごとにモデルを全部セーブする方式をやめた。
      
    • 学習率を1e-5にしていたけど、SAMに限ってはなかなか学習が進まないので止めた。
      
  • ver17
    
    • nb007_ver15.5のモデルの2回目のstage2。
      

    • CV	train_loss	valid_loss
      0.9534	1.7517	0.1366

  • ver18(ver17は失敗)
    
    • 学習率を2e-5にした。
      
    • Lossが大きいのが気になって途中で止めてしまった(止めなければよかった)。
• nb007
  
  • ver15(ver15.5)
    
    • nb006_ver12のモデル(リークがない、fold1のやつ)を学習させた。
      
    • 今気づいたが、ver15が二つある。これはver15.5ということにする。
      

    • CV	LB	train_loss	valid_loss
      0.9635	0.961	0.1075	0.1273

  • ver19(ver16, ver17, ver18は失敗)
    
    • nb006_ver15のモデルのfine tune。Dual Attentionをつけた。
      
    • どのモデルでも後半は過学習しているので、epochを5から4に変更する。
      
    • なぜかエラーを吐かれてしまった。
      
  • ver20
    
    • ひらさんに回してもらうためにquick saveした。
      
  • ver21
    
    • ver15.5と同じ。サイクルの２週目を回す。ミスラベルのデータを外すのを忘れてた(またやっちまったけどしゃーない...)。
      
    • epoch4にするのを忘れていた。
      

    • CV	LB	train_loss	valid_loss
      0.9679	0.963	0.1077	0.1185

    • 良い感じに伸びた。仮説は当たっていたらしい。
      

20210307

• nb006
  

  • ver19
    
    • 学習率を3e-5にした。
      

    • CV	train_loss	valid_loss
      0.9346	2.2481	0.1489

    • epoch5で過学習してしまっている。
      
  • ver20
    
    • 結局学習率を2e-5にした(何してんだよ俺)。
      

    • CV	train_loss	valid_loss
      0.9254	2.3515	0.1561

    • 学習率は3e-5の方がよかった。
      
  • ver21
    
    • ver12にFocal_Loss(gamma=0.5を入れた)。
      

    • CV	train_loss	valid_loss
      0.9316	1.6560	0.1679

• nb007
  

  • ver23(ver22はquick save)
    
    • これもquick save。ひらさんにDANetのリベンジをしてもらうべく、ver19のバッチサイズを12にして、epochを5に戻した(自分のNotebookでは14になっているが、ひらさんに回してもらうときに12になった)。
      

    • CV	LB	train_loss	valid_loss
      0.9648	0.963	0.1063	0.1223

    • まだvalid_lossが下がり続けているため、もっといける気がする。
      
  • ver24
    
    • ディスカッションで、trainingの最後でaugmentationを外すと精度が改善される言われている。原論文のリンク。ということで、lr=1e-6, min_lr=5e-7, epoch=2にして回してみることにした。
      
    • 元のモデルは、ver21のfine tuneモデル。
      

    • CV	LB	train_loss	valid_loss
      0.9687	0.963	0.0961	0.1142

    • CVは若干上がっている。LBも多分、表示桁以下は上がっていると思う。
      
  • ver25
    
    • nb006_ver21のFocalLossモデル。
      

    • CV	LB	train_loss	valid_loss
      0.9632	0.962	0.1229	0.1221

    • 一応LBは改善している。工夫の一つとして使えそう。
      

20210308

• nb006
  
  • ver22
    
    • nb007_ver21のfine tuningモデルを、さらにfine tuningする。設定はver13と全く同じ。nb007でFocalLossも使う予定。
      

    • CV	train_loss	valid_loss
      0.9535	1.472	0.1369

  • ver23
    
    • nb007_ver30のモデルの重みを使って、DANet moduleをつけてpretrainした。
      

    • CV	train_loss	valid_loss
      0.9552	1.4004	0.1284

    • nb007_ver30の方のモデルのLBが0.959で異様に低かったので、こちらのモデルの使用も見送ることにした。
      
• nb007
  
  • ver26
    
    • ver23のDANet moduleモデルを、バッチサイズ14で回す。
      

    • CV	LB	train_loss	valid_loss
      0.9656	0.964	0.1055	0.1214

    • 若干だけどCVがよくなって、LBも0.001上がっている。まだまだ上がりそうなので、ver25のfine tuningを試してみたい。
      
  • ver27
    
    • ver24からroc_star_lossを追加する。roc_starは、Deep AUCと同じような、AUCを最大化することを狙った損失関数。GitHubのリンクはここで、参考にしたNotebookはここ
      
    • GPUで動作確認をしたので、一旦quick saveした。
      
  • ver28
    
    • ver24のforkで、min_lr=9e-6にした。epochも3にした。モデルはnb007_ver26のもの。
      

    • CV	LB	train_loss	valid_loss
      0.9664	0.965	0.0984	0.1190

    • CV, LBともに若干改善した。しっかり効果が出ている。
      
  • ver29
    
    • ver27を回した。モデルはver28と同じ。
      

    • CV	LB	train_loss	valid_loss
      0.9664	0.963	40.5113	0.1187

    • roc_star_lossを使っているため、train_lossの値は他とは異なる。
      
    • 学習時間もかなり長くなった上にスコアも落ちてしまった。これは却下する。
      
  • ver30
    
    • nb006_ver21のモデルを、FocalLossを用いてfine tuningする。設定はver15と同じ。
      

    • CV	LB	train_loss	valid_loss
      0.9697	0.959	0.1051	0.1055

    • どうしてLBがこんなに低いのかさっぱりわからない。これならうまくいくと思っていたのに...
      

20210309

• nb007
  
  • ver31
    
    • ver30から、FocalLossのgammaを0.1に変える。
      

    • CV	LB	train_loss	valid_loss
      0.9689	0.957	0.0983	0.1034

    • 見るに耐えないのでFocal Lossは一旦保留にする。何かがおかしい可能性は否定できないけど、時間もない。
      
  • ver32
    
    • nb006_ver22のモデルのstage3を行った。cycleの３周目。
      

    • CV	train_loss	valid_loss
      0.9658	0.1075	0.1200

    • 悪化してしまった。Focal Lossが全部ダメだったのもこのせいである可能性が高い。
      

20210310

• nb006
  
  • ver24
    
    • nb007_ver21のモデルにDANet moduleを使ってpretrainする。nb006_ver15を使って、参照先をnb007_ver21のモデルに変える。
      

    • CV	train_loss	valid_loss
      0.9518	1.4768	0.1323

    • あまりver15からの改善は大きくはない。
      
• nb007
  
  • ver33
    
    • 前回はcycle の３周目のモデルに対してFocal Lossを適用してスコアが下がったが(ver30)、そもそも、Focal Lossを使わなくてもスコアが下がっていることがわかった(ver32)。なので、cycleの2周目のモデル(nb006_ver17)を使って、nb007_ver30で学習させてみる。
      

    • CV	LB	train_loss	valid_loss
      0.9672	0.959	0.1056	0.1109

    • FocalLossは何をやっても効かないのて完全にボツにする。
      

20210311

• nb006
  
  • ver25
    
    • DANet　moduleをつけた状態でもう一度step2とstep3を学習させてみることにした。そのstep2。ver15とハイパラは同じで、モデルの初期値がnb007_ver26になっている。
      

    • CV	train_loss	valid_loss
      0.9590	1.6305	0.1301

    • めちゃくちゃ強い。これが最強説ある。
      
• nb007
  
  • ver34
    
    • nb007_ver26を、nb006_ver24のモデルに対して適用する。cycle x2 -> DANet module
      

    • CV	LB	train_loss	valid_loss
      0.9463	0.963	0.1110	0.1240

    • 悪化してしまった。この方向性はよくないので変える。
      
• nb014(SeResNet152D-step1)
  
  • ver1
    
    • nb005_ver6のモデルをSeResNet152Dに変更した。デバイスをGPUにしたので、バッチサイズが16 -> 8に学習率が5e-4 -> 2.5e-4に、変わっている。
      
    • モデル名を変え忘れた。中身はちゃんと変わってる。
      
• nb015(EfficientNetB5ns-step1)
  
  • ver1
    
    • nb005_ver6のモデルをEfficientNetB5nsに変更した。デバイスをGPUにしたので、バッチサイズが16 -> 8に学習率が5e-4 -> 2.5e-4に、変わっている。
      
• nb016(SeResNet152D_step2)
  
  • ver1
    
    • nb006_ver12のモデルをSeResNet152Dに変えた。
      
  • ver2
    
    • ver1の親モデルがGPUに乗っていなかったので、乗せた。意味なかった。
      
  • ver3
    
    • nb006_ver15と同じで、DANet moduleをつけた。ローカルで回すとギリギリOOMになったのでバッチサイズを7に下げた。
      

    • CV	train_loss	valid_loss
      0.9407	3.1717	0.1377

    • ResNet200Dに比べると若干弱い。ただ、学習率をもうちょい上げればまだCVは伸びそう。
      
  • ver4
    
    • batch_sizeを4にして、gradient_accumulationを2にした。
      
    • このページによると、gradient_accumulationをやっても、Batch_Normalization層はbatch１つ分しか認識しない(確かにそれはそう)ため、完全に再現できるわけではないそうだ。
      

    • CV	train_loss	valid_loss
      0.8921	3.6073	0.1562

    • 確実に悪化してる...
      
  • ver5
    
    • gradient_accumulation=4にしてlr=2e-5にしたが、途中経過があまりにも悪すぎて途中で止めた。
      
  • ver6, ver7
    
    • batch_size=7に戻して、optimizerをRAdamとAdaBeliefに変えた。Adamの結果と合わせて記載する。
      

    • optimizer(version)	CV	valid_loss
      Adam(ver3)	0.9407	0.1377
      RAdam(ver6)	0.9376	0.1426
      AdaBelief(ver7)	0.9439	0.1402

  • ver8
    
    • optimizerをAdamに戻して、batch_size=7のままgradient_accumulation=2に、lr=2e-5してみた。
      

    • CV	train_loss	valid_loss
      0.1447	3.3681	0.1447

    • もはやgradient_accumulationって悪影響しか与えない結果になってしまった。実装は間違っていないように見えるのでおかしい気もするが諦める。
      
• nb017(EfficientNetB5ns_step2)
  
  • ver1
    
    • nb006_ver12のモデルをEfficientNetB5nsに変えた。
      
  • ver2
    
    • nb016_ver3のモデルをEfficientNetに変えた。こっちの方がメモリ消費が若干激しいので、nb016の方でgradient_accumulationの実験をしてからこっちを動かすことにする。
      
    • nb016の方で何をやってもうまくいかなかったので、普通にAdamでbatch_size=6, gradient_accumulation=1で回す。
      

20210313

• nb007
  
  • ver35
    
    • nb006_ver25(DANet module付、2周目)のモデルを学習させた。nb007_ver26からバッチサイズを15に上げた。
      
  • ver36, ver37
    
    • lrを下げた。パラメータ探索を軽くやりたいため、1epochのみで止めた。
      

    • lr(version)	CV	valid_loss
      2e-5(ver35)	0.9640	0.1271
      1e-5(ver36)	0.9642	0.1254
      5e-6(ver37)	0.9638	0.1247

    • CVはほぼ全部同じであるため、lossの下がり方と数値を見て5e-6を採用する。
      
  • ver38
    
    • ver35のlrを5e-6にした。
      

    • CV	LB	train_loss	valid_loss
      0.9651	-	0.1052	0.1224

    • 結局nb007_ver26に勝てない...
      
  • ver39
    
    • ver38のモデルをwoaug_fine_tuningする。ハイパラはnb017_ver4と同じ。
      

    • CV	LB	train_loss	valid_loss
      0.9658	0.965	0.0956	0.1210

    • LBは変わらなかったし、step2とstep3を一回ずつだけのモデルの方がvalid_lossは低い。失敗した...
      
• nb016
  
  • ver9
    
    • ver4からbatch_size=8にした。
      
  • ver10
    
    • AdaBeliefに変えた。
      
    • 二つの実験結果をまとめる。
      

    • optimizer(ver)	CV	train_loss	valid_loss
      Adam(ver9)	0.9470	3.2392	0.1354
      AdaBelief(ver10)	0.9420	3.3278	0.1387

    • Cassavaでも今回でもAdamの方がよかった。１からモデルを作る場合とfine tuningをする場合ではまた違う結果になるのだろうか。理由がいまいちよくわからない。
      
  • ver11
    
    • woaug_fine_tuningをやってみる。nb017_ver4とハイパラは同じ。
      

    • CV	train_loss	valid_loss
      0.9485	3.0327	0.1317

• nb017
  
  • ver3
    
    • nb016_ver9をモデルをEfficientNetB5nsに変えた。
      

    • CV	train_loss	valid_loss
      0.9439	0.7462	0.1386

    • なんかまだ下がりそうだな。
      
  • ver4
    
    • TPUが空いていなくてGPUに余裕があるので、wo aug fine tuningを試してみる。lr=1e-6, min_lr=5e-7, epochs=3, T_max=3にした。
      

    • CV	train_loss	valid_loss
      0.9490	0.7000	0.1347

• nb018(SeResNet152D)_step3
  
  • ver1
    
    • nb007_ver26をモデルをSeResNet152Dに変えてnb016_ver9のモデルを学習させた。
      

    • CV	LB	train_loss	valid_loss
      0.9609	-	0.1250	0.1282

  • ver2
    
    • nb016_ver11のモデルを学習させた。
      

    • CV	LB	train_loss	valid_loss
      0.9607	-	0.1248	0.1285

    • ほぼ変わらなかったので、ver1を使う。
      
  • ver3
    
    • ver1のモデルでwoaug_fine_tuningを行った。

    • CV	LB	train_loss	valid_loss
      0.9628	0.946	0.1054	0.1266

    • なんでだよーーーーーーーーーーーーーーー
      
• nb019(EfficientNetB5ns_step3)
  
  • ver1
    
    • TPUでどうしても動かないなあと思っていたが、よく考えたらtimmのEfficientNetはTPUだとうまく動かないとCassavaのときから言われていた。そこで、GPUで動かす。batch_sizeを16から8に落としてlrを2e-5から1e-5に下げた。
      

    • CV	train_loss	valid_loss
      0.9615	0.1343	0.1252

    • valid_lossの極小がepoch1にきてしまったため、明らかにlrが高すぎた。woaug_fine_tuningで調整すればいいか。
      
  • ver2
    
    • ver1のモデルをwoaug_fine_tuningした。epochは3にした。
      

    • CV	LB	train_loss	valid_loss
      0.9629	0.939	0.1086	0.1232

    • LBおかしくね？なんで？？？
• nb020(DenseNet121_step1)
  
  • ver1
    
    • fold1で、DenseNet121の親モデルを作った。
      
    • ETT - Abnormalが(他のモデルもそうだけど、一番)極端に悪い。流石にもうちょい上げたい。
      
  • ver2
    
    • 勘で、epochs=5, T_max=5, lr=1e-4にした。
      
    • best_scoreのモデルがいい感じになったので、それを採用する。
      
• nb021(DenseNet121_step2)
  
  • ver1
    
    • nb017_ver3のモデルをDenseNet121に変えた。ハイパラなどは全て同じ
      
    • ETT - AbnormalクラスのAUCが明らかにおかしいので止めた。
      
  • ver2
    
    • 親モデルをbest_lossに変えた。
      
    • CVが0.85ぐらいまでしか上がらなくて明らかにダメそうなのでここで諦める。
      

20210314

• 半分以上昨日のところに書いてしまった。
  
• nb006
  
  • ver26
    
    • nb006_ver15のモデルをwoaug_finetuningした。
      
    • スコアは若干上がったけどlossが悪化したので止める...
      
  • ver28(ver27は失敗)
    
    • 0.965のPublicモデルにDANet moduleをつけた。foldは0にしてある。
      

    • CV	train_loss	valid_loss
      0.9531	1.6474	0.1202

    • 強い。
      
• nb007
  
  • ver40
    
    • nb006_ver28のモデルのstep3。ver26をforkしてlr=1e-5に、batch_size=15に変更した。
      

    • CV	train_loss	valid_loss
      0.9668	0.0907	0.1078

    • 過去最高級に強い。
      

20210316

• nb005
  
  • ver9
    
    • ひらさんが見つけてきてくれたfoldの切り方にしたがってfoldを切った。fold0を使う。親モデルを作った。
      
    • 最初からDANet moduleをつけてみた。
      
    • lossが一番低いepochのCVが、ETT - abnormalクラスだけ異常に低いが、そもそもかなり陽性のデータが少ないので気にしない。
      
• nb006
  
  • ver29
    
    • nb005_ver9の親モデルを使って子モデルを作った。
      

    • CV	train_loss	valid_loss
      0.9459	0.3231	0.1213

    • train_lossの下がり方が全然違った。重みを近づけるなら、そもそもモデルの形を全て揃えるべきだったと考えられるし、foldも最初からこの切り方をすべきだった。
      
    • このepochはたまたまCVが低いが、直前では0.956まで上がっているので問題はないと思う。それよりlossの下がり方がすごい。
      
• nb007
  
  • ver41
    
    • ver40のモデルのwoaug_fine_tuning。ひらさんに回してもらう。
      

    • CV	LB	train_loss	valid_loss
      0.9673	0.962	0.0779	0.1082

    • LB低い。なんもわからん。
      
    • 後から気づいたが、augmentationを外し忘れていた。まあどのみち結果はあんまり変わらなかった気がする。
      
  • ver42
    
    • nb006_ver29のモデルの学習を回す。ひらさんに頼んだ。
      

    • CV	LB	train_loss	valid_loss
      0.9641	0.964	0.1109	0.1135

    • これは期待できそう。woaug_fine_tuningもやる。
      
  • ver43
    
    • ver42のモデルのwoaug_fine_tuning。
      
    • ひらさんが回す直前Datasetを差し替えてしまい、失敗した。
      
• nb016
  
  • ver12
    
    • 公開Notebookの重みにDANet moduleをつけて学習させた。
      

    • CV	train_loss	valid_loss
      0.9460	3.0299	0.1252

    • 当然強いけど、nb007_ver42の方が優先かなあ
      
• nb018
  
  • ver4, ver5
    
    • nb016_ver12のモデルのstep3をひらさんに回してもらおうとしたが、エラーがでて断念した。
      
  • ver7(ver6は失敗)
    
    • SeResNetのPublic Weightをfine tuningしたが、foldの切り方をPatient leakが起こらないものにした結果、逆にリークが大きくなったらしくCVが異常に高くなったしまった。
      
  • ver8
    
    • foldの切り方を戻してひらさんに回してもらった。
      

    • CV	LB	train_loss	valid_loss
      0.9683	0.962	0.1133	0.1087

    • 結局リークしてるけどもう時間がない。これ本当は絶対に良くないやつだよな...反省...
      
    • 表示桁以下はスコアが改善しているものと信じる(後から確認したら0.0004ぐらい上がってた)。
      

20210316

• もうここに記録するのを怠り始めていて、何が何だかだんだんわからなくなってきている。
  
• nb007
  
  • ver44
    
    • ver43のwoaug_fine_tuning。
      
• nb009
  
  • ver15
    
    • 公開Notebookのモデルをほぼ全て差し替えた。
      
      • ResNet1はTTAにvertical flipを追加。
        
      • ResNet2はnb007_ver12に差し替え(LB0.966)
      • ResNet3としてDual Attention Moduleがついた自作ResNetを追加(LB0.965)。
        
      • SeResNet152Dはfine tuningしたnb007_ver8に差し替えた。
        
      • PublicのEfficientNet、Multi Headを拝借した。本当は全部自力で行きたかった。力不足...
        
    • 何はともあれLBが0.968で銅圏に入れた。