AI_ML_DL’s diary

人工知能、機械学習、ディープラーニングの日記

SIIM-ISIC Melanoma Classification

SIIM-ISIC Melanoma Classification

2020年5月28日~8月17日

1st place $10,000.-

 

7月23日:あと26日

このコンペの目標は、正確な医療診断技術を習得し、1位を獲得することである。

その手段は、目標となる公開ノートを探し出し、それを理解し、ファインチューニングすることである。

不明なところは、そのノートの製作者に直接聞くことができる。

コンペの概要を読み、関連文献にざっと目を通し、人気のEDAを探してじっくり眺めてから、学びたいコードを、スコアの高い方から順に眺めて、探した。

TPUはさわらないようにしようと思ったのだが、まるで教科書の練習問題のようにスマートなノートがあったので、今回はそれを使わせていただく。

初期設定値で動作確認した。

今日はここまで。

明日は、初期設定値で走らせて、コミット、サブミットまでやってみよう。

 

7月24日:あと25日

夜中に、画素数を増やして走らせてみたが、深夜に気が付いたときには、停止していた。現状におけるTPUの連続使用可能時間は3時間であることがわかった。

これで、大きな画像を大きなモデルで計算するためには、途中経過を出力して終了し、再立ち上げの際に途中経過を入力して、計算を継続できるようにしなければならないのだが、どうやればよいのだろうか。

 

同一条件で、efficientnet-B0とB1をそれぞれ走らせ、commitし、予測結果をsubmitしてみた。それぞれ、LBは0.913と0.933であった。

いい感じだが、B2, B3, B4と、モデルを大きくしていけばスコアが上がるかといえばそうは問屋が卸さない。

overfitthingや不安定性などが生じるなど、単純ではないが、B6まで走らせて実験することはできる。

条件を揃えて計算しているつもりだったが、B5やB6は予想外に重く、TPU3時間の時間制限にひっかかってしまう。

他の条件が同じならばモデルが大きくなるほどoverfittingが早まる傾向にあるので、エポック数を減らすなどしてTPU使用時間を節約しているが、少ないエポック数では、不十分なこともある。

B0やB1では、underfittingになることもあり、augmentationの軽減やエポック数を多くするなどの検討も必要になる。

 

7月25日:あと24日

今回はTPUの公開コードをベースに進めている。

今からだと、TPUの割当は4週分120hで、1つのモデルの計算が3時間以内だから、commitと合わせると6時間以内なので、120/6=20種類以上の組み合わせについて計算できる。

B0からB6まで7種類のモデルで、画素数が3種類とすると、これらを組み合わせるだけでTPUの使用時間を使い切ってしまうことになる。augmentation、学習率、データベース、アンサンブル、K-fold数など、調べてみたい組み合わせはたくさんあるので、スコアアップのために、計画的に進めなければならない。

B0とB6とでは計算時間が4倍から5倍くらい違い、画素数に比例して計算時間は長くなる。したがって、画素数の多い画像を用いて重いモデルを訓練するには3時間の制限が大きな制約になる。

 

今日は、efficientnet-B6を用いて学習・予測した結果をsubmitしてみた。

ようやく、デフォルトと同等の結果0.94xが得られた。

当然といえば当然のことなのだが、公開コードは、デフォルトでも、高性能のGPUやTPUを長時間使用して、そこそこの性能を出していることが多いので、デフォルトと同等の結果が得られたということはよかった。

ここからが、スタートだ。

 

今日1日でTPUを9時間30分使用した。

 

7月26日:あと23日 

今回使っているモデルはEfficientNetである。

Mingxing TanさんとQuov V. Leさんが論文を書いており、所属はGoogle Research, Brain Team, Mountain Viewとなっている。

Kaggleも、TPUも、TensorFlowも、・・・、全てはGoogleの手の中、・・・

 

今日は、画像解像度とモデルの組み合わせを種々変えて、cvと計算時間を調べた。

しかし、これが、意外と難しい。

素数とモデルの組み合わせによって、cvのばらつきの程度が異なるようで、このばらつきを抑えないと、組み合わせたときの性能を正しく評価することができない。

2日間で、TPUを23時間ほど使った。

素数が少ない場合は、efficientnetのどのモデルでもsvは低く抑えられる。

素数がある程度多くなれば、efficientnetのどのモデルでも、よく似たcv値を示す。

まだ最適化の途中だと思うが、LBのスコアは、0.945を超えられない。

 

明日は小さいモデルで計算して、LBがどうなるか調べてみる。

その後で、GPUによる動作確認、train_dataとtest_dataの違いについての調査、を行う。

 

7月27日:あと22日

TPUは、今週(土曜日午前9時まで)の残りが7時間しかないので、温存する。

GPUの30時間を活用するために、GPUが使える最大画素数と最大モデルの組み合わせを調べる。

今使っているプログラムのTPUとGPUの計算速度は、10倍くらい違うことがわかったので、このコンペでスコアを競うには、GPUは不十分(使えない)であることがわかった。

 

当該コードの質疑を読んでみた。

素数の多いデータを重いコードで走らせたいということは、みんな、最初に思うところである。しかし、TPU v3-8で何時間もかかるプログラムは、機械学習を業としていている機関や情報系の研究室等でないと動かすのが難しそうだ。お金があればクラウドAIを利用すればいいだけのことだろうけど。

それに加えて、異物検査のごとく、病巣を含む画像が極端に少ないことも大きな課題である。ただし、異物検査のごとくといっても、異物の有無ではなく、変質の有無であるから、やっかいである。

あとは、train_dataとは少し異なる画像がtest_dataに含まれているということもわかっている。それが、pablic_dataとprivate_dataにどう振り分けられているかは知る由もない。

 

TPU残り時間を温存しようと思っていたが、良さそうな条件がみつかったので、残り少ないTPU使用時間を使って、モデルを走らせた。ところが、条件出しに1時間かかり。ようやく開始した計算が、1時間を少し過ぎたところで停止した。回線が切れたようだ。残念だが、明日やり直そう。といっても、順調にいけばcommitできるはずだったのが、計算だけしかできない状態になった。

 

計算させるより、上記課題の解決方法を考えろ、ということだと受け止めよう。

 

7月28日:あと21日

8月1日からの30時間に、チューニングだけで0.950を超えるために、これまでの結果を見直そう!

 

チューニングは、overfittingの抑制、best trained model取得の判定方法(loss、AOC、acc、・・・)、画素数とモデルと識別目的の相性、外部データベースを利用するか否か、アンサンブルの組み合わせ方(モデルの種類、画素数、random seed、単純繰り返し、fold数、・・・)などたくさんある。

 

これまでの約50時間の計算結果から何が言えるか。

ベースモデルが同じでも、augmentationや学習率、学習の停止条件、などによって予測性能は異なるだけでなく、1foldごとの評価結果のばらつきも大きいので、ごく大雑把なことしか言えない。

128,192, 256, 384, 512ピクセル、efficientnetのB0からB6について調べた結果、

ピクセル数は、192と256の間に境界があるようにみえるが、

モデルについては、B0からB6の間に明瞭な境界は認められない。

たとえば、512ピクセルの画像に対するB0とB6を比較するならば、train中のスコアは、B6の方が明らかに高いが、validationスコアは、ばらつきの範囲内にあって、どちらが良いのか一概にはいえない。

これが容易に判定出来れば、調べる場合の数が少なくなって調べやすいのだが、ばらつきのゆえに判断しにくく、ときには先入観(解像度の高い画像と高性能のCNNの組み合わせが良い)が優って、よいスコアが得られる組み合わせを見つけ難くなっているのかもしれない。

使っている条件では、B0と比べるとB6の方がoverfitting状態にあるといえるかもしれない。overfittingと予測性能の関係も複雑なので、結局は、良さそうな組み合わせから順に、時間とTPUマシンタイムの範囲内で、試行錯誤することになる。

 

TPUの残り時間の少ない中で、B6-384pixelの外部データなしを計算し、commitし、submitした。その結果、LBは0.94+から0.93+に下がった。外部データは必要なんだな。こんな感じで1歩づつ上がっていければよいのだが・・・。

 

明日は、tabuler dataと計算済みのCNNの結果とのensembleというのを試してみよう。

これなら、TPUを使わなくてもできる。

 

7月29日:あと20日 

とりあえず、CNNの予測結果と、tabular dataによる予測結果の加重平均を計算して、submitしてみた。

CNNの1つと、tabular dataを加重平均したところ、tabular dataの割合が0.3のときLBは最大値となった。

それならばと、3つのCNNとtabular dataを等分(各0.25)で加重平均してみたところ、LBは、0.951+になった。

テスト的に行ったので、submit回数の制限によって、5つの組み合わせでしかLBは確認できず、全容はわからないが、tabular dataとの加重平均をとると、tabular dataの割合が0.3以下では、LBが高くなることがわかった。

しかしながら、submitしたデータのヒストグラムを見ると、最大値が0.8以下になっており、tabular dataのヒストグラムは、最大値が0.2以下であることなど、何がどうなっているのか、皆目わからない。

 

LBが上がる理由が全く理解できない。

とりあえず、明日は、AUCとは何なのかを調べよう。

さらに、手持ちのデータを使って、加重平均をとって、submitしてみよう。

 

7月30日:あと19日 

AUC:

日本バイオインフォマティクス学会編 バイオインフォマティクス入門の2-19機械学習の評価に、わかりやすく、まとめられている。

内容省略

 

B6-384で、外部データー使用の効果を調べた。その結果、2019と2018のデータを追加すると、LBが0.93+から0.94+へと0.01程度上がった。

tabular dataを使わないで、自分がcommitしてsubmitした3種類のデータを、単純平均もしくは加重平均してsubmitしてみた。そうすると、LBの平均は、ほとんどの場合、上がった。

 

今回のコンペには、1週間ほど前に参加したのだが、その初日にノートブックをスコア順にソートしてみると、上位に、ensembleしただけのノートブックが並んでいたことに驚くとともに、違和感を感じた。質疑のところには、無意味じゃないかとか、ハイスコアのノートブックを公開するのはまずいんじゃないかというやりとりがあった。

そのようになった原因の1つは、2クラス分類でクラス間の偏りがハンパなく、AUCで評価していることから、そのことに起因するスコアの変動(主に上昇)が大きいということが関係しているのだろうと思う。そのメカニズムはわからない。

 

いずれにせよ、ハイスコアを出さないことには、何も始まらない。

 

今日、ようやく、LB=0.95+と表示できるところまできた。

明日は、土曜日の午前9時に回復するTPUの30時間の使用スケジュールを考えよう。

 

LB=0.96+と表示できるレベルに到達するためには、B6-384とB6-512の計算条件の検討、Bn-768のnの最大化の検討、および、外部データ無しの計算条件の検討などが順調に進むことが最低条件となりそうだ。

 

768pixelの画像を入力して計算する場合の問題点は、2つあって、1つは、計算に必要なメモリーが大きくなって扱えなくなること、もう1つは、メモリーの問題をクリヤ―しても、計算時間が長くなって、所定の時間内(たとえば1回3時間)に計算結果が得られない事である

前者については、Cloud TPUのトラブルシューティングの資料に対応方法が書かれている。メモリー不足の原因は次の4つの場合に分けられる。モデルの重みの数が多い場合、テンソルパディングが過剰である場合、バッチサイズが大きすぎる場合、および、モデルが大きすぎる場合である。

現に起きているのは、モデルが小さい場合(B0,B1,B2)は動くが、B3で動かなくなるということである。これに対する対策は、モデルの総数を減らせ、ということだが、それは出来ない、より大きなモデルで計算したいのに、モデルを小さくせよというのは対策になっていない。可能であれば、バッチサイズを減らすことである。これは、TPUに限ったことではなく、GPUでも同じである。PANDAコンペではGPUを使っていたが、大きなモデルで動かすために、バッチサイズは2まで減らした。

TPUは、Cloud TPUの説明では、バッチサイズの合計が64の倍数になるようにしなければならないと書いてある。無料のGoogle CloudのTPUは、v2であって、Kaggleのv3とは異なる。説明書を探してみたが、適切なバッチ数の説明はあっても、v3-8について最小値を記述したものが見つからない。とにかく動けばいいのだ。今使っている公開コードのバッチ数の計算式は[32]*FOLDとなっているので、FOLD数を減らしてみよう。(この記述は誤解にもとづくもので、バッチサイズを変更するには、[32]を変更すればよい)

次は計算時間の問題だ。これは、バッチサイズにも依存するが、動くことが前提なので、バッチサイズはおのずと決まる。ということでFOLD数が決まる。計算時間との相関が大きいのは、データベース(画素数と枚数とaugmentationによる増加率)、エポック数、TTA数などである。画素数は768pixelである。エポック数は性能を発揮するための最小数がある。TTA数は公開コードの初期値を使っているが、時間が不足すれば小さくする。augmentationも頻度のパラメータがあれば調整する。

 

7月31日:あと18日

TPUが使えるようになった最初のコンペFlower Classification with CPUsに非常に参考になるコードがある。が、しかし、扱っている画像の画素数が決まっているので、バッチサイズに関係する議論はなさそうだ。チュートリアル的な公開モデルは、バッチサイズとして128を使っている。

そのチュートリアル的な公開コードに関するコメント欄で、lrスケジュールについての質問があり、作者は、特に立ち上がり部分に関しては自信を持っているようだ。自分が今使っているコードの初期設定値とよく似ている。エポック数との関係で、自分はそれを変更して使っているのだが、変更が良かったかどうかわからない。cv,LBがどうなったかをチェックしておこう。

lrの最大値をバッチサイズに比例させているのは常識なんだろうな。TPUは大きな特定のバッチサイズにすることで高速化していて、バッチサイズを桁で変えているので、lrをそれに比例させて変化させているのだろう。

 

こんな記事があった。

16バッチでもTPUは動くらしい。

When to use CPUs vs GPUs vs TPUs in a Kaggle Competition. by Paul Mooney

     In order to compare the performance of CPUs vs GPUs vs TPUs for accomplishing common data science tasks, we used the tf_flowers dataset to train a convolutional neural network, and then the exact same code was run three times using the three different backends (CPUs vs GPUs vs TPUs; GPUs were NVIDIA P100 with Intel Xeon 2GHz (2 core) CPU and 13GB RAM. TPUs were TPUv3 (8 core) with Intel Xeon 2GHz (4 core) CPU and 16GB RAM). The accompanying tutorial notebook demonstrates a few best practices for getting the best performance out of your TPU.

     For our first experiment, we used the same code (a modified version*** of the official tutorial notebook) for all three hardware types, which required using a very small batch size of 16 in order to avoid out-of-memory errors from the CPU and GPU. Under these conditions, we observed that TPUs were responsible for a ~100x speedup as compared to CPUs and a ~3.5x speedup as compared to GPUs when training an Xception model (Figure 3). Because TPUs operate more efficiently with large batch sizes, we also tried increasing the batch size to 128 and this resulted in an additional ~2x speedup for TPUs and out-of-memory errors for GPUs and CPUs. Under these conditions, the TPU was able to train an Xception model more than 7x as fast as the GPU from the previous experiment****.

Image for post

Image for post

この記事によれば、CPU, GPUと条件を合わせるために16バッチで計算したと書かれている。したがって、16バッチでの計算も可能なのだ。モデルにもよるが、16バッチを128バッチにすれば、速度は約2倍になるようだ。

見方をかえれば、16バッチまで小さくしてもTPUは動作するし、バッチ数を1/8にすると速度は遅くなるが、1/2程度だ。あとは、速度低下による時間制限の壁との戦いだ。

 

リーダーボードのスコアが上がっている!

とくに、50位以内は大きく動いているような気がする。

負けずにがんばろう。

 

明日は、768x768を扱えるモデルサイズの最大値を探すために、バッチ数を設定する方法を調べる。 

 

8月1日:あと17日

Discussionを読んでいると、誰でもLB=0.96+に到達できそうに思うのだが、もう10日も経つのに、まだ0.95+の下の方にいる。

何が足りないのだろうか。

 

今日は、TPUがリセットされて使えるようになったので、早速、バッチ数の変更を試してみた。その結果、batch_size=128と表示されるようになり、768画像がB6でも計算できるようになった。

とはいえ、バッチ数が半分になり、画素数が2.25倍になることで、計算速度は大きく低下しそうだ。

 

今週の最初のモデルとして、1回の計算で決められないかと思い、5FOLDの各FOLDで、B6-384*2, B6-512*2, B2-768を計算して、commitし、submitした。

tabular dataと加重平均も行った。

期待は、0.95+の後半だったが、結果は0.94+の後半で、平凡な結果となった。

 

今日のこの結果と、先週行った5FOLDの個別モデルのアンサンブルの結果を合わせて考えてみる。

今日の各FOLDの計算条件は先週の個別モデルの計算条件を改善したもので、かつ、組み合わせの幅も広げたものになっている。

それにもかかわらず、先週よりも低いスコアになったことから、明日からは、個別モデルの性能を上げたうえでアンサンブルをすることにする。

 

明日からの5日間は、今日計算した5つのFOLDの各モデルをベースに、B4とB5を加えて、個別に3-5FOLD計算することにしようと思う。

 

目指せ0.96+

 

8月2日:あと16日 

今日も1つ予測データを作成したのだが、LBが予想より小さく、アンサンブルの効果も少なく、これまでの結果を上回ることはできなかった。

予測データの数が増えてくると、どれをアンサンブルしたのかわかりにくくなってきたので、これまでの予測モデルと、アンサンブルの組み合わせを、一覧表にしてみた。

その結果、効果の有無が明確になり、組み合わせのいくつかを変えてみると、わずかではあるが、LBが上がる組み合わせが見つかった。

1/1000のスコアアップへの挑戦が続く。

 

8月3日:あと15日

今日はB6-512の検討(外部データベースの変更)

 

768x768の画像を用いた計算ができるようになり、アンサンブルモデルに加えたが、まだ、スコアアップにつながっていない。

B4ではスコアが上がらないような感じ。

かといって、B6では、時間制限にひっかかりそうだし、・・・。

 

データベースを変更してB6-512の計算を終え、commitし、submitした。単独のスコアは0.94xであり、アンサンブルの効果を期待したが、自分の期待どおりにいかず、いくつか組み合わせを変えて、ようやく、LBが2/10000だけ上がった。

アンサンブルの試行錯誤をやっているときりがない。組み合わせる場合の数は増える一方だ。困ったことに、単独でLBの高いものを上から順に組み合わせても、必ずしもLBが高くなるわけではない。

 

数日前からLBのスコアがかなり上がってきたのは、ノウハウに近いヒントをディスカッションのところでかなり具体的に書いている人がいたからだと思っていた。スレッドの主は、昨日から見かけなくなったし、記事も削除されている。

自分もその記事をヒントに試行錯誤してみたが(768pixelの計算をしたのもその影響)、残念ながら、スコアアップにはほとんどつながらなかった。上位の人たちは、ヒントを生かせる能力があるということだろう。いや、もっと別のことを考えていたのかもしれない。

 

upsamplingとcoarse dropoutに関するノートブックが、8日前から公開されていたようだ。何日か前に、作成者の別のスレッドからリンクが張られていてちょっと見たような気がするが、スコアがよくなかったこともあって、よく見ていなかった。

前作とは違った手法が使われていて、非常に魅力的だと思う。

こういうプログラムが、動かせる状態で、目の前にあるということは、非常にありがたいことである。しっかり勉強させていただかないと、と思う。

 

今の自分には、すぐれたノートを使わせていただくよりほかにメダル圏内を目指す手段はない。使わせていただきながら学ばせていただくというつもりなのだが、中身の理解よりも、パラメータの設定に大半の時間と労力と使っている自分がいやになることがある。そうであっても、この競争に加わらないと、このような高度な技術を駆使したプログラムのチューニングをすることも学ぶ機会も殆どないと思う。

A. GeronさんやF. Cholletさんらのテキストはすばらしいが、テキストを卒業するためには、このレベルのプログラムに、直に接することが重要だと感じている。

 

TTAは20くらいが適切との記事を見た記憶があるが、今日、実験してプロットした結果が投稿されていた。その図面は、TTAが20くらいのところで飽和していた。こういうのは、自分で実験しないといけないな。急がば回れだ。

投稿を探すだけでなく、自ら実験するのだ。少ない画素数で小さいモデルで調べればすぐにわかることだ。画素数依存性とかモデルサイズ依存性などもあると思うが、あらかじめ傾向が分かっていれば、少ない実験点数で調べることができるだろう。

 

明日は、別の公開コードで予測した今日の結果をsubmitしてLBを確認し、それによって、乗り換えるか、元に戻るか、それとも、両方の公開コードで予測した結果をアンサンブルするかを決めようと思う。

なんとしても、0.96の大台に到達するぞ!!!

 

8月4日:あと14日

同じ条件で走らせてもずいぶん事なる結果が得られるようだ。

 

今朝、昨日計算していたモデルをsubmitしたところ、単独モデルでは初めて、LB=0.95+が出た。これを、tabular dataと組み合わせると、LB=0.959+となった。

ならばと思い、TTAとSEEDのみ変えて計算したら、なんと、単独モデルのLBは、0.93+となった。先の例と同じようにtabular dataと組み合わせても0.94+となり、0.950にも届かなかった。

 

その原因を知りたいのだが、TTAとSEEDの2つを同時に変更したのはまずかった。

とりあえず、最初の結果が良すぎるので、それがばらつきによるものかどうか、ばらつきがどの程度のものなのかを知るために、元のTTAとSEEDに戻して、あと2回計算して、計3回の試行におけるばらつきを調べてみることにする。

 

この計算で、TPUの使用時間は30時間に達する。(2回の計算はできないかもしれない。その場合は土曜日の9時を待つ)

このような重い計算に対して、同一条件で、3回繰り返すのは初めてだ。

TPUの時間切れがなければ、明日の午後には結果が出る筈だ。

 

学習曲線のばらつきが非常に大きいことが、スコアに反映されているようである。1回目の計算結果を見たときに学習曲線のばらつきの大きさが気になっていて、SEEDとTTAを変更したときの学習曲線も大きな変動が見られたのだが、さらに、さきほどの初回の条件での計算すると学習曲線が初回よりもさらに大きく変動していることから、大きな変動はupsamplingに起因するものだと推測される。

LBが高ければよいということだけではないので、しばらく、この挙動を追跡してみる。といっても、TPUは残り5時間を切ってしまった。土曜日の午前9時からの30時間は、upsamplingのばらつきを追いかけてみることにする。

 

8月5日:あと13日 

LB=0.959+が、偶然の産物であることがわかった。

 

昨夜同一条件で計算した結果を、前回と同様にtabular dataとアンサンブルし、submitしたところ、LB=0.953+となった。0.006ほど下がったということになる。

再現実験の前に行った、SEEDとTTAを変えた学習の結果は、0.949+であり、この場合は0.01ほど下がったということになる。

コンペの順位争いにおいては非常に大きな数値変化なので、さらに上位を狙うには、計算に使うモデルの性能、データベースの選択、分布不均衡の補正などを加えたうえで、さらに、ばらつきの範囲で上限に近い値を得るためには、計算を繰り返すことが必要になる。

 

TPUの残り時間は、コンペ終了までに、60時間あまりしかない。

仮に、今のモデルが最良だとしても、データの選択とか、エポック数とか、Fold回数とか、学習率のスケジュールとか、それぞれの最適化など、調べたいことはたくさんあるが、これらのうちのほんの一部しか検討する時間はない。

 

さらに、データが集まってくると、アンサンブルにどれを使うか、重みの配分をどうするかという問題もある。

 

偶然得た、LB=0.959+、昨日の朝から今日の16時半までで、すでに30人くらいの人に追い越されている。じっとしていたら、週末までには、メダル圏外に放り出されそうである。したがって、次の30時間のTPU使用によってスコアアップし、0.96+を超えるための方策を考えよう。

 

良い結果を出したモデル、よく見たら、3FOLDすべて、条件が異なっている。したがって、3回から5回くらいは繰り返して、その中から3つくらいをピックアップすることが想定されているモデルのように思う。

よって、土曜日にTPU使用時間が回復したら、5回以上、同じ条件で計算しよう。

極端な話、30時間全てを同一条件で計算し、その中から5つくらい選んだら、もしかすると、0.965越えもあるかもしれない、と期待しよう。

 

8月6日:あと12日 

8月8日の午前9時までTPUは使えない(残り約1時間)ので、アンサンブルの練習をしよう。

旧モデルによる計算結果を生かせないか検討する。

旧モデルからめぼしいものを7つ選んで、平均をとってsubmitしたところ、LBは平均値よりも6/1000だけ大きくなった。

これを新モデルの1つとアンサンブルするのだが、新モデルのLBが5/1000ほど大きいので、アンサンブルの効果があらわれるかどうかわからない。

新モデルの重みを70%にし、旧モデルとの組み合わせをいくつか変えてみたところ、LBが7/10000(7/1000ではない)上がる組み合わせがみつかった。

ここで、本日のsubmission (5回)は終了した。

昨日のアンサンブルはうまくいかなかったので、こんなに(7/10000)上がるとは思わなかった。アンサンブルをいろいろ試すには、5回は少なすぎて、慎重にならざるを得ない。スコアの高い新モデルの割合をある程度大きく保ちながら組み合わせを検討したのがよかったのかもしれない。

 

リーダーボードのスコアがどんどん上がっている。今日は、アンサンブルで少し稼いだつもりだったが、焼け石に水だ。明日には、メダル圏外に押し出されそうだ。

明日もアンサンブルを試してみるが、持ち球があまりないので、苦しいが、5回のsubmissionを生かして、1/10000でも、スコアを上げよう。

 

なんか、急に順位が下がったと思ったら、LB=0.9619に相当するsubmissionファイルが公開されているではないか。これを追い越せ、ということだろう。

このファイルは、誰でも利用できる(もちろんそのままsubmitしてもよい)ので、誰も文句は言わないし、話題にもならない。

何が現れても、それを超える技術を持っている人が、メダルを与えられる資格があるということだと理解しよう。

 

明日は、このLB=0.9619を超えるための方法を考えよう。

 

8月7日:あと11日 

LB=0.9619の予測データのヒストグラムをログスケールで表示してみた。左半分しかない。.describe( )を見ると、最大値が0.5以下になっている。

この分布からは、tabular dataとのアンサンブルは実施済みと推測される。試しに、自分が使っているtabular dataとのアンサンブルを行ってみると、予想通り、LBは殆ど変化しなかった。

このアンサンブルのノートが公開されたため、約100グループが利用したようで、メダル圏内は、0.9619以上となっている。

 

試しに、これを使わせてもらって、自分の最も良い予測結果とアンサンブルしてみると、0.963+になった。これには驚いた。

この0.9619のノートブックは、minmax ensembleと呼ばれている手法を用いているらしく、ディスカッションでも、これを使ってスコアが飛躍的に向上したという記事が投稿されていた。

プログラムコードが公開されていて、具体的にスコアが上がっていて、上位に位置しているのだから、ここから、上位の戦いがさらに激しくなりそうだ。

このminmax ensembleの計算を、自分のsubmissionデータに対して、行えるようになることが上位に行くには必要になりそうである。

 

明日は、TPUが使えるようになるので、計画している計算を進めよう。

さらに、minmax ensembleの計算ができるようにしよう。

アンサンブルの繰り返しの話題が出ていたので、それも試してみよう。

 

8月8日:あと10日 

upsamplingを含むモデルを使っているのだが、3回のLBは、0.945±0.011 となった。

いまのところ、最初が最高値で、今日(同一条件で3回目)が最低値だった。

同一条件の計算を繰り返して、最高値を更新するのを待つよりも、別の条件を順に試していくことにしよう。

uosamplingの効果を実験した結果が紹介され、malignant画像を32%程度まで増やすとAUCが3/1000上昇するという結果が図示されている。それ以上の量ではAUCが下がり、60% まで増やすと3/1000程度下がっている。なぜだろうか。

とりあえず、10%、20%、30%あたりに相当するupsamplingで計算してみよう。

気になるのは、upsampleしたデータでtrainingしていると、途中でAUCが数十%も振れることである。

 

minmaxは、どういう意味があるのか理解できず、放置。

 

しまった、計算中にパソコンの前を離れて戻ったら計算が終了していて、TPUを15分ほど、無駄にしてしまった。

それはともかく、今週は、upsamplingのモデル計算をやり続ける。

月曜日中にはTPU使用時間を使い果たすだろう。

あとは、今回の計算結果をまとめ、アンサンブルに使えるデータを作り上げ、アンサンブルを完成させて、0.967+を目指そう。

 

さらに、来週の土曜日からのTPU使用時間、30時間をフルに使って、やはり、upsamplingの計算を継続し、バリエーションを増やすとともに、偶然にも期待しよう。良い結果が出れば、0.969+を目指そう。

 

何か、良い方法がある筈だ。 

 

8月9日:あと9日  

今日は、アンサンブルの重みを微調整して、LBが、4/10000だけ大きくなった。

適当にアンサンブルしていたので、このくらいの、改善の余地はあったのだろうが、そろそろネタ切れになってきた。

このままでは、0.967+は難しいな。

 

期待しているupsamplingの方は、少しずつ条件を変えながら計算しているが、アンサンブルで手いっぱいだったために、ほとんどsubmitしておらず、LBが不明のままである。

明日から、upsamplingした計算結果のLBを確認する。cvは0.89から0.93の間でばらついており、どうなるかわからない。

 

明日は、5つの溜まっている出力をsubmitするだけでおわりだ。

その結果を見て、アンサンブルするか、さらに計算を続けるかを判断しよう。

まだ1週間以上あるので、さらに上を目指そう。

 

8月10日:あと8日 

昨夜、予測データのヒストグラムの形状とLBの間に何か関係がないだろうかと思って調べてみた。立ち上がり、ピーク、幅などが、種々変化しているのがわかって面白い。スコアとの関係は、画像をCNNにかけてみて、regressionで予測すれば何かわかるかもしれない。まずは、ヒト知能で関係性を把握しようとしたが、何もわからなかった。

この24時間で5番くらい下がったので、ヒストグラムを見ながら思いついたことをやってみたが、全く効果がなく、submitした2回分は、損した気分だ。

LB未確認データ6件のうち、3件をsubmitし、upsamplingの効果の有無を確かめてみた。なんとなく、効果はありそうにみえるが、ばらつきが大きい。

残り1回の計算を、さらにサンプリング量を増やしてやってみることにする。

これで、TPUの30時間を消費してしまうので、明日から金曜日までは、個々のLBの確認、アンサンブルのトライアンドエラーの繰り返しとなる。

upsamplingの効果が、投稿にあるように3/1000程度あれば、上位にくいこめるかもしれないが、仮に単独で3/1000の効果があっても、アンサンブルの重みが1/6だとすると、効果は5/10000程度になる。これでも上がればうれしいのだが・・・。

 

ヒストグラムの平均と標準偏差とAUCを散布図にすると、AUCは、平均と標準偏差に対して相関がありそうにみえる。結果としてそういう傾向が認められるというだけのことなのか、この関係を利用して、後処理でAUCを高くすることが可能なのかはわからない。今日の最初の2回のsubmitは、直観的に気づいたこの予想にしたがって行ったものである。与えた変化幅が小さかったためなのかどうかわからないが、プラスにもマイナスにも変化しなかった。直観だけではなく、数式を用いて議論できないとだめだな。

 

TPUの残りの時間で、次の準備として、B6-512pixelの計算の時間計測を行った、いつもは、明らかにオーバーする場合は警告が出ると止めていたのだが、今回は、試しに計算継続ボタンを押してみたら40分くらいオーバーして、計算は終了した。

commit中に同様の状態になった時、詳細は忘れてしまったが、結局保存できずに終わってしまい、合計で5時間以上のロスをしたことがある。

ともかく、512pixelでも計算できることがわかったので、今週土曜日は、これにかけてみるか。upsamplingのデータ数が多すぎると3時間の制限時間をオーバーしてしまうので、要注意。

 

8月11日:あと7日

ヒストグラムの平均値と標準偏差を参考にして、ハイスコアのアンサンブルの変更を試みたが、改善ナシ。

upsampleの計算結果を3件submitしたが、昨日のmaxには及ばず。さらに、ヒストグラムの平均値や標準偏差とLBの相関性は、この3件に関しては、殆ど認められなかった。

 

あと3日間は、ひたすら、アンサンブル。

 

8月12日:あと6日  

午前9時にsubmissionができるようになることが待ち遠しくて、9時前から計算を始めるのだが、10時前には、5回のsubmissionを終えてしまう。

それでもスコアが上がればいいが、過去2日間は、上がっていないので、順位がじりじり下がっていくのを眺めているだけである。

あと何日あるとか、あと何回あるとかを考えるにしても、プランがあって、計画的に進めているならよいが、ちょっとした思い付きでやってみてダメなことが多い。

今日は、submittの間隔を少なくとも1時間はとることにしよう。

思い通りにならないと、すぐに、次の作業をやってしまうのだが、1つの結果が出たら、次の計画は、必ず見直すようにしよう。まず予想があり、結果が出て、予想と結果から、事前の次の予定を見直すほうが良いことの方が多いはずだ。もちろん逆もある。全体計画をきちんと進めておかないと、駒が不足して戦えなくなることもある。

最少の試行回数で最大の効果を得る方法があるはず。

たとえば、ここに、アンサンブル用の4つのデータがある。

個別LBの比較から、この4つのデータに追加するには性能が不足している新たなデータがあるとしよう。

1つの方法としては、4つのデータに対して、新しいデータを、個別に、或る割合で配合してLBを算出する。これだけで4回、submitする必要がある。次に、新たに得られた4つのデータのうち、LBが上がったデータのみ差し替えて、4つのデータのアンサンブルをsubmitする。これで5回のsubmitとなる。

もし、今、submitは残り5回ではなく、残り1回だとしたら、どうするだろうか。

あるいは、5回のsubmitをもっと効果的に使う方法はないのか。

いまやってるアンサンブルは、出力データの線形結合だから、個別に計算して最後に合算するのも、最初から合算するのも同じではないのか。

4つのデータに対して、LBが最大化する配合比が、0.1, 0.1, 0,2, 0.2だったとする。元の配合比が0.1, 0.2, 0.3, 0.4だったとすると、新しいデータの配合割合は、0.01+0.02+0.06+0.08=0.17となる。個別に効果がどれだけあるかを計算(確認)してから合算するのも、最初からその割合で5番目のデータとして追加(配合割合0.17)するのも同じということかな。

もし、新しいデータが、元のデータのどれかに対してマイナスに作用するなら、それは、プラスに作用したものだけ置き換えて合算したとしても、マイナスの影響は他のデータに及ぶので、4つのデータのうち、効果があったデータだけ置き換えても、4つのデータをアンサンブルすると、どれかのデータに対して負の効果があるなら、その負の効果は自然に導入されてしまう。

以上の考察が正しければ、個別に計算してから導入することと、最初から5番目のデータとして導入することは等価である。

そうであれば、新しいデータを、5番目のデータとして加えることとすれば、その効果は、配合比を変えればすぐわかり、5回のチャンスを有効利用できる。

 

1回目:ちょっと気になっていた(気になるとのメモ書きあり)アンサンブルを試した。しかし、無駄だった。何を今さらって感じだった。

2回目:upsampleのデータを、5番目のデータとしてアンサンブルしてみた。配合割合が0.05となるように加えた結果、2/10000、上がった。

3回目:元の4つのデータの配合比で気になるところがあったので、変えてみた結果、1/10000、上がった。

しまった、約40分の間に3回もsubmitしてしまった。

5回のsubmissionを有効に使うためには、1時間以上の間をとって、冷静になって頭を使わないといけないと思ったのだが、・・・。

4回目:2回目の続き:元の4つを1つにまとめてあるので、2回目は、元の4つを合わせて0.95、5つ目のデータを0.05にした。元の4つのデータで最も割合を多くしているのは0.5である。次に0.90対0.10にすると、最も割合が高データは0.45で、5番目のデータが0.1となり、この2つのデータの比率は90:20となる。元の4つのデータで最も割合が小さいものは0.1だったので、これと比べると0.09:0.10となって、5番目のデータの割合の方が高くなる。ということで、少しの変動のつもりが、大きな変動になる。

ちょっと大きいかなと思いつつも、5番目のデータの割合を0.10にしてsubmitした。その結果、スコアは変わらなかった。

5回目:最大値を探すには、0.15の値が欲しいところ。明日、0.15のLBを見て、0.05と0.10の間で最大になりそうな数値を推定すればよいのだが、明日は、5番目のデータを、6番目以降のデータとアンサンブルして、もう少しスコアが上がるかどうか検討する予定にしているので、ここは適当にすませよう。

ということで、中間の0.075で計算してsubmitした。幸運にも1/10000上がった。

以上、今日はLBが4/10000、も、上がった。

 

明日は非常に難しい課題となりそうだ。

残りの8件のデータのアンサンブルで、今日の5番目のデータのLBにどこまで迫れるか。同レベルまで近づけば、今日の半分、2/10000のスコアアップが期待できるかもしれない。

 

 8月13日:あと5日  

1回目:8件のデータのアンサンブル:5番目のデータに及ばなかった。これでは次のステップに進めない。8件のデータを平均しただけだが、やはり重みづけしよう。

2回目:8件のうちの1件は、LBを調べていなかったので重みを与えられない。データがすべてなので、放置していたのはまずかった。単独のLBを調べるためにsubmitする。結果は、8件の中では最も低いスコアであった。

3回目:8件のLBスコアを見ながら重みづけしてsubmitしたが、まだ離れている。

あっという間に、3回ぶん消化。

4回目:5番目のデータとアンサンブルして、LBが1/1000上がれば、最終結果が1/10000以上上がることが期待される。結果は、4/10000の増加にとどまった。

5回目:5番目のデータと置き換え、昨日の最適条件でsubmitしたところ、最終スコアは2/10000下がった。わずかとはいえ、アンサンブルすることによってスコアが上がったので、トータルスコアも上がる筈だと思ったのだが、かえって下がったのは腑に落ちない。原因究明が必要だ。

可能性が高いのは、アンサンブルの結果、tabular dataとの組み合わせの割合(個々の出力データとtabular dataとの比率)の変化だと思う。アンサンブルで予期せぬ改善や改悪が生じるのは、出力データ間の相互作用(互いに常にプラスに作用するとは限らない)にも関係しているように思うのだが、確かなことはわからない。

予測データのヒストグラムの違いをみていると、ピーク位置を合わせて平均化したり、立ち上がり位置を合わせて平均化したり、実験してみたいことはいろいろある。

それよりも、ネットワークが画像から抽出している特徴量が、melanomaを正しく判定できる(専門家の判定のごとくに)ものなのかどうかも気になる。スコアが高ければ正しく把握出来ているということなのだろうけど。

 

discussionに良くない知らせがある。Kaggle KernelのTensorFlowがバージョンアップされ、それによって、TPUでTensorFlowコードを実行するとエラーが発生するようだ。Google Colabでも同様の事象が生じ、そちらは、TFのバージョンを戻すことで、解決しているようだが、Kaggle KernelのTensorFlowのバージョンを戻すことは、いまのところできないらしい。

土曜日から使えるTPUでの計算に期待しているので、その時までに状況が改善されていることを願う。

さもなければ、これ以上のスコアアップの可能性は、非常に低い。

 

 8月14日:あと4日 

今日のsubmission予定:5番目のデータを作るときの割合を変えてみる:全体への効果は1/10000レベルと予想しているので、試行は1回のみとする。

元の4つのデータの配合比を変えてみる。上位2件のデータの割合は、余り動かしていない。4回のチャンスがある。明日からの計算で良い結果が出なければ、手持ちのデータの組ア合わせで最後まで戦うことになるので、4回の試行は、少なくとも相対的な寄与が明確になるように変化させてみる。

1回目:トップデータの割合を4/3倍にしたところ、1/10000、増加した。これだと最終結果の寄与、この1/10程度と予想されるので、これ以上追求しない。

2回目:元の4つの中のトップと2番目の割合にのみ着目する。トップを上げてみる。1/10000下がった。

3回目:トップを下げてみるしかない。1/10000下がった。

まいった。次の手がない。

 

Kaggle KernelのTFがダウングレードされて、TPUの使用は一昨日以前の状態に戻ったようだ。使えるようになったのはありがたい。

しかし、どの計算をすれば良いcvが得られるのだろうか、

cvスコア、LBスコアと、計算条件(使うデータベース、TTA数、augmentation)を変えても、その効果を判断できるようなデータが得られない。繰り返し再現性が悪い。エポック毎に全てのパラメータを保存しておいて、val_aucの良い物だけをピックアップして予測データをアンサンブルするということでもしないと、当たりくじが出るのを待つだけ、何位になるかは偶然が支配する。

 

もっとも、今のスコアが得られたのは、まさに、その、偶然のなせる業である。

同一条件で3回計算して、cvの最小と最大の差が22/1000もあったのだ。このときの最大値のおかげで、現在、そこそこの順位にいるわけである。

しかもそれがupsamplingに対応した公開コードを使わせていただいて最初に得られた結果であった。そのあとは、TTAの効果、upsamplingの効果、Coarse Dropoutなどの効果によるさらなるスコアアップを期待していたが、最初の結果を凌ぐデータは得られなかった。残り物みたいな感じて、残りのデータを重みづけしながらアンサンブルしても最初のデータのcv,LBに2/1000ほど、届かなかった。

以上は全て384pixelでの結果だったので、512pixelのデータと合わせればスコアが上がるかなと思っている。

シナリオ1.最初に512pixelで計算する。この値が、同条件での384pixelの平均値より高ければ、以降は、512pixelで計算し、そうでなければ、384pixelと512pixelを1回の計算の中でmixしよう。

ダメもとで、最初から、384と512のmixでもいいかな。

 

 8月15日:あと3日 

このコンペもあと三日で終了する。

 

良い予測モデルを得るための条件は何だろう。

テストデータを正確に評価するためには、評価方法を正しく学ぶことが必要である。

評価方法を正しく学ぶためには、良い訓練データが必要である。

今回のテーマを現実に即して考えると、専門家ができることは必ずできること。

専門家ができないことは、できなくてもよいが、少なくとも、専門家の助けになるような結果は出せるようにしたい。

コンペに欠けている視点があるとすれば、正しく診断するのが困難なテストデータを見分けることではないだろうか。識別困難な画像は別に扱う方が良いと思う。

そうではないかもしれない。

識別困難な画像を識別しやすくすることもモデルの機能として含んでいるとしよう。

TTAはその機能の一部を強化するために使われているとみなすことができる。

augmentationも、その機能を担っているということだな。

discussionで、GANを用いたaugmentationが話題になっていたな。

 

公開モデルを見ていて思うのだが、モデルは、たった11行で記述されている。

自分でモデルを考えて何とかなる世界ではない。トップレイヤーも超簡単だ。

これに比して、augmentationに40行くらい、coarse dropoutに20行弱、train schedule(learning rateの設定)に20行弱、費やしている。

 

B6-512pixelの計算結果が出た。LBは低くて使えそうにない。

あとは、B6-384pixelに戻して、高い方にばらつくのを待つだけ。

B6-384もだめだった。さらに低いLBだった。

再度B6-512を計算した。すこしましだが、まだ、LBが低い。

メダル圏外に押し出されるのを待つだけというのも情けないものだな。

 

 8月16日:あと2日  

計算は、今日の24時に終了予定だ。最後は、B5-512pixelで締めようかな。

B6-512を昨夜commitしてたら、回線の調子が悪かったのか、計算時よりも時間がかかって、2h58mかかったということもあって、B5-512で締めようと思う。あとは、運。

0.950に近いモデルがいくつできるかが、最後のランクアップの可否を決める。

 

B4,5,6-512で、かなり良いスコア(LB=0.952)が得られた。

512pixelで単独でLBが0.95+となったのは、はじめてだ。

もう1回、0.95+が現れてくれたら、トータルスコアで5/10000くらいのアップが期待できるのかもしれない・・・。

これも、並外れて優れた公開コードのおかげだ。

 

ちょっと条件かえた512pixel、よくなかった。commitの際に20分ほど余計に時間がかかった。ネットワークの不調か、過負荷か。

TPUの残り時間を考え、512pixelで、さらに少し条件を変えて計算したが、LBはよくなかった。

最後は、残り時間を考えて、B5-512について計算している。

これで、今回のコンペのDNNの計算は終わりとなる。

 

8月17日:最終日(日本時間:明日の午前9時00分終了)

最後の30時間の成果を適当にアレンジしてtabular dataと合わせてみたが、平凡な結果となった。

公開コードを活用させていただいて、メダル圏内に入ることができた。このまま大きな変動なく終了することを期待して待つ。

 

今回は、少しは上位が見える位置にいたので、最終日が近づくにつれて、種々の変化が生じているのがよくみえた。

ハイスコアのノートブックの投稿も気になったが(つまみ食いもしたが)、それ以上に、投稿数も実績もないヒトが、ハイスコアで、かつ、同じスコアで数名並んでいるのが奇妙であった。

なにはともあれ、これで終了だ!

 

次は、鳥の囀りか、肺の診断か。

いずれにしても、もっと勉強して、プログラミング技術を向上させないとだめだな。

 

8月18日:午前9時00分終了

結果が出ました。

見事に、メダル圏外に放り出されました。

最後に3つのモデルを提出することができたのだが、

3つとも、スコアに執着したのが敗因ですな。

この最終提出モデルをどういうふうに選択すればよいかを、

時間をかけて冷静に考えるべきだったな。

声高にCVを信用しろと叫んでいた人たちの勝利でした。

 

結論は、プログラムを作る人になれ!、ということです。

それにしても、Chris Deotte氏のプログラムは、完璧だった。

 

8月22日追記:Chris Deotte氏のプログラムの出力のみをアンサンブルしたもの(B6-384pixelとB6-512pixelのアンサンブル)は、銀メダル相当であることを確認した。

最終提出物を冷静に判断していたとしても、public scoreにあれほど大きな違いがあると、やはり、選ぶことはなかった(メダル圏外に入ることはなかった)だろうと思う。

これが、現実だ。

さらに、単独で、public LBの高いものが現れた時にそれに飛びついたことも反省材料だ。

まとめると、public test dataにoverfittingすることに夢中になっていた(public LBを追い求めていた)自分には、メダル圏外への道しかなかったのだ。

 

 

f:id:AI_ML_DL:20200723211109p:plain

style=151 iteration=1

f:id:AI_ML_DL:20200723211208p:plain

style=151 iteration=20

f:id:AI_ML_DL:20200723211259p:plain

style=151 iteration=500