Kaggle-SIIM-FISABIO-RSNA

KaggleのSIIM-FISABIO-RSNA COVID-19 Detectionコンペのリポジトリです。
codeというディレクトリに今回使用したスクリプトを置いていて、outputというディレクトリの対応するバージョンのところにlogなどが置いてあります。

KaggleのDiscussionに弊チームのsolutionを公開しています。こちらから飛べるのでぜひご覧ください！

最終結果

• Public: 0.628 59th/1324
  
• Private: 0.607 78th/1324
  
• 銀圏からshake downして銅でした。悔しい...
  

方針

• ファイルはgitで管理する。ただし頑張り過ぎない。
  
• Notebookやスクリプトはsiim_○○○_ver□□_hoge.ipynb(nb)の形で統一する。
  

振り返り

良かった点

• Yoloに頼らずに、EfficientDetのコードを自分のパイプラインに組み込んだこと。
  
• 過去コンペから解法を手早く引っ張って来れたこと。(3step学習など)
• 初めてしっかりgithubを使ってコードを管理し、チーム内でもスムーズに共有ができた(これはshopeeの時の課題だったので成長)。
  
• 最後の最後に粘ってスコアを上げられた(これもshopeeの時の課題だった)。
  

悪かった点

• EfficientDetやmAPの計算の実装に時間がかかりすぎて本質的なことに踏み込んだのが遅かった。
  
• CVの切り方をしっかり確認しなかったせいで直前になってリークに気づいて直す羽目になった。(Shopeeの時にはできていたので大反省)
  
• 読んだ論文の本数が少なかった。もうすこし自分で真面目にサーベイをするべきだった。
  
• githubのProjectsでアイデアを管理する予定だったが、あまり使うことができなかったためにアイデアの実装スピードが遅かった。
  
• アイデアはGithub、記録はREADME、共有はslackで行っており、ちょっと分散させすぎたかもしれない
• 単純に火がつくのが遅かった。
  

Paper

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

No	Name	Detail	Date	link
01	Weighted boxes fusion: Ensembling boxes from different object detection models	各bboxのconfidence scoreをもとにしてbboxを合成する、物体検出におけるアンサンブル手法	9 Feb 2021	link
02	The Lovasz-Softmax loss: A tractable surrogate for the optimization of the intersection-over-union measure in neural networks	IOUを直接最適化する手法。今回のコンペにおけるAuxiliary Lossに入れたかった。	9 Apr 2018	link

Overview(Deepl)

Description

COVID-19は、インフルエンザの5倍の致死率で、重大な罹患率と死亡率を引き起こします。他の肺炎と同様に、COVID-19に肺感染すると、肺に炎症や水が溜まります。COVID-19は、胸部X線写真では他のウイルス性や細菌性の肺炎と非常によく似ているため、診断が困難です。COVID-19を検出して位置を特定するコンピュータビジョンモデルがあれば、医師が自信を持って迅速に診断を下すことができます。その結果、患者はウイルスの最も深刻な影響を受ける前に、適切な治療を受けることができます。

現在、COVID-19の診断は、ポリメラーゼ連鎖反応でウイルスの遺伝物質を検出する方法と、胸部X線写真で行う方法があります。しかし、分子検査の結果が出るまでには、数時間から時には数日かかることもあります。これに対し、胸部X線写真は数分で撮影できます。放射線科医がCOVID-19を他のタイプの感染症と区別するためのガイドラインは存在するが、その評価は様々である。また、放射線科医以外の医師は、視覚的なバウンディングボックスなどを用いて、疾患の位置をより明確にすることでサポートすることができます」と述べています。

Society for Imaging Informatics in Medicine（SIIM）は、教育、研究、革新を通じて医療画像情報学を推進することを使命とする、この分野における主要なヘルスケア団体です。SIIMは、バレンシア地方健康・生物医学研究促進財団（FISABIO）、バレンシア地方医用画像データバンク（BIMCV）、北米放射線学会（RSNA）と協力して、このコンペティションを開催します。

このコンテストでは、胸部X線写真上でCOVID-19の異常を識別し、位置を特定します。特に、肺炎の陰性、COVID-19の典型、不確定、非典型のいずれかに分類します。あなたとあなたのモデルは、複数の放射線科医が撮影した画像データと注釈を用いて作業を行います。

成功すれば、放射線科医が何百万人ものCOVID-19患者をより自信を持って迅速に診断できるようになります。また、医師が病気の範囲を確認し、治療に関する意思決定に役立てることができます。重症度によっては、入院や集中治療室への入室、人工呼吸などの支持療法が必要になる場合もあります。より良い診断の結果、より多くの患者さんが迅速に最適な治療を受けることができ、ウイルスの最も深刻な影響を軽減することができます。

Evaluation

この課題では、標準的なPASCAL VOC 2010の平均平均精度（mAP）をIoU > 0.5で使用しています。なお、リンク先の資料にはVOC 2012が記載されていますが、VOC 2010とは細かい点で異なります（例：VOC 2010には「難しい」クラスの概念がありません）。P/R曲線やAPの計算方法は変わりません。

本大会では、スタディ（複数画像）レベルと画像レベルの両方で予測を行っています。

Study-level labels
テストセットのスタディには、複数のラベルが含まれている場合があります。それらは以下の通りです。

"negative"、"typical"、"indeterminate"、"atypical"

詳細は「データ」のページをご覧ください。

テストセットの各研究について、上記のラベルのうち少なくとも1つを予測する必要があります。与えられたラベルの予測のフォーマットは、上記リストからのクラスID、信頼度スコア、0 0 1 1は1ピクセルのバウンディングボックスとなります。

Image-level labels
テストセットの画像には、複数のオブジェクトが含まれている場合があります。与えられたテスト画像の各オブジェクトに対して，クラスIDとして "opacity"，信頼度スコア，バウンディングボックスをxmin ymin xmax ymaxの形式で予測する必要があります．ここで，noneは "No finding "のクラスID，1.0は信頼度，0 0 1 1は1ピクセルのバウンディングボックスを表しています．

Submission File
投稿ファイルは，ヘッダを含み，以下の形式である．

Id,PredictionString 2b95d54e4be65_study,negative 1 0 0 1 1 2b95d54e4be66_study,typical 1 0 0 1 1 2b95d54e4be67_study,indeterminate 1 0 0 1 1 atypical 1 0 0 1 1 2B95D54E4BE68_画像,なし 1 0 0 1 1 2b95d54e4be69_image,opacity 0.5 100 100 200 200 opacity 0.7 10 10 20 20

Data(Deepl)

この競技では、胸部X線写真上のCOVID-19の異常を識別し、局所化しています。これは、物体検出と分類の問題です。

各テスト画像について、すべての所見のバウンディングボックスとクラスを予測することになります。所見がないと予測した場合は、「none 1 0 0 1 1」という予測を作成します（「none」は所見がないことを示すクラスIDで、これは信頼度1.0の1ピクセルのバウンディングボックスを提供します）。

さらに、各試験研究について、以下のラベル内で判定を行う必要がある。

肺炎陰性」「典型的な外観」「不確定な外観」「非典型的な外観」。

上記のラベルの1つを予測するには、上記の「none」クラスと同様の予測文字列を作成します：例： atypical 1 0 0 1 1

予測値のフォーマットについての詳細は、「評価」のページを参照してください。

画像はDICOM形式なので、視覚化や分類に役立つ追加データが含まれています。

データセット情報
訓練データセットは、DICOM形式の6,334枚の胸部スキャンで構成されており、患者のプライバシーを保護するために非識別化されています。すべての画像は，経験豊富な放射線科医のパネルによって，不透明性の有無と全体的な外観についてラベル付けされています．

すべての画像はstudy/series/imageという形式のパスに格納されていることに注意してください。ここでのstudy IDはstudyレベルの予測に直接関係し、image IDはimageレベルの予測に使われるIDです。

隠れたテストデータセットは，学習データセットとほぼ同じ規模のものです．

Files

train_study_level.csv - 学習データレベルのメタデータで，各学習データごとに1行あり，正しいラベルも含まれています．
train_image_level.csv - 訓練画像レベルのメタデータで，各画像ごとに1行，正しいラベルと辞書形式のバウンディングボックスが含まれています．test, trainともに，複数のバウンディングボックスを持つ画像があります．
sample_submission.csv - 全ての画像レベルと研究レベルのIDを含むサンプル投稿ファイル。

Columns

train_study_level.csv
id - 一意の研究識別子
Negative for Pneumonia - 肺炎が陰性の場合は1、それ以外は0。
典型的な外観 - このような外観の研究であれば1、それ以外は0
不確定な外観 - 研究がこのような外観である場合は1、そうでない場合は0
非典型的な外観 - このような外観の場合は1、それ以外は0

train_image_level.csv
id - 一意な画像識別子
boxes - 簡単に読める辞書形式のバウンディングボックス
label - 与えられたバウンディングボックスに対する正しい予測ラベル

Citation

この課題で使用されているBIMCV-COVID19データは、The Foundation for the Promotion of Health and Biomedical Research of Valencia Region (FISABIO)とThe Regional Ministry of Innovation, Universities, Science and Digital Society (Generalitat Valenciana)の協力のもと、Medical Imaging Databank of the Valencia Region (BIMCV)によって公開されたものですが、画像は異なるアノテーションタイプを用いて完全に再アノテーションされています。このデータの利用者は、BIMCV-COVID19 Dataset research Use Agreementに従わなければなりません。論文参照 BIMCV COVID-19+：COVID-19患者のRXおよびCT画像の大規模なアノテーション付きデータセット

この課題で使用されたMIDRC-RICORDデータは、元々The Cancer Imaging Archiveによって公開されたものです。この課題のために、画像は異なるアノテーション・スキーマを用いて再アノテーションされました。このデータを使用する際には、TCIA Data Usage Policyおよび公開されているCreative Commons Attribution-NonCommercial 4.0 International Licenseを遵守する必要があります。アトリビューションには、TCIAの引用情報ページ（ページ下部）に記載されている引用文献への参照を含める必要があります。論文の参照先 The RSNA International COVID-19 Open Radiology Database (RICORD)

Log

20210621

• join !!
  
• 色々コンペに関して不明な点や物体検出に関してわからない点が多かったので初日はEDAと調査に費やした。色々わかったことを書いていく。
  
  • タスクについて。今回は各画像に対して画像分類と物体検出を両方行っていく。study_levelに対しては画像分類を、image_levelに対しては物体検出を行う。study_levelは6054枚、image_levelは6054枚あり、前者は後者のStudyInstanceUIDに対応してるらしい。だから、画像分類に関しては全部の画像は必ずしも使わなくてかもしれない。
    
  • 評価指標について。mAPの説明に関してはこのQiita記事がわかりやすかった。その中のconfidenceなどに対する説明はこのQiita記事がわかりやすかった。ついでにYoloも色々学べた。
    
  • study_levelのラベルについて。trainデータのラベルは全て1種類のみだが、Evaluationのページはなぜか2種類予測しているところがあり、文章でも"Studies in the test set may contain more than one label."とある。このDiscussion�におけるホストの回答では、各annotatorは1つのラベルのみを付与しているが、今回の提出format上、2つ以上のラベルを予測することを拒否できないからと回答している。今のところは基本的に一種類で予測してしまっていいような気がする。
    
  • モデルについて。大体はtfを使っていてコードがよくわからなかった。そのまま動かしてもいいが、いまいちやった感がないのでは勉強にならないので、このNotebookを参考にしてしっかり自分のコードに落とし込んでから色々なモデルを試していこうと思う。
    
• 001(EDA)
  
  • ver1
    
    • ここでわかったことは割と上で書いてしまったが、そうでないところを書いていく。
      
    • image_levelに関して、StudyInstanceUIDで被りがあるため、そこはgroup化してvalidationをしないとリークになるだろう。ただ、StudyInstanceUIDが同じ画像群はほとんど画像が同じである上にbboxが付与されているものが一つしかないため、結局そのうちの一つだけを使うことになりそう。そうなると別にgroup化する必要はなくなるか。このDiscussionにおけるホストの回答からの情報。
      
    • study_levelに関して、クラスの偏りはあるがそう大きくはないような気がする。いったん気にせず学習させて、予測精度に偏りが見られたらFocal Lossなどで対応していく感じでいいかな？
      

20210625

この三日間、ひたすらDetectionのモデルを動かすのに苦戦していた。

• AdamのWeight Decayは若干おかしいため、AdamでWeight Decayを使うぐらいならAdamWを使うのがいいらしい。自分はいつもAdamでWeight Decayを使ってきたので、これを機にAdamWに乗り換えてみる。
  
• 002(EffDetd0)
  
  • 本当は上述の通りにFasterRCNNを使おうとしていたが、どうしても推論の時にモデルが出力をしてくれず、結局断念した。また、参考にしようとしていたNotebookもおかしかったのでどうすることもできなかった。無念。
    
  • 実は、参考にしていたNotebookは、小麦コンペのEfficientDetのNotebookをほぼそのまま使っていたようなので、こちらを参考にすることにした。upvote数が半端じゃないぐらい高い上に推論のコードもしっかり用意されているので、とても良さそう。小麦コンペにはDetectionに関して参考になるNotebookが非常にたくさんあるため、他のモデルについても参考にしていきたい。
    
  • そのままEfficientDetを使うことにした。小麦コンペの上位解法は大体EfficientDetで構成されているので信用できそう。ただ、今後の勉強のためにどこかのタイミングでFasterRCNNはフルスクラッチで実装できる必要がある。
    
  • ver1
    
    • とりあえずD0にした。最初は色々様子を見たいので軽い方がいい。
      

2020627

• 002
  
  • ver2
    
    • modelを呼び出そうとしたらload_state_dictでエラーが起こってしまったのでそれについて調べた。今回はなぜか、state_dictの中身がmodel.mode.hogeの形になっていて、読み込む側はmodel.hogeの形になっているためにミスマッチが起こっている。いつもはstate_dict側もmodel.hogeの形になっているため問題がなかった。恐らく今回のDetBenchTrainあたりが何か裏でやっているのかもしれない。それ以外は状況が同じなので、それぐらいしか考えられない。今回は目を瞑ってsaveするときにmodel.model.state_dict()として解決することにする。
      
    • それに伴って、学習をやり直すことにした。
      
    • CVを出せるようにコードを追加する。CVを出すにあたって、このNotebookを参考にした。ただ、小麦コンペのprecisionは分母にfalse segativeも入っているがSIIMでは含まれていないはずだから、そこは抜かないといけない。
      
    • やっぱり、小麦コンペのものをそのまま使っても正しくスコアが出せないと見た(多分presicion-recallの曲線の積分ができてない？)ので、titoさんのNotebookを参考にすることにした。ここで疑問に思うのが、grand-truthがない場合のAPの数値について。一つも予測しなければnoneとして予測してpresicionもrecallも1の状況ができるからAPは1でよくて、一つでも予測してしまった時点で0になると言う認識で良さそう。
      
    • version関係で死ぬほど苦戦して、結局titoさんのNFLのNotebookを参考にしてなんとか動かせた。闇が深い。
      
    • 動かせたが、lossの落ち方が若干悪くなってしまった。どこが原因かよくわからないので探る必要がある。また、mAPが0になってしまった。恐らくnoneの予測の仕方が間違っているので、考え直さなければいけない。
      
  • ver3
    
    • noneの予測の仕方について。思いついているのは次の通り。
      
      • 全部opacityで予測して、面積が異常に小さいやつは全てnone扱いにする。
        
      • 普通に2クラスで予測させる。閾値に2クラス分類モデルを使う。
        
      • opacityのみについて学習し、予測の際には2クラス分類でopacityが存在すると予測されたものだけを対象にする。予測がなかったものに関してはnoneを入れる。
        
    • 筋が良さそう(2値分類モデルとの相性が良さそう)なのは2番目と3番目だと思う。2値分類がそんなに強くないなら2番目、強いなら3番目にしていいと思うが、それは実験をしてみないとわからなさそう。
      
    • 2クラスでbboxを予測するコードをとりあえず書いたところで終わった。

20210629

• 002
  
  • ver3
    
    • 色々デバッグに苦しんだ。リストではさまざまな型のデータを同時に入れることができるが、ndarrayではそれができないためにnp.stack(list)とした時点でデータ型が全て統一されてしまう仕様に気づかず、モデルの出力がいつの間にか全て文字列になってしまっているのがどうしてかわからなかった。ちなみに、mAPを出す関数内では改めて型を変換しているのでそのまま突っ込んで大丈夫。
      
    • 中途半端にクラス名を0・1にしたりnone・opacityにしたりしてしまったが、全部0・1に統一して、subする時だけnone・opacityを書いた方がいい。
      
    • デフォルトだとmAPは0で、後処理を頑張って初めてnoneクラスのmAPが0.2程度になる。opacityクラスは、IOU_thresholdを0.01にしてもmAPが0なので、全く当て切れていない。モデルを大きくしたり画像サイズを大きくしたりして少し粘ってみて、そのあとは2クラス分類モデルと組み合わせる。
      
• 003(2class_train_Eff)
  
  • ver1~4
    
    • stei_002_ver7を引っ張ってきて、各画像がopacityなのかnoneなのか学習させるモデルを作った。モデルはEffb0。
      

    • ver	ver1との差分	CV(AUC)
      1	-	0.87024
      2	バッチサイズを64->128にした	0.86923
      3	画像サイズを256->384にした	0.87431
      4	画像サイズを256->512にした	0.87152

    • bboxがあるかどうかの2値分類はやはりそれなりに難しいみたい。大幅に改善するには外部データを持ってくるなどしなければいけないと思われるので、とりあえずこの精度でできることをしたい。
      

20210630

• 002
  
  • ver4
    
    • 発展DeepLearningとarutemaさんのNotebookを参考にしてnmsを実装した。多少はbboxが減っていたようなので、いい方向に働くはず。
      
  • ver5
    
    • モデルをD1に変更した。
      
  • ver6
    
    • モデルをD2に変更した。nmsのところでエラーが出てしまったので、恐らくconfの値で全て切られてしまったと思われる。modelごとにconfの値が大きく違うのは結構気になる。
      
• 003
  
  • ver5, 6
    
    • ver3から、モデルをEffv2に変えてみる。
      

    • ver	model	CV
      5	tf_efficientnetv2_s	0.88113
      6	tf_efficientnetv2_s_in21ft1k	0.88085

    • CVは伸びたが、モデルがかなり重たい。だったら普通にb0でいいと感じた。
      

20210701

• 002
  
  • ver7
    
    • confのthresholdを0.01にして再挑戦する。
      
  • ver8
    
    • EffDetD3。ここでOOMが起きたのでバッチサイズを64から32に下げた。
      
  • ver9~ver12
    
    • モデルを大きくし続けた。実験結果は以下の通り。
      

    • ver	model	batch_size	loss
      04	D0	64	8.6876
      05	D1	64	5.8122
      07	D2	64	4.8656
      08	D3	32	1.3821
      09	D4	32	1.2380
      10	D5	24	1.1016
      11	D6	16	0.9420
      12	D7	16	0.9019

    • D3から先が一気にLossが落ちているため、当面の間はD3で実験をしていく。
      
• 004(4class_train_EffNet)
  
  • ver1~3
    
    • study_classの予測のためのモデル。
      
    • てっきり確率が一番高いクラスのconfを1にして提出するのかと思いきや、公開Notebookを見ていると確率をそのままconfにして、4クラス全てを予測して提出していた。どっちがCVが高くなるか確認する必要がある。
      
    • 公開Notebookをみる限りではimage_classよりもstudy_classの方がスコアが高いので、こっちをしっかり詰める必要がある。
      
    • RANZCRのときに公開されていた重みがそのまま今回も使えるかもしれないので、それも考えてEffB3で始めようと思う。
      
    • 画像サイズを色々変えて実験した。
      

    • ver	size	Score(AUC)
      01	256	0.7706
      02	384	0.7760
      03	512	0.7811

    • そこまで変わらなかった。とりあえずCVもだす。
      

20210702

• 002
  
  • ver13, 14
    
    • 画像サイズを変えて実験した。
      

    • ver	size	loss
      08	256	1.3821
      13	384	1.1065
      14	512	1.0010

    • モデルのサイズからしても画像のサイズからしても、まだまだLossが落ちそう。
      
  • ver15, ver16
    
    • 256の画像を使って拡大してしまっていたため、512の画像を使ってやり直す。
      
    • また、nmsは1画像ごとにconfが高いbboxをtop_k個取ってきて、その中で重複しているbboxを消すものであって、EffDetは１画像に対して100個の予測をしするため、top_kは200ではなく100で十分であることがわかった。10程度に削ってもいいが、mAPをあげるにはとりあえず当てきれないといけないので予測は積極的に残すべき(下位に正解があるのにそれを切ったら損するだけ)。
      

    • ver	size	loss
      08	256	1.3821
      15	384	1.1301
      16	512	0.9952

  • ver17
    
    • opacityクラスだけを学習するように修正した。
      
    • loss: 0.9934。ほぼ変わらないので実装はあっていると思う。
      
• 005(detection_caliculate_CV)
  
  • ver1, 2
    
    • それぞれ002-ver13, ver14のmAPを計算した。
      

    • ver	002-ver	mAP
      01	13	0.1596
      02	14	0.1793

    • ただし、これらは全てnoneクラスに対するmAPである。本来、noneクラスは2クラス分類モデルで当てるため、detectionモデルではopacityをしっかり当てきれないといけない。まだまだ改善が必要...
      
    • ver3
      
      • 003-ver6のモデルの予測を使ってnoneを入れた。
        
      • mAPが0.4303まで上がった。明らかによくなったので、やはりdetectionはopacityだけを予測して、noneは2クラス分類で予測する方が筋がいいみたい。
        
      • ちなみに、detectionの予測も利用してnoneの精度をあげようとしたがほぼ上がらなかった。
        
    • ver4
      
      • 各bboxの正誤判定は画像ごとに行われるが、それぞれのtrue or falseと一緒にconfが一緒に保存されて、最後にconfをthresholdとして動かして積分してmAPを出すから、予測にしっかりモデルの自信を反映させることが大事であることがわかった。今回の2クラス分類のモデルはopacityがある確率を出すため、noneのconfには1 - probの値を入れればいい。そうするとmAPは0.4303から0.4916まで上がった。今後はこれでいく。
        

20210703

• 003
  
  • ver7
    
    • モデルをEffcientNetB3に変える。
      
    • Score(AUC): 0.89131。EfficientNetv2_sより軽いし性能もよかった。v2はなんだったんだろう。
      
  • ver8
    
    • mAPを算出できるようにした。
      
    • mAPが0.3620で、005-ver4よりかなり低かった。なぜだろう...
      
  • ver9
    
    • ver8で戸惑ったmAPについては、opecityの0が入った平均になっていた。なので、クラスnoneに関してはその倍の値のAPが出ていた。ついでにモデルの保存に使うscoreもmAPにするなど色々整えた。
      
    • ということは、005のCVも、noneは確率0.5以上ではなく全部入れてしまうようにすればもっと値が高くなるはず。
      
    • mAP: 0.7240
      
• 004
  
  • ver4
    
    • 各クラスのmAPを算出できるようにした。それ以外はver3と同じ。
      
    • mAP: 0.5224。こっちをあげる方が優先かもしれない。
      
• 005
  
  • ver5
    
    • 003-ver9で気づいた通りにmAPを算出したら0.7153まで上がった。AUCが0.8を超えていることからも、妥当な値だと思われる。
      
    • 公開Notebookでは、imageクラスのmAPは大体0.16であるということは、opacityとnoneのmAPの平均はその3倍の0.48ぐらい。現段階で0.7153*(1/2)=0.3577程度出ているため、思った以上にopacityクラスのmAPは低そう。noneクラスのmAPが今のままだとしても、opacityのmAPが0.25程度出てしまえば追いつける。(0.000021しか出てないけど...)
      

20210704

• 002
  
  • ver18
    
    • ローカルで動かせるようにデータセットなどを整えた。また、mAPをちゃんと出力・記録できるようにして、annotationsとpredictionsはDataFrameにしてからpickleで保存するようにした。
      
    • bboxの変換を最初にして、DataSet内では変換しないようにして1epochあたり1分程度高速化した。
      
    • バッチサイズを8から16に上げた。
      

    • train loss	valid loss	CV
      1.0184	1.2654	0

    • バッチサイズを倍にしたので学習しきれなくなってる。公平な比較のために学習率は同じ比率であげるべきだった。ここまで学習率はいじらずにきたので、もしかしたらまだまだ学習できるかもしれない。物体検出のモデルの勘所が掴めないが、他のどのモデルを見ても30~50epochぐらいは回しているので、もっと気長に待つべきなのかもしれない。
      
  • ver19
    
    • とりあえず学習率を上げていきつつ様子を見る。本来ここでハイパラを探索するのは得策ではないが、学習率は実験を回すスピードにもろに影響するので上げられる分は上げていいと思う。
      

    • ver	lr	train loss	valid loss	CV
      18	1e-4	1.0184	1.2654	0
      19	2e-4	0.8776	1.0328	0
      20	3e-4	0.8387	1.0053	0

    • バッチサイズに合わせて学習率はあげるべきだった。また、今回は最小値も変えてしまったがそれは変えないべきだったかもしれない。しょうもない実験だけどいまいち見えないのでもう少し続けようと思う。
      
  • ver21
    
    • ver18からepochを30に増やしてみた。
      

    • ver	epoch	train loss	valid loss	CV
      18	10	1.0184	1.2654	0
      21	30	0.7916	1.0428	0

    • epochが足りていないわけではなかった。ひとまず10のままで固定する。
      

20210705

• そういえばwandbを導入しようとしていたのを忘れてた。いちいちここに表形式でlossを書くぐらいなら使った方がいい気がする。
  
• 002
  
  • ver22
    
    • ver20から最小値だけ元に戻す。恐らくこれは画像認識の方でも同じようにした方がいい。学習の初動はパラメータが進む方向は定まりやすいはずで、その時は学習率は大きくすべきだが後半はそうではないと考えられる。
      

    • train loss	valid loss	CV
      0.8391	1.0053	0

    • ほぼスコアは同じだが後半は安定していたのでこっちにする。
      
  • ver23
    
    • transformで、validationの時だけNormalizeが入ってたので抜く。今回はDatasetの中で簡易的にNormalizeをしているため、transformで入れる必要はない。もしかしたらこれが原因で精度がでてなかったのかも。
      

    • train loss	valid loss	CV
      0.8390	0.9337	0

    • 無事にlossは落ちたが、それでもmAPは0のままなので、もう少しlossを下げに行った後に根本的な誤りを見つけに行った方がいいと感じる。
      
  • ver24
    
    • augmentationを少し強めた。
      

    • train loss	valid loss	CV
      0.8128	0.9529	0

  • ver25
    
    • augmentationをさらに強めた。
      

    • train loss	valid loss	CV
      0.7952	1.0136	0

    • augmentationを強くしているのにどんどん過学習が強くなってしまっている。全然わからん...とりあえずver23に戻して実験をする。
      
  • ver26, ver27
    
    • モデルを大きくした。
      

    • ver	model	train loss	valid loss	CV
      23	D3	0.8390	0.9337	0
      26	D4	0.7942	0.9196	0
      27	D5	0.7440	0.8862	0

    • lossはどんどん改善しているが依然としてCVはゼロのまま。これはどう考えてもモデルの性能じゃなくて出力の途中でバグを埋め込んでるだろ...
      
  • ver28
    
    • titoさんNotebookをよくみたら、モデルの元々の出力は[xmin, ymin, xmax, ymax]ではなく[xmin, ymin, width, height]らしく、それを後から修正していた。恐らくこれを見落としていたんだと思う。
      
• 003
  
  • ver10
    
    • Kaggle Notebookで動かすために、バッチサイズを16に落とした。
      
    • また、annotationsやpredictionsを保存しておくようにした。
      

    • train loss	valid loss	CV
      0.1999	0.3273	0.7188

    • 案の定過学習気味になってしまった。めんどくさがらずに学習率も合わせて調整すべきだった。ただ、画像サイズが384に落ちたことによって多少はmAPも落ちるはずなので、妥当な数値ではある。
      
  • ver11
    
    • バッチサイズを16に落としたのに合わせて、学習率も半分に落とした。
      

    • train loss	valid loss	CV
      0.3122	0.3280	0.6990

    • なぜかうまくいかなかったのでver10に戻す。
      
  • ver12
    
    • Normalizeを全くしていないことが発覚したので修正した。
      

    • train loss	valid loss	CV
      0.2019	0.3361	0.7107

    • 多少mAPが落ちているが、多分誤差の範囲内だしこっちの実装が正しいのでこのままいく。
      
  • ver13
    
    • augmentationを少し強めた。
      

    • train loss	valid loss	CV
      0.2779	0.3254	0.7239

  • ver14
    
    • さらにaugmentationを強めた。
      

    • train loss	valid loss	CV
      0.3057	0.3183	0.7179

    • 多少CVが落ちているが、lossはこちらが低く、これからモデルを大きくするので一旦これでいこうと思う。
      
  • ver15
    
    • 実はRANZCRの時のpretrainedのモデルはB5だったので、モデルのサイズを上げていく。
      

    • train loss	valid loss	CV
      0.3411	0.3354	0.7081

    • 全然安定しないので少しepochを伸ばす必要があるかもしれない。また、CVは基本的に高い方を採用していくべきなのでver13に戻す。あまり時間が取れずに色々並列に回しているので至らないところが増えてきてるな...
      
• 004
  
  • ver5
    
    • Kaggle Notebookで動かすために、バッチサイズを16に落とし、画像サイズも上げっぱなしだったので384に落とした。
      
    • また、annotationやpredictionsを保存しておくようにした。
      

    • train loss	valid loss	CV
      0.3174	0.3919	0.5271

  • ver6
    
    • Normalizeされていないバグを修正した。
      

    • train loss	valid loss	CV
      0.3520	0.3957	0.5218

  • ver7
    
    • augmentationを少し強めた。
      

    • train loss	valid loss	CV
      0.3633	0.3810	0.5232

  • ver8
    
    • augmentationをさらに強めた。
      

    • train loss	valid loss	CV
      0.3692	0.3839	0.5174

    • 003と同様に悪化してしまった。lossとCVの挙動が若干不安定なので、一度epochを増やしてみる。
      

20210706

• 003
  
  • ver16
    
    • ver13に戻して、epochを10に増やした。
      

    • train loss	valid loss	CV
      0.3001	0.3239	0.7227

    • epoch5でこれを出した後はゴリゴリに過学習してしまった。epochは6のままにしておく。
      
• 004
  
  • ver9
    
    • ver7に戻してepochを10に伸ばした。
      

    • train loss	valid loss	CV
      0.3671	0.3834	0.5320

    • こちらもepoch5でこれを出した後に過学習してしまったので戻す。スコアが伸びたのはlossをみると偶然だろうと考えられる。
      
• 005
  
  • ver5
    
    • 002-ver28のpredictionsを詳しくみた結果、一部の画像に対する出力の座標が0~512に収まっていないことがわかった。元のtitoさんのNotebookでは単純にclipしているので、モデルの組み方や出力のさせ方が悪いわけではなさそう。clipしたらmAPが若干上がった(0.000455->0.000502)。
    • また、出力が直線x=yで反転していたことがわかった。直してmAPを計算すると、0.000502から0.249239(noneも合わせた平均は0.485954)まで上がった。ようやくまともな数値まで上がった。もっと早く見ればよかった。コンペの度に公開しているのでいい加減反省を生かさないといけない。
      
    • noneに対するconfが高い時にopacityの予想を切ったらわずかに上がって0.486999になった。
      
    • また、画像1枚ずつに対して個別にmAPを計算してから平均を取ると、opacityとnoneの平均で0.61まで上がった。上がるのは当然なのだが、LBがどっちで出しているのか確信が持てないのでこればかりはサブをしないとわからなさそう。十中八九前者だろうけど。
      

20210708

• 002
  
  • ver29
    
    • 005-ver6にしたがってモデルの出力のさせ方を変えた。
      

    • train loss	valid loss	mAP
      0.7426	0.8887	0.254139

    • ようやくちゃんとしたmAPが出せた。
      
• 003
  
  • ver16, ver17, ver19
    
    • モデルを大きくした。
      

    • ver	model	train_loss	valid_loss	mAP
      13	B3	0.2779	0.3254	0.7239
      17	B4	0.2779	0.3258	0.7105
      18	B5	0.2970	0.3272	0.7127

    • lossとCVが全然噛み合ってないのがすごい気になる。ずっと過学習気味で実験結果が比較しづらいので少し学習率を落とすかweight decayを強めるかをしてみる。
      
• 004
  
  • ver10, ver11
    
    • モデルを大きくした。
      

    • ver	model	train_loss	valid_loss	mAP
      7	B3	0.3633	0.3810	0.5232
      10	B4	0.3506	0.3896	0.5253
      11	B5	0.3175	0.3793	0.5470

    • モデルを大きくするとmAPも大きくなっているので、まだスコアが伸びる余地が残っているかもしれない。ただ、lossの下がり方はそこまで大きくないので偶然だった可能性もある。
      

20210713

• ここ数日の間ずっと続けてはいたのだが、まとまった時間が取れずにKaggle日記の更新も止まってしまっていた。こういうことはなくしていきたい。
  
• 002
  
  • ver30
    
    • titoさんのNotebookをみたら、datasetのところでxy反転を行っていた。一応ちゃんとEfficientDetのリポジトリを見に行って入力がどうなっているのか確認したい。
      
    • datasetで反転させたのに、make_predictionsの中で反転を消すのを忘れていたので、二重に反転させてしまった。
      
• 003
  
  • ver18~
    
    • 過学習を防ぐためにWeight decayを変えた。このパラメータに関してはあんなmり触ることがなかったので、この際に大まかな挙動を掴みたい。
      

    • ver	weight decay	train_loss	valid_loss	mAP
      18	1e-6	0.2970	0.3272	0.7127
      19	1e-5	0.2960	0.3272	0.7127
      20	1e-4	0.2960	0.3272	0.7127
      21	1e-3	0.2919	0.3307	0.7164
      22	1e-2	0.2950	0.3254	0.7170
      23	1e-1	0.2251	0.3371	0.7178
      24	1e-0	0.3014	0.3215	0.7311
      25	1e+1	0.4146	0.4315	0.5942

    • 表を見ると、1e-4あたりまではほとんど変わらず、1e-3から少しずつ変わり始めて1で一気に効果が表れて10でunder fittingになった。この辺はデータの正規化の仕方やモデルのサイズなどにもよるところではあると思うが、weight decayをしっかり効かせたいなら1e-3あたりにはしておかないといけないっぽい。
      
• 004
  
  • ver12
    
    • RANZCRで使われていたpretrainedを使ってみた。
      

      • train loss	valid loss	mAP
        0.3624	0.3747	0.5434

      • 普通に悪化した。
        
• 006(infer_image)
  
  • ver29-ver24-1
    
    • imageクラスの推論を行うNotebook。今回はcode competitionなので推論のNotebookはgit管理しない。どうせ手元で回すことはないから。
      
    • 最初のver29は002のversionで、次のver24は003のversionに対応して、最後の1は、002と003のverが被ったときの連番。
      

    • CV	mAP
      0.1647	0.160

    • studyクラスの予測値を全てデフォルトの'negative 1 0 0 1 1'のままにしてしまったので、negativeクラスのスコアが入ってしまっている。全て空白にしないといけない。
      
  • ver29-ver24-2
    
    • studyクラスのPredictionStringは''にした。
      

    • CV	mAP
      0.1647	0.109

    • 元画像のサイズで補正するときに縦横反対にしていた。実質noneクラスだけのスコアになってしまっている。
      
  • ver29-ver24-3
    
    • 元画像のサイズでの補正の仕方を修正した。
      

    • CV	mAP
      0.1647	0.180

    • 若干上振れしているが大きなミスはないと考えられる。
      
• 007(infer_study)
  
  • 004-ver11
    
    • studyクラスの推論を行うNotebook。006と同じくgitで管理することはない。
      
    • studyクラスの画像は一部被りがあることを忘れていたために何度もエラーを出してしまった。
      

    • CV	LB
      0.5470	0.365

20210714

• 002
  
  • ver31
    
    • make_predictionsの中の反転を消した。
      

    • train loss	valid loss	mAP
      0.7564	0.8617	0.2559

    • 若干学習の進みがよくなった。
      
  • ver32
    
    • mAPの計算方法から考えると予測個数を増やす分にはスコアは上がっていくと思われるので、make_predictionsの中のthresholdを0.01から1e-7に落とした。
      

    • train loss	valid loss	mAP
      0.7566	0.8620	0.2512

    • 変わらないのはありえるにしても落ちるのは考えていなかった。mAPの理解が足りていないのかもしれない。
      
    • vinbigdataのchrisさんのディスカッションを見ても、やはり増やす分には問題がない。ということは、増やしてもほぼ効果がなく、かつスコアのランダム性で若干落ちたのだと考えられる。よく見たらseedの固定が甘かった...
      
  • ver33
    
    • 学習率を1e-4に落としたが悪化した。
      

20210716

• アイデアを全然書いてなかったので、githubに色々かいた。
  
• 002
  
  • ver34
    
    • seedを完全に固定して(torch.backends.cudnn.deterministic=True, torch.backends.cudnn.benchmark=False)ver31を回した。
      

    • train loss	valid loss	mAP
      0.7561	0.8637	0.2495

    • 若干スコアが落ちているが乱数の影響なので気にしない。
      
  • ver35
    
    • seedを完全に固定してver32を回した。
      

    • train loss	valid loss	mAP
      0.7561	0.8637	0.2495

    • confidenceが0.01未満のboxは予測に関わってこないらしい。やはりスコアは下がることはないのでこのままにしておく。
      
  • ver36
    
    • WBFを実装してみた。
      

    • train loss	valid loss	mAP
      0.7561	0.8637	0.0929

    • 予測個数がかなり減ってしまった影響だと考えられる。みてみたがスカスカだった。それでもしっかり当てているので別に実装が間違っているということはなさそう。
      
    • iou_thresholdはNMSとほぼ同じだからわかるが、skip_box_thresholdの意味がわからない。論文にもロクな説明がなかった。
      
    • 実装をみたらわかった。この値よりconfが低いboxは削除されるらしい。今回のmAPはboxは増えていいので、この値は0でいいはず。
      
    • 原論文には、単一のモデルの予測に使うと精度が悪化するとある。TTAをして複数個の予測を作ってからWBFをする必要がある。
      
  • ver37
    
    • TTAをする前に、skip_box_thresholdの値を0にしてみた。
      
• 006
  
  • 002_ver29-003_ver24-4, 002_ver29-003_ver24-5
    
    • それぞれopacityとnoneのみでsubした。

    • class	CV	LB
      opacity	0.0428	0.077
      none	0.1218	0.102

    • 意外にopacityのスコアが高くてnoneのスコアが低い。noneクラスはもっといけるとは思うが、overfitしてる可能性は高いので、外部データを入れるなりマルチタスク化するなりしないといけない。
      
  • 002_ver29-003_ver24-6
    
    • VinBigDataのGuanshuo Xuさんのディスカッションで、(noneでない確率) ** nをopacityにかける(Xuさんは0.2にしていた)という処理を行うという発言があったので実際に試してみた。
      

    • n	mAP
      0.1	0.259320
      0.2	0.261252
      0.3	0.261938
      0.4	0.261512

    • n=0.3が一番よかったのでそれを採用する。opacityの確率で比重を取ることでmAPをよくするという考え方。もともとしていた、noneの確率が0.8を超えるデータについてはopacityの予測を取り除くという処理を一緒にやってみたらスコアが落ちたのでそれは除外した。
      

    • CV	LB
      0.1655	0.182

    • 少しだが確実に上がっているので今後も使い続ける。
      

20210718

• 002
  
  • ver37
    
    • skip_box_thresholdを0にした。mAPが0.17~まで上がっていたのでやはり間違いなかった。しかし、予測を見ると大分減っている(大体半分ぐらい)ので、それなりの数のboxが混ぜられたらしい。iou_threshを変えながら様子を見てみた。
      

    • iou_thresh	mAP
      0.45	0.170246
      0.50	0.242080
      0.55	0.253263
      0.60	0.252275

    • 原論文通りで、0.55が一番よかった。TTAをした後にどうなるかはわからないが、一旦この値で比較してみる。
      
  • ver38
    
    • TTAを実装して、TTAの回数ごとにmAPを計算した。WBFを用いていて、iou_threshdoldは0.6。
      

    • TTA	mAP
      1	0.252275
      2	0.170850
      3	0.186038
      4	0.135670
      5	0.132810
      6	0.114838
      7	0.097058
      8	0.071985

    • TTAをやるごとにスコアが下がっているのは、TTAをしていないときに合わせてiou_threshを上げたからだと考えられる。iou_threshをあげると混ぜられずに残るbboxが増えるので、1つのモデルだけならそれでいいが、たくさんの予測がそのまま生き残ってしまうとFPが増えてしまう。
      
    • よく考えたらimagesを反転させたのにbboxの座標を反転させ直すのを忘れてたので座標が全部反転してしまっていた。そりゃやればやるほど落ちるわ...
      
    • それとは別で、skip_box_threshを0にしているからか、とても計算が重かった。NMSの時は0でも0.01でも変わりなかったから、0.01にして計算量を減らしても以下もしれない。
      
    • skip_box_threshは0.01にしてもスコアが変わらなかった。
      

20210720

• 002
  
  • ver39, ver40
    
    • iou_threshを変えながらWBFを適用してmAPを計算した。TTAの実装はこのNotebookを参考にした。
      

    • iou_thr\TTA	0	1	2	3	4	5	6	7
      0.40	0.154260	0.182200	0.194400	0.199104	0.205522	0.209720	0.218064	0.216368
      0.45	0.170246	0.208891	0.219482	0.223817	0.236323	0.237921	0.239357	0.239492
      0.50	0.242080	0.237871	0.239051	0.253142	0.251299	0.254216	0.256417	0.262196
      0.55	0.253263	0.256867	0.261684	0.266026	0.267409	0.273478	0.276994	0.276177
      0.60	0.252275	0.264300	0.269555	0.269084	0.273862	0.276459	0.276928	0.278356
      0.65	0.256670	0.265052	0.271165	0.269275	0.272705	0.275570	0.276806	0.279867
      0.70	0.259962	0.261966	0.265956	0.264781	0.268622	0.267630	0.270709	0.270636
      0.75	0.261023	0.251460	0.259795	0.258474	0.262128	0.262242	0.262361	0.262955

    • mAPが上がっている。ただ、計算時間が最大で50m~1h程度かかるので、普段はTTAは3回ぐらいで抑えた方がいいかな。
      

20210721

• 002
  
  • ver41
    
    • ver39, 40と同じ内容をNMSでやった。
      

    • iou_thr\TTA	0	1	2	3	4	5	6	7
      0.40	0.242868	0.249600	0.251743	0.252385	0.251778	0.251100	0.248799	0.248799
      0.45	0.249535	0.255431	0.258217	0.259565	0.257934	0.256658	0.255898	0.256638
      0.50	0.261517	0.262028	0.263797	0.263485	0.260934	0.260607	0.259960	0.260537
      0.55	0.261432	0.262817	0.264566	0.264028	0.261487	0.261494	0.260908	0.261351
      0.60	0.261428	0.263027	0.263555	0.262987	0.261038	0.260353	0.259565	0.259751
      0.65	0.261493	0.262221	0.262084	0.261133	0.258947	0.257825	0.256852	0.257885
      0.70	0.261507	0.260746	0.258392	0.256639	0.254099	0.252582	0.251540	0.251624
      0.75	0.261447	0.255826	0.252386	0.250183	0.246874	0.244414	0.242181	0.241300

    • 計算時間は圧倒的にこっちが早いが、mAPは低い。また、TTAをやればやるほど上がっていくわけでもないので、TTAの結果をうまく削減しながらまとめられるのはWBFだった。
      
  • ver42
    
    • submitするときにCVを計算できるように、NMS、iou_thr=0.55, TTA2回の条件で推論のみ行った。モデルはver37のものを使っている。また、pklファイルは重いのでcsvに変えた。
      
  • ver43
    
    • ver42と同じ目的で、WBF、iou_thr=0.65、TTA2回で推論のみ行った。モデルも同じ。
      
  • ver44
    
    • ver43からTTAを7回に変えた。
      
• 003
  
  • ver24から、元画像のサイズを256から512に変えた。
    
• 004
  
  • ver13
    
    • モデルをb6にした。
      

    • train_loss	valid_loss	mAP
      0.3473	0.3844	0.5395

    • よくならなかったので、モデルや画像サイズでの改善はもう見込めないとする。かえるさんのディスカッションを参考にしてAUX lossを実装してみる。
      
• 006
  
  • 002_ver42-003_ver24-1
    
    • 間違えてTTAをやらないままサブしてしまった。参考記録として残しておく。
      
    • CV: 0.25ちょい LB:
  • 002_ver42-003_ver24-2
    
    • TTAをちゃんと2回行った。
      

    • opacity mAP	none mAP	CV	LB
      0.267580	0.731090	0.1664	0.186

  • 002_ver43-003_ver24
    

    • opacity mAP	none mAP	CV	LB
      0.276015	0.731090	0.1679	0.187

  • 002_ver44-003_ver24
    

    • opacity mAP	none mAP	CV	LB
      0.283403	0.731090	0.1691	0.189

    • サブに4時間以上かかったので、ちょっと重たすぎるか。
      
• 009(2class_step1)
  
  • RANZCRの3stepのトレーニングを真似して、まずはopacityクラスのbboxを使ってmaskを作って、maskをかけた画像を使って学習をさせてそれを親モデルとし、次に子モデルを普通に学習させつつ親モデルの途中の特徴量マップと子モデルの途中の特徴量マップをAUX Lossを使って近づけ、最後に普通に学習させる3step学習を行った。このNotebookはそれのstep1。
    
  • ver1
    
    • 003_ver11からコピーして、かめさんのudemyの講座を参考にしてmaskをつけた。
      
    • lossがあっという間に収束するので、epochを4に削った。
      
• 010(2class_step2)
  
  • ver1
    
    • 009で作った親モデルの出力の途中の特徴量マップとのAUX Lossをかけつつ子モデルを作った。
      
    • 親モデルの方の入力にannotationをつけるのを忘れていて失敗した。
      
  • ver2
    
    • 親モデルの入力にannotationをつけた。
      

    • train loss	valid loss	mAP
      0.7389	0.3243	0.7301

• 011(2class_step3)
  
  • ver1
    
    • 010_ver1のモデルを用いて、AUX Lossを外してモデルを作った。
      

    • train loss	valid loss	mAP
      0.2106	0.3197	0.7421

    • かなりmAPが改善された。これは期待できそう。
      

20210722

• 006
  
  • 002_ver43-011_ver1
    
    • 002_ver44は計算が重たすぎるので、002_ver43をとった。
      

    • opacity mAP	none mAP	CV	LB
      0.276887	0.742109	0.1698	-

    • EfficientNetに使うtimmとEfficientDetに使うtimmのversionがズレているため、どちらかに合わせるとどちらかが動かなくなってしまう。色々試してみたが、途中でtimmのversionを切り替えることができなかったので、EfficientNetの方のversionをなんとか合わせるしかない。
      
  • 002_ver43-003_ver24-2
    
    • 2classの方のモデルは、本来画像サイズは384のはずなのに推論時にEfficientDetに合わせて512になってしまっていたので直した。
      

    • opacity mAP	none mAP	CV	LB
      0.276015	0.731090	0.1679	0.194

    • もう少し上がってもいいような気はしたが、まあこんなもんか。
      
  • 002_ver43-003_ver24-3
    
    • 2classの方にもTTAを実装した。
      

20210723

• 007
  
  • 004_ver11-2
    
    • TTAを実装した。
      

    • CV	LB
      0.5470	0.378

    • かなり伸びたが、これでも公開Notebookより低いのでなんとかしなくてはいけない。
      

20210727

• ここ数日間はここに記録しないまま進めてしまっていたので、一気に書く。
  
• 002
  
  • ver45
    
    • 011_ver1の重みをEfficientDetのbackboneにロードしてから学習させた。マルチタスク学習をいきなりさせるのは手間なので、一種の近似(？)と考えてもいいこの形で試してみる。
      

    • train_loss	valid_loss	mAP
      0.7995	0.8795	0.2712

    • 学習が進むのがかなり早くなったが、その分後半で過学習しただけだった。最適解に近づける効果はないみたい。
      
• 006
  
  • 002-ver43-012_ver1
    

    • opacity mAP	none mAP	CV	LB
      0.276887	0.742109	0.1698	0.205

    • EfficientDetに合わせたversionのtimmでは、CNNの特徴量が常に(batch_size, -1)に流れてくるせいで、新しいtimmに合わせたモデルではうまくいかなった。途中でいい感じに整形したらうまくいったので安心。落ち着いて考えればすぐにできたことだけど、やたら時間がかかった...
      
    • AUX Lossが相当効いてる。恐らくnoneクラスに関してはかなりいい線まで来ているのでEfficientDetをなんとかしたい。
      
    • CVの上がり方とLBの上がり方があまり一致していないのが気になるが、相関はしっかり持っているので頭の片隅に入れる程度に止める。
      
• 008
  
  • 002_ver43-011_ver1-014_ver2
    

    • opacity	none	negative	typical	indeterminate	atypical	CV	LB
      0.2769	0.7421	0.7741	0.8423	0.3046	0.3044	0.5407	0.598

  • imageクラスが0.205なのでstudyクラスは0.393。ディスカッションをみている限りはまだまだ上がりそう。AUX Lossの入れ方、mモデルの選択あたりは効いていそう。
    
• 009
  
  • ver2
    
    • ver1を全foldで回した。
      
• 010
  
  • ver3
    
    • ver2を全foldで回した。
      

    • fold	mAP
      0	0.7301
      1	0.7261
      2	0.7540
      3	0.7618
      4	0.7637

    • 平均的にはmAPは思ったより高かった。最近疎かにしていたが、定期的に全foldで回してちゃんと評価するのは大事。
      
• 011
  
  • ver2
    
    • ver1を全fold回した。
      
• 012(4class_step1)
  
  • ver1
    
    • AUX Lossを入れた3step学習のうちのstep1。
      

    • train_loss	valid_loss	mAP
      0.1755	0.1704	0.7642

    • mAPが1に行くかと思ってbest_lossを取る方針にしたが、そうでもなかったのでbest_scoreを取る方針に変える。
      
  • ver2
    
    • best_scoreをとった。
      

    • train_loss	valid_loss	mAP
      0.1532	0.1798	0.7794

• 013(4class_step2)
  
  • ver1
    
    • AUX Lossを入れた3step学習のうちのstep2。
      

    • train_loss	valid_loss	mAP
      0.7976	0.3849	0.5568

  • ver2
    
    • epoch10に増やしたが、後半過学習しただけだった。そもそもschedulerがcosine Annealingなので、別に6epochにしたら最後まで落ち続けたからといって10にしたらもっと落ちるわけではないのが難しい。
      
• 014(4class_step3)
  
  • ver1
    
    • AUX Lossを入れた3step学習のうちのstep3。
      

    • train_loss	valid_loss	mAP
      0.3414	0.3859	0.5521

    • 学習率が高すぎたように見える
      
  • ver2
    
    • 学習率を1e-4から1e-5に下げた。
      

    • train_loss	valid_loss	mAP
      0.3165	0.3874	0.5564

    • 改善がみられたのでこっちで行く。
      

20210729

• 002
  
  • ver46
    
    • ver43を全fold回した。
      
• 007
  
  • ver14_A100_1
    
    • 中筋さんに回してもらったもの。014_ver2から全foldになってモデルがEfficientNetV2Lに、画像サイズが512に、バッチサイズが128に上がっている。
      

    • CV	LB
      0.5455	0.393

    • 思ったより高くないので学習率をセットで上げてないことが問題かもしれない。
      
  • ver14_A100_2
    
    • 学習率を上げてもらった。
      

    • CV	LB
      0.5612	0.393

    • LBが異様に低いと思ったら画像サイズが384のままになっていた。申し訳ない...
      
• 009
  
  • ver3
    
    • DualAttentionHeadを入れた。
      
• 010
  
  • ver4
    
    • DualAttentionHeadを入れた。009_ver3のstep2
      
• 011
  
  • ver3
    
    • 010_ver4のstep3
      

    • train_loss	valid_loss	mAP
      0.2823	0.3169	0.7335

    • lossは落ちたがmAPが落ちきってない。DualAttentionHeadをつけると学習が重くなるのでもう少し粘ってみる。
      
  • ver4
    
    • epochを10にしてみたが改善しなかった。
      
• 012
  
  • ver3
    
    • ver2を全fold回した。
      

    • fold	mAP
      0	0.7794
      1	0.7842
      2	0.7630
      3	0.7925
      4	0.7749
      all	0.7682

• 013
  
  • ver3
    
    • ver1を全foldで回した。
      
    • CV: 0.5533
      
• 014
  
  • ver3
    
    • CV: 0.5525
      

20210730

• 007
  
  • 014_A100_2-2
    
    • 画像サイズを512に直した。
      

    • CV	LB
      0.5612	0.399

    • 大きく上がった。やはりモデルサイズは効いてるみたい。
      
• 008
  
  • 002_ver43-011_ver1-013_ver1
    
    • studyクラスのCVはstep2の方が高かったので、013のモデルを使ってみたがLBは0.595に落ちた。
      
  • 002_ver46-011_ver2-014_ver2
    
    • 002, 011が全foldになっている。計算量的に厳しいのでEfficientDetに関してはNMSに変更している。
      

    • CV image	CV study	LB image	LB study	LB
      0.1681	0.3709	0.211	0.393	0.604

    • foldを増やすだけで結構伸びた。ただ、detectionも2classも一気に変えてしまったので、どっちかを戻してそれぞれの伸びを確認しなければいけない。
      
  • 002_ver43-011_ver2-014_ver2
    
    • detectionを戻した。
      

    • CV image	CV study	LB image	LB study	LB
      0.1682	0.3709	0.210	0.393	0.603

    • NMSにしたからか、detectionに関してはモデルを増やした恩恵がほぼなかった。WBFは性能は出るが予測が多くなると一気に厳しくなるので、YoloとEffDetを一つずつみたいなアンサンブルが現実的かもしれない。
      
  • 002_ver43-011_ver2-014_ver3-1
    
    • studyクラスを全foldのものにしたが、trn_fold_4classを[0]のままにしていたので何も変化がなかった。
      
  • 002_ver43-011_ver2-014_ver3-2
    
    • バグをとった。
      
  • 002_ver43-011_ver3-014_ver2
    
    • 2classがDualAttentionHeadになっていて、studyはfold0のみに戻っている。
      

    • CV image	CV study	LB image	LB study	LB
      0.1684	0.3684	0.205	0.393	0.598

    • 014のverを戻さずにfold0だけをとったせいでCVがおかしくなってる。
    • 変化が全くなかった。
      
  • 002_ver43-011_ver2-014_ver3-2
    

    • CV image	CV study	LB image	LB study	LB
      0.1682	0.3684	0.210	0.393	0.605

    • 全foldにした分で0.002だけ上がった。
      

20210731

• 006
  
  • 002_ver43-011_A100_1
    

    • mAP opacity	mAP none	CV	LB
      0.2737	0.7376	0.1686	0.209

    • 0.210から落ちてしまった。モデルサイズによる恩恵は小さいか。
      
  • 002_A100_1-011_ver2
    

    • mAP opacity	mAP none	CV	LB
      0.2416	0.7354	0.1628	0.211

    • D7にしてCVは落ちたがLBはそうでもなかった。各foldの計5モデルでTTAをやったからなのかもしれないが、モデルの調整をすればまだ上がりそう。
      

20210802

• meetingをして、自分はmixupや外部データに対するpseudoラベリングを担当することになった。後半になってからはここにアイデアを書かなくなっているので反省する
  
• SAM optimizerとmixupで精度を上げて、そのモデルを用いてpseudoラベリングをする方針でいく。
  
• 外部データに関しては、以前に実験した際にはわずかにPublic scoreは落ちてしまったが、Private scoreはよくなっている可能性も十分に考えられる。
  
• 012
  
  • ver4
    
    • ver3にSAM optimzierを加えた。
      
    • mAP: 0.7787
• 013
  
  • ver4
    
    • 012_ver4のstep2。同じくSAM optimizerを加えた。また、epochが10になっていたのでそのまま10にした。
      
    • mAP: 0.5697
      
• 014
  
  • ver3
    
    • 013_ver5のstep3。SAM optimizerを加えた。また、学習率を下げた。
      
    • mAP: 0.5705
      

20210803

• 007
  
  • 014_ver03
    

    • CV	LB
      0.5705	0.401

  • 014_ver9
    

    • CV	LB
      0.5626	0.401

    • CVは多少落ちたがLBは変わらなかった。mixupは採用しない。
      
• 008
  
  • 002_A100_1-011_ver2-014_A100_2
    

    • CV image	CV study	LB image	LB study	LB
      0.1628	0.3742	0.211	0.399	0.609

  • 002_A100_2-011_ver2-014_A100_2
    
    • EffDetがD5からD7になっている。
      

    • CV image	CV study	LB image	LB study	LB
      0.1648	0.3742	0.128	0.399	0.527

    • detectionのスコアがほぼ死んでしまっている。どこかにバグを埋め込んでるっぽい。
      
    • 後からみたら、画像サイズを1024にあげたのに、(0, 512)でclipしてしまっていたことが原因だった。
      
• 009
  
  • ver4
    
    • ver2から、画像サイズを512に上げて、SAMを入れた。
      
• 010
  
  • ver5
    
    • 009_ver4のstep2。
      
    • CV: 0.7459
      
• 011
  
  • ver5
    
    • 010_ver5のstep3
      
    • CV: 0.7479
      
• 014
  • ver5~ver8
    
    • ver4にmixupを入れた。(ver3が二つ存在しているため、後の方を指している。)

    • ver	mixup proba	CV
      5	0.2	0.5476
      6	0.4	0.5719
      7	0.5	0.5470
      8	0.6	0.5429

    • どれもあまり変わらないが、ver5を採用する。
      
  • ver9
    
    • ver5を全fold回した。
      
    • CV: 0.5626。結局若干落ちてしまった。
      

20210804

• 007
  
  • 014_A100_3
    
    • V2LにSAMを入れてもらった。
      

    • CV	LB
      0.5613	0.410

    • CVは下がったがスコアは大きく伸びた。CVとLBの相関が弱い原因を調べつつアンサンブルの用意に入ってよさそう。
      
• 008
  
  • 002_A100_2-011_ver2-014_A100_3
    
    • clipのバグを修正して、studyクラスのモデルを更新した。
      

    • CV image	CV study	LB image	LB study	LB
      0.1648	0.3742	0.215	0.410	0.625

    • imageクラスがまだ弱いのと、studyクラスのCVとLBの相関が弱いのが依然として気になる。詳細まで踏み込んで安定させるのは時間的に厳しい可能性があるが、最低限あと1モデル入れてロバストにしたい。
      
  • 002_A100_2-011_ver5-014_A100_3
    
    • 2classのモデルをSAM optimizerを入れたものに差し替えた。
      

    • CV image	CV study	LB image	LB study	LB
      0.1669	0.3742	0.212	0.410	0.622

    • 2classのモデルもCVとLBの相関が弱い。前半はいい感じだったので盲信してしまったのがダメだったか。shopeeの時みたいに最初にしっかり考えるべきだった。
      
  • 002_A100_2-101_ver1-011_ver5-014_A100_3
    
    • Yolov5をアンサンブルした。Vinbigdataの1位解法ではYoloと他のモデルのアンサンブルがかなり効いていたようなので期待できる。予想以上にYoloを使うのは簡単っぽいので、こっちにも早くから着手しておくべきだったかな。
      
    • CVにどう反映させればいいか見当がつかないので、CVに関しては引き続きEfficientDetのみにする。
      

    • CV image	CV study	LB image	LB study	LB
      0.1669	0.3742	0.213	0.410	0.623

    • 思ったより上がらなかった。confidenceの大きさのスケールがEfficientDetとYoloでだいぶ異なるので、大雑把にでも無理矢理合わせてWBFで平等に扱わせるべきかもしれない。
      
• 018
  
  • ver1
    
    • 009_ver4からモデルをResNet200Dにした。
      
• 019
  
  • ver1
    
    • 018_ver1のstep2
      
    • CV: 0.7388
      
    • 今更だけど、CVではなくmAPで書くべきだった。
      
• 020
  
  • ver1
    
    • 019_ver1のstep3
      
    • mAP: 0.7534
      

20210805

• アイデアの共有などはチームのslackでしているので、ここに書くものは結局記録+α程度になってしまっている。だったらgithubである必要は無いかなと思うので、次のコンペではNotionやwandbを取り入れていきたい。
  
• これまではnoneの確率を元にopacityのconfidenceを修正していたが、4classのNegativeであってもbboxは存在しないことから、4classのNegativeの確率でさらに補正がかけられそう。CVも実際に上がった。
  
• 008
  
  • 002_A100_2-101_ver1_2-011_ver2-014_A100_4
    
    • yoloの予測のconfidenceをEfficientDetのconfidenceに大体合わせた。
      

    • CV image	CV study	LB image	LB study	LB
      0.1648	0.3766	0.211	0.410(多分)	0.621

    • studyクラスのモデルも変わっているので0.410が本当なのかどうかがわからないのがちょっと困るかも。EfficientDetとYoloは恐らく単体ではスコアが均衡しているはず(ソース)なので、直感的にはこっちが伸びそうではある。一度studyクラス単体で調べるべきかもしれない。
      
  • 002_A100_2-101_ver1_2-011_ver2-014_A100_3_017_A100
    
    • 関わっているモデルが多すぎて管理しきれなくなってきた。まああと少しなので今回は押し切る。
      
    • 4classのモデルとしてResNet200Dを加えた(017)。単純平均でアンサンブルをとった感じではCVがかなり上がっているので期待できる。
      

    • CV image	CV study	LB image	LB study	LB
      0.1648	0.3859	0.211	0.412(多分)	0.623

    • アンサンブルすれば0.002上がることはわかったので、一旦EffcientNet単体のver4のスコアを取り直す。
      
• 009
  
  • ver5
    
    • 008で後処理を考えてた時、リークを発見したので修正して回し直した。updated_train_labelsは一つの画像に複数のbboxがある時に複数のレコードに分けている。detectionであればこれでいいのだが、２値分類ではbboxの有無でラベリングをしているので、一つの画像が複製された形になってしまっている。そこで、idについて重複を取り除くことでリークを防いだ。
      
• 010
  
  • ver6
    
    • 009_ver5のstep2
      
    • CV: 0.7911
      
    • リークを防いだことで明らかにCVが伸びている。opacityの画像が複数紛れ込んでいると不均衡さが増して学習しにくくなっていた可能性が高い。
      
• 011
  
  • ver6
    
    • 010_ver6のstep3
      
    • CV: 0.7771
      

20210807

• 昨日は2回目のワクチン接種の副作用でここに記録している余裕がなかった。
  
• 018
  
  • ver2
    
    • 018_ver1からリークを修正した。
      
• 019
  
  • ver2
    
    • 018_ver2のstep2
      
    • mAP: 0.7772
      
• 020
  
  • ver2
    
    • 019_ver2のstep3
      
    • mAP: 0.7833
      

20210809

• サブミッションについては、たくさんしすぎてとてもではないがここに書き写しきれなくなった。
  
• 002
  
  • ver48
    
    • 同じ画像の中のbboxは複数のレコードに分けられているデータセットをずっと使ってきたが、それをそのままStratifiedKFoldで分けてしまうと同じ画像のデータが複数のfoldに分かれてしまってリークすることに気づいたので修正した。
      
    • mAP: 0.2874
      
    • リークを防ぐだけでここまで上がった。もっと早くデータの分け方についてしっかり確認するべきだった。
      
  • ver49
    
    • ver48の残りのfoldを回した。
      
• 014
  
  • ver10
    
    • 004_ver14で入れた外部データを入れた。本当はstep1とstep2も外部データ込みで学習させたかったが、対応するbboxのアノテーションが存在しないので、アノテーションが不要なstep3からリークが無いように加えた。
      
    • 動作確認だけして引き継いだ。