PANDA Challenge
6月30日参戦：4月22日開始、最終日は、7月22日
目標順位：1位 : $12,000
目標スコア：0.985
予定：
課題の把握
結果：
Data Descriptionは、精読すべきである。
TReNDSのコンペでは、データの説明欄に免責事項が書かれていて、その内容は、解析上の留意点を含んでいた。これに気付いて適切に対応できていればスコアは改善されたであろう。
さらに詳細な情報を得るには、コンペの開始からある程度の時間が経てば、親切な方々が、よくできたEDAを公開してくださることが多いので、それを利用させていただけばよい。
いろいろと、複雑な仕掛けが組み込まれているようであり、しっかりと計画を立てて進めていくことが重要だと感じた。
7月1日：あと22日
１．過去のコンペ、APTOS 2019に学ぶ。
正解は1つではないように思う。preprocessの重要性を説く人がいれば、preprosessを行わずにトップになった人もいる。preprocessはしていなくても、augmentationで同等もしくはそれ以上の効果が得られているかもしれない。
画像解析は得体のしれない物かもしれない。
膨大なパラメーターが特徴を捉えている。捉えてほしい特徴と、とらえてほしくない特徴をどう区別するか、そんな方法があれば良いのだが。dropoutやpooling、ノイズ添加、コントラスト、明暗、ピンボケなどによって増えた画像が、望んでいる方向に行くのかいかないのか、1つ1つ調べていく、実験していくことだな。
２．過去のコンペ、Recursion ...、に学ぶ
このコンペは参加してみたが、データ量が膨大で、前処理も難しそうだったので、早々に退散した。これは、もっともだめなパターンで、こういうことを繰り返してきたので全く進歩していない自分がいる。（猛省中）
データ量が膨大で、分類数は1108だったと思う。
1位の方の記事をみると、まず、progressive pseudo-labelingという手法が気になった。類似コンペのデータをtrainingに使うのだが、つぎ足しながらtrainingするようである。CNNのモデルは、大きいほど良いらしく、DenseNet201まで使い、動かすのがたいへんらしい。Cutmix, ArcFaceLoss, Linear Sum Assignmentなど聞いたことのない単語がでてきてついていけない。
常に新しい手法を探し求めているようで、学習済みモデルの種類が豊富であり、新しい手法が多く取り込まれていることもあって、上位入賞者には、PyTorchを勧める方が多いようである。
３．当該コンペのdiscussionに学ぶ
画像をタイル状にしたものに関すること、CNNモデルに関すること、サンプルの提供元による違いに関することなどが述べられている。
画像をタイル状にするプログラムコードと、画像をタイル化したものをデータベースとして提供するという、非常にありがたい話があった。
タイルに加工したときの画像の解像度と到達できる予測性能との関係に関する議論があった。
４．当該コンペのnote bookに学ぶ
まずは、EDAを含むnotebookを探す。画像の提供元による分布の違いがよくわかる。画像をそのまま解析するよりも、空白部分を除いて画像を再構成することの必要性を感じる。試料の形状からは、半分あるいはそれ以上の空白を含んでも良いと思う。空白を少なくした試みも紹介されていて見栄えは非常に良いが、情報の欠けや重なりによって元画像が持つ情報と異なってしまうので、それが解析結果に及ぼす影響が気になる。情報元の違いやラベルの信頼性の違い、症状の分布とその情報元による違いなどは、実際に解析するときに考量する必要がありそうで、その時考えよう。
多くの解析モデルが紹介されている。現時点で100位以内に届きそうなモデルが公開されているが、まだ3週間もあるので、現在のスコアは、目安にもならないかもしれない。1週間くらいのうちに、今のトップのスコアに追いつけないと、メダルはとれないような気がする。
7月2日：あと21日
１．データ処理
画像データの前処理：サイズは、縦横それぞれ数千から数万ピクセル。
タイリング：16x128x128, 36x256x256, 25x512x512などが紹介されている。
色彩等の調整：augmentation：stain normalization：？
Maskデータの利用方法？
２．trainとinference
notebookをtrainとinferenceに分けるには、どうすればよいのか？inferenceだけで動作しているのは、訓練済みのパラメータをKaggleのデータセットとして保存しているのだろうか。
test.csvには、image_idのデータが3つしか入ってないが、どうなっているのだろう？
３．Karolinskaの論文に学ぶ
なんかスケールが違う。レベルが非常に高い！
1枚のスライドから1000パッチ：1パッチは598x598 ピクセル：30のInception V3からなるアンサンブルを2組用意：1組は悪性と良性の分類：1組はGreasonスコアの予測：Tesla P100 GPUが136台：組織の画像に組織のマスクとペンマークのマスクを重ねてラベルマスクを作成：
training：バッチレベルでラベルを付けて学習させる：スライドレベルでラベルを付けて学習させる：パッチ集合体にマスク情報を重ねて学習させる？：クラスアンバランスへの対応：
7月3日：あと20日
１．Radboudの論文に学ぶ
こちらは、さらに高度というか、自動化を実用化するためのステップを確実に歩んでいる気がする。全てにおいて、非常に緻密にやっておられるし、1つ1つのステップが合理的でかつ正確に記述されているように思う。
自動化のためには、標準化が必須であり、標準化のためには信頼できる試料とラベル（正確な評価値）が必須である。ここに最も力を注いでいるのがRadboundであり、この論文で表現していることだと思う。
小さなメモ：deep learningとreference standardの不一致は、2と3の境界および4と5の境界を決めるところで生じているようである。confusion matricsでみれば明白。
augmentation: flipping, rotating, scaling, color alterations (hue, saturation, brightness, and constrast), alterations in the H&E color space, additive noise, and Gaussian blurring.
２．公開コードを動かしてみた。タイルを作成して、pretrainモデルで学習するものだが、1エポックに1時間以上かかっている。とりあえず、明日の朝まで動かしてみよう。途中で停止しないことを祈る。
7月4日：あと19日
朝起きると、プログラムが強制終了されていた。7エポック目の計算中に停止。連続使用可能時間は9時間となっているようだ。
今回走らせたコードの1回の訓練には、最低でも10エポック程度は必要で、15時間程度かかる。9時間で強制終了だと、1度の訓練回数を減らして、訓練を継続できるようにする必要がある。
たとえば、そういうプログラム変更は、使い慣れていないと難しく、書き換えるかどうか悩むところだ。
いずれにしても、Kaggle kernelだけでは不足なのと、自分の計算環境も使えることは必須なので、
ステップ１：自分の計算環境で同等の結果を得られるようにする。これができれば、まずは、fastai, pytorch, tensorflow/keras, のどれでも良い。
１．"git"がインストールできていなかった。conda install -c anaconda git
２．KaggleのデータベースにEfficientNet-PyTorchがアップロードされているのを知らなかった。Kaggle kernelからimagenetで学習したEfficientNet-PyTorchをつかうことができる。他に何があるか調べておこう。
３．Value Error! cannot decompress jpegが表示された。だいぶ時間をかけたが解決せず、scikit-imageのバージョンアップで解決するとの書き込みに対しては、condaがまだ対応していない。画像表示だけなので横に置いておく。
４．Kaggleのデータセットの使い方、パブリックデータセットスペースの使い方を学んでおこう。
・データセットとして、imagenetで学習済みのDNNのweightがアップロードされており、さらに、コンペのデータセットで学習したDNNのweightをアップロードしておいてKaggle kernelから呼び出してこれらのweightを読み込むことができるのだろう。この点に関して初心者につき確信無し！
・PANDA Challenge関係では、tileに変換した画像が何種類かアップロードされている。
・汎用的に使える、種々の学習済みCNNがPyTorch, Keras, fastai用にアップロードされている。そこに便利に使えるデータがある、というだけでなく、関連論文が紹介されていることもあり、丁寧な解説がついていたりすることもある。
５．データセットについて調べていてあらためて感じたのは、notebookの公開についてである。コンペなのに比較的性能の高いコードがコンペ中に公開されていて、借り物競争することに躊躇していたが、Kaggleのコンペが求めているのは、借り物でトップ50％レベルに入ることではないのだろう。たとえば初期のトップ20～50％くらいのコードを利用させていただいてsubmitすることでLBに顔を出し、そこからスコアを上げ、順位を上げていくことに注力する中で、先輩のコードに学び、試行錯誤し、成長していくことが期待されているのだろうということである。コンペにはいくつも参加してきたが、公開コードでLBに顔を出したのは、このコンペで3度目である。1度目は、後ろめたさを感じながら、借り物でLBに顔を出したものの、コードの理解が追い付かず、スコアアップの手がかりは得たと思ったが、コードに反映する技術が足りず、改善には至らなかった。最後の方はあきらめていたような気がする。2度目はTReNDSである。このときは、借り物からスタートして上位に進出したいと思って、積極的に公開コードを利用させていただいたが、結局は、そのスコアを超えられなかった。しかし、借り物をすると、そのスコアを超えたいという思いが強くなり、必死でコードを理解しようとするし、よりスコアが高くなる方法を探そうとするので、成長にプラスになると感じる。ということで、このコンペは、躊躇なく、公開コンペを利用させていただいてLBに顔を出した。さてさて、この先、どうなることやら。
６．重たい計算だから、TPUを使ってみよう！と思ったのだが、そんな簡単なものか。そもそも、TPUとGPUの違いはどこにあるのか。今回のコンペにTPUはうまくはまるのだろうか。batch_sizeを増やすにはメモリー不足かもね。
７．TPUの使い方、明日、勉強しよう。
7月5日：あと18日
１．TPUを用いたnotebook：42x256x256x3：.tfrecフォーマットのタイルデータを読み込み：GPUを用いたnotebook：36x256x256x3：学習中にタイルデータを作成
GPUを用いたnotebookは、タイルデータを作成しながら学習させているので、TPUとGPUの比較にはならない。
この2つのnotebookの最も大きな違いは、TPUを用いたnotebookは、トータルの処理時間が短いので、Kaggle kernel内で追試しやすいことかな。
２．TPUを用いたnotebookに学ぶ：トラブルシューティングを日本語に訳して眺める：動的形状がサポートされない：トレーニング速度とメモリー使用量を大幅に改善するため、グラフ内のすべてのテンソルの形状は静的、すなわちグラフをコンパイルする時点でその値が既知である必要がある：これを原因とするエラーが起きないよう、端数を削除するなどの命令が用意されている：計算効率を最大にし、パディングを最小限に抑えるようにメモリ内にテンソルをレイアウトしようとする：メモリのオーバーヘッドを最小限に抑え、計算効率を最大化するために、バッチサイズの合計は6の倍数、特徴ディメンションは128の倍数、などが良いらしい。：速度を上げるには、なにがしかの自由度を犠牲にする必要があるということのようだ。
３．Kaggle kernelのTPU環境でtrainingできそうなので、TPU/TensorFlow/KerasとTPUに合致したデータベースの組み合わせを使わせていただいて、モデルの予測性能を向上させる技術を検討することに注力しようと思う。
４．明日は。TPUモデルのtraining方法を検討してみよう。
7月6日：あと17日
１．TPUモデルの検討は、エラー発生により中断。
TPUのメリットは、計算時間が早いことで、それは、Kaggle kernelを使用して大きなモデルのトレーニングをする場合には適合する場合もあるが、トラブルシューティングを読み込んでいくと、高い速度で計算するには制約条件が多く、その条件から外れると、期待した速度が得られないだけでなく、精度が低下することもあると書かれている。DNNは、もともと、計算時間が長いだけでなく、出力も安定しない。それを克服するための種々の工夫がなされているが、それがTPUと整合する保証はない。ゆえに、TPUは、それ自体を調査対象とすることには興味があるが、コンペでは、その計算速度の高さが、モデルの予測性能の向上につながらなければ意味がない。
いま発生しているエラーは、上記の事情とは無関係だが、諸条件を勘案し、TPUモデルの検討は、中止する。
２．次の実験計画：
Kaggleデータセットにあるタイル画像と、imagenetで学習済みのefficientnetを用いて、transfer learningのモデルを作成し、自前の環境で、計算時間、計算精度を調べる。
TensorFlow/Kerasを使う。
３．公開notebookに学ばないとだめだ。
・目標とするnotebookを１つに定めて、最後まであきらめずにスコアアップに努める中で、コードを学ぶ。
・新しい活性化関数といえば、'elu'かと思っていたら、'Mish'が良いらしい。
・augmentationを個々のタイルと結合したタイルの両方でやるのか？
・transfer learningとfine tuning、考え方、やり方は難しくないが、データにうまく適合させるには、やはり、何かが・・・。
ひどいオーバーフィッティングだ！
・PyTorchの転移学習は、モデル（たとえば、最後の全結合層など）が見当たらないのだが、どうなっているのだろう。（PyTorch素人発言です）
今度は、regularizationのやりすぎか。
7月7日：あと16日
１．上記のregularrizationやりすぎのような結果になった理由がわかったような気がする。A. Geronさんのテキスト341ページに次の記述がある。Finally, like a gift that keeps on giving, Batch Normalization acts like a regularizer, reducing the need for other regularization techniques (such as dropout, described later in this chapter).
つまり、Batch NormalizationとDropout(0.5)のセットを最終段で、2回使っていたのだ。さらに、augmentationの変化幅を大きくしていたのである。
２．これを確認しよう。
実験１：2か所のDropout(0.5)を取り除く。
実験２：2か所のBatch Normalization( )を取り除く。2か所のDropout(0.5)は復活。
これで、Dropout(0.5)の寄与とBatch Normarizationの寄与がわかるだろう。
＊GPU使用可能時間が少なく、エポック回数を5回に減らしたので、DOとBNの両方を同時に使ったときとの比較は、少しやりにくい。
・BNよりもDO(0.5)の方が、汎化能力は高いようだ。
・BNの汎化能力は、高くはなさそうだ。
＊前途多難：小さな改善検討では、とても上位には行けない。しかしながら、この小さな改善を正しくやるのは、とても難しいのだ。
＊根本的な改善方法の探索が必要だ。どうやって探す？
7月8日：あと15日：
Kaggle kernelのGPU残り時間25分（スイッチ切り忘れにより15時間のロス、11日の午前9時まであと3日間は使えない）
１．実験３：昨日の続きで、Dropout(0.5)とBatchNormalizationの両方とも外してみた。
・今回の実験の結果をながめての結論は、明確ではないが、BNとDOの両方を使って、かつ、DOの割合を追加調整する、ということになるかな。それから、できれば10エポックぐらいまで計算したかったが、GPUをoffにするのを忘れて、できなくなった。
２．転移学習再考：
かっこつけて、再考と書いてみた。その意味は、テキストで学習しているだけでは身に付かない、実地で経験しながら検討しよう、ということです。しかし、GPUが使えないので、土曜日までは、実験できない。
A. Geronさんのテキストの10章に、ヘアスタイルを識別する場合、顔認識のためにトレーニングしたモデルがあれば、ランダムパラメータからスタートするより、顔認識の学習済みモデルの入力側に近い層のパラメータを初期値にする方が早く良い結果が得られる、というようなことが書かれている。
11章には、Fashion MNISTを題材にして、転移学習の1つの手順が示されている。ここでのポイントは、学習済みモデルの出力層のみを取り換えること、最初の数エポックは、再利用するパラメータが壊されないように固定しておくこと（layer.trainable = False）、その後でtrainableにするのだが、再利用するパラメータが破壊されてしまわないように、学習率をデフォルト値よりもかなり小さくすること（説明事例では1/100）、などであろう。
最後に、14章には、imagenetでpretrainしたXceptionを用いた花の分類例。花の画像が1000枚、すなわちデータ数が少ない場合の活用例。最初に、練習用のデータセットをtest_set, valid_set, train_setに分けている。次にモデル（Xception)の入力データサイズ224x224に合わせる。tf.image.resize(image, [224, 224])。さらに、shuffle, batching, prefetching, augmentationなどのpreprocessingをする。肝心のモデルだが、imagenetで学習したモデルとパラメータをロードする。必須条件は、include_top = False。これは、global average pooling layerとdense output layer（imagenetは1000種類に分類するから、1000のユニットからなる）を除去することで、代わりに、自前のglobal average pooling layerと、分類数のユニットをもつdense output layerを追加する。trainingの最初はbase_modelをlayer.trainable = Falseとして、数エポック、続けて、base_modelをlayer.trainable = Trueとし、かつ、learning rateを小さくして学習させる。およそこんな感じだ。
３．F. CholletさんのテキストにおけるTransfer learning
関連する内容は、Using a pretrained convnetで始まり、feature extractionとfine-tuningという表現になっていて、transfer learningという用語は、少なくとも見出しには使われていない。全体がTransfer learningで、バリエーションが多いという感じがする。
４．NIPS 2019の論文
Transfusion: Understanding Transfer Learning for Medical Imaging
Maithra Raghu∗ Cornell University and Google Brain maithrar@gmail.com
Chiyuan Zhang∗ Google Brain chiyuan@google.com
Jon Kleinberg† Cornell University kleinber@cs.cornell.edu
Samy Bengio† Google Brain bengio@google.com
Abstract
Transfer learning from natural image datasets, particularly IMAGENET, using standard large models and corresponding pretrained weights has become a de-facto
method for deep learning applications to medical imaging. However, there are fundamental differences in data sizes, features and task specifications between natural
image classification and the target medical tasks, and there is little understanding of
the effects of transfer. In this paper, we explore properties of transfer learning for
medical imaging. A performance evaluation on two large scale medical imaging
tasks shows that surprisingly, transfer offers little benefit to performance, and
simple, lightweight models can perform comparably to IMAGENET architectures.
Investigating the learned representations and features, we find that some of the
differences from transfer learning are due to the over-parametrization of standard
models rather than sophisticated feature reuse. We isolate where useful feature
reuse occurs, and outline the implications for more efficient model exploration. We
also explore feature independent benefits of transfer arising from weight scalings.
医療データの解析にtransfer learningがデファクトスタンダードとして用いられていることに意義を唱えている。疑問点は、たいていの人が感じているように、imagenetと医療画像とでは、画質も読み取る情報の位置や分布なども全く異なるので、そもそも、imagenetで学習したモデルのtransfer learningに大きな効果を期待するのはおかしいのではないか。transfer learningの効果があるとしたら、その理由、根拠は何なのかを、実験的、具体的に示したデータがあるのか。著者らは、確かに高い性能を示しているが、それは、transfer learningから期待されるもの、特徴量の効果的な利用、などによるものではなく、単にモデル自体の性能の高さによるものであろう、というのがこの論文の結論のようである。その根拠を示す結果を得ているようだが、自分にはそこまで読み取れない。
仮に、この論文の結論通りだとしても、imagenetで学習した高性能なモデルを用いることは、他の初期値を用いるよりも収束が早くて期待通りの性能が得られることに間違いはないのだから、我々は、何も変えることはない、ということになるのかな。
５．モデルのもつ性能を生かすための方法を考えよう。
病巣の面積率を反映した評価になるようにするには、タイルの集合体の中に組織の全体が入っているほうがよさそうだし、ある程度の画質も必要だし、モデルの性能は高い方がよさそうだし、計算時間の制約もあるし、・・・。
明日も、Kaggle kernelのGPUは使えないので、頭を使わないとだめだな。
7月9日：あと14日：
１．タイルの作り方を学ぶ：タイルの枚数、組み合わせ、各タイルの視野と解像度、これらを自由に操れるようになるため。
解読中
２．出力層をシンプルにしてみた。
・GPUが使えないので、CPUで動作確認したところ、オーバーフィッティング気味に動作することがわかった。
・そうすると、augmentationをしっかりしないといけないので、albumentationを調べてみた。非常に種類が多いことが分かった。これまで使ったことのないものについて、１つ１つ効果を調べてみる。
明日は、タイル作成コードをしっかり理解して、思い通りのタイルが作れるようにしよう。
7月10日：あと13日：
１．タイル作成コード：
・画像の高さと幅の値を取得する：例：image_shape = image.shape
・タイルの画像サイズをtile_sizeとしよう。
・元画像にパディング（周囲にダミー画素を追加）する。パディングは、パディングした画像サイズが、tile_sizeの整数倍になるように行う。
・パディングの大きさ（各方向へのピクセル数）を計算するために、演算子%が使われ、パディングを上端下端、左端右端に振り分けるために//2が使われる。
%や//の入った演算は、わかってしまえばどうってことないが、初見では戸惑うこともある。そういうときは、元画像の画素数とタイルの画素数を式に代入して、作図してみよう。数式は、具体的数値を代入し、その結果を図やグラフに表すと理解しやすい。
・.pad, .reshape, .transpose, .argsort, 等を、通常の説明書レベルで理解するだけではだめなのだろうという気がする。実際、np.padなども、説明書とは異なるフォーマットでも使われているようで、どう理解したらよいのかわからない。
・以上の結果、自分で組み立てなおしたり、欲しい解像度、形状、のタイルを得るのはあきらめた。使わせていただいているプログラムは、制約はあるものの、自由度は高く、さまざまなタイル構造を作り出すことができる。
明日は、何種類かのタイルの比較を行う予定。
7月11日：あと12日：
自分でコントロールできるプログラムは、いまだ、LB: 7.0にとどまっている。
discussionでの上位者の含蓄のある発言：要約すると、「実験あるのみ！」
タイルの解像度と枚数の制御範囲は広がった。そうすると、ある程度の解像度で検体全体を含むタイルを使いたくなるのだが、計算資源の問題にぶつかってしまう。
解像度の高い画像が得られたので期待して動かしてみた。ただし、バッチサイズ２でしか動かない。計算時間が長い。モデルとフィットすれば数エポックで高いスコアも可能だと期待して途中経過を見ていたが、予想外に悪かった。タイル画像は明瞭で、これなら容易に分類できるだろうと思っただけに残念だった。
自分の目を、コンピュータに合わせないとだめだな。実験あるのみ。先入観なしに、系統的に、実験しないといけないようだ。
検討中のモデルを、今朝、GPUを用いて10エポック計算し、スコアは0.75くらいだったのでcommitしたが、9時間も経ってエラーで停止し、スコアは得られなかった。lossやaccのデータまで消えてしまった。非常に残念だ。
もう1つのモデルも計算しているが、commitできるか心配だ。
心配どおり、今度は、自分でミスった。
はい、今日は、終り。
7月12日：あと11日：
勝者のキーワード：
Kaggle kernel、private dataset、GPU、TPU、の使いこなし。
stacking、ensemble、concatenate、・・・。
このあたりを調べてみよう。
・タイルの構成（個別タイルの解像度と画像範囲）を整えると、やたら画像が大きくなることがある。そのときは、適度な大きさにリサイズする。これを正しく行うためには、データの流れを正しく把握しなければならない。そのためには、プログラムを正しく理解しなければならない。もう少しだと思っている。
・どのタイルが良いのかを試しながら、良さそうなものを組み合わせる。アンサンブルの登場だが、出力をどうするのか。まだ理解していないので、見本になるプログラムを探して、学ばなければならない。
・各クラスに特徴的な画像を機械学習で抽出し、それを用いてCNNで学習させるというのが面白そうだし、CNNを通して特徴量を抽出してから機械学習で分類するのも面白いかもしれない。ただし、これは、単なる思い付きにすぎず、素人の妄想にすぎないかもしれない。。
・Kフォールドをやって、学習済みの各モデルで予測したクラスの平均をとるか、予測したクラスの多数決をとるか、これも妄想かもしれない。
・今日もcommitのところで、時間切れで失敗した。コミットがうまくいったのは借り物の予測・提出用のプログラムと、これも借り物だが、約3時間かかって計算した後、GPUをonのままにして約3時間でcommitしたものだけだ。
後者のkommitのとき、GPUは、3時間くらいしか動いていなかったはずなのに、その3時間の間にGPUを15時間くらい使ったことになっていたような気がする。
まだ20時間あると思っていたのに、残り5時間の警告が出てあわてて動作中のプログラムがないか調べて対処したように思う。
いまだに、コミットのときの条件を正しく把握できていないのだろうと思う。うまくいかなかったのは、2回とも、計算終了後にGPUをoffにしたことが原因だろうと思う。
commitの際に、GPU使用時間のさらに3倍以上の使用時間を消費してしまった原因は、コミットに要する時間が長くて、コミット中に、別のプログラムを編集しようとしてkernelを立ち上げた際に、GPUがプログラムに同期して自動的に立ち上がっていたのに気づかなかったためだろうと思う。
まだまだこんなレベルなのだ。
計算用と予測用を別にするなど、kernelを効率よく使う方法を習得したいものだ。
commitしたところで、良くてもLBは0.75くらいだろうからGPUを無駄に使わずに済ませられないかと思ったのも事実だ。
忘備録：技術習得目標
➂アンサンブル：異なるCNN、異なるフォールド、異なるタイル構造、異なるハイパーパラメータ：計算環境の問題
④学習の継続：引継ぎ：学習モデル（学習パラメータ）の受け渡し：学習と予測の分離：学習モデル（学習パラメータ）の受け渡し：それほど必要性を感じていない：それではだめだ。これは、自在にできるようにしておかなければならない。
②タイル等の画像のリサイズ：入力画像の画素数の調整：配列の次元が多い場合に対応できない：次元の低い話だ。
①自分の計算環境でどのnotebookも動かせるようになること：これがいつまでたっても克服できない ：windowsからlinuxに切り替えることで解決できるのだが、いつまでも、踏み切れずにいる。
7月13日：あと10日：
アンサンブルに限らないが、使いたいデータは、KaggleのDatasetsのpublicもしくはyour detasetsにアップロードしておき、Kaggle kernelのnotebookから、それらをアップロードするという使い方がある。
複数のモデルに対する学習済みDNNの重みをアップロードしておくことで、アンサンブルが容易になる。
強力なマシンを使って学習させたモデルの重みをアップロードすれば、それだけ予測精度の高いモデルを使うことができる。
容量制限はあるが、データベースもアップロードできるので、時間をかけて前処理したデータをアップロードしておくこともできる。
出力層：すでに書いたかもしれないが、現時点では、GlobalAveragePoolingの後は出力層に直結している。これで良いのかどうか、わからない。出力層としてdense層を加えた場合と比較しだすときりがないと思うので今はやらない。
学習済み（もしくは学習中）モデルのsaveとload、callbacks、modelcheckpointやearlystoppingなどは、ディープラーニングのテキストを読んで勉強しているときは、読み飛ばしていたように思う。
trainingに時間がかかるDNNでは、このあたりを押さえておかないと、時間を無駄にしてしまっていることを、実感させられているところである。
ここのところ、ずっと、毎回、imagenetで学習したモデルからスタートしてtrainingしているが、何か無駄をしているような気がしてならない。
モデルは学習するたびに賢くなっていくべきだと思う。さまざまに学習した成果を蓄積する方法はないものだろうか。
面白い論文があった。
Automated Gleason Grading and Gleason Pattern Region Segmentation Based on Deep Learning for Pathological Images of Prostate Cancer. YUCHUN LI et al., IEEE Acsess 2020
明日読んでみよう！
このコンペの技術目標を、「アンサンブルモデルによる予測」ということにする。
まだ、あと、9日間もある。
7月14日：あと9日：
学習と予測の分離及びアンサンブルを行うための枠組み：
（学習コードアップロード⇒学習⇒モデル保存）＊ｎ⇒予測コードアップロード⇒ｎ個のモデル読込（＋アンサンブル）⇒予測
ここで、保存したモデルは、Datasetとして保存する。予測コードをアップロードしたら、Datasetとして保存したモデルをアップロードする。
学習と予測の分離、および、DNNのアンサンブルの枠組みを理解するのに、14日間を要した（Kaggleに参加したのは昨年の今頃だったと思うので、1年を要した）。理解が正しいかどうか、簡単なモデルを使って、確かめてみよう！
Dropout：次の論文は、非常に重要で、参考になることが書かれているのに気づいた。主題は「isometric」であるが、自分にとって最も参考になりそうなのは、著者らが提案しているモデルに「dropout」を追加するだけでResNetの性能に近づいた、というところである。
今使っているモデルがoverfittしたら、同じ場所に、追加してみよう。
dropout(0.4)で効果はあったが、まだ不足。入力データの量とモデルの複雑さのバランスがとれていないのだろうが、適正化は時間がかかる。限られた時間と計算資源を有効に使って・・・。
Deep Isometric Learning for Visual Recognition
Haozhi Qi, Chong You, Xiaolong Wang, Yi Ma, and Jitendra Malik arXiv:2006.16992v1 [cs.CV] 30 Jun 2020
Abstract
Initialization, normalization, and skip connections are believed to be three indispensable techniques for training very deep convolutional neural networks and obtaining state-of-the-art performance. This paper shows that deep vanilla ConvNets without normalization nor skip connections can also be trained to achieve surprisingly good performance on standard image recognition benchmarks. This is achieved by enforcing the convolution kernels to be near isometric during initialization and training, as well as by using a variant of ReLU that is shifted towards being isometric. Further experiments show that if combined with skip connections, such near isometric networks can achieve performances on par with (for ImageNet) and better than (for COCO) the standard ResNet, even without normalization at all. Our code is available at https://github.com/HaozhiQi/ISONet.
Since R-ISONet is prone to overfitting due to the lack of BatchNorm, we add dropout layer right before the final classifier and report the results in Table 5 (g). The results
show that R-ISONet is comparable to ResNet with dropout (Table 5 (b)) and is better than Fixup with Mixup regularization (Zhang et al., 2018).
CNNのアンサンブルができるようになっても、今のモデルでは、単独で、まだ0.75を超えていないので、アンサンブルがうまく機能しても、LBは0.8にも届かないだろうな。
単一モデルで少なくとも0.85以上にならないと、勝負にならないだろうな。
分類のところに注目してみようか。
病巣の段階とその検体中における占有面積比が重要な意味をもっているように思う。
そうすると、タイル画像内で、病巣の占有率が把握できるようになっている必要がありそうだ。すなわち、タイルには、各検体の全体が写っていなければならないのではないか。クロップなどのaugmentationによって画像が画面からはみ出して見えなくなるのはまずいだろうな。元々のタイル内に、検体全体が含まれているのが大前提となるのか。
さて、今週のGPU使用可能時間は、あと4時間半となった。今走らせている計算が終われば残りは1時間となる。あと3日半は、GPUが使えない。
ということで、残っている大きな課題の１つである、自分の計算環境の整備をこの3日半の間に片付けてしまおう。
Anacondaの仮想環境を、元の環境をコピーして作成し、そこに、pipで必要なモジュール等をインストールすることで、たいていのものは動くようになる。さらに、Kaggleの議論もさんこうにしながら進めている。
これでOKかと思ったら、こういうエラーが出た。”BrokenPipeError: [Errno 32] Broken pipe” この原因が、さっぱり、わからない。これはPyTorchのモデルだ。
この作業をすることによって、Kaggleのpublicデータセットの使い方が少しわかった。
明日は、なんとしても、BrokenPipeErrorを克服しよう！
7月15日：あと8日：
BrokenPipeError：
定義：exception BrokenPipeError
A subclass of ConnectionError, raised when trying to write on a pipe while the other end has been closed, or trying to write on a socket which has been shutdown for writing. Corresponds to errno EPIPE and ESHUTDOWN.
日本語バージョン：
ConnectionError のサブクラスで、もう一方の端が閉じられたパイプに書き込こもうとするか、書き込みのためにシャットダウンされたソケットに書き込こもうとした場合に発生します。 errno EPIPE と ESHUTDOWN に対応します。
・なんのことやらさっぱりわからん。
・そこで、エラーメッセージの中を１つづ追いかけてみる。どうやら、data.to(device)のところがあやしい。deviceは、GPUである。
・パソコンに搭載されているGPUは1050Tiなので、メモリーは４GBである。そうすると、pytorchでは、num_workers = 0 以外の選択肢はなさそうである（pytorch GPU num_workersをキーワードに検索してみると、それらしい説明があった）。tensorflow/kerasでは、num_workers = 4でエラーが発生したときに、たぶん、num_workers = 1で動いたと思う。今回も、最初にnum_workers = 4があやしいと思って4を1に変更したが、エラーは発生したままだった。
・なにはともあれ、エラーの原因は、num_workersの値が、使っているGPUとマッチしていなかったということである。適正な値を用いることで、エラーは解決した。
・エラーの原因は、元プログラムが想定しているよりもGPUの能力が低いことにある。したがって、トップを狙える可能性は、いまだ低いままである。
・今、ノートパソコンのGPU:1050Ti:の冷却ファンがうなりを上げている。
・2エポックでval_kが0.68くらいまで上がりそうだったので、よしよし、と思っていたら、2エポックで停止、3エポック開始時にエラーが発生した。
・まいった、まいった。
・2エポックの計算に3時間以上かかっているので、エラー対策をしてもその結果がわかるまでに、３時間以上かかることになる。
・類似エラーのQ&Aには、pytorchのバージョンを最新のものにすればよいとか、1つ前のバージョンにすればよいとかいうのがある。現状は1.2だから、まずは、1.4にして、それでだめなら、1.5にしてみよう。これで結果がわかるまでに7時間以上かかることになる。2エポックまでは計算できるので、タイルの条件を変えてみよう。
コンペサイトの説明で気になる箇所がある。
１．training setのイメージの一部は、ペンによりマーキングされているが、test setにはマーキングはない。
２．セグメンテーションマスクが用意されていて、ISUPグレードが示されている。全ての画像に付属しているわけではない。種々の理由により偽陽性、偽陰性が含まれている。マスクは、効果的なサブサンプリングをする方法を開発するのを支援するために提供したものである。マスクの値は供給機関によって異なる。
３．機関によってラベル（の定義）が異なっているようにみえる。
技術検討用ということでしょうか。最初はマスクを使わず、写真や試料の不具合も関係なくそのままデータを通す。次からは、不具合のある写真や試料を除く。試料がどちらの機関由来かを識別することができるかどうか調べる。テストデータについても機関間の識別ができれば、機関ごとに学習モデルを作りテストデータを分類することができるかもしれない。どれがうまくいくかは、予測結果を提出してスコアが算出されるまでわからない。
計算環境の問題：
仮想環境(????vision)を作ったうえで、condaでインストールできないモジュールやパッケージをpipでインストールしている。
仮想環境のpytorchを1.2から1.4もしくは1.5にバージョンアップするつもりが、まちがってベース環境のpytorchをバージョンアップした。
notebookをどちらの環境で立ち上げているのか間違うと、環境を壊してしまうことになりかねないので要注意。
出来ることが増えるということは、管理すべきことも増えるということ。
使い方がわかっていないところがある。
pytorchのバージョンアップが、jupyter notebookに反映されない。
明日は、このエラー対策だ！
AttributeError: 'CosineAnnealingLR' object has no attribute 'get_last_lr'
これも！
pytorchのバージョンアップが、jupyter notebookに反映されない。
エラーに明けて、エラーに暮れる。
そうだ！ AIエンジニア＆AI研究者になろう！
7月16日：あと7日：
今日の課題は、1.2.0から1.4.0以上へのpytorchのバージョンアップ：
Anacondaを使用している。
conda updateから始めたのだが、1.2より新しいものが出てこない。uninstallしてからinstallしても、1.2.0だけを推奨し、バージョンアップできない。アップデートや再インストールの際にバージョンを指定しても、別の場所に、単独でインストールされるようで、使える状態にはならない。conda listでは1.2が表示されるだけである。
condaによるfastaiのインストールの説明文の中に、pytorchへの言及があった。Anacondaにはfastaiもインストールしているので、非常に気にはなったが、pytorchのインストールやバージョンアップへの影響に関係する記述はないようだ。
試しに、fastaiとpytorch 1.2の両方をアンインストールしてから、pytorchのみインストールしようとしたが、1.2しか出てこない。
pytorchのHPに書かれているインストール方法、conda install pytorch torchvision condatoolkit=10.2 -c pytorchを実行してみた。もう３時間近く動いている。互換性のないパッケージを調査するということで、examining conflict for ... が表示され、動き続けている。もう5時間以上になる。これだけ時間がかかると、うまくいくとは思えない。pytorchはtensorflow/kerasと衝突しているのだろうか。もう10時間を超えただろうか、延々とexamining conflict forが続いている。これでバージョンアップできたらAnacondaの技術者は凄いってことになるのだが。どうかな。
1日つぶした。pytorchのバージョンアップが目的なのではなく、エラーが生じた可能性の１つがこれではないかということである。エラーが生じているのは、learning rateの更新のところだから、プログラムの変更でエラーはなくせるかもしれないので、そちらをやろう。
7月17日：あと6日：
Kaggle kernelに頼りすぎたな。もっと広く言えば、Kaggleのコミュニティーに頼りすぎたな。技術を磨くには、とても良い仕組みであり、コミュニティーだと思う。引き続き利用させていただきたいと思っている。自分にとってのメリットとデメリットを列挙してみよう。
メリット
・スコアを争うことは、真剣に取り組む動機付けになる。
・スコアを争うことにより、モデルの予測能力を上げるための技術に敏感になる。
・スコアを争うことにより、当該分野の技術開発状況に敏感になる。
・公開コードによって、プログラミング技術の基礎から、モデルの高性能化のための様々な工夫、様々なデータの前処理技術を学ぶことができる。
・自前の計算環境が無くても、Kaggle kernelで、GPUやTPUを使うことができる。
デメリット
・公開コードに頼りすぎると、自前のコードを作らなくなってしまう。
・Kaggle kernelに頼りすぎると、自前の計算環境の保守がおろそかになる。
さて、あと6日になった。
ハイスコアを狙うには、1050Tiは自分の能力との足し算では、不足である。
自分が或る程度理解できて、ある程度条件検討してきた中で、最も良いスコアが得られそうだと思うタイルとモデルの組み合わせにおいて、良いスコアを出すために必要な時間は短く見積もっても100時間である。残りは30時間である。4週間前なら120時間あるが、今使っているモデルは自前ではできないノウハウが入っており、その時期にそのモデルの原型が公開されていても自分ではとりかかれていないだろうと思う。
google colaboは使えるのかどうか調べてみよう。
Kaggle kernelよりも一般向けに設計されているようである。使えるGPUやTPUの性能は同レベルかな。Google Driveは15GBまで無料で使用可能。12時間まで連続使用可能となっているようだが保証されているわけではない。
大容量のデータや大きなモデルを扱うためには、Google Cloud Platformを使うことになるのだろうな。自前のモデルで、ハイスコアの可能性があれば、やってみてもよいのだが、・・・。
最後までスコアアップの手段を検討し続けよう！
7月18日：あと5日：
ハイスコアのポイント：
データの特徴：2つの機関KとRから、データとラベルが提供されている：ラベルにも画像にもバイアスがかかっている：Kの画像/ラベルで訓練したモデルでKのテスト画像のラベルを予測し、Rの画像/ラベルで訓練したモデルでRのテスト画像のラベルを予測するのが最も正確だと考えるのが妥当だろう：入れ違いになるとどうなるのだろう：Kの画像/ラベルで訓練したモデルでRのテスト画像のラベルを予測し、Rの画像/ラベルで訓練したモデルでKのテスト画像のラベルを予測した場合が最も不正確になると考えるのが妥当だろう：KとRの論文には、正確なラベルを与える難しさが書かれている：不正確なラベルが、ある割合で含まれている：コンペの概要には、ラベルの定義すら違っているような記述がある：Rでは試料をいくつかのクラスに分けてラベル付けしている：そのクラス/ラベル付け手法によってラベルの正確さは異なっている：そのうちのどれが訓練データに、どれがテストデータに組み入れられているのかは不明：機械学習を援用して半自動でラベル付けしたり、専門家がラベル付けを繰り返したり（不一致のラベルは再検討）している。加えて、不良データの追加、マスク（セグメンテーション？）の付与、マーキング残しなどがある：こういう状況の中から、テスト画像に付与されたラベルを予測する：主催者の期待はどこにあるのだろうか：少なくとも、テストデータのラベルは、専門家による最も確度の高いものでなければ意味がないと思うが、現実にはグレーゾーンがある。ミスもある。意図的にノイズデータを加えることもある。：もし、最初に述べたとおりになっているのなら、訓練データを用いて、徹底的にRとKを識別するのがよくて、そのモデルでテストデータをRとKに仕分けし、対応する訓練モデルで予測するのが最も正確な予測結果をもたらすのかな：そうだとしても、用いるDNNモデルが貧弱であったり、タイリングなどの画像の前処理技術が貧弱であったり、計算資源が不足していれば、高いスコアは望めない。
機械学習プログラムの設計製作技術を身に着けよう、向上させよう、絵に描いた餅に終わらないようにしよう！
さて、Kaggle kernelのGPUの最後の30時間を有効に利用する方法を考えよう。
今回のコンペで新たに学んだのは、Kaggle Datasetの利用/活用方法である。これを使って３つか4つのCNNモデルのアンサンブルを試してみることにする。
7月19日：あと4日：
アンサンブルを1回やって今回のコンペは終えることになりそうなので。効果的なアンサンブル法についてコンペ内での情報があれば参考にしながら考えてみたい。
アンサンブル用予測モデルの取り出しに失敗した。
明日は、目標を小さくするしかない。
予測モデルの取り出しだ。
自分の今のレベルがよくわかった。
7月20日：あと3日：
今日は全休です。
7月21日：明日提出締切（正確にはあさって午前9時00分まで）
今日の予定：次のステップへの準備
１．Kaggle kerner内での出力ファイルの確認と取り出し
２．Kaggle kernelのGPUとTPUの活用について
結果
１．訓練中の出力ファイルの変化の確認、訓練終了直後の出力ファイルの確認、出力ファイルの取り出し作業を、1ステップ毎に記録しながら慎重に作業する
・計算途中であるが、これまでの最も良いモデルのパラメータファイルが出力されているのを確認し、ダウンロードできることも確認した。
・明日は、ダウンロードしたパラメータファイルをDatasetに保存し、予測用のコードに読み込んで実行し、submitしよう。
２．TPUを用いたnote bookから、TPU使用方法を学ぶ
基礎学習
Google Cloudからのコピペ
Cloud TPU は、Google がニューラル ネットワークのワークロードに特化して設計した行列プロセッサです。TPU では、文書処理、ロケット エンジンの制御、銀行取引といった操作に対応できませんが、ニューラル ネットワークの大規模な乗算と加算に関しては、極めて高速に処理でき、しかも、消費電力と内部の物理フットプリントは CPU や GPU と比較して大幅に下回ります。
TPU が他のデバイスより優れている点としては、フォンノイマン ボトルネックが大幅に軽減されることが挙げられます。このプロセッサの主要なタスクは行列処理であるため、TPU のハードウェア設計者はその演算処理の実行に必要なあらゆる計算ステップを把握しました。そしてその知識を基に、何千もの乗算器と加算器を配置して直接相互に接続し、これらの演算子からなる大規模な物理行列を形成することができました。この構造は、シストリック アレイ アーキテクチャと呼ばれています。Cloud TPU v2 の場合、128 x 128 のシストリック アレイが 2 つあり、16 ビットの浮動小数点値を処理する 32,768 個の ALU を単一プロセッサ内に集約しています。
・調べた範囲では、モバイル用途の他には、特段のメリットは無さそうだが、実際に使ってみなければわからない。2か月ほど前に、Flower Classification with TPUsというコンペがあったので、合間を見て、そこのnotebooksで学んでみよう。
明日は最終日だな。１つは、commitしてsubmitしよう！
7月22日：本日提出締切日（明朝午前9時）
本日の予定
１．最後のsubmit
・trainモデルを走らせ、最良のcvが得られたモデルのパラメータセットをsaveする⇒そのファイルをdata setとしてアップロードする⇒data setを経由して予測モデルにそのパラメータセットを読み込み、test dataの分類をしてsubmission fileを出力する。
・この手順でsubmitした結果、スコアはLB=0.85であったが、このスキームでsubmitする手法を学んだということで、良しとしよう。わずか4エポックの単一モデルでこのスコアが出るということは、元のプログラムがハイレベルだったということだろう。
２．commit中のGPU使用時間の確認
Kaggle kernel内での操作に少し慣れてきたので、以前から気になっていたcommit中のGPU消費時間を、commit開始からモニターしている。
現状の理解：
commitは、プログラムを再度走らせるので、GPUを使って5時間かかったのであれば、commitにもGPU使用で5時間かかる。（CPUでは計算に9時間以上を要する場合、GPUをoffにしてcommitすると、commitは失敗する）
GPUの使用時間は、GPUのon/off操作の下段にGPU Quotaとして表示されている。それを見れば、GPUの使用時間がリアルタイムでわかる。
commit中、GPU Quotaの時間表示は、session on/offによらず、実際の経過時間の倍の速さで時間は進む。
session onでcommitすると、GPU Quotaの表示のとおり、実際の経過時間の２倍の時間、GPUを使ったことになる。
session offでcommitしても、GPU Quotaの表示は2倍の速度で進むが、My account画面に表示されるGPU消費時間は、commitの経過時間のみを反映したものであり、 Quotaをクリックすると、やはり、commitの経過時間のみを反映した表示があらわれる。
画面によって異なる時間が表示される。これは、現実におきていることである。
しつこいようだが、GPUの残り時間から、commitできると思っていても、単純な操作ミスによって、commitに失敗することがあることに注意しよう。
注意）GPUのon/offと、sessionのon/offは、まめにチェックしよう！
３．data augmentationについて
train、validation、testの3つのステージについて考えてみる。
A. Geronさんのテキストでは、AlexNetの説明のところで、Augmentationが紹介されている。AlexNetはoverfittingを防ぐためのgenerarization techniqueとして、DropoutとともにAugmentationを用いていたことが紹介されている。
F. Cholletさんのテキストでは、データが無限にあればoverfitは起きない。その代替方法として、データをランダムに加工することによって本物に近いデータを増やす方法としてAugmentationを位置づけている。さらに、data augmentationは、所詮、元画像の単純な加工に過ぎずoverfitthingを防ぐには十分でない。その場合には分類器の全結合層の手前にdropout(0.5)を入れるとよい、と説明されている。
さらに、コードの説明のところで、validation dataに対しては、Note that the validation data shouldn't be augmentedと書かれている。
ということで、data augmentationは、train dataに対してのみ行うものと思っていた。
しかし、Test Time Augmentationは、適切に用いれば大きな効果を発揮する可能性があるようだ。次のような論文がある。
Greedy Policy Search:A Simple Baseline for Learnable Test-Time Augmentation
Dmitry Molchanov, Alexander Lyzhov, Yuliya Molchanova, Arsenii Ashukha, and Dmitry Vetrov, arXiv:2002.09103v2 [stat.ML] 20 Jun 2020
Test-time data augmentation—averaging the predictions of a machine learning model across multiple augmented samples of data—is a widely used technique that improves the predictive performance. While many advanced learnable data augmentation techniques have emerged in recent years, they are focused on the training phase. Such techniques are not necessarily optimal for test-time augmentation and can be outperformed by a policy consisting of simple crops and flips. The primary goal of this paper is to demonstrate that test time augmentation policies can be successfully learned too. We introduce greedy policy search (GPS), a simple but high-performing method
for learning a policy of test-time augmentation. We demonstrate that augmentation policies learned with GPS achieve superior predictive performance on image classification problems, provide better in-domain uncertainty estimation, and improve the robustness to domain shift.
・TTAは、予測性能を上げるための手法として過去に検討されていたようだ。
・Kaggleでは、すでに常套手段になっているようである。効果的なTTAを探そう。
４．今回、アンサンブルをやろうとしてできなかったこと
・アンサンブルのコードをどのように仕上げるかということも課題であったが、どういうアンサンブルをするのかを、決めることについても十分な検討はできなかった。したがって、効果のほどはわからないが、以下のような単純な方法を検討しようとしていた。
・タイルの枚数や解像度を変えたモデル
・学習率の初期値を変えたモデル
・パラメータの初期値（He、ランダム、imagenetによるpretrain）を変えたモデル
スコアアップのためのTTAを検討し、TTAを変えたモデルのアンサンブルというのもありかもしれない。
・GPUの残り時間が少ない中で、アンサンブルのためのデータ保存とそのダウンロードのタイミングを間違えたのが痛かった。
これで、PANDAコンペは終了だ！
目標の1位からは、はるか遠くの順位にとどまり、仮の（借り物の）スコアから抜け出せなかった。
次は、SIIM-ISIC Melanoma Classificationに取り組もう！
7月23日：本日午前9時終了
verify中とのことだが、最終結果が発表された。
＊順位について
まず、順位変動の大きさに驚いた。test_dataの42％を使ったPublic（暫定）から、残り58％のtest_dataを使ったPrivate（最終）とで、こんなに順位（スコア）が違ってもいいのか、ものすごく、大きな疑問を感じる。
200も300も飛び越してベストテンに入った人はおめでとうでよいのだが、優勝だと思っていた人が41位にまで下がっているのはなんとも残念な気がする。
＊上位の方々の戦術
印象に残ったのは2つある。
１つは、丁寧なラベルと画像の選択である。これは、ディープラーニングの基本中の基本、すなわち、良い（画像 - ラベル）ペアを作り上げることである。この作業を、どうやるか。訓練後に、訓練データを予測して、ノイズ画像やノイズラベルを除去することになるのだが、除去するしきい値の決め方など難しいことがありそうだな。
もう1つは、お手本となるコードの作成者が早々に（2か月も前に）退出されたことだ。終了後にその理由を投稿されている。この方のモデルは、42％の側のtest_dataに適合しなかったことが最大の要因だと思う。結果的には、優勝候補の方と同じ道を歩むことになったようである。非常に残念なことである。
追加でもう１つ。Kaggle kernelとGoogle Colabしか使えない方が、工夫して、ベストテンに入っていること。これを言い訳にしている自分が恥ずかしい。
以上
