Kaggle散歩（September 2020）

9月のKaggle散歩

9月1日

8月17日にSIIM-ISIC・・・が終わり、翌日から、OSIC・・・に取り組んでいる。

これまでは、一定の期間に1つのコンペを選んで取り組んできたが、結果が出ずに、リーダーボードに載ることなく終わったものが多い。リーダーボードに載ることが目的ではないとはいえ、結果が残らないよりは残ったほうがよい。何よりも、途中で投げ出すと、他の人の解法に学ぶことも少なく、スコアアップのための重要な技術を学ぶこともなく、結局、得るものも少ない。

ということで、1週間くらい前から、いろいろなテーマに取り組んでいる。公開コードを利用してリーダーボードに載ることからスタートしている。ということで、今は、締め切りの無いもの、メダルに関係ないものを含め、12件がactive conpetitionとして表示されている。このうちの2件はゲームで、参加することを躊躇したが、Reinforcement Learningを学ぼうとすると必ずゲームが出てくるし、2件のゲームコンペのnotebookをreinforcementで検索すると、実際に、reinforcement learningに関する公開コードが出てくるので、ゲームにも取り組むことにした。

noisy studentを調べてみた。

model = eff.EfficientNetB0(weights='noisy-student')

論文にざっと目を通してみた。

https://arxiv.org/abs/1911.04252

Self-training with Noisy Student improves ImageNet classification

GitHubに効果と使い方が示されている。

https://github.com/tensorflow/tpu/tree/master/models/official/efficientnet

We have provided a list of EfficientNet checkpoints:.

• With baseline ResNet preprocessing, we achieve similar results to the original ICML paper.
• With AutoAugment preprocessing, we achieve higher accuracy than the original ICML paper.
• With RandAugment preprocessing, accuracy is further improved.
• With AdvProp, state-of-the-art results (w/o extra data) are achieved.
• With NoisyStudent, state-of-the-art results (w/ extra JFT-300M unlabeled data) are achieved.

Kaggleの競争に勝つためには、最新技術をコンペのテーマに合わせてうまく取り込むことが必要であるらしい。

9月2日（水）

Cornel Birdcall Identificationというコンペに参加している。公開コードを利用させてもらっている。本音は、あわよくば、メダルを獲得したいということである。

コンペに参加すれば、最低でも、鳥の鳴き声から、機械学習によって、鳥の種類を見分けることができること、そのために必要な、データベースが存在すること、さらには、使われている機械学習の種類などを知ることができる。

こんな総説がある。

Deep Learning for Audio Signal Processing 

Hendrik Purwins∗, Bo Li∗, Tuomas Virtanen∗, Jan Schlüter∗, Shuo-yiin Chang, Tara Sainath

JOURNAL OF SELECTED TOPICS OF SIGNAL PROCESSING, VOL. 13, NO. 2, MAY 2019, PP. 206–219 

まあ、こんなたいそうな文献よりは、目の前にあるコンペの公開コードやディスカッションに目を通すことのほうが、具体的で、理解しやすい。

気になるキーワード：

Sound Event Detection (SED)

chunk level detection, clip level detection

segment-wise prediction

2D CNN based model, CNN feature extractor

log-melspectrogram

librosa

気になる論文

PANNs:Large-Scale Pretrained Audio Neural Networks for Audio Pattern Recognition

Qiuqiang Kong, Student Member, IEEE, Yin Cao, Member, IEEE, Turab Iqbal,
Yuxuan Wang, Wenwu Wang, Senior Member, IEEE and Mark D. Plumbley, Fellow, IEEE

こういうのを並べてみると、とても、自分でどうにかするというレベルのものではなく、そういうのを、遥かに超えていることに気付くべきであろう。

ということは、オープンソースをいかに使いこなせるか、ということが重要なのである。ゼロから作ることにこだわると、かえって、時代に取り残されることになる。

9月3日（木）

Google Landmark Recognition 2020に参加している。

2018、2019に続き、3回目とのことだが、通常の物体認識とは違うようだ。

81000クラスあり、クラスあたりの画像枚数に大きな偏りがある。

Google Landmarks Dataset v2
A Large-Scale Benchmark for Instance-Level Recognition and Retrieval
Tobias Weyand ∗ Andre Araujo ´∗ Bingyi Cao Jack Sim Google Research, USA
{weyand,andrearaujo,bingyi,jacksim}@google.com

Unifying Deep Local and Global Features for Image Search
Bingyi Cao? Andr´e Araujo? Jack Sim
Google Research, USA
fbingyi,andrearaujo,jacksimg@google.com

このコンペに参加したのは良いけど、ホストが用意したbaseline exampleコードを使ってsubmitするしかないような感じ。

チューニングするだけで終わるかもしれないが、最低でも、関連論文２，３編には、目を通して、パラメータの意味を把握しよう。特に、RANSACパラメータ。

9月4日（金）

Halite by Two Sigmaに参加している。

対戦型ゲームで、ルールを読んで覚えるのもしんどいなと思った。

ルールを覚えたところで、何か役に立つわけでもないしと思った。

A. GeronさんのテキストでReinforcement Learning (RL)を学ぼうとしたら、ゲームが出てきて、いやになっていたのだが、ここでもまた、RLとゲームがセットになっていた。

RLを学ぶにはゲームは避けて通れないのだろうと思い、RLを学ぶことを目的に、このコンペに参加することにした。

このコンペは、tutorial notebookだけでなく、Intro to Game AI and Reinforcement LearningというLessonまで用意されている。このLessonは、Connect Xの立ち上げのときに作られのではないだろうか。

ということで、Lessonをほんの少しかじって、Tutorial Notebookを使ってsubmitして、公開コードを使ってsubmitして、ということをやっていた。

RLを学ぶために参加したはずなのに、借り物競争に夢中になっている。

次のステップへ。

まずは、Reinforcement Learningのレクチャーから学ぼうと、腰を落ち着けて読み始めてみたところ、事例は、Haliteではなくて、Connect X であった。Haliteを事例にするのはさすがにまずいか。

ところで、8か月ほど前に、Connect Xのコンペ（Knowledge) がセットされたようであり、その概要には、Reinforcement Learningに関して、次のように書かれている。

Background History

For the past 10 years, our competitions have been mostly focused on supervised machine learning. The field has grown, and we want to continue to provide the data science community cutting-edge opportunities to challenge themselves and grow their skills.

So, what’s next? Reinforcement learning is clearly a crucial piece in the next wave of data science learning. We hope that Simulation Competitions will provide the opportunity for Kagglers to practice and hone this burgeoning skill.

ということで、Kaggleのコンペは、すべて、食いつこう。

9月5日（土）

新たにコンペが立ち上がった。早速参加しよう。

Mechanisms of Action (MoA) Prediction

Can you improve the algorithm that classifies drugs based on their biological activity?

If successful, you’ll help to develop an algorithm to predict a compound’s MoA given its cellular signature, thus helping scientists advance the drug discovery process.

薬剤候補物質の特徴量は、記号で表現されているだけなので、考える余地がないように思うのだが、機械学習は、本来そういうものかもしれない。

公開コードでsubmitしてみたら、トップテンに入ってびっくり。まだ2日目だからな。あっという間に、下がっていくんだろうな。というか、今なら、一瞬でも、トップに立てる可能性があるということだ。どうせ最後はメダル圏外。ならば、今のうちに、頑張ってみようか。

と言ってる間に、３つ下がった。

ああっ、自分のスコアを上回るコードが、1時間前に、公開されている。

さらにもう１つ、自分のスコアを上回るコードが公開された。

これで、明日は、一気に順位が下がって、トップが、はるか彼方に行ってしまいそうだ。

9月6日（日）

MoAコンペの続き：計算回数を増やして平均とっただけでは殆ど改善されなかった。

ここで、Kaggleコンペの取り組み方について検討しよう。

現状：

１．Overviewに目を通す。

２．NotebooksをEDAで検索し、マスター以上の方もしくは、EDAで定評のある方のNotebookから、データベースの詳細、課題解決の手段等について学ぶ。

３．NotebooksをBest Scoreでソートし、スコアが高く、かつ、マスター以上の方のNotebookに、ざっと目を通し、オリジナルか、全コピーか、一部コピーか、セルごとに説明もしくは注釈が付いているか、構成がわかりやすいか、コードが整然と配列されているか、変数名は一般的な名称が使われているか、理解しやすいか、などを考慮して、自分に合う、適切なNotebookを選ぶ。

４．フォークして、そのままRunするか、明らかに仮の値が入っているパラメータ等を変更して、Run、Commit、Submitする。

５．パラメータを変更して、スコアアップを図る。

改善したいポイント：

　スコアアップは、フォークしたnotebookのパラメータの変更によってのみ行うのではなく、フォークしたnotebookを、改造することによっても行えるようになることが必要である。

　フォークしたnotebookを改造するためには、課題とデータベースを正確に理解すること、および、フォークしたプログラムの構成を理解し、過不足を判断できることが必要である。

　そのために、機械学習とディープラーニングをテキストを使って勉強しよう、というのではなく、Kaggleを最大限活用する。すなわち、discussionの全てに目を通し、notebookの全てに目を通し、そこで紹介されている文献を理解し、そこで引用されているGitHub等のコードを理解し利用する方法を学び、実際に利用してnotebookに組み込むことである。と、意気込んでみる。

MoAコンペのDiscussionに学ぶ：

metricの議論、よくわからん。Hinge loss, Focal loss？？？

tabular data competitionに対するアプローチといっても様々。XGBoost, LightGBM, Catboost, and NN？？？

Abhishek Thakur氏による当該コンペの取り組みのビデオレクチャーが行われるとの紹介記事が掲載されている。

そのレクチャー中に作成されたnotebookが公開されているので、それに学ぼう。

9月7日（月）

Lyft Motion Prediction for Autonomous Vehicles - Build motion prediction models for self-driving vehiclesに参加した。

提供されるデータ量が膨大で多岐にわたる。

baseline modelが提供される。

安全で効率的な運転はヒトでも容易ではない。しかし、受け取る情報量はヒトよりも多いので、ヒトよりも安全に、かつ、効率的に運転できる可能性はあると思う。

PN社の方が、わかりやすく、かつレベルの高いEDAと解析コードを公開されているので、学ばせていただこう。

コードの学習が進まないので、次の手を考える。

１．自前のEDAコードを作成する。

２．自前の解析コードを作成する。

ゼロから自前で作る必要はない。お手本を探して、真似すればよい。

手入力の必要もない。コピペでもなんでもよい。

わかりやすいように、編集しなおせば良い。

これで、1ミリでも前進できれば良い。

締切の近いコンペから始めよう。

まずは、Cornell Birdcall Identification - Build tools for bird population -

ほんの1部分をやってみた。

それでも、確実に、1ミリ以上、前に進んでいることを実感できる。

ハイパーパラメータなどは、変数にしてまとめておけば、チューニングに便利だし、結果も記入していけばよい。

9月8日（火）

Cornell Birdcall Identification

周波数が高いbirdcallを聞き分けるために、音響情報を2次元画像にして、CNNなどで分類しているようである。画像としての解像度が不足しないために必要な画素数はどの程度必要なのだろうか。

9月9日（水）
Cornell Birdcall Identification

まだ終わってないけど、次に備えて、trainからinference, submissionまでの流れを学ぼう。

Radek OsmulskiさんのESP Starter Pack - from training to submission

に学ぶ。

最初に、train_dataのpreprocessingを行なっている。mp3データを、spectrogramに変換して、データセットを作成しているのである。オリジナルのコードを作成する方々の多くは、フォーマットや画素数を変えたデータセットだけでなく、External DataやPre-Trained Modelのパラメータを保存するためにもKaggle Datasetを作成している。

External DataやPre-Trained Modelは、コンペの公平性を保つために、情報を共有することになっていて、具体的な情報をコンペ毎に申告することになっている。

External_DataとPre-Trained Modelによって、結果は全く異なるということを知っているだけではだめで、具体的に実行できなければならない。

新しくnotebookを立ち上げ、コードをコピペしてから、手を加えようとしているのだが、コンペのデータセットの他に、4つのデータセットが使われている。データセットは、直接コピペできないので、自分のnotebookに追加する。

mp3データを、spectrogramに変換するために、GitHubにあるコードを利用し、さらに、spectrogramを解析するために必要なコード等もGitHub等からダウンロードして利用しているようである。

コードを1行づつ理解しようと思っても、たとえば、その、spectrogramへの変換コードとそれに付随するコード、そこには、さまざまなツールも使われていて、容易には理解することができない。

ということは、class単位、def単位で、ツールとして使うしかないのだろうと思う。

データベースと前処理（音声データの画像化）ツールの準備ができたら、モデルの訓練コードを作る。

ここで作者はPyToechを使っている。

pretrained resnet 34をベースに使っている。

全部写しとって、動作確認して、40分程度走らせてみたが、ほとんどnocallであった。

この公開コードは、シンプルなモデルであって、全体の流れはわかりやすい。

だが、最近の進歩に追いつかないといけない。

たとえば、

The contribution of this work includes:

(1) We introduce PANNs trained on AudioSet with 1.9 million audio clips with an ontology of 527 sound classes;

(2) We investigate the trade-off between audio tagging performance and computation complexity of a wide range of PANNs;

(3) We propose a system that we call Wavegram-Logmel-CNN that achieves a mean average precision (mAP) of 0.439 on AudioSet tagging, outperforming previous state-of-the-art system with an mAP 0.392 and Google’s system with an mAP 0.314;

(4) We show that PANNs can be transferred to other audio pattern recognition tasks, outperforming several state-of-the-art systems;

(5) We have released the source code and pretrained PANN models.

音声のpretrain_modelを用いて、かつ、最新の研究成果を取り入れることによって、上位に進出することができる。
オリジナリティーとクオリティーの高いnotebookにおける質疑応答は、ついていけないことが多いが、雰囲気が味わえるだけでも楽しいし、やるべきことがはっきりと見えてくるところがよい。

はやく、このレベルの人達の仲間に入れるように、なりたいものだ。

9月10日（木）

新しいコンペが２つ始まった。１つはドローンで、もう1つはゲームだ。

9月9日開始：Hash Code Archive : Drone Delivery - Can you help the drone delivery supply chain?：これは機械学習ではなく、最適化、とのこと。最適化の課題にはまだ取り組んだことが無いので、面白いかも。サンタシリーズが最適化の課題らしい。

9月2日開始：Conway's Reverse Game of Life 2020 - Reverse the arrow of time in the game of life

ルールを読んでも理解できない。頭が固まってしまったのだろうか。

9月11日（金）

Conway's Reverse Game of Lifeの続き。

このReverseの意味が分からない。

困った時のウイキペディア、といこうか。

ライフゲーム (Conway's Game of Life^[1]) は1970年にイギリスの数学者ジョン・ホートン・コンウェイ (John Horton Conway) が考案した生命の誕生、進化、淘汰などのプロセスを簡易的なモデルで再現したシミュレーションゲームである。単純なルールでその模様の変化を楽しめるため、パズルの要素を持っている。

生物集団においては、過疎でも過密でも個体の生存に適さないという個体群生態学的な側面を背景に持つ。セル・オートマトンのもっともよく知られた例でもある。

ライフゲームのルール[編集]

ライフゲームでは初期状態のみでその後の状態が決定される。碁盤のような格子があり、一つの格子はセル（細胞）と呼ばれる。各セルには8つの近傍のセルがある (ムーア近傍) 。各セルには「生」と「死」の2つの状態があり、あるセルの次のステップ（世代）の状態は周囲の8つのセルの今の世代における状態により決定される。

セルの生死は次のルールに従う。

誕生

死んでいるセルに隣接する生きたセルがちょうど3つあれば、次の世代が誕生する。

生存

生きているセルに隣接する生きたセルが2つか3つならば、次の世代でも生存する。

過疎

生きているセルに隣接する生きたセルが1つ以下ならば、過疎により死滅する。

過密

生きているセルに隣接する生きたセルが4つ以上ならば、過密により死滅する。

下に中央のセルにおける次のステップでの生死の例を示す。生きているセルは■、死んでいるセルは□で表す。

ライフゲームの基本ルール

誕生	生存（維持）	死（過疎）	死（過密）

ウイキペディアでは、さらに具体的な例が、たくさん掲載されている。

もう少しだけ再掲しておこう。

パターンの例[編集]

ライフゲームでは世代を経ることで最終的に死滅する図形もある。

生き延びる場合の変化は4パターンに分類することができる。

• 固定物体は世代が進んでも同じ場所で形が変わらないものを指す。
• 振動子はある周期で同じ図形に戻るものを指す。
• 移動物体は一定のパターンを繰り返しながら移動していくものを指す。
• 繁殖型はマス目が無限であれば無限に増え続けるパターンである。

コンウェイは「生きたセルの数が無限に増えつづけるパターンはありうるか」という問題に50ドルの懸賞金をかけた。コンウェイ自身は、そのようなパターンとして「周期的だが次々にグライダーを打ち出すもの」や「移動しながら通過した後に破片を残すもの」の存在を予想し、前者を「グライダー銃」、後者を「シュシュポッポ列車」と呼んだ。1970年11月、ビル・ゴスパー（英語版）らは、初めてグライダー銃の具体例を挙げて賞金を獲得した。後にシュシュポッポ列車の具体例も与えられている。繁殖型としては、移動しながらグライダーを打ち出す「宇宙の熊手」(space rake) と呼ばれるものや、四方に向かって成長する「マックス」と呼ばれるものなど、様々なパターンが見付かっている。

4つの分類における単純な例を以下に示す。

「ライフゲームの物体一覧」も参照

固定物体の例[編集]

ブロック	蜂の巣	ボート	船	池

振動子の例[編集]

周期が2で発生しやすい振動子には以下のようなものがある。

ブリンカー	ヒキガエル	ビーコン	時計

ちなみに周期が3以上のものでは、以下のようなものがある。

パルサー	八角形	銀河	ペンタデカスロン

移動物体の例[編集]

グライダー	軽量級宇宙船	中量級宇宙船	重量級宇宙船
		⬜️⬜️⬜️⬛️⬜️⬜️ ⬜️⬛️⬜️⬜️⬜️⬛️ ⬛️⬜️⬜️⬜️⬜️⬜️ ⬛️⬜️⬜️⬜️⬜️⬛️ ⬛️⬛️⬛️⬛️⬛️⬜️	⬜️⬜️⬜️⬛️⬛️⬜️⬜️ ⬜️⬛️⬜️⬜️⬜️⬜️⬛️ ⬛️⬜️⬜️⬜️⬜️⬜️⬜️ ⬛️⬜️⬜️⬜️⬜️⬜️⬛️ ⬛️⬛️⬛️⬛️⬛️⬛️⬜️

繁殖型の例[編集]

グライダー銃

なかなかおもしろそうだな。

さらに、ウイキペディアには、次に様な記述もある。

バリエーション[編集]

オリジナルのライフゲーム以外にも様々な新しいルールを考えることができる。

周囲に3つの隣人がいれば生命が誕生し、周囲に2つか3つの隣人がいれば生き残り、それ以外の場合では死ぬというルールである標準のライフゲームを23/3と表す。最初の数 (2,3) は生き残るために必要な数を表し、次の数 (3) は生命の誕生に必要な数を表す。従って16/6は、「1つあるいは6つの隣人がいれば生き残り、6つの隣人がいればセルが誕生する」ことを意味する。

バリエーションの中では、23/36が有名である。HighLifeと呼ばれ、オリジナルのルールに加えて、6つの隣人がいれば誕生するというルールを付け加えたものである。 また、一般的なライフゲームでうまくいかない点を研究するために、3-4Life (34/34) などの変則ルールが多数作られている。

また、「2次元平面とムーア近傍」以外の空間における、類似したルールによるセル・オートマトン、といったものも考えることができる。^[2]

ライフゲームを用いた計算機[編集]

ライフゲームはチューリング完全であり、チューリングマシンと同等の計算能力を持つ。これは、ライフゲームのパターンで計算機を形成し、その上でプログラムを実行する事が可能である事を示している。

計算機を構成するために必要な要素として、グライダーなどのパターンの組み合わせでAND、OR、NOTなどの論理ゲートを構築できる。グライダーを利用することで他のオブジェクトとの相互作用を得られる。例えばブロックを近くに運んできたり遠くへ移動させたりすることができる。この移動機構はカウンタとして利用できる。

他にも様々な計算能力を持つパターンが発見されている。素数/乱数生成器や、ライフゲームを用いてライフゲームを計算する "Unit cell" などは、実際に動作する計算機としてのライフゲームの例である。

さて、コンペの内容に戻ろう。

ある時点のパターンから、何ステップか前のパターンを推測するモデルを作り、テストデータとステップ数から、推定したパターンを出力して提出する。このコンペのタイトルにあるreverseは、時間を逆転する、すなわち、何ステップか前のパターンを予測せよという意味で名付けられたのだろう。

もし、このゲームのパターン生成方法を正しくコーディングできれば、正解できるわけだが、それはこのコンペの目的ではないだろう。

このコンペは、異なる時点のパターンとステップ数の50000組のデータから、パターンとステップ差の関係を学習し、与えられたパターンとステップ差から、パターンを予測する。このとき行う学習は、座標変換方法を直接学習するのではない。あるパターンから何ステップ戻るとどういうパターンになるかを、train_dataから機械学習（NN系）を用いて学ぶのだろう。

足し算の問題と結果の組を与えて、NNに学習させて、NNに足し算をさせるのと同じで、足し算の規則を直接予測するのではなく、規則を教えずに、教師データから、規則を使った場合と同等の結果が得られるモデルを作ることが目的である。

説明が、ちょっと、くどかったかな。

ということで、やっと、このコンペの内容が分かったような気がする。

9月12日（土）

また新たなコンペが始まったようだ。

RSNA-STR Pulmonary Embolism（肺塞栓症） Detection

- Classify Pulmonary Embolism cases in chest CT scans -（9/10-10/27)

今回用いられているCTは、ウイキペディアによれば、以下のとおりである。

CT pulmonary angiogram (CTPA) is a medical diagnostic test that employs computed tomography (CT) angiography to obtain an image of the pulmonary arteries. Its main use is to diagnose pulmonary embolism (PE).^[1] It is a preferred choice of imaging in the diagnosis of PE due to its minimally invasive nature for the patient, whose only requirement for the scan is an intravenous line.

Modern MDCT (multi-detector CT) scanners are able to deliver images of sufficient resolution within a short time period, such that CTPA has now supplanted previous methods of testing, such as direct pulmonary angiography, as the gold standard for diagnosis of pulmonary embolism.^[2]

オンライン翻訳では、

CT肺血管造影（CTPA）は、肺動脈の画像を得るためにコンピューター断層撮影（CT）血管造影を使用する医療診断テストです。その主な用途は、肺塞栓症（PE）の診断です。^[1]スキャンの唯一の要件が静脈ラインである患者にとっての侵襲性が低いため、PEの診断におけるイメージングの好ましい選択です。   

最新のMDCT（マルチ検出器CT）スキャナーは、十分な解像度の画像を短時間で提供できるため、CTPAは、肺塞栓症の診断のゴールドスタンダードとして、直接肺血管造影法などの以前の検査方法に取って代わっています。^[2]

画像診断に適したモデルを開発する余地はあるのだろうか。

コードを読み、論文を読み、チューニングもがんばろう。

というより前に、

データサイズが大きすぎ！！！

どうすればいいのだろうか？

9月13日（日）

また新たなコンペが開始されていた。

(9/11 - 10/6)

OpenVaccine: COVID-19 mRNA Vaccine Degradation Prediction

Urgent need to bring the COVID-19 vaccine to mass production

開発が急がれているワクチンの候補材料であることから、コンペの結果が、開発に寄与することを期待して、期間を短縮したようである。

バイオインフォマティクス技術者資格の試験勉強のおかげで、RNAの配列とか二次構造の表現方法を見て、フムフム、どこかで見たぞと思うのだが、親近感を覚えるだけでなく、こういう課題に取り組むために、それなりに、準備してきただから、成果を出したいものだ。

RNNを用いている。LSTMやGRUが使われているようだ。

あてずっぽうでいえば、ATTENTIONは、どうなのかな。

9月14日（月）

明日はBirdcallとHalideが最終日だ。

Birdcallは、trainingモデルを使用してinferenceのみ。しかも、当該分野で具体的にデータを解析したことが無かったので、パラメータの意味がよくわからず、モデルの変更の効果も予測できず、むやみに数値を変えてみるだけだった。しかも1日の投稿回数が2回までなので、いろんなパラメータを系統的に調べるだけの日数がなかった。

こうやって言い訳してみると、ただの勉強不足だ。しっかりと関連文献を読むべきだったと思う。

明日は、後日のために、関連文献を読んでみる。

9月15日（火）

明日はBirdcallとHalideがsubmit最終日だ。

明日の結果を待つだけだが、メダルの可能性は、いずれも、ゼロ、である。

Birdcall関連文献を見ておこう。

Proceedings of Machine Learning Research 101:924–939, 2019 ACML 2019
Fusing Recalibrated Features and Depthwise Separable Convolution for the Mangrove Bird Sound Classification
Chongqin Lei, Weiguo Gong, and Zixu Wang

In this paper, we propose a novel method that combines the feature recalibration mechanism with depthwise separable convolution for the mangrove bird sound
classification.

In the proposed method, we introduce Xception network in which depthwise separable convolution with lower parameter number and computational cost than traditional convolution can be stacked in a residual manner, as the baseline network.

And we fuse the feature recalibration mechanism into the depthwise separable convolution for actively learning the weights of the feature channels in the network layer, so that we can enhance the important features in bird sound signals to improve the performance of the classification.

In the proposed method, firstly we extract three-channel log-mel features of the bird sound signals and we introduce the mixup method to augment the extracted features.

Secondly, we construct the recalibrated feature maps including the different scales of information to get the classification results.

To verify the effectiveness of the proposed method, we build a dataset with 9282 samples including 25 kinds of the mangrove birds such as Egretta alba, Parus major, Charadrius dubius, etc. habiting in the mangroves of Fangcheng Port of China, and execute the experiments on the built dataset.

このaugmentationのやり方は、単純だが、他の分野でも使えそうだ。

9月16日（水）

Birdcallコンペの結果が出た。

順位は大きく下がった。

inferenceだけなので、出力層をうまく調整できればと思ったのだが、PyTorchには、まだまだ不慣れこともあって、変更しようとするたびにエラーが出てしまい、ここは変更すること自体がダメなのかなと思い、それ以上追求しなかった。

こういうときこそ、PyTorch理解のチャンスだったのだが、・・・。

出力層のdropoutを変更したモデルのprivete scoreが、若干良かった。

今、出力層のモデル変更は不可であることを確認した。

文法エラーもあったかもしれないが、trainパラメータを用いてinferenceするのだから、出力層も含めてモデルの変更は不可、ということだろうな。

dropoutは変更してもエラーにならず、最後まで計算されて、予測結果も違ってくることは確認できた。trainとinferenceでdropoutが違っていても、inferenceは可能で、結果は異なるが、dropoutを多くすることによる結果は、不明である。今回の例では、dropoutを多くすることでprivate_dataのスコアが上がったのは、汎化性能が上がったためだと思いたいが、偶然かもしれない。

Openvaccin：

昨日は、非常に効果的に、スコアがアップした。

これで、方向付けができたと思ったが、今日は、初手でつまづき、次から次へと悪手を繰り出したというところだろうか。

Landmark：

これは、birecallと似たところがあって、今の自分には、Hostのbaseline exampleコードを使って、チューニングするだけである。

9月17日（木）

Landmark：

#Retrieval & re-ranking parameters

#RANSAC parameters

これらのパラメータは合わせて６つだが、これらを最適化するために必要な知識は、これらのパラメータが、プログラム中でどのような役割を演じているのかをしらなければならない。

一般論は、Google Research, USAの3名の研究者の共著論文Unifying Deep Local and Global Features for Image Searchに詳しく書かれている。

プログラムは、Host Baseline Exampleに上記パラメータとともに記述されている。

多くの参加者はこの6つのパラメーターを調整するしかないので、スコアは狭い範囲に集中する。しかも、同一条件で計算しても結果はばらついて制御できず、得られた最良スコアが表示されている。

当初は0.99以外の5つのパラメータだけを見ていたが、行き詰ってしまい、上記論文を読んだり、プログラムの中での働きを少しずつ調べたりしているところである。

9月18日（金）

Landmark：

朝、セットしたパラメータで計算した結果が、夕方、出揃った。

しかし、5件とも、ベースラインに設定していたスコアを下回った。

各パラメータの効果がよくわからなかった。ばらつきの範囲内なのかどうかが見分けられていない。

明日は、パラメータの変更割合を大きくしてみよう。

同じところをぐるぐる回っているだけのような気がするので、せめて、論文読んで勉強しよう。

「Unifying Deep Local and Global Features for Image Search」を最初からゆっくりと読んでみよう。

1  Introduction

A global feature : 

・summarizes the contents of an image

・often leading to a compact representation

・information about spatial arrangement of visual elements is lost

Local features : 

・comprise descriptors and geometry information about specific image regions

・they are especially useful to match images depicting rigid objects

2  Related Work

Local features

Hand-crafted techniques such as SIFT and SURF have been widely used for retrieval problems. Early systems worked by searching for query local descriptors against a large database of local descriptors, followed by geometrically varifying database images with sufficient number of correspondencies. .......... The one most related to our work is DELF; our proposed unified model incorporates DELF's attention module, but with a much simpler training pipeline, besides also enabling global feature extraction.

Global features

Joint local and global CNN feature

Dimensionality reduction for image retrieval

3  DELG

3.1  Design consideration

...................................................

9月19日（土）

Landmark：

B. Cao et al., Unifying Deep Local and Global Features for Image Search

この論文の主題は、global descriptor とlocal descriptorを１つのモデルで実現したことであるが、現時点での自分にとっては、Feature extraction and matching, Re-ranking, Tuning image matchingなどにおけるパラメータの設定に関するヒントを得ることである。

いくつかのパラメータについて具体的な数値が出ているが、これらの値は、開発したモデルと従来モデルもしくは他者のモデルとの比較を目的にしているため、簡略化されているようであり、また、再現性がとれるよう、限られた条件の下で計算しているため、最大公約数的な数値になっているようだ。

実際に論文中のパラメータの具体的な値をいくつか試したが、これまでのところ、public LBの改善にはつながっていない。

しかしながら、各パラメータの意味はすこしづつわかってきた。

今日の夕方にスコアが出てくる。もし、スコアとの相関性が高いパラメータが見つかれば、追記しよう。

残念な結果に終わった。いずれも、0.46+だった。0.48+を超えられない！！！

TEAM JL Solution to Google Landmark Recognition 2019の記事を読んでみよう。

昨年のコンペでトップになったチームによる報告書である。

Dataset Cleaning

画像が約400万枚、約20万クラス、約5万クラスは画像が3枚以上含まれない。

前処理の詳細は、理解できない。

Global CNN Model

6種類のbackbone network、4種類のpooling operation。

Local CNN Model

Detect-to-Retrieve(D2R) : Detect-to-Retrieve: Efficient Regional Aggregation for Image Search. Marvin Teichmann, Andre Araujo, Menglong Zhu, and Jack Sim

Step-1: Global Search

Step-2: Local Search on Global Candidates

Step-3: Re-Ranking

This re-ranking step aims at distinguishing real landmark images from distrantors.

Results

Conclusion

References 15件

2位をみてみよう。

K. Chen et al., 2nd Place and 2nd Place Solution to Kaggle Landmark Recognition and Retriecal Competition 2019

引用文献21件

3位をみてみよう。

K. Ozaki and S. Yokoo, Large-scale Landmark Retrieval/Recognition under a Noisy and Diverse Dataset

引用文献22件

＊いずれも、レベルが高すぎて、評価できない。

9月20日（日）

Landmark：

NUM_TO_RERANK=3の確認：結果は本日の夜。

これまでの値をようやく上回って、メダル圏内に再突入した。

しかし、不規則な動きをしていて、相関しているのかばらつきなのかが不明。

明日、再現性を確認する。

OpenVaccine：

更新スピードについていけず。

enbedd_dimとhidden_dimの検討：結果はすぐわかるのでフィードバックが早いのは良いが、手詰まりになるのも早い。

明日は、自分のデータでアンサンブルしてみるかな。

それよりも種々の条件で計算した結果を蓄積しようか。

OSIC：

停滞中

矛盾を抱えたまま。

9月21日（月）

Landmark：

昨日、久しぶりにLBスコアがアップした。

今日は再現性の確認と、他のパラメータの確認を行う。

夜になって、結果が出始めた。

残念ながら、昨日の結果は再現されず、単なるばらつきのようだ。

これだけばらつきが大きいのだとすると、パラメータの最適化の判断も、間違っていた可能性が、非常に、高い。

複数のパラメータがリンクしているようで、あるパラメータが不適切な範囲にあると、他のパラメータの最適化ができない。

関連文献を読み込んで、各パラメータの意味を理解するしかなさそうだ。

OpenVaccine：

アンサンブルの前に、単独で良いスコアを出しておかないと、アンサンブルしても戦えないので、今は、スコアアップに注力しよう。

といっても、なかなかスコアが上がらない（数値が下がらない）。

モデルのサイズを大きくし、かつ、繰り返し回数も増やして計算していたら、2時間半以上経過してから、メモリー不足（出力領域の容量をオーバーしたようだ）のエラーが表示され、プログラムが停止した。

あとでアンサンブルしなさい、と言われているようなものだな。

計算条件のチェックも含めると、GPUの使用時間を5時間くらいロスした。

OSIC：

計算精度の高いものと、public LBの良いものの、2種類用意してみるしかないかな。

9月22日（火）

Landmark：

文献を読んで、これだっ！と思って調べたパラメータは、完全な、空振りだった。

ばらつきを超えた変化をしているので、間違いない。

なぜ、空振りだったのか。

おそらく、同時に満たすべき他の変数の値が、外れているのだろう。

それは、どれだろう。

明日は、また、探索だ。

OpenVaccine：

競争にならないところで、パラメータ調整しているのだが、式が間違っていたために、またもや、5時間くらい無駄にGPUを使ってしまった。

並行作業しているために、注意散漫になっていたのも原因の1つだろう。

ともかく、殆ど、前進していると感じられない。

100位がものすごく遠く感じられる。

そうだ、このコンペは、コードコンペじゃないし、テストデータは全部見えているので、スコアアップのいろんな手段が使えるから、Kagglerのノウハウを最大限に生かせるコンペだといえるだろうな。

勝手に言わせてもらえば、課題の趣旨からすると、コードコンペの方がよかったんじゃないかな。

9月23日（水）

Landmark：

今日も、パラメータ探索に、出かけよう。

ばらつきに惑わされながらも、ほんの少しずつではあるが、スコアは上がっているので、やる気は出てくる。

同一条件であり、さらに、良くなるはずの条件でもある、と思って設定しても、下がることの方が多い。

RANSACのチューニングだけをdiscussionしている人たちに、ケチをつけて、トレーニングからきっちりやることを勧めている人がいたが、やはり、トップレベルにいる。

あと1週間、メダル圏内から放り出されないように、さらに上を目指そう！！！

OpenVaccine：

重要なテーマで、バイオインフォマティクスの知識を活用できると思って参加したのだが、スコアばっかり気にして、課題の意味もデータの詳細も把握していないことに気付いた。

情けないことだ。

明日は、課題の内容をしっかり勉強しよう。

9月24日（木）

Landmark：

繰り返しになるが、参考文献の、何か所かにおいて、Host Baseline Exampleの初期値と同じ値が出てくる。

ところが、これらの値を使っても、良いスコアは出ないどころか、組み合わせによっては、スコアは下がる。

しかしながら、これらの初期値が、無意味な数値でないことは、確かであろう。

今日も、スコアアップの望みを託して、5つのパターンをsubmitした。

結果は夕方から夜にかけて出てくる。

１つのパラメータに対して、ばらつきの範囲を少し超えてスコアが上がった。

１つは、明らかに下がった。

２つは、ばらつきの範囲を超えて下がったように見える。

偶然によってしか、スコアは上がらないのかな、と思ってしまう。

OpenVaccine：

ワクチンのお勉強：きれいな図が掲載されている論文

コンペの内容にもっと近い情報は、Overviewのadditional resourcesに紹介されている。

OpenVaccine：

チューニングがうまく進まない理由が少しわかってきた。

CNNと比べるとRNNのチューニングは、これまで、ほとんどやったことがない。

CNNであれば、データ量が十分多い場合には、通常、できるだけ広く深いモデルを用いることにより、良い結果が得られる。

CNNで用いるdropoutは、出力手前のdense layerでは、0.5にすることが多いのだが、RNNでは、0.2～0.3が良く用いられているようだ。

今回使っているモデルはRNNだが、RNNのチューニングの経験が少ないため、何気なく、最初から0.5に設定し、サイズも、128から、256、384、 512と増やしていった。

そうすると計算時間が増えるので、時間短縮のためにバッチサイズを大きくするとか、エポック数を減らすとかしていると、よけいに、良いスコアが出にくくなる。

今日、A. Geronさんのテキストを見ていて、ようやく気付いた次第である。

実際に、enbedding, hidden, dropoutを、(128, 512, 0.5)と(16, 64, 0.2)とで比較したところ、同じ計算時間では、後者の小さなモデルの方が良い結果を示した。

それぞれのモデルについて、十分最適化したわけではないので、断定はできないが、少なくとも、常に大きなモデルの方が良い、という結果にはならなかった。

とはいえ、この程度のことは常識だろうから、上位進出はおぼつかなさそう。

気になるのは、構造との相関だが、コンピュータに、分子構造や配列構造を効果的に認識させるために、one-hot encodingを使うとか、数値を規格化するとか、コンピュータが識別しやすい方法を考える必要がありそうだな。

数値に分布をもたせたり、構造情報に意図的に欠損を導入することなど、実際にプログラミングしていかないと、レベルが上がらないな。

9月25日（金）

Landmark:

ここまででpublic LBが最も高いパラメータに変更を加えてsubmitした。

まだまだ気になる組み合わせがたくさん残っているし、ホストのbasic modelのチューニングだけで0.52+に到達していることを宣言している人もいるので、がんばれば、50位以内に入れる可能性がある。

１つは、error、であった。これは解せない。これまでにも設定した値で、そのときにはerrorにはならなかった。明日、余裕があれば、再トライしてみよう。

3つは下がった、そのうちの2つはばらつきの範囲を超えてさがっている。

1つは上がったが、ばらつきの範囲内だろうと思う。

文献を探っていくと、パラメータの設定値がいくつか出てくるが、文献によって大きく異なっていたり、試してみると全く効果がなかったり、いろいろある。

しかし、公開コードのパラメータをまねている間に出来上がってきた固定観念から抜け出し、スコアアップにつながったということにおいては、多くの文献を見ることは効果があったということになる。

OpenVaccine：

戦いにならないので、

①ちまちまとベーシックな公開コードをチューニングする。

②課題を解くうえで非常に有用な情報と優れたコードが公開されているので、できるだけ多く見る。

このサイトを見ていると、本物の研究者、技術者が集まっていることを、実感できる。

9月26日（土）

Landmark：

今日は、昨日errorになったパラメータの再確認と、MAX_RANSAC_ITERATIONSのチェックを行う。

結果は夕方。

昨日エラーになったパラメータは、同一条件で計算できたが、今回の条件では、スコアアップに効果は認められなかった。

MAX_RANSAC_ITERATIONSについては、元の値の1/2と1/10がばらつき範囲内で、1/5がばらつき以上に小さなpublic LB値を示しており、わけがわからない。

まあ、ばらつき以上に小さい値も、ばらつきの範囲内ということかもしれない。

次どうすればよいのか、見当がつかなくなった。

OpenVaccine：

バッチサイズをtrainの途中で5段階も変更するのを初めて見た。

その変化を見ていると面白い。小さなバッチから始めてだんだん大きくするのだが、最初のバッチサイズでもう下限かなと思っても、そこでバッチサイズが大きくなると、途端にロスが下がる。その次も、その次も、ということがいつも明瞭に分かるというわけではなさそうだが、興味深い。

学習率lrを段階的に小さくしていく場合にも同様なことが生じるが、大きくしても興味深い変化が生じることがある。

バッチサイズが大きいと、収束時間は短くなるが、最小値の近傍で振動するとか、局所最小値に陥ることがある。バッチサイズを小さくすると、計算時間は長くなるが、グローバル最小値に到達しやすくなる。それでも、やはり、局所最小値に陥る可能性はあるようだ。

学習率とも関係してくるので、バッチ数の変化と学習率の変化をうまく組み合わせる方法が模索されているんだろうな。

drop outはトレーニング中一定のようだが、これだって、トレーニング中に変化させると面白いかもしれない、初めのうちは小さくして、だんだん大きくすれば収束が早くて、かつ、汎化性能も上がるなんてことにならないだろうか。

drop outはコンパイルするときに組み込まれてしまうのであれば、drop outの異なるモデルを直列につないでも良いかもしれない。並列でもいいか？

さらに、アンサンブルしたり、モデルの構造も変えたり、初期値も、BNも、・・・。

今日は、ドラフトをcommitしようとしたらエラーが発生して、saveできなくなった。計算に要した、約70分のGPUの浪費となった。くやしいな。

・公開コードで頑張ってメダル圏内に首を突っ込んだけど、数時間もしないうちに、見事にはじき出された。最後まで残れるだけの、プログラミング技術やチューニング技術などがあればいいのだが、こういう場面に出くわすと、無力だなと思う。

・公開コードはますます高度になって、コメントや他の人のコードなどを参考にしながらレベルが上がっていく。しかし、LBへの影響が大きくなることを意識してか、フォークしても動かないものがある。

・今の自分と同じようにチューニングで頑張っている人もいることを考えると、明らかに、チューニング力においても、トップ50とは開きがあるように思う。もっと頑張らないといけないな。

・チューニング力を上げるには、コード理解力/解析力を上げることが必要で、目の前にあるコードを理解しなければ、ちゃんとしたチューニングは出来ないし、改造もできない。

・チューニングだけで、スコアを、高い目標レベルまで上げたいときは、プログラムコードを読み解こうとする集中力が高くなる。数ある公開コードの中から、スコアだけでなく、コードを見て、好スコアが狙えるものかどうか自分で判断できなければだめだ。

・なんか、チューニングしかできないことを、正当化しようとしている。

9月27日（日）

Landmark：

今日も、パラメータを振って、submitしてみた。あてずっぽう、です。

ここまでで、結局、13/1000くらい上がっただけなので、文献を参考にして、パラメータの意味を理解し、適切な値にすることによって、スコアが上がりました、と言えるようなレベルではない。

今日も、夕方の結果を待つ。夕方2件の結果が出て、2/10000だけアップした。

残りの３つは、10時間経っても計算中だ。あるパラメータ（MAX_RANSAC_ITERATIONではない）を大きくしたためだと思うが、時間切れになる可能性がある。

スコアアップの可能性があると思って設定したのであるが、他のパラメータとの相関が大きいことも予想される。

今回、それほど悪くなければ、明日は、計算時間の短縮に直結しそうな他のパラメータを調整しようと思っている。

今回の結果次第だが。

結果が出た。

12時間以内に計算が終了しなければ、time out errorになる。

あと2日、10回のsubmissionしかチャンスは無いので、非常に難しいが、まさかと思うパラメータ設定をやってみよう。

OpenVaccine：

2つの計算結果の平均値で、2/1000だけLBスコアアップを確認したが、これでは、メダル圏内は遠い。今日も、メダル圏をかすったが、数時間も経てば数十番下がる。

今でこれだと、今の50位でも最終的にはメダル圏外かもしれないと思って準備したいが、どうすれば良いのだろうか。

マウスの調子が悪い：たまに、2度押しの状態が生じる。commitの際にこの現象が生じると、バージョンが違うと表示されてエラーから回復できず、再度計算しなおしとなる。submitでこの症状が出ると、同じデータが2度submitされる。今日は、後者がおきた。マウスを、買い換えよう。899円の有線マウスを発注した。

9月28日（月）

Landmark：

残り2日、10回のsubmitで終了だ。

今日は、スコアが大きく動く可能性のあるパラメータの値に設定した。

期待通りにはならなかった。

全て、time out errorでした。

明日の最終submitは、どうしようかな。

これといって、スコアアップの方策はないので、private LBのための、最終の2つの候補をしっかりと選ぶことにしよう。といっても、上位2つを選ぶだけだな。

OpenVaccine：

スコアアップの速度が速くて、ついていけない。

1/1000の改善で大きくステップアップできるのだから、再現性を確かめながら、ち密に改善していくことが重要な段階になってきているような気もする。 

コードも、Attention, Multi-Head Attention, Transformerなど自分にはなじみの薄いモデルが登場している。

有効なチューニング方法がわからない。

A. GeronのテキストでもAttentionやTransformerのコード例は少なく、論文を読んで勉強しなさい、という感じである。

9月29日（火）

このブログ、書式が急におかしくなってしまうことがある。

長い記事なので、書式を元に戻すためには、書きかけの記事を放棄するしかない。

そうすると、1回前の保存状態に戻る。

というわけで、今日書いた記事が、消えてしまった。

Landmark：

今日は、最終日である。

５つのパターンをsubmitしたが、スコアアップはできなかった。

ということで、このコンペは終了だ。

今の順位を維持できれば初メダルとなるが、大きな下落を経験しているので、静かに待つだけだ。

OpenVaccine：

プログラムの構造が少しずつ見えてきたので、パラメータを変更してみた。

少し希望が出てきたが、まだまだスコアは大きく動くので、なんともいえない。

9月30日（水）

Landmark：本日午前9時00分終了

暫定結果だけど、はじめてのBronzeを獲得できそうだ。

最もスコアが高かった条件は、

NUM_TO_RERANK=8

TOP_K=3

MAX_INLIER_SCORE=30：70に設定している文献があったがだめだった。

MAX_REPROJECTION_ERROR=6.0

MAX_RANSAC_ITERATION=500k：250kや50kという文献があったが、大差なかった。

HOMOGRAPHY_CONFIDENCE=0.995

DELG_SCORE_THRESHOLD_TENSOR=600：これが効果的だったと思っている。

LOCAL_FEATURE_NUM_TENSOR=8000

上位者には笑われるかもしれないが、ご参考まで。

Landmark：10月1日追記

最終結果（暫定）は、68位だった。上記の条件がprivate LBでも最良のスコアだった。

Host Baseline Exampleだけで、40位以内を確保しているような表現をしていた人が、終了後にコメントを発表していたが、予測モデルを走らせていたようなことを述べていた。せめて、RANSACやDELGパラメータにふれてほしかった。

Landmark：10月2日追記

メダル圏内の複数のチームから、Host Baseline Exampleのパラメータ設定値がいくつか紹介されていた。残念ながらどれもスコアはそれほど高くないためか、どのパラメータが決定的なのかはよくわからない。自分の設定値に似たものもなかった。

OpenVaccine：

チューニングに熱中していたら、もう、GPU割当時間を消費してしまった。

とりあえず、アンサンブルして、メダル圏に接近できたのでよしとしよう。

KaggleのGPUが使えるようになる土曜日に、どれだけ離されているかだな。

それまでの10回のsubmitチャンスを使って、アンサンブルの組み合わせと重みを検討しておこう。

9月は今日で終わりだ。

明日から10月、新しいページを作ろう。

style=153 iteration=1

style=153 iteration=20

style=153 iteration=500