AI_ML_DL’s diary

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

GitHub散歩(November 2020)

GitHub散歩(November 2020)

これまでは、コードを見るだけのGitHubだった。

もう少し活用したいと思っている。

 

11月21日(土)

GitHub Guidesのページの下端に次のように書かれている。

GitHub is the best way to build and ship software.
Powerful collaboration, code review, and code management for open source and private projects.

GitHubを初めて使ったのは、機械学習のテキストを学習する際、実際にプログラムコードを動かすため、GitHubに置かれているプログラムコードをダウンロードしたときである。機械学習のテキストを購入するたびにGitHubからプログラムをダウンロードした。

テキストの著者がGitHubでBuildしたソフトウエアを利用していたということだ。

GitHubをプログラムをダウンロードする場所としてしかみていなかったが、プログラムを作って公開して共同で編集する場所のようですね。

GitHub Guidesに入ると、そこには、GitHubを理解し、活用するために必要なさまざまな仕掛け、教育ツール、ドキュメントが存在している。さまざまなプログラム言語も学べるようになっている。

 

11月22日(日)

What is GitHub?

I'm glad you asked! Many people come to GitHub because they want to contribute to open source 📖 projects, or they're invited by teammates or classmates who use it for their projects. Why do people use GitHub for these projects?

open source

Open source software is software that can be freely used, modified, and shared (in both modified and unmodified form) by anyone. Today the concept of "open source" is often extended beyond software, to represent a philosophy of collaboration in which working materials are made available online for anyone to fork, modify, discuss, and contribute to.

forkは次のように定義されている。

fork

A fork is a personal copy of another user's repository that lives on your account. Forks allow you to freely make changes to a project without affecting the original upstream repository. You can also open a pull request in the upstream repository and keep your fork synced with the latest changes since both repositories are still connected.

forkは、forkしたコードの改善、改良のために行うものであり、成果があれば、元の所有者に、改善結果等を反映するかどうか打診する。ということかな。

 

GitHubの中に、Learnibg labというのがあり、いろいろ学べるようになっているのだが、Introduction to GitHubを最初にやりましょうと促されたので、やってみることにした。

Introduction to GitHubは、1から8までのコースステップからなっていて、このコースを完了すれば次のステップに進めるようになっているようだ。逆にいえば、このコースを完了しないと、GitHubを利用することはできないのではないかと推測される。

1から8までのステップの項目は、1. Assign yourself, 2. Turn on GitHub Pages, 3. Close an issue, 4. Create a branch, 5. Commit a file, 6. Open a pull request, 7. Respond to a review, 8. Merge your pull request, となっていて、GitHubでの操作手順の説明がなされているようである。

わからないことがあれば、こまごまとしたことまで、丁寧にリンクが張られていて、用語もきちんと説明されている。

今日の書き始めの箇所に、一部、コピペしているが、いくらやってもきりがないので、教育内容まで踏み込むのはやめておく。

 

上記の8つの項目についても、前に進むには、少なくとも、紫で示した単語についての、GitHub内での定義とその内容を理解しておかなければならないので、初心者がこの8つのステップをクリヤするのは、容易ではないと思う。

ということで、自分も、ちょっと見ただけでも、理解しなければならないことがたくさんあり、かつ、英語で直接コミュニケーションできるようにするために、苦手の英語を、できるだけそのまま理解しながら前に進もうとしているので、いつ、8つのステップをクリヤできるかわからない。

この8つのステップをクリヤ出来たら、そのことを書きたいと思う。

 

11月23日(月):

Introduction to GitHub

Step 1を学習中:Step 4まで通過したが、

Step 5: Commit a fileで止まっている。

 

 

 

f:id:AI_ML_DL:20201121115658p:plain

style=159 iteration=500

f:id:AI_ML_DL:20201121115805p:plain

style=159 iteration=50

f:id:AI_ML_DL:20201121115914p:plain

style=159 iteration=5

 

DNNで量子化学計算(November 2020)

DNNで量子化学計算(November 2020)

最近の進展についてまとめる機会があったので、より深く理解することと、実際の解析コードを使えるようになることを目標に、その経過をブログに記す。

 

11月10日(火)

FermiNet:

FermiNet is a neural network for learning the ground state wavefunctions of atoms and molecules using a variational Monte Carlo approach.

基底状態波動関数を学習するためのNNであるという記述が気になる。

troyerらの成果

Despite the simplicity of the restricted Boltzman machines, very accurate results for both ground-state and dynamical properties of prototypical spin models can be readily obtained.

図のタイトルを並べてみると、

Figure 1.  Artificial Neural Network encoding a many-body quantum state of N spins.

Figure 2.  Neural Network representation of the many-body ground states of prototypical spin models in one and two dimensions.

Figure 3.  Finding the many-body ground-state energy with neural-network quantum states.

Figure 4.  Describing the many-body unitary time evolution with neural-network quantum states.  Shown are results for the time evolution induced by a quantum quench in the microscopical parameters of the models we study (the transverse field h, for the TFI model and the coupling constant Jz in the AFH model). 

TFI : transverse-field Ising (model)

AFH : anti-ferromagnetic Heisenberg (model)

 

11月11日(水)

HermannらのPauliNetの成果

PauliNet outperforms comparable state-of-the-art VMC anzats for atoms, diatomic molecules and a strong-correlated hydrogen chain by a margin and is yet computational efficient.

成果は、正確さと効率化(行列の数)だけなのか。効率化によって、より大きな原子、分子について正確な計算結果を得ることができたということなのか。

Figure 1に、PauliNetによる効率化の程度がわかりやすく図示されている。

PfauらのFermiNetの成果

Using no data other than atomic positions and charges, we predict the dissociation curves of the nitrogen molecule and hydrogen chain, two challenging strongly correlated systems, to significantly higher accuracy than the coupled cluster method, widely considered the most accurate scalable method for quantum chemistry at equilibrium geometry.

coupled cluster method:結合クラスター法

 結合クラスター法(けつごうクラスターほう、クラスター展開法CC法:Coupled Cluster)は多体系を記述するために使われる数値手法である。最もよく使われるのは、量子化学計算化学)におけるポスト-ハートリー-フォック第一原理計算がある。CC法は、ハートリーフォック分子軌道法を基本にして、電子相関を考慮する指数関数クラスタ演算子を使って多電子波動関数を構成する。CC法を用いて、小さい分子や中程度の大きさの分子について最も正確な計算を行うことができる[1][2][3]。from ウイキペディア

Table 1.  Ground state energy, ionization potential, and electron affinity for first-row atoms.

Table 2.  Ground-state energy at equilibrium geometry for diatomic and small molecules.

いずれの表も、FermiNetがCCSD(T)に優っていることを示している。イオン化ポテンシャルと電子親和力は、FermiNetの結果しかないのは、CCSD(T)では基底状態のエネルギーしか計算できないということだろうか。

C.  The H4 rectangleの最初に次のように記述されている。

While CCSD(T) is exceptionally accurate for equilibrium geometries, it often fails for molecules with low-lying exited states or stretched, twisted or otherwise out-of-equiliblrium geometries.

昨日学会に送ったA4半ページの紹介記事で、FermiNetやPauliNetは励起状態のエネルギーも正確に計算できると書いたのだが、励起状態あるいは非平衡状態のエネルギーの計算に関しては、論文の斜め読みでそう書いただけだったので、気になっていたのだが、少なくとも、FermiNetに関しては問題ないようだ。図4から図6には、非平衡状態の計算においてもFermiNetはFCIなどの厳密な計算手法や正確な実験データに匹敵する正確さをもつことが示されている。

PauliNetについても、原子間距離に対するエネルギーの変化をHaetree-Fockなどの量子化学計算結果と比較していて、PauliNetのほうが、exactなデータに近いことが示されているので問題なさそうである。

 

11月12日(木)

PauliNetのGitHubを見てみよう。

deepqmc:Deep learning quantum Monte Carlo for electrons in real space

deepqmc.github.io:DeepQMC documentation

プログラムコードとは別にドキュメンテーション(ユーザーガイドを含む)も用意されていて、勉強しやすそうだ。

 

11月14日(土)

FermiNetのGitHubを見てみよう。

REDME.mdの最後に、This is not an official Google product.と書かれていて不安になるが、アルファ碁を開発し、その後はバイオやフィジックスなどの自然科学の領域でも影響力を増しているDeepMindが運営している89のrepositoriesのうちの1つである。

 

PauliNetの開発者Jan Hermann氏は、量子物理の専門家であり、計算物理の専門家でもある。Hermann氏のGitHubには45のrepositoriesがあり、量子物理計算関連の内容がメインで、pySCFSchNet(K.T. Schütt. P.-J. Kindermans, H. E. Sauceda, S. Chmiela, A. Tkatchenko, K.-R. Müller. SchNet: A continuous-filter convolutional neural network for modeling quantum interactions. Advances in Neural Information Processing Systems 30, pp. 992-1002 (2017))なども含まれている。

 

FermiNetとPauliNetのどちらから始めようか考えているのだが、Hermann氏のサイトは、SCF計算やSchuNetなど量子物理の匂いが強く、DeepMind社のサイトはディープラーニングの匂いが強い。個人と団体の違いもある。入り口で立ち往生しても始まらないし、チェックしたいGitHubサイトは無限にあるので、GitHub散歩、みたいな感じで進めていこうと思う。

 

11月15日(日)

Hermann氏のサイトをながめてみよう。

Software projects

Most of my programming is related to my research in computational materials science. I believe that strong computational science benefits from strong software engineering, and that all scientific academic software should be open source.

I am involved in the following software projects.

Creator

Beta projects

These are experimental packages that, although fully functional, I don’t yet consider finished.

  • KnitJalternative front-end to Jupyter kernels aiming at editor freedom and easy versioning
  • Mona—framework for reproducible and distributed, potentially long-running calculations

Contributor

  • FHI-aims—massively parallel electronic structure code package with DFT at its core

 

<雑談>

ずっと会社に勤めていて、結局、独立することなく終わったのだが、50歳くらいで研究に没頭できる環境が欲しいと思って、理論計算の受託で稼ぎながら、研究できないかと検討したことがある。 理論屋でも物理屋でもないのだが、量子化学化学結合論などに興味があって、様々な分子軌道計算の論文をながめていたことがあったので、Gaussianのようなソフトを購入して、自分で使いながら、使いたい人に使い方や理論を教えたり、計算代行したりということを考えていた。このとき、ネックになったのが、ソフトの購入代金(使用料)と計算環境であった。会社の中で提案できるヒトではなかったので、夢想に終わった。ネットにアクセスできるパソコンがあれば、幸いにも、無料で、Gaussian(詳細は知らない)のような計算ができるようになっているので、夢の大半は実現することができる。ということを、pySCFについて調べながら、ぼんやり振り返っている。

 

DNN+量子化学計算+紹介記事 ⇒ FermiNet & PauliNet

ということになったのだが、現実問題として、FermiNetやPauliNetにアクセスしてすぐに計算を始められるヒトは理論も計算もすでにプロの領域にいる研究者に限られるだろう。φ、ψ、HF、CBS、FN-DMC、QMC、VMC、Jastrow、FCI、fixed-node correlation energy、・・・、専門用語や略語の意味も分からず、DNNが最先端の量子化学計算の分野に応用されているというだけで食いついても、この技術を適用する課題をもっていないことには始まらない、いや、終わらない。

 

PySCFについて調べてみた。

Recent developments in the PySCF program package
Qiming Sun et al., arXiv:2002.12531v2 [physics.chem-ph] 11 Jul 2020

abstract

PYSCF is a Python-based general-purpose electronic structure platform that both supports first-principles simulations of molecules and solids, as well as accelerates the development of new methodology and complex computational workflows.

The present paper explains the design and philosophy behind PYSCF that enables it to meet these twin objectives.

With several case studies, we show how users can easily implement their own methods using PYSCF as a development environment.

We then summarize the capabilities of PYSCF for molecular and solid-state simulations.

Finally, we describe the growing ecosystem of projects that use PYSCF across the domains of quantum chemistry, materials science, machine learning and quantum information science.

machine learningに関係する記述を次に示す。

A. PySCF in the materials genome initiative and machine learning

As discussed in section I, one of our objectives when developing PYSCF was to create a tool which could be used by non-specialist researchers in other fields.

With the integration of machine learning techniques into molecular and materials
simulations, we find that PYSCF is being used in many applications in conjunction with machine learning.

For example, the flexibility of the PYSCF DFT module has allowed it to be used to test exchange-correlation functionals generated by machine-learning protocols in several projects, and has been integrated into other machine learning workflows.

PYSCF can be used as a large-scale computational engine for quantum chemistry data generation.

Also, in the context of machine learning of wavefunctions, PYSCF has been used as
the starting point to develop neural network based approaches for SCF initial guesses, for the learning of HF orbitals by the DeepMind team, and for Hamiltonian integrals used by fermionic neural nets in NETKET.

最後のNETKETってなんだろう。

著者19名の論文が出ている。

トップオーサーのCarleo氏は最初に多体問題にNNを適用した2017年の論文の著者。

NetKetを共通基盤にして、さらなる発展を目指すということかな。

NetKet: A machine learning toolkit for many-body quantum systems
Giuseppe Carleo, Kenny Choo et al., SoftwareX 10 (2019) 100311

abstract

We introduce NetKet, a comprehensive open source framework for the study of many-body quantum systems using machine learning techniques.

The framework is built around a general and flexible implementation of neural-network quantum states, which are used as a variational ansatz for quantum wavefunctions.

NetKet provides algorithms for several key tasks in quantum many-body physics and
quantum technology, namely quantum state tomography, supervised learning from wavefunction data, and ground state searches for a wide range of customizable lattice models.

Our aim is to provide a common platform for open research and to stimulate the collaborative development of computational methods at the interface of machine learning and many-body physics.

NetKetのホームページがある。

What is NetKet?

NetKet is an open-source project delivering cutting-edge methods for the study of many-body quantum systems with artificial neural networks and machine learning techniques.

GitHubに公開されているが、NetKetで検索しても出てこないので、使いにくそうだ。ElsevierのSoftwareXというシステムの中に埋もれてしまっているようである。

NetKetのホームページはチュートリアルもあって、コードの説明も詳しく、自習に適しているように思う。

Carleo氏オリジナルのNQS(Neural-network Quantum States)がGitHubに掲載されているが、更新している形跡がない理由がこれでわかったような気がする。

 

<雑談>

頭が使える間に、何かできないかなと思うのだが、何もできていない。小柴先生が亡くなられたが、ニュートリノの検出に成功されてノーベル賞を受賞され、お弟子さんの梶田先生もニュートリノに質量があることを明らかにしてノーベル賞を受賞された。こんな実験は誰にでもできるものではないが、湯川先生の中間子理論なら誰にでも発見のチャンスはあった。最先端の分野の論文を読んでディスカッションを重ね仮説を積み上げ理論を組み立て・・・。

 

11月16日(月)

G. Carleo氏らの総説(著者8名)、Machine learning and the physical science、arXiv:1903.10563v2 [physics.comp-ph] 6 Dec 2019を読んでみた。 

機械学習がこれだけ浸透していたのかと驚かされる内容だ。

と、書いてみたが、斜め読み(英文の斜め読みだから内容までは頭に入っていない)しただけで、これからじっくり解読していこうと思う。

著者と所属(専門領域が想像できる機関名)をいくつか示す。

Giuseppe Carleo
Center for Computational Quantum Physics,

Ignacio Cirac
Max-Planck-Institut fur Quantenoptik,

Kyle Cranmer
Center for Cosmology and Particle Physics,
Center of Data Science,

Maria Schuld
National Institute for Theoretical Physics,

Leslie Vogt-Maranto
Department of Chemistry

Lenka Zdeborová
Institut de physique théorique

 

11月17日(火)

FermiNetとPauliNetのどちらに食らいつこうか考えていて、チュートリアルも含め、コードの解説がしっかり書かれているように感じたHermann先生のPauliNetでほぼ決まりのつもりだった。

ところが、Neural-network quantum states (NQS) の創始者のCarleo先生は、FermiNetとPauliNetの論文を引用したうえで、NQSをさらに発展させた論文を書いておられる。

さらに、共著で機械学習の物理学への展開と相互作用に関する総説を書かれている。

加えて、NetKetと称する多体量子系に適用する機械学習toolkitを開発されている。

以上のことを勘案して、NetKetで本格的な学習を始めることにしたいと思う。

 

ということで、早速、NetKetのホームページへ、行く。

まずは、Get Started、をクリック。

下の方に、青地に白抜きで、こんな表示がある。

Remarks

We are not yet supporting Conda installs
Windows Os is not supported

想定されているのは、MacUbuntuである。

Windowsユーザーは、これにて終了!

ということにならないために、

Windowsパソコンで、Ubuntuを使えるようにする、ということになる。

今使っているパソコンに何かあると困るので、他のWindowsパソコンで確認してみようと思う。

昨年、使わなくなったWindows Vistaパソコンに、Ubuntuをインストールしており、すぐにでも使える状態にある。GPUはなく、RAMは4GB、HDは100GBで、とりあえず動くのであるが、勝手がわからないというか、まったく手も足も出ず、放置している。

Windowsの方々は、私のように、ここで止まってしまう可能性が高いので、Ubuntuを使えるようになることを、当面の目標としよう。

 

Ubuntuの立ち上げ:

WindowsUbuntuをパソコンの起動時に切り替えられるようにしている。

Ubuntuを使いたいと思ったのは、Anacondaに後から追加できるpythonパッケージやモジュールに制限があることで、AnacondaはTF2.0に対しても対応が非常に遅かった。無理に入れようとして、Anaconda3を壊してしまったこともある。

Ubuntuのインストールは、簡単なマニュアルを見ればできる。問題は、UbuntuでAnaconda3を使おうとしたときにおきた。WindowsにAnaconda3をインストールするのは容易で、Windows10だと、すぐに使えるようになったので、その感覚でUbuntuにもAnaconda3を簡単にインストールできると思ったのが間違いだった。

Anacondaのドキュメントには、Installing on Linuxという項目があって、インストール手順を説明しているのだが、Ubuntuという単語が見当たらない。

 

ウイキペディアによると、

Ubuntu(ウブントゥ[6][ʊˈbʊnt] ( 音声ファイル); oo-BOON-too[7])はDebian GNU/Linuxを母体としたオペレーティングシステム(OS)である。Linuxディストリビューションの1つであり、フリーソフトウェアとして提供されている。概念はディストリビューションも参照。カノニカルから支援を受けて開発されている。開発目標は「誰にでも使いやすい最新かつ安定したOS」を提供することである。

Linuxリナックス、他の読みは後述)とは、狭義にはUnix系オペレーティングシステムカーネルであるLinuxカーネルを指し、広義にはそれをカーネルとして周辺を整備したシステム全体のことをいう(GNU/Linuxシステムも参照)。

Linuxは、狭義にはLinuxカーネル、広義にはそれをカーネルとして用いたオペレーティングシステムを指す。LinuxUnix系Unix likeUnixライク)オペレーティングシステム (OS) の1つとされる。カタカナでは「リナックス」と表記されることが多い(「Linux」の読み方を参照)。Linuxは、スーパーコンピュータメインフレームサーバパーソナルコンピュータ組み込みシステム(携帯電話やテレビなど)など、幅広い種類のハードウェアで使用されている。

デスクトップやサーバ用のLinuxは、Linuxディストリビューションという形でパッケージ化されて配布されている。有名なLinuxディストリビューションとしては、Debian(とその派生であるUbuntuLinux Mint)、Red Hat Linux(とその派生であるFedoraRed Hat Enterprise LinuxCentOS)、Mandriva Linux/MageiaopenSUSEArch Linuxなどがある。各Linuxディストリビューションは、Linuxカーネルシステムソフトウェアライブラリ等、巨大なコンパイル済のアプリケーション群を含んでいる。

 

<雑談>

Ubuntuはメジャーではなさそうだが、Kerasを開発したF. Cholleさんが、著書Deep Learning with PythonのAppendixAに、Installing Keras and its dependences on Ubuntuという記事を書かれていたことと、12年ほど前にイオン散乱シミュレーションのソフトを使おうとしたときに、教授から渡されたソフトがUbuntu上で動いていて、Ubuntuの入門書を渡されたということがあって、自分の中ではメジャーであった。しかし、今から思えば残念なのだが、ほどなくして、Windows上で動作する高性能のシミュレーションソフトを使うことになって、Ubuntuという奇妙な単語だけが頭に残った。さらに、F. Cholle氏のテキストをバイブルとしてディープラーニングを学ぶときにはAppendixAの記事を読む前にGPUを搭載したWindowsマシンを購入してAnaconda3上でKeras/TensouFlowを使うようになっていたので、後に、Ubuntuを使ってみたいと思ったときには、時すでに遅し、大きな壁が立ちはだかっていたのである。

 

今、そのAppendixAを眺めているのだが、sudo apt-get update, sudo pip3 install tensorflow-gpu, sudo python setup.py installなどの単語が並んでいる。

こういうものだということがわかったのだから、コマンドプロンプトに慣れて、Ubuntuを自分のものにしていこう。ほんとうに必要性を感じた時に使ってみよう。難しいのではなく、不慣れなだけである、ということにして、Ubuntuは、とりあえずこのへんでおいておく。

 

11月18日(水)

NetKetのホームページを丁寧に辿っていけば目的とする量子化学計算に辿りつけそうであることはわかってきた。

NetKetの論文のabstractをもう1度見てみよう。

abstract

We introduce NetKet, a comprehensive open source framework for the study of many-body quantum systems using machine learning techniques.

The framework is built around a general and flexible implementation of neural-network quantum states, which are used as a variational ansatz for quantum wavefunctions.

NetKet provides algorithms for several key tasks in quantum many-body physics and
quantum technology, namely quantum state tomography, supervised learning from wavefunction data, and ground state searches for a wide range of customizable lattice models.

Our aim is to provide a common platform for open research and to stimulate the collaborative development of computational methods at the interface of machine learning and many-body physics.

 

NetKitの論文を最後まで読んでみた感想:

neural-network quantum states (NQS)とrestricted Boltzman machine (RBM)が根底にあり、C++でプログラムを強化しているようである。使いやすさを強調しており、例題をみると、プログラムコードは非常に単純化されていて、確かに、すぐに使えそうな感じである。機械学習量子化学計算の橋渡しをするプログラム開発の拠点を目指しているようである。

PauliNet:Hermann先生のこてこての量子物理、FermiNet:DeepMindチームのディープラーニング等と比べると、NetKitに対しては、量子物理の観点からも、機械学習の観点からも、前2者と比べると、もの足りなさを感じる。

ということで、NetKitは、このあたりで、ひとまずおいておく。

 

さて、つぎ、どうしようか。

 

多体電子系の量子化学計算ができるようになりたいと思って、このテーマでブログを書いているのだが、「DNNで量子化学計算」というタイトルから多くの方が思い浮かべるのは、おそらく、教師あり学習で、分子構造と基底状態のエネルギー(DFT、CCSD(T)等による計算結果)を教師データにして、DNNにその関係性を学ばせることによって、任意の分子構造に対して基底状態のエネルギー値を予測することができる、ということではないだろうか。

ここで紹介している3種類のNNは、波動関数をなんらかの方法でNNに記述し、その波動関数に物理的意味を与える(最適化する)ために、そのNNを、VMC(variational Monte Carlo)等を用いて学習させる。そうすると、学習したNNは、基底状態だけでなく、非平衡状態や励起状態の分子のエネルギーをも計算することができる、というものだと理解している。

この説明は正確ではないかもしれないので、正しい知識を得るために、D. PfauらのFermiNetの論文を熟読したいと思う。

Ⅰ.  Introduction

ここでは、DNNを量子化学計算に用いる、これまでの方法が紹介されている。そのうちの1つの論文(引用文献6)を眺めてみよう。

Physical machine learning outperforms “human learning” in Quantum Chemistry
A. V. Sinitskiy and V. S. Pande, Department of Bioengineering, Stanford University, Stanford CA 94305, arXiv:1908.00971 (2019).

abstract

Two types of approaches to modeling molecular systems have demonstrated high practical efficiency. Density functional theory (DFT), the most widely used quantum chemical method, is a physical approach predicting energies and electron densities of molecules.

Recently, numerous papers on machine learning (ML) of molecular properties have also been published. ML models greatly outperform DFT in terms of computational costs, and may even reach comparable accuracy, but they are missing physicality — a direct link to Quantum Physics — which limits their applicability.

Here, we propose an approach that combines the strong sides of DFT and ML, namely, physicality and low computational cost. By generalizing the famous Hohenberg-Kohn theorems, we derive general equations for exact electron densities and energies that can naturally guide applications of ML in Quantum Chemistry. Based on these equations, we build a deep neural network that can compute electron densities and energies of a wide range of organic molecules not only much faster, but also closer to exact physical values than current versions of DFT. In particular, we reached a mean absolute error in energies of molecules with up to eight non-hydrogen atoms as low as 0.9 kcal/mol relative to CCSD(T) values, noticeably lower than those of DFT (down to ~3 kcal/mol on the same set of molecules) and ML (down to ~1.5 kcal/mol) methods. A simultaneous improvement in the accuracy of predictions of electron densities and energies suggests that the proposed approach describes the physics of molecules better than DFT functionals developed by “human learning” earlier. Thus, physics-based ML offers exciting opportunities for modeling, with high-theory-level quantum chemical accuracy, of much larger molecular systems than currently possible.

赤色に変えた文章が、これまで最も多く用いられてきた手法である。同じことが本文中ではもう少し詳しく記述されている。

Recently, many authors used machine learning (ML) for much faster computations of E and some other molecular properties (polarizabilities, HOMO-LUMO gaps, etc.).

However, neither currently used descriptors of molecules, nor ML models have a transparent connection to the basic physical concepts derived from the Schrödinger equation.

For example, the vast majority of ML models cannot be extended to compounds with new elements without retraining, making them methodologically inferior even to least accurate DFT functionals, let alone the absolutely transferable Schrödinger equation.

As a result, such approaches might be devoid of physics, and the criticism of ML as “black boxes” and “curve-fitting” seems totally applicable to them.

物理の教授に機械学習ディープラーニングの話をすると、ああ、あれね、ブラックボックス化されていて、何やってるかわからないよね、物理じゃなくて、単なるカーブフィッティングでしょ、などどいわれる。

A. V. Sinitskiyらは、上記abstractの紫色で示したように、ネットワークの中に物理(DFT)を持ち込み、持ち込んだ関数をDNNで最適化することによってDFTよりも高性能なCCSD(T)を超える正確さでEやρを高速に計算することができるとのことである。FermiNetやPauliNetは基底状態だけでなく非平衡状態(例えば結合距離を変化させたとき)や励起状態のエネルギーを計算できる。これに対して、A. V. Sinitskiyらがこの論文で示しているのは基底状態のみであるが、本文の最後に次の記述がある。

We foresee wide-scale applications of the approach proposed here (after certain technical developments) to computer modeling of various large molecular systems, including biomolecular or artificial material systems of much practical interest, and highly accurate and fast modeling of excited states of molecules and chemical reactions involving bond breaking and formation.

Fig.1 に、用いたDNNモデルの模式図が示されている。

f:id:AI_ML_DL:20201118224659p:plain

Pfauらの論文は20ページもあって読むのも理解するのもたいへんなのだが、参考のためにと思って引用しているこのSinitskiyらの論文は、62ページ(本文7ページ)もある。

 

準備が整ってきたようなので、FermiNetにフォーカスしようかと思ったのだが、根底にある量子物理、シュレーディンガー波動方程式波動関数、密度汎関数、多体電子系、スピン、強相関、・・・、これらに対する強い興味と理解がないと、何をやっているのかわからない。

ここで偶然出会ったA. V. Sinitskiy and V. S. Pandeの論文は、分子を扱っていて、他の論文をみると、生体分子とタンパク質 との相互作用を計算機シミュレーションで調べているようだ。さらに、上記論文の1つ前の論文もある。Deep Neural Network Computes Electron Densities and Energies of a Large Set of Organic Molecules Faster than Density Functional Theory (DFT), Anton V. Sinitskiy, Vijay S. Pande

ということだが、A. V. Sinitskiyらの研究は、別にフォローすることにして、ここでは、FermiNetを、とことん理解することにしよう。

 

11月19日(木)

FermiNetの全体像

f:id:AI_ML_DL:20201119190813p:plain

文字が小さくて見えないので拡大してみよう。

f:id:AI_ML_DL:20201119185931p:plain

 

f:id:AI_ML_DL:20201119191234p:plain

f:id:AI_ML_DL:20201119191524p:plain

f:id:AI_ML_DL:20201119191732p:plain

f:id:AI_ML_DL:20201119191915p:plain

f:id:AI_ML_DL:20201119192002p:plain

f:id:AI_ML_DL:20201119192210p:plain

f:id:AI_ML_DL:20201119192304p:plain

f:id:AI_ML_DL:20201119192822p:plain

入力するのは原子核と電子の座標だけで、ネットワークの形状と四則演算、行列演算との組み合わせによって、波動関数が表現されます、ということのようなのだが、確かに、アルゴリズムの最上段と最下段を見るとそうなっている。

ついでに、変数間の関係式も張り付けておこう。

 

f:id:AI_ML_DL:20201119213948p:plain

f:id:AI_ML_DL:20201119214044p:plain

f:id:AI_ML_DL:20201119214118p:plain

f:id:AI_ML_DL:20201119214152p:plain

f:id:AI_ML_DL:20201119214243p:plain

PauliNetのHermann先生は、論文Deep neural network solution of the electronic Schrodinge equationの中で、次のように書いている。

The parallel work of Pfau et al. (2019) follows the same basic idea as ours, but differs in several significant aspects.

Their architecture does not encode any physical knowledge about wave functions besides the essential antisymmetry, which is compensated by a much larger number of optimized parameters.

Perhaps as a result of that, their ansatz achieves somewhat higher accuracy at the cost of being about two orders of magnitude more computationally expensive than ours.

この文章から、FermiNetは、反対称性以外に波動関数に関する物理学的知識を含んでいないと思い込み、自分の紹介記事にもそう書いたのだが、これは正しい認識だろうか。

次にPauliNetの模式図を示す。

Hartree Fock, Jastrow, Backflow, Electronic cusps, Equivariant Interaction Blockが、fixed functionもしくはtrainable functionとして組み込まれている。

Fermi netには、それらのphysical knowledgeを表現することができる変数は用意されているが、physical knowledgeが含まれているとは言えない、という理解でよいのだろうか。

 

f:id:AI_ML_DL:20201119224317p:plain

 

11月20日(金)

B. Wave-function optimization

これが、FermiNetにphysical knowledgeを教え、学ばせる作業、ということかな。

波動関数のエネルギー期待値を最小化する、ということのようだが、Kronecker-factored approximate curvature (KFAC)、Fisher Information Matrix (FIM)など、ついていけなくなる。

大沢 和樹 氏の記事を一部転載させていただく。

Kronecker-factored Approximate Curvature (K-FAC) は(当時)University of Toronto の Ph.D. 学生であった James Martens らによって、2015年のICMLで提案された深層ニューラルネットワークのための最適化手法である。大規模な深層学習において応用が限られていた二次最適化手法のボトルネックである曲率 (Curvature) 計算の効率的な実現手法である。

自然勾配学習法(Natural Gradient Learning)は1998年にShun-ichi Amariによって提案された情報幾何に基づくニューラルネットワークの最適化手法である。自然勾配学習ではFisher情報行列を曲率として用いることで目的関数の地形を正確に捉え、「反復数」において学習の高速な収束を実現する。このため、自然勾配学習法は二次最適化の効率的な実現法としても知られる。

Natural Gradient Works Efficiently in Learning
Shun-ichi Amari
RIKEN Frontier Research Program, Saitama 351-01, Japan

This article introduces the Riemannian structures to the parameter spaces of multilayer perceptrons, blind source separation, and blind source deconvolution by means of information geometry. The natural gradient learningmethod is then introduced and is shown to be statistically efficient. This implies that optimal online learning is as efficient as optimal batch learning when the Fisher information matrix exists. It is also suggested that natural gradient learning might be easier to get out of plateaus than conventional
stochastic gradient learning.

KFACの論文:

Optimizing Neural Networks with Kronecker-factored Approximate Curvature
James Martens∗ and oger Grosse†
Department of Computer Science, University of Toronto

Abstract
We propose an efficient method for approximating natural gradient descent in neural networks which we call Kronecker-factored Approximate Curvature (K-FAC). K-FAC is based on an efficiently invertible approximation of a neural network’s Fisher information matrix which is neither diagonal nor low-rank, and in some cases is completely non-sparse. It is derived by approximating various large blocks of the Fisher (corresponding to entire layers) as being the Kronecker product of two much smaller matrices. While only several times more expensive to compute than the plain stochastic gradient, the updates produced by K-FAC make much more progress optimizing the objective, which results in an algorithm that can be much faster than stochastic gradient descent with momentum in practice. And unlike some previously proposed approximate natural-gradient/Newton methods which use high-quality non-diagonal curvature matrices (such as Hessian-free optimization), K-FAC works very well in highly stochastic optimization regimes. This is because the cost of storing and inverting K-FAC’s approximation to the curvature matrix does not depend on the amount of data used to estimate it, which is a feature typically associated only with diagonal or low-rank approximations to the curvature matrix.

optimizationの奥の深さを少し感じることができたような気がする。Optimizationの方法を理解するだけならもうすこし簡単だと思うのだが、ハミルトニアン波動関数の式を目の前にしてoptimizationのアルゴリズムを理解することは、たいへん難しく感じる。

Ⅲ. RESULTS

ここから先は、他の手法と比較して、FermiNetの方がより正確に計算結果を出すことができるかということを示している。ちょっととばして先に進んでみよう。

 

 

APPENDIX A: EXPERIMENTAL SETUP

1. FermiNet architekuture and training

FermiNetは4層+最終層

各層は、one-electron streamに対して256のhidden units、two-electron streamに対して32のhidden units

最終層はlinear、Laplacianが良く定義されて、全領域で正になるように、4層全てにtanh nonlinialityを用いている。

特に指定がなければ、16の行列を用いている。

表1に示したSethらの通常のVMC (Variational Monte Carlo)の結果は、50のconfiguration state function (CSF)を用いている。

CSFの行列の数は系に依存し、その数は数百から数千である。

対応するFermiNetのパラメータ数は、約700,000であり、正確な数は原子数や分子構造によって異なってくる。

*以上がFermiNetの構造に関する本文より具体的な説明である。これでも、Fig.1の概略図との対応はわかりにくいが、なんとなくわかったような気にもなる。

 

optimizationとしてlocal energyを適用する前に、pySCFを用いて計算したHartree-Fock (HF)軌道に合致するように事前トレーニングを行っている。

この事前トレーニングは、optimizationに対して非常に効果的であるとのこと。

事前学習のlossの式が示されており、Hartree-Fock計算に用いるminimal basisはSTO-3Gであるとのこと。

少しとばす。

 

FermiNetはTensorFlowで書かれている。

20電子系に対しては、8台のV100 GPUを並列作動させている。より大きな系では16 GPUも用いられている。

etheneの計算には、8GPUで2日間を要するとのこと。

30電子のBicyclobutaneは、16GPUで1か月を要するとのこと。

デフォルトのパラメータが表4に示されている。ただし、Bicyclobutaneの場合には、batch sizaは半分にし、事前トレーニングの試行回数は桁で増やしているとのこと。

 

このブログの目的は、多電子系の電子状態の計算をANNを使ったプログラムで実行するところまでの道筋を記録することだった。しかし、ここまで見てきてわかったように、FermiNetは、計算コストが高すぎるように思う。

FermiNetの論文解読はこのへんで中断して、プログラムの中身をのぞいてみようか。

 

早速、GitHubにあるdeepmind/ferminetに行ってみましょう。

github.com

ここへは何回か来ているが、プログラムをちょっと覗いてみただけで、何もしていない。したがって、どうなるかまったくわからない。

FermiNet: Fermionic Neural Networks

An implementation of the algorithm and experiments defined in "Ab-Initio Solution of the Many-Electron Schroedinger Equation with Deep Neural Networks", David Pfau, James S. Spencer, Alex G de G Matthews and W.M.C. Foulkes, Phys. Rev. Research 2, 033429 (2020). FermiNet is a neural network for learning the ground state wavefunctions of atoms and molecules using a variational Monte Carlo approach.

Installation

pip install -e . will install all required dependencies. This is best done inside a virtual environment.

virtualenv -m python3.7 ~/venv/ferminet
source ~/venv/ferminet/bin/activate
pip install -e .

11月21日(土)

ここで壁にぶち当たりました。

GitHubのコードの利用の仕方を学ぶ必要があります。 

 

11月22日(日)

Introduvtion to GitHubを学習中

 

 

f:id:AI_ML_DL:20201110151235p:plain

style=158 iteration=500

 

f:id:AI_ML_DL:20201118002548p:plain

style=158 iteration=50

f:id:AI_ML_DL:20201118002845p:plain

style=158 iteration=5

 

Kggle散歩(November 2020)

Kggle散歩(November 2020)

 

11月は、25日にLyftが、30日にMoAが終了する。

Lyftは、計算資源の確保が課題であり、MoAは、Public LBとCVを天秤にかけながら、性能を上げる方法を探ることが課題である。

 

11月1日(日)

Generative Deep Learning by David Foster : CHAPTER 1 : Generative Modeling

discriminativeとgenerative:discriminativeは、training datasetに含まれる特徴を把握して、test dataが何であるかを予測する。generativeは、training datasetに含まれない、新たなデータを作(創)り出す。

generative modelの定義:

A generative model describes how a dataset is generated, in terms of a probabilistic model. By sampling from this model, we able to able to generate new data.

ここに馬の画像データがある。新たに用意した画像が馬かどうかを判別することが、discriminative(識別)であり、馬の画像データに含まれていない馬の画像をつくるのが、generativeである。馬の画像をつくるためには、作られた画像が「馬」でなければならないので、馬であることを、馬の画像から学ぶのである。

元の画像に含まれず、かつ、元の画像に含まれていたがごとく、「リアル」であることが、generative modelの性能を測るものさしになる。

The Rise of Generative Modeling:

2018年に、NVIDIAからStyleGAN(非常にリアルな顔画像を生成)が発表され、

2019年に、OpenAIからGPT-2(導入文から完全なテキストを生成)が発表された。

6ページから7ページにかけて、著者のgenerative modelingに対する考え方が、簡潔に表現されていて、その内容が非常に興味深い。

As well as the practical uses of generative modeling (many of which are yet to be discovered) , there are three deeper reasons why generative modeling can be considered the key to unlocking a far more sophisticated form of artificial intelligence, that goes beyond what discriminative modeling alone can achieve.

このあと、約40行にわたってそのthree deeper reasonsが説明されている。

うまく要約できないし、全文掲載するのもはばかられるので、3つのパラグラフのはじめの方の文章を転記しておく。

First, purely from a theoretical point of view, we should not be content with only being able to excel at categorizing data but should also seek a more complete understanding of of how the data was generated in the first place.

Second, it is highly likely that generative modeling will be central to driving future developments in other fields of machine learning, such as reinforcement learning (the study of teaching agents to optimize a goal in an envilonment through trial and error).

Finally, if we are to truly say that we have built a machine that has acquired a form of intelligence that is comparable to a human's, generative modeling must surely be part of the solution. One of the finest example of a generative model in the natural world is the person reading this book. Take a moment to consider what an incredible generative model you are.

 

11月2日(月)

MoA:

先週、GPUを使わないで、CPUだけでパラメータ調整を行った。CPUだけだと、少ししか走らせることができないので、最も早く結果が分かる、最初のFoldのVal_lossを使うことにした。

モデルの性能を上げるために、チューニングを行った結果、最初のFoldのval_lossの値を、公開コードの初期条件で計算した場合よりも小さくすることができた。

良い結果が得られるだろうと思って、GPUが使えるようになった土曜日に、全体の計算をして、commit, submitしたところ、CVもpublic LBも公開コードより悪くなった。

期待外れの結果になったのは、最初のFOLDにoverfittしたのが、その原因だろうな。

Public_dataにoverfittして、private_dataのスコアが悪くなるのと同じようなことだな。

DNNではないので、計算時間が短く、チューニングの作業は比較的簡単に行えるのだが、見えないprivate_dataに適合するモデルに仕上げるチューニングは、難しい。

 

11月3日(火)

MoA: 

今日は、モデルの不具合に気づいたおかげで、CVが少し改善した。(epochsを50にしてearly stop=Trueにすると、なぜか収束が悪くなる。どうしてそうなるのかわからないので、とりあえず、early stoppingを使わないようにした。)

SEEDを変えたモデルのアンサンブルの効果を調べてみた。その効果は意外に大きかったので、それならばと、本命のモデルに適用してみたところ、効果は実験に使ったモデルの場合の1/3程度しかなく、少しがっかりした。原因は、おそらく、実験に使ったモデルの方が、FOLD間でのval_lossのばらつきが大きかったので、SEED間でのばらつきも実験に使ったモデルの方が大きかったため、アンサンブルの効果も大きかったのではないかと考えている。

3000人以上が参加していて、同一スコアにたくさん並んでいる。

上位のスコアの公開コードを見ると、public LBはCVとは連動しているようには見えず、public_dataにoverfittingしているのではないかと思う。CVもpublic LBも良好なコードも公開されているので、それらに勝るモデルにするには、CVだけでなく、public LBもある程度の値になっていないとダメだろうけど、それがどのあたりなのかは、わからない。

 

11月4日(水)

MoA:

NNの特徴は、深さだと思うのだが、どうなんだろう。

非線形活性化関数を通過する毎に非線形性が増して、より複雑な関係性を繋ぐことができるのではないだろうか。

浅いNNは従来の機械学習に劣り、深くすることによって、従来の機械学習を凌ぐことができるのではないだろうか。

DNNの世界から表データが取り残されているように思っていたら、TabNetというのが考案されたようだ。

TabNet: Attentive Interpretable Tabular Learning
Sercan O. Arık and Tomas Pfister, arXiv:1908.07442v4 [cs.LG] 14 Feb 2020

ABSTRACT
We propose a novel high-performance and interpretable canonical deep tabular data learning architecture, TabNet.

TabNet uses sequential attention to choose which features to reason from at each
decision step, enabling interpretability and more effcient learning as the learning capacity is used for the most salient features.

We demonstrate that TabNet outperforms other neural network and decision tree variants on a wide range of non-performance-saturated tabular datasets and yields interpretable feature attributions plus insights into the global model behavior.

Finally, for the first time to our knowledge, we demonstrate self-supervised learning for tabular data, significantly improving performance with unsupervised representation learning when unlabeled data is abundant.

 

11月5日(木)

Study:

量子多体問題を解く鍵である多体量子状態を完全に(近似ではなく)表現する波動関数ニューラルネットワークで表現する方法が注目されている。それを初めて具体化したのが次の研究のようである。

Solving the Quantum Many-Body Problem with Artificial Neural Networks

G. Carleo and Matthias Troyer, arXiv: 1606.02318v1 [cond-mat.dis-nn] 7 Jun 2016

この研究に至る前夜の状況が次の総説にまとめられているようである。

THE NONEQUILIBRIUM QUANTUM MANY-BODY PROBLEM AS A PARADIGM FOR EXTREME DATA SCIENCE
J. K. Freericks, B. K. Nikoli´c and O. Frieder,  arXiv:1410.6121v1 [cond-mat.str-el] 22 Oct 2014

Generating big data pervades much of physics.

But some problems, which we call extreme data problems, are too large to be treated within big data science.

The nonequilibrium quantum many-body problem on a lattice is just such a problem, where the Hilbert space grows exponentially with system size and rapidly becomes too large to fit on any computer (and can be effectively thought of as an infinite-sized data set).

Nevertheless, much progress has been made with computational methods on this problem, which serve as a paradigm for how one can approach and attack extreme data problems.

In addition, viewing these physics problems from a computer-science perspective leads to new approaches that can be tried to solve them more accurately and for longer times.

We review a number of these different ideas here.

Keywords: Nonequilibrium quantum many-body problem; extreme data science.

 

MoA:

CVかpublic LBか、ということだけでなく、val_log_lossの単純平均も重要だと思う。

CVとlog_lossは比例していない。 

log_lossのFoldごとのばらつきが大きいと、CVが小さくなる傾向にあるが、どういう計算をしているのか、よくわからない。

優先順位は、val_log_loss > CV > public LBというところかな。

 

11月6日(金)

Study:

以前に掲載したかもしれないが、今日は、波動関数をNNで表現するところにフォーカスしたいと思う。

Ab initio solution of the many-electron Schrödinger equation with deep neural networks
David Pfau, James S. Spencer, Alexander G. D. G. Matthews, and W. M. C. Foulkes

PHYSICAL REVIEW RESEARCH 2, 033429 (2020)

f:id:AI_ML_DL:20201107001409p:plain

Deep neural network solution of the electronic Schrödinger equation
Jan Hermann, Zeno Schätzle, and Frank Noé, 

arXiv:1909.08423v5 [physics.comp-ph] 23 Sep 2020

f:id:AI_ML_DL:20201107001743p:plain

明日は、FermiNetとPauliNetを理解したうえで、簡潔な日本語で説明できるようにしようと思っている。

 

MoA:

CPUを使って、NNのチューニングを行っていた。

2層、3層、4層、および5層のNNについて、log_lossが最小になる条件を探している。

 

11月7日(土)

MoA:

GPUを使うとサクサク進むが、細部にこだわりすぎることがあるので、要注意。

log_lossを小さくしていくのは、簡単ではないが、log_lossが小さくなっても、submitしてみたときにpublic LBが大きい値になると、これでいいのだろうかと、悩んでしまう。

 

FermiNetとPauliNet:

原理を正しく説明しようとしているのだが、正しく理解するのが難しくて、原稿の締め切りに間に合わない!

 

11月8日(日)

MoA:

今日は、最も基本的なhidden_layerが2層のNNモデルに集中してチューニングした。

val_log_lossは、これまでになく小さくなったが、public LBスコアは、改善せず、むしろ悪化した。何に注力すべきか迷う。

learning_rate, batch_size, hidden_size, dropout_probabilityなどの変更は常にやっているが、今回は、これまで以上に、変化率を小さくして検討している。そうすると、パラメータ間の相関がこれまでよりもよく見えるようになったと思う。それもそのはず、見ている数値の桁数が違うのだ。4桁目、5桁目、6桁までじっくり見ていると、見えなかったものが見えてくるのだ。活性化関数による違いもよく見える。

 

11月9日(月)

今日は、FermiNetとPauliNetの説明文を作成しよう。

第一原理量子化学計算、変分量子モンテカルロ波動関数仮説

量子多体問題を厳密に解く

数原子、数十電子(2-30電子)を超えると計算機の能力を超える

近似計算しかできない

多体電子系波動関数ニューラルネットワークで表現する(ニューラルネットワーク量子状態:neural-network quantum states:NQS)

多体スピン構造の波動関数を、制限ボルツマンマシンによって表現する

ニューラルネットワークのパラメータ(多体電子波動関数)の最適化は、変分モンテカルロ法もしくは時間依存変分モンテカルロ法を用いて行う

PauliNet:ハートリーフォックベースラインや標準ジャストロー因子やバックフロー変換などの物理モデルから構成されているネットワーク

FermiNet:PauliNetの考案者らは、FelmiNetについて、物理学を組み込むことなく印象的な精度に到達している、と評価している:比較的単純な数学関数とディープニューラルネットワーク構造によって多電子系波動関数を表現

PauliNetは物理屋さん主導で、FermiNetは機械学習屋さん主導、の印象

 

11月10日(火)

DNNを用いた量子化学計算手法について、半ページほどにまとめた原稿を完成させて学会の編集部に送った。できれば、もう少し長い原稿を書きたいと思うが、それが読者に役に立つ内容にするためには、GitHubの公開コードを実際に使ってみて、実際に使うにはどうすれば良いのかを紹介できることが必要だな。

Kaggleの計算環境を使うのは筋違いだろうな。

パソコン環境だと、自分のGPUがもう古臭いからだめだろうな。

そうなると、google colabを使うことになるのか。 

 量子化学のブログを書いてみよう。

 

MoA:

dropoutとCVとpublic LBの相関を調べてみる。

自前の条件で計算した結果だけを比較してみると、dropoutは0.4以上よりも0.3以下の方がCVもpublic LBも小さくなる傾向がみられた。

public LBのスコアは、公開コードの条件では0.01839だが、自前の条件では0.0186+の後半の方だったのが、今日、やっと0.185+の前半の領域に入った。

CVが小さいところでpublic LBも小さくなってきたのは、良い傾向だと思っている。

今日は、CVを下げるために、hidden layerのユニット数の増減の幅をかなり小さくして、計算を繰り返した。パラメータの調整幅をこれまでにやったことがないくらいまで小さくしているので、まだまだ時間がかかりそうだ。

 

11月11日(水)

MoA:現在、3680チーム

今日もファインチューニングだ!

モデルの基本構造を変えずにCVを下げると、public LBのスコアの最後の桁が1だけ下がった。これを繰り返せばいいのだが、どんどん難しくなる。

 

11月12日(木)

MoA:現在、3730チーム 

今日もファインチューニングだ!

training中にあらわれるnanが気になりはじめた。

train_lossとval_lossがnanになる。discussionで問題提起して解釈や対策が書かれていて、その対策が役に立ったとの返信があるのだが、さっぱり理解できない。

コメントに気になる箇所があったので、weight_decayをデフォルトに戻したら、とんでもないことになった。

 

11月13日(金)

MoA:3762チーム

train_lossとval_lossがnanになる原因がわかった。

weight_decayの値を変えてみると、nanが生じやすくなったり、全く現れなくなることが、現象として把握できた。

weight_decayは、L2正則化のパラメータで、overfittingの抑制に効果があるということを、確認することもできた。

 

11月14日(土)

MoA:3798チーム

全結合層は2層、dropout=0.2、weight_decay=1e-6、こんな感じで、ようやく、0.184+になった。

気をよくして気合を入れて、CVを小さくすることができたので、期待してsubmitしたら、0.01858が現れてがっかりした。public_dataに適合しなくても、private_dataで良いスコアが出ればいいのだと思っていてもやはり気になるものだ。

何度も同じ言葉を並べてしまうが、頭を整理しながら進まないといけないな。

今日は、活性化関数や最適化関数をいくつか試してみて面白い結果も得られたので良しとしよう。

relu, leaky_relu, elu, seluなどを試してみたが、少しづつ違う結果になる。

reluでnanが発生しても、leaky_reluにすれば少し抑制され、さらに、eluにすればnanが現れなくなった。といっても、良いことばかりではない。reluでnanが頻繁に出現する条件では、eluで抑制できても、スコアは悪化するだけだった。

Adamの他に、AdamW, Adamax, SGD,などを試したが、Adamより良い条件は見つけられなかった。それぞれの特徴を生かすには、細かい調整も必要なので、良く調べてからでないと、どれが本当に合うのかは、わからない。

今日から1週間のGPUの割当は、37時間だが、今日だけで7時間使った。

 

11月15日(日)

MoA:

今日も、ちまちまと、チューニングしていた。

public LBのスコアは同じだったが、順位が少し変動した。 

 

11月16日(月)

MoA:

今日はじめて気がついた。

optim.lr_scheduler.OneCycleLR

これはすごい機能だと思う。

これに関わるパラメータの値によって、nanが現れたり消失したりする。

 

11月17日(火)

MoA:3,911 teams, 14 days to go

今日も、public LBを上げることに注力していた。

nanが発生しにくくなって計算できる領域は広がったが、public LBのスコアをよくする方向は、なかなか見えてこない。CVを下げるにはdropoutを大きくするのが効果的だが、public LBのスコアは良くならない。

それでもようやく0.01838に到達した。

 

11月18日(水)

MoA:3,958 teams, 13 days to go

今日もチューニング、チューニング、チューニング。

改善の見込みがありそうな条件だと思ったが、

CVもpublic LBも改善できなかった。

 

11月19日(木)

MoA:4,004 teams, 12 days to go

低スコアの公開コードが投稿されている。

なかなかやるもんだな。

今日もチューニング、チューニング、チューニング。

 

こんなことばっかりしとったら、あかん。

プログラミング技術が上がらん。

 

11月20日(金)

MoA:11 days to go

TabNetを勉強する予定だったが、進捗なし。

dropoutの比率に対するCVとpublic LBスコアの依存性を調べている。

 

11月21日(土)

MoA:4,072 teams, 10 days to go 

dropoutとの相関調査継続中。

 

TabNet:

TabNet: Attentive Interpretable Tabular Learning
Sercan O. Arık and Tomas Phister, Google Cloud AI
arXiv:1908.07442v4 [cs.LG] 14 Feb 2020

ABSTRACT
We propose a novel high-performance and interpretable canonical deep tabular data learning architecture, TabNet. TabNet uses sequential attention to choose which features to reason from at each decision step, enabling interpretability and more efficient learning
as the learning capacity is used for the most salient features. We demonstrate that TabNet outperforms other neural network and decision tree variants on a wide range of non-performance-saturated tabular datasets and yields interpretable feature attributions plus insights into the global model behavior. Finally, for the first time to our knowledge, we demonstrate self-supervised learning for tabular data, significantly improving performance with unsupervised representation learning when unlabeled data is abundant.

Overall, we make the following contributions in the design of our method:
(1) Unlike tree-based methods, TabNet inputs raw tabular data without any feature preprocessing and is trained using gradient descent-based optimization to learn flexible representations and enable flexible integration into end-to-end learning.
(2) TabNet uses sequential attention to choose which features to reason from at each decision step, enabling interpretability and better learning as the learning capacity is used for the most salient features (see Fig. 1). This feature selection is instancewise, e.g. it can be different for each input, and unlike other instance-wise feature selection methods like [6] or [61], TabNet employs a single deep learning architecture with end-to-end
learning.
(3) We show that the above design choices lead to two valuable properties: (1) TabNet outperforms or is on par with other tabular learning models on various datasets for classification and regression problems from different domains; and (2) TabNet enables two kinds of interpretability: local interpretability that visualizes the importance of input features and how they are combined, and global interpretability which quantifies the contribution of each input feature to the trained model.
(4) Finally, we show that our canonical DNN design achieves significant performance improvements by using unsupervised pre-training to predict masked features (see Fig. 2). Our work is the first demonstration of self-supervised learning for tabular data. 

とても良さそうな手法だけど、論文をいくら読んでもだめだな。

実際に使ってみないと。

GitHubに、TabNetが、いくつも出ています。

こういうのを使えないのがなさけない。

なんとかしなければ。

 

11月22日(日)

MoA:4,094 teams, 9 days to go

これまでよりスコアの良いコードを用いて、NNの部分だけ、チューニングしてみた。

自信を持って自分のチューニング結果をsubmitしたところ、最後の桁の数値が+2と+4になった。

公開するだけのことはある、と、感心するばかりである。

 

11月23日(月)

MoA:4,124 teams, 8 days to go

CVはほとんど変わらず、むしろ、わずかではあるが少し大きかったにもかかわらず、LBが、-4も下がった。 

こんなことがあると、CVが少し大きかったためにsubmitしていない計算条件がたくさん残っているのが気になる。その中に、宝物が隠れているかもしれない。

そうではなく、これが、もしかして、public dataへのoverfittingなのか?

 

11月24日(火)

MoA:4,122 teams, 7 days to go

昨日うまくいったベストLBモデルをさらに改良できないかとパラメータを変更してみたが、そう簡単にはいかない。

パラメータの、小さな変更によって改善されることを期待したが、いずれも、最後の桁が+2もしくは+3となった。

難しい。

 

11月25日(水)

MoA:

チューニングを繰り返すのみ。

月曜日にメダル圏内に入ったのに、もう、追い出されて、どんどん離れていく。

 

11月26日(木)

MoA:4,201 teams, 5 days to go

public LBスコアを上げることだけ考えてチューニングしている。

 

Lyft 

本日午前9時00分終了。

課題に適合するモデルの選択と、train時間の確保が、後半の課題だった。

データが膨大で、前処理が複雑にみえて、不十分な取り組みとなってしまった。

複雑なデータに取り組む練習をしないと、こういう課題はクリヤできそうにない。

 

<雑談>

自分は、この分野には、ディープラーニングから入った。データを呼び出し、それを、train_data, validation_data, test_dataに分け、DNNモデルに投入する。最初に使ったテキストでは、いわゆるデータの前処理は、簡素化されていた。ある程度、モデルが組めるようになったので、Kaggleに挑戦した。そこには大きな壁があった。データの前処理と後処理である。データサイエンスのテキストは、ディープラーニングのテキストとペアで購入していて、並行して勉強しようとしたのだが、面白くなかった。それに対して、ディープラーニングは、AIの歴史とともに語られ、インターネット、ビッグデータ、その集大成としてのディープラーニングというふうに続いていて、非常に興味が湧いた。

手元にあるデータサイエンスの本は、和訳で360ページくらいのものだが、機械学習の内容が始まるのは、165ページからである。単純にいえば、自分には、この前半部分の勉強が足りてない、ということになる。今日から、まず、前半部を勉強するとしよう。

 

Riid!:2,062 teams, a month to go

このコンペ、MoAが終われば集中して取り組むつもりだが、MoAはチューニングのみなので、計算の合間に、こちらも進める。

Riiid! Answer Correctness Prediction

Track knowledge states of 1M+ students in the wild

課題は、生徒の学習履歴から、正答率を予測することのようだ。

用いるデータは、EdNetと称するもののようだ。

EdNetというネーミングは、ImageNetを意識したものだろうか。

主催者がすでにそれらしい論文を出している。

SAINT+: Integrating Temporal Features for EdNet Correctness Prediction

DONGMIN SHIN, YUGEUN SHIM, HANGYEOL YU, SEEWOO LEE, BYUNGSOO KIM, and
YOUNGDUCK CHOI, Riiid! AI Research, Republic of Korea

arXiv:2010.12042v1 [cs.CY] 19 Oct 2020

 

11月27日(金)

MoA:4,232 teams, 4 days to go

最終日が近いので、とりあえず、LBスコアの良いモデルに対して、試行回数を増やすなどして、少しでも汎用性を高くしておこう。

試行回数を増やすと、順位が少し上がった。

 

  • Riiid AIEd Challenge
  • :2,076 teams
  • , a month to go

データベース、EdNetに関する論文を見ていたら、EdNetは、韓国の学生の約2年間にわたるTOEICの学習履歴データを収集したものであることがわかり、さらに、santaというワードが気になってgoogleで検索したら、次のような宣伝が出てきた。

SANTA TOEIC

世界的な学会から認定されたAI技術を搭載したTOEIC®︎学習ソリューションです。
“AIチューター”が解答傾向から苦手問題を推測し、あなただけのカリキュラムを構築。
解くべき問題だけに集中することで、短期間で大幅なスコアアップを実現します。

すでに、スコア予測システムは出来上がっていて(上記論文ではAUCが0.80前後)、商品に組み込まれているようだな。さらに性能を向上させることを狙って、Kagglerの知恵を拝借ってことなのか。

Time-series API Details

  • Refer to the starter notebook for an example of how to complete a submission. The time-series API has changed somewhat from previous competitions!

とりあえず、starter notebookを見る。

 

11月29日(日)

MoA:4,287 teams, 2 days to go

締め切りまで、あと2日、となった。

メダル圏内に0.01825が160件あまり、並んでいる。

公開コードがあるので、こういうことになるのだが、9日前に公開されたときには無視していた人たちも、間際になると、保険のつもりで使ってみるのだろうな。

かくいう自分も、最終投稿の2件のうちの1件はこれにしようかなと思って準備している。

 

11月30日(月)

MoA:4,332 teams

今日が実質、最終日だ。

とりあえず、メダル圏内に入った。

圏外で待つよりは、圏内で待つ方が、メダル獲得の可能性は高い、だろう、と思いたい。

 

12月1日(火)

MoA:4384チーム:終了

暫定結果だが、182位となり、銀メダル相当である。

このまま確定すれば、2個目のメダル獲得となり、エキスパートになる。

最終日の投稿結果を選んだことによって、銀メダル相当となった。

最終的に2件の投稿を選ぶのだが、このとき違うものを選んでいれば、違った結果になる。

過去に、メダル圏内の投稿結果を最終投稿として選ぶことができなかったことでメダルを逃したことが2回ある。1回は、public LBが良くなかったので仕方ないともいえるものであるが、もう1回は、Public LBスコアにこだわりすぎて、アンサンブルのし過ぎによるpublic_dataへのオーバーフィッティングを意識できなかったことによるものである。

さて、うまくいった原因を書きたいのだが、自分の今後の指針になるようなものは、残念ながら、いまのところ思いつかない。

 

 

f:id:AI_ML_DL:20201101113720p:plain

style=157, iteration=1

f:id:AI_ML_DL:20201101113848p:plain

style=157, iteration=20

f:id:AI_ML_DL:20201101113944p:plain

style=157, iteration=500

 

Kggle散歩(October 2020)

Kggle散歩(October 2020)

 

10月は、OpenVaccine(10/5:訂正10/6)とOSIC(10/6)とRSNA(10/26)が締め切りを迎える。

これらのコンペの中からメダルを1個獲得できれば、2個目となり、Expertにランクアップされる。

しかし、どのコンペも難しい。

OpenVaccine:メダル圏の外ではあるが近くにいる。(10/2追記:すごい勢いで遠ざかっていく、public LBでは勝負にならない)

OSIC:適正なパラメータセッティングの方向性が見えない。

RSNA:いまだに、戦う手段を持っていない。(OpenVaccineとOSICが終わってから検討する)

 

10月1日(木)

OpenVaccine:

アンサンブルの重みの検討:

最大値と最小値の差が2/1000程度ある6件のデータを用いたアンサンブルでは、単純平均の場合と比べると、重みづけにより、public LBは、2/10000程度改善した。

今の自分の順位だと、周辺のチームは数時間で2/10000くらい上がってしまうので、もっと効果的なスコアアップ手段がないとメダル圏内は難しい。

少しスコアが悪くても、スコアが近いものを複数合わせると良くなるので、今日検討した6件以外のデータについて、アンサンブルに使えるかどうか、明日、調べる。

10時間くらいで、メダル圏内との距離が、5/10000以上、大きくなった気がする。

13時間くらい前に、新たなコードが公開された。活発な議論が展開されている。

伝説のKagglerまで現れてコメントしている。(ただし、ネガティブなコメント?)

それにしても、参加していないようでも、ちゃんと、見ているんだね。

しかし、非常に難しい状況になってきた。

 

10月2日(金)

OpenVaccine:

メダル圏との差が2/1000以上になった。

チャレンジしないと、とても追いつかないし、追いつけない戦いはしたくないし、ここであきらめることもしたくない。(public_test_dataが9%と少ないので、どんでん返しにも少しは期待しながら・・・。)

まずは、アンサンブルの効果確認から始めよう。

メダル圏内が、0.239+となっているときに、3件の0.247+と4件の0.246+を利用できるかどうかを調べるのは無意味のように思うが、やってみよう。

それぞれの効果はそれなりに認められたが、最終結果への効果は、4/100000であった。

順位変動なし、というより、この作業中にも順位は下がった。

自分のアンサンブルのやり方では、public LB値は、最もよいモデルのそれよりも、2/1000くらい小さくなることがわかった。

自分の単一モデルの結果0.243+は、現在トップの0.228とは、6-7%くらい違う。

efficientnetの'b0'と'b7'くらい違うということか。

mrkmakr氏の公開コードの概要説明を転記させてもらおう。

training scheme

(1) train denoising auto encoder model using all data including train and test data

(2) from the weights of denoising auto encoder model, finetune to predict targets such as reactivity

rough network architecture

inputs -> conv1ds -> aggregation of neighborhoods -> multi head attention -> aggregation of neighborhoods -> multi head attention -> conv1d -> predict

this architecture was inspired by https://www.kaggle.com/cpmpml/graph-transfomer

最後にinspireされたプログラムとしてあげられているのは、CPMP氏の公開コードで、NFL Big Data Bowlコンペのものである。

 

(さきほど、スカパーのチャンネルを適当に変えていたら戦争映画にでくわした。途中からだったが、引き込まれて、最後まで見た。Darkest Hourというタイトルだった。)

 

10月3日(土)GPU:0/38, TPU:0/30

OpenVaccine:245/1543, 0.24148, 0.23846

現時点で、3/1000の改善が必要。

単独のスコア0.24353を0.24053まで下げる方法を探す。

最初に試した結果も、2番目に試した結果も、散々(0.245+)だった。

深夜までトライしていたが、0.24353すら超えられない!

 

OSIC:309/2063, -6.8072, -6.8070

検討中

 

10月4日(日)

OpenVaccine:

新たに得た3件の予測データをアンサンブルに追加したが、スコアは改善されなかった。

ともかく、最良と思われる結果を、締め切りまで、計算し、submitしつづけるだけだ。(やけくそ!)

ようやく単独で0.242+となったが、ちょっと遅かったかな。

メダル圏内はすでに0.237+にまで下がっているので、このスコアでは、届かない。

計算資源を節約しながら(時間制限を受け入れながら)ハイスコアを出すには、まだまだ、技術が足りないということだ。

 

10月5日(月)

OpenVaccine:

昨夜計算した結果はcommit中のトラブルにより失ったため、計算は終了した。あとは、新たに得た2件の結果をアンサンブルに追加してsubmitするだけである。

今、public LBで320番くらいで、新しい結果をどう組み合わせても、メダル圏内に入ることはないが、最後の5回のsubmissionで最善をつくそう。

コンペ挑戦終了。

0.24105, 311st(10/5/10:57)

 

OSIC:

締切日の前日にして、GPU割当時間を使い切った。

といっても、結局、方向が定まらず、気になる計算条件を煮詰めようとして計算を繰り返していたが、見えない相手に対して、どう攻めたらよいのか、わからないままである。

88回のsubmit履歴が残っているが、どのモデルがprivate test dataに対して最も確からしい予測結果を出せるのか、判断基準がわからないままである。

コンテストのために用意されたデータではなく、現実世界で使われているデータで、よく整理されたデータというよりは、医療現場で蓄積されたデータを取捨選択することなくかき集めてきたもののように思う。

それだけに、このデータから何が言えるのかを根拠をもって説明できるだけのモデルでなければならないのだろうが、残念ながら、そこには辿りつけていない。

 

10月6日(火)

OpenVaccine:

最終提出期日を間違っていた。

昨日ではなく、今日だった。

 

OSIC:

今日が投稿最終日だ。

 

RSNA:

20日間は、このコンペに集中しよう。

現在、330チームがリーダーボードに掲載されている。

A pulmonary embolism (PE) is caused by an artery blockage in the lung.

Currently, CT pulmonary angiography (CTPA), is the most common type of medical imaging to evaluate patients with suspected PE. 

In this competition, you’ll detect and classify PE cases. 

 

10月7日(水)

OSIC:

暫定結果は、1504番目

気合十分で始めたコンペだったので、この結果は、非常に残念である。

結局、最後の2回のsubmissionを選んだ。

public LBの最も良い値を選んでいたら、1120番くらい。

submitした中で最も良かったのは、最終順位で106番で、銀メダル相当だった。これは、NNのフィッティング結果が良かったのでsubmitしたのだが、public LBは良くなかったし、これを選ぶ特段の理由がなかったので、選ばなかった。

これは、順位が大きく変動するだろうという予想どおりとなったが、どうすれば良いか、どれを選べばよいかは、わからなかった。

 

OpenVaccine:

暫定結果は、379番だった。

メダル圏外ということでは、残念な結果だが、これは、ほぼ、予想通りである。

普通に計算して、その結果をアンサンブルしただけなので、大きく上がることも下がることもないだろうと思っていた。

 

RSNA:

データが非常に大きく、inferenceに長時間を要することから、コードコンペでありながら、inferenceに限るということだが、こういうのは、自分にとっては初めてのことである。

画像の扱いも、少し、特殊であり、train画像の枚数も多い。

データは、大きすぎて(900 GB以上)ノートパソコンにダウンロードできない。

 

10月8日(木)

RSNA:379チーム

今日は。trainコードとinferenceコードを準備しよう。

参加者が少ないためか、公開コードが少ない。

trainコードの準備

・学習させたモデルはsaveする。

・saveしたモデルは、kaggle datasetとして保存する。

inferenceコードの準備

・ 学習済みモデルのload:作成したkaggle datasetから学習済みモデルを読み込む。

これだけのことなんだが、モデルの保存・読み込みは、これまで、それほど意識して使ったこなかったが、これを機に、使えるようにしよう。

モデルの保存等に関するコード:A. Geronさんのテキスト314ページ

Saving and Restoring a Model

When using the Sequential API or the Functional API, saving a trained Keras model is as simple as it gets:

    model = keras.models.Sequential([...]) # or keras.Model([...])

    model.compile([...])

    model.fit([...])

    model.save('my_keras_model.h5')

Keras will use the HDF5 format to save both the model's architecture (including every layer's hyperparameters) and the values of all the model parameters for every layer (e.g. connection weights and biases).

It also saves the optimizer (including its hyperparameters and any state it may have).

 

<雑談>

AIを極めることに取り組んできたが、そこから遠ざかっている自分の姿が見える。自分に見えているAIは、自分が見てきた過去のプログラミングでは成し得なかったことを成し遂げているが、それらが、ものすごく大きなものに見えることもあれば、想像していたものとは全く違って見えることもある。 (twitterに書こうとしてやめた)

今のプランは、メダル獲得競争と、メダル獲得を強いモチベーションにして、様々な課題解決のためのプログラミング技術を習得しながら技術レベルを高め、様々な課題に対してより高いレベルの解決方法を模索していくことであり、その先に、次の世代のAIを考え、構築していこうというものである。

今の自分の最大の弱みは、英語力である。このハンディーは非常に大きい。マニュアルをいちいち和訳していては進まないし、プログラムは英語そのものだから、プログラムもマニュアルも論文も書籍も斜め読みできる英語力がなければだめだ。

そう思って、昨年の6月頃にdeep learningを勉強するためのテキストとして、F. Chollet氏の著書を購入し、その後も、何冊か英語のテキストを購入してきた。しかし、読まなければ、書かなければ、使わなければ、英語力は身に付かない。

気がつくと、Google翻訳やオンライン翻訳に頼っている自分がいた。英語のテキストが理解できずに和訳を買って見比べながら読むこともやってみたが、新しい概念は和訳したってわからないのだ。定義や応用事例を見てその意味を理解していくのだから、1つの概念を理解するために日本語と英語の両方でやるなんてことは非効率の極みである。

 

10月9日(金)

Riiid!:

Answer Correctness Prediction

Track knowledge states of 1M+ students in the wild

The goal is to accurately predict how students will perform on future interactions.

If successful, it’s possible that any student with an Internet connection can enjoy the benefits of a personalized learning experience, regardless of where they live.

面白そうだな。オンライン学習が進めば、学習プロセスに関するデータが蓄積され、各人に合った学習プロセスを提供できるようになるということか。

学習の経過がフィードバックされるようにプログラムしておけば、自律的に成長していくということか。個々人の成長に合った学習プログラムが提供できればいいな。

各人が、自分で、自分の脳にプログラミングしているために、その能力の違いが学力の違いを生じさせているのだろう。そうすると、自分で自分の脳にプログラミングできない人にとっては、このような学習システムは重要なものになるのだろう。

学力に応じたプログラムが自動的に生成されるようにすればいいのだろう。

Tailoring education to a student's ability level is one of the many valuable things an AI tutor can do.

Your challenge in this competition is a version of that overall task; you will predict whether students are able to answer their next questions correctly.

You'll be provided with the same sorts of information a complete education app would have: that student's historic performance, the performance of other students on the same question, metadata about the question itself, and more.

公開コードのパラメータを少し変えて投稿してみた。

NNよりもLGBMの方が良さそうだ。

 

10月10日(土)

RSNA:

10月8日に検討した結果を元に進めるが、全体の流れをチェックしやすいように、再スタートする。

1.kerasで書かれた公開コードを使ってみる。(trainを含んでいるので切り離すが、trainを含んだままでcommit->submit->scoreまで進むかどうか調べてみる)

2.コードコンペなので、internet offにしなければならないが、このコードは、'imagenet' pretrained modelのweightsを、インターネット経由でダウンロードするようになっている。

3.kaggle kernelで使うdatasetを準備する。

 tensorflow/kerasのサイトの情報から、'imagenet' pretrained modelのweightsをダウンロードし、kaggle datasetに格納する。

4.このデータセットを、kaggle kernelの入力データに追加する。

5.train+inferenceプログラムを実行してcommitする。trainもinferenceも実行時間を設定しているので、各1時間で試してみる。実験なので、GPUは使わないでやってみる。

6.submitまでは無事に済んだ。

 ここで、スコアが表示されるかどうかによって、次の対応が決まる。

7.スコアが出た。0.975(0に近い方が良いスコア)であった。

 ということは、trainとinferenceが共存しても大丈夫ということだ。

8.GPUをonにすると、trainは5倍以上速くなるが、inferenceは2倍程度しか早くならないことがわかった。

9.試しに、512x512のデータをefficientnetB5でinferenceすると、GPUを使っても1時間に50kくらいしか処理できなかった。したがって、trainとinferenceの両方を含むコードでは、9時間の制限時間でも不足する。それだけでなく、大きなモデルで大きな画像を処理すると、inferenceだけのコードでも、制限時間内にinferenceが終わらない可能性が出てくる。ということで、trainとinferenceは分離しよう。

10.と言いつつ、0.975(これはとんでもなく悪いスコアで、トップは0.149、0.325とか0.434がたくさん並んでいる)を上回るスコアになるかどうか確かめるための計算を行う。CPUのみで、trainとinferenceのそれぞれに、4時間の時間制限をつける。0.975のときは、1時間の時間制限であった。どうなるか楽しみだが、計算とcommitを合わせて16時間、それにスコア計算の時間が加わるので、20時間以上かかりそうだ。

・こういう長い時間を要する場合は、いろんな不具合が生じて、何日もかかることがあるので、気長に、楽しみながらやるのがよい。

 

10月11日(日)

RSNA:

悪い予想が当たった。朝起きると、次のメッセージを残して、計算が止まっていた。

Your notebook tried to allocate more memory than is available. It has restarted.

停止していたのは、inferenceの途中だったので、train中の情報がメモリーに蓄積されていたのが、まずかったのか。ともかく、途中経過がわからないと対策のしようがない。

'view session metrics'を'on'にしておけば、メモリーの使用状態が、リアルタイムでわかる。(眠っていたらわからないけど)

途中経過を見ているところだが、Diskではない。RAMの使用量(max 16GB)が、14GBから徐々に増え、50分くらいで16GBに到達し、それ以降は、なんらかの調整機能が働いているようで、15.4-15.9GBあたりで推移している。

GPUをonにしたらどうなるのだろうか。:RAMは16GBから13GBに割り当てが減少するので直接比較できない。GPUのRAMとの関係もわからない。GPU併用との大きな違いは、CPUの稼働率が300%を超えていたのが、120%以下に下がったこと。ともかく、途中で停止せず、予定の計算を最後までやってくれたらそれでいい。

順調に進んでいるように見えていたが、one batch timeが、inferenceの進行とともに長くなっている。バッチあたり13秒くらいで始まったのが、1時間を過ぎるころには2倍くらいかかっている。

予定の3時間まであと25分のところで、同じメッセージYour notebook tried to allocate more memory than is available. It has restarted.があらわれて停止した。

嫌なパターンだ。

どうしたものか。

モリー使用量が問題なら、batch_sizeを下げれば良かろうと思って500から250に下げると、処理時間が倍ほどかかりそうで、途中でやめた。batch_sizeが原因かどうかもわからず下げるより、上限を探ろうと1000に設定してみた。理由はわからないが、とりあえず最後まで計算が進んだので、ひとまずOK。

さらに条件検討してみよう。メモリーコントロールを学ばないといけないようだ。プログラムコード中に、del modelとか、del x,とか、見かけたような気がする。

とりあえず、inferenceもできるようになった。しかし、スコアがおかしい。最初のスコアは、一部の結果しか得られていないから仕方ないのだが、inferenceは完了したにもかかわらず、スコアがそれほど良くならない。

 

10月12日(月)

RSNA:

predictionの割合とLBスコア:53k/147k:0.975、88k/147k:0.934、147k/147k:0.862

 train:efficientnetB0、256x256、25k-125k/1790k 

いまは、predictionが進めば、スコアが少しづつだが、良くなっている(値が小さくなっている)、というレベル。

次は、predictionの後処理を調べてみよう。

evaluationを見ているのだが、よくわからん。

 

10月13日(火)

RSNA:

うまく動き出したと思ったのだが、submitした後のスコアリング中にNotebook Timeoutが発生した。

なぜエラーになるのかわからない。

 

Kaggle cources:

Kaggleから、Intro to Deep Learningの案内が来た。

昨年、deep learningを本格的に勉強し始めたころは、Kaggle minicource ?、には、たいへんお世話になっていたのだが、もの足りなくなって、data campを利用したり、テキストを追加購入したりして勉強していたのだが、ある程度習得したつもりで、あとは、応用だとばかりに、Kaggleコンペにのめりこんでいるところである。

しかしながら、課題に取り組んでみると、自作のモデルでは、良い性能が出せなくて、いつしか、公開コードをフォークするのがあたりまえのようになってきた。

こういう状況をみすかされたわけではないと思うが、良い機会ととらえ、勉強してみようと思っている。

昨晩は、YouTubeDeep Learning State of the Art (2020) | MIT Deep Learning Seriesを聴講したが、お話は、いくら聞いても身に付かないと感じていたところである。

入門レベルだが、英語の勉強を兼ねて、取り組もう。

 

10月14日(水)

mail from Kaggle:

You’re not too far from receiving a completion certificate!

f:id:AI_ML_DL:20201014093748p:plain

For every course you complete on Kaggle, we’ll issue an official certificate that celebrates the progress that you’ve made in your data science and machine learning journey.

手を付けたはいいが、ほったらかしにしていたら、こんなメールが届いた。

今月中に、全コースの終了証をもらえるように、がんばってみよう。

 

<雑文>

ここ2,3日、頭が重い。なぜかと考えてみた。脳になんらかの負担がかかっているということなんだろうな。脳には、体のあらゆる情報が集まっているのだから、頭が重いのは、体のどこかに不具合が生じているということだろう。ここ2,3日の変化と言えば、1週間くらい前から、ダンベルを持ち出して、腕力のトレーニングを始め、数日前からは、push ups(腕立て伏せ)の回数を増やそうとして、計算の合間に、強めのトレーニングをしてきた。今日は、肩から上腕部にかけて痛みがあり、同時に、頭の重さを強く感じるようになった。こうなると、トレーニングをやめてしまい、三日坊主に終わってしまうことになるんだろうな。負荷を調整しながら、トレーニングを続けよう。

 

RSNA:

まだ、trainとinferenceの両方を含むプログラムを使っている。

性能アップのためには、十分なtrainingが必要であり、trainとinferenceを分離する必要がある。これが、まだうまくいっていない。

train modelは、detasetに入れて、inference notebookの入力データに追加して、読み込もうとしているのだが、・・・。

今日は、trainとinference共存で、trainをかなり多くしてみたところ、inferenceに移ってからの処理速度が遅くなった。負荷がかかってるなという気がしてから30分くらいの間にプログラムが停止した。

GPU使用、'B0', 256x256で3エポックでも18時間くらいかかりそうなので、もうこれは、単にtrainとinferenceを切り離せばよいというものではないことを確信した。

ここからメダル圏内に入るために、trainにTPUを使おうと思う。当初からそうしないとだめだろうなというところにきてしまった。

ぼちぼち勉強しながら前進しよう。

 

Winner's Interview:Tweet Sentiment Extraction

Kaggleからのメールを見て、インタビューの一部を聴講してみた。2位は日本人3名のチームだった。説明内容もトークも良かった。あたりまえだが、レベルが高い。雲の上の人たちだなと感じてしまう。

 

intro to machine learning:

ぼちぼち勉強中。

 

10月15日(木)

RSNA:

スコアの良いコードが公開されていたので、利用させていただいた。それでもメダル圏外である。公開したチームは、(当然)それより良いスコアで上位にいる。

関連するdiscussionから、trainには、相応の計算資源と計算時間(+コーディング+デバッグ)が必要であることがわかる。

trainに用いたコード(例)も公開されている。

この公開コードによって、Project MONAIの存在を知った。

https://docs.monai.io/en/latest/:以下、ここから引用

Project MONAI

Medical Open Network for AI

MONAI is a PyTorch-based, open-source framework for deep learning in healthcare imaging, part of PyTorch Ecosystem.

Its ambitions are:

  • developing a community of academic, industrial and clinical researchers collaborating on a common foundation;

  • creating state-of-the-art, end-to-end training workflows for healthcare imaging;

  • providing researchers with the optimized and standardized way to create and evaluate deep learning models.

Features

The codebase is currently under active development

  • flexible pre-processing for multi-dimensional medical imaging data;

  • compositional & portable APIs for ease of integration in existing workflows;

  • domain-specific implementations for networks, losses, evaluation metrics and more;

  • customizable design for varying user expertise;

  • multi-GPU data parallelism support.

Modules in v0.3.0

MONAI aims at supporting deep learning in medical image analysis at multiple granularities. This figure shows a typical example of the end-to-end workflow in medical deep learning areaimage

MONAI architecture

The design principle of MONAI is to provide flexible and light APIs for users with varying expertise.

  1. All the core components are independent modules, which can be easily integrated into any existing PyTorch programs.

  2. Users can leverage the workflows in MONAI to quickly set up a robust training or evaluation program for research experiments.

  3. Rich examples and demos are provided to demonstrate the key features.

  4. Researchers contribute implementations based on the state-of-the-art for the latest research challenges, including COVID-19 image analysis, Model Parallel, etc.

The overall architecture and modules are shown in the following figure: image

これまでに、MONAIを見たり聞いたりしたことがない。情報収集力に問題ありだな。

0.1.0-2020-04-17となっているので、半年前に公開されたということか。

PANDAとTReNDSのdiscussionでは話題になっていたようである。

特に、TReNDSでは、discussionで7件、notebookで1件、検索でひっかかった。

discussionで多くでてきたのは、上位者が入賞記事でMONAIに言及していたため、すなわち、上位入賞者はMONAIのことを4か月以上くらい前から知っていて使っていたのである。さすがだな。

Kaggleは、100 ppmレベルの違いを競っていて馬鹿らしく見えるときもあるが、さらに上を目指すために、新しい優れた技術を探し当てて利用し、あるいは、それらを創り出すきっかけになっているのだろう。

 

Intro to Machine Learning:

初歩の初歩だけど、あらためて、やり直してみると、最近はプログラムを一から書いていないからだろうな、解説やコード例を何度も見返さないと正しいコードが書けなくなっている。

 

10月16日(金)

Intro to Machine Learning:

本日22時46分、やっと終了した。過去にsubmitまでやった履歴が残っていたが、記憶に残っていたのは少なかった。

 

Bonus Lessons:Intro to autoML:

google cloud autoMLの宣伝?ひとまず中断!

 

Intermediate Machine Learning:

2019年9月14日に終了していた。

記録が残っているのだが、記憶に残っていない。

気がつけば、ボケ老人になっていたということか。

1年前は、3時間で片付けようとか、3日でやってしまおうとか、1週間もあればできるとか、3か月後にエキスパート、6か月後にマスター、1年後にグランドマスターとか、言っていた。

そのようなノリで、このコース:Intermediate Machine Learning:も、斜め読み(英語の斜め読みはいい加減だったと思う)とコピペで終了したのかもしれない。正確には思い出せないが、じっくりと腰を据えて取り組んだものではなさそうだ。

PythonがYour Completedの中に入っていたので、中を見たが、とても理解できているとは思えない。とにかく、Coursesを、全部、やりなおそう。

 

10月17日(土)

RSNA:

パラメータを変えてRun, commit, submit, スコアに変化なし。

 

Cources:Pandas

英文の単語の配置を変更して少し記号を追加すればコードになるのに、日本語が間に入ってしまうから、難しくなる。それだけのこと。

Lessonは、TutorialとExerciseに分かれていて、Tutorialのテキストを読み、Exerciseの各問題を解く(コードを入力する)、ということだと思っていて、Tutorialは読むだけだったが、Editorを動かせば、例題のコードを好きなように変更して、コードの動作確認をしながらコーディングを学ぶことができる。いまごろ気付いた。

 

10月18日(日)

RSNA:

進捗なし。

 

Cources:Pandas

Create variable centered_price containing a version of the price column with the mean price subtracted.

(Note: this 'centering' transformation is a common preprocessing step before applying various machine learning algorithms.)

centered_price = reviews.price - reviews.price.mean()

Exercise中にYour notebook tried to allocate more memory than is available. It has restarted. このメッセージが現れた。全く、理由がわからない。

リスタートしたら、こんどは、このメッセージがすぐに現れて、停止した。

 

Lyft

フォークして実行するだけ。だめだな。進歩無し。

 

10月19日(月)

今日は、朝から、Cheatingに関する議論を眺めている。

Cheatingは不正行為全般を指しているので案件ごとに内容が異なり、対応も異なるが、詳細を記することは、それを真似た不正が生じる恐れもあり、対応策にしても明確に示すのは難しく、検討のさなかにあるということである。

Plagiarismの話題では、盗作といえば、公開コードに関するものだが、公開コードを使って計算して投稿すること自体が問題だという人もいる。これを許容していることがKaggleの特徴であり、これ自体は問題ではない。

問題は、Kaggleのランク付けと関係しており、公開コードのupvote数およびその件数によってランクが上がり、コンペのランクと同じ呼称、エキスパート、マスター、グランドマスターが与えられる。この公開コードでランクアップを狙う過程で盗作があるということである。コードを販売して利益を得ているのではないが、公開コードへの投票が自分への投票になるということにおいて、栄誉という利益を得ていることになり、それが、著作権を盗んでいることになるのである。

論文を書いたことのある人はわかると思うのだが、著作物は、そこで使われている文章、図面、手段、理論などの出典を明らかにすることと、著作者の許諾を得ることは必須であるが、それを理解しない人が多いということである。

こういう決まり事は、体得していないとわからないものである。SNSで発信する場合も同じ縛りがあるのだが、個人使用と公開との境界があいまいになり、放置されていることが多い。

Plagiarismに関する議論で、誰かが、盗作者に対しては、きちんと取り締まるべきであり、盗作か否かの境界を明確にし、担当者を増やすなりしてきちんと対処してほしいということをKaggleに対して要望していた。これに対して、Kaggleの担当者の1人が、そのとおりであるが、全体のバランスも勘案しながら良い方法を検討していくと述べた。実社会でもそうだが、訴えがなければ、裁判は始まらず、訴えができるのは、原則として、損害を被った当事者であることから、利害関係のない人から盗作の指摘があっても、主催者が事実関係を調べるべきである、ということにはならない。

コンペは賞金が絡むので不正を見逃すことはできないが、それ以外は、当事者がKaggle参加者であれば、ゆるくしておいてもよさそうな気はする。

最近、GitHubから引用した人が引用元を明示していなかったことを、制作者に指摘されているのを見た。これは非常識すぎると思った。GitHubには、ライセンスの種類が明記されており、表示が必要な場合には、表示の仕方が明記されている。

 

RSNA:

STARTER DATASET: Train JPEGs (256x256)

This competition is challenging due to the huge dataset size. In addition, people may not be familiar with medical imaging and CT scans.

To lower the barrier to entry to this competition and to encourage more people to participate, I have converted all of the DICOM images into JPEGs (about 52GB), 256x256 pixels (standard is 512x512).

GMIan Pan氏が、1か月も前に、コンペに参加してもデータが大きすぎて、手も足も出ない者に対して、このようなデータセットを作っておられたことに気付かなかった。

 

Cources:Pandas

学習中のエラーの原因は、コードの書き間違いだった。'.'とすべきところに'/'が入っていたのが原因だったようだ。しかし、メッセージの意味とのつながりがわからない。

とりあえず、エラーは解消し、次に進めるようになった。

 

今日のスロージョギング:4.2 km, 46 min

 

10月20日(火)

Cources:Pandas

ようやく、一通り終えた。TutorialとExerciseがペアになっているので、Tutorialで学び、Exerciseで学んだことを確認するものと思ったが、そうではない。両方を合わせて1つであり、両方合わせても、Pandasのごく一部にすぎない。ということは、このレベルのことは、スイスイできるようになっていなければならないということだろう。

 

Cources:Data Visualization

Progressが53%になっているので半分くらいやったのかなと思ったら、Tutorialをすべて眺めただけだった。ということで、Exerciseにとりかかろう!ではなくて、Tutorialの最初から、英文で内容を理解しよう!

genre:ゲンレと発音していて、ジャンルの意味だとは知らなかった。こんなレベル!

categorical scatter plot:

sns.swarmplot(x=candy_data['chocolate'], y=candy_data['winpercent'])

f:id:AI_ML_DL:20201020201216p:plain

作図は形式的にやっていても得るものは少ない。表から直観的に概要を捉えたうえで、仮説を立てながら、図示し、図から関係性を定量的につかんでいく、というような感じで進めていくことができなければ、コードも頭に入らない。1年くらい前に取り組んだ時には、表の意味を理解することに、ものすごく手間がかかって、結局、放り出していたのだろうと思う。

 

RSNA:

何かやれることはないかと考えていただけである。

 

10月21日(水)

自主学習:ニューラルネットワークと第一原理計算

最近の状況をA4半ページ以内のスペースで紹介することが直接の目的。

引用論文は次の3件にするつもり。

1)  D. Pfau, J. S. Spencer and A. G. D. G. Matthews, Phys. Rev. Res. 2, 033429 (2020)

Ab initio solution of the many-electron Schrödinger equation with deep neural networks.

2)  J. Hermann, Z. Schätzle and F. Noé, arXiv:1909.08423v5 [physics.comp-ph] 23 Sep 2020

Deep neural network solution of the electronic Schrödinger equation.

3)  K. Choo, A. Mezzacapo and G. Carleo, Nat. Commun. 11, 2368 (2020)

Fermionic neural-network states for ab-initio electronic structure.

1番目の論文では、FermiNet、2番目の論文ではPauliNet、という略語が用いられているが、3番目の論文では、どちらの略語も使われていない。

 

RSNA:

2~3日、見ていない間に、ハイスコアのコードが公開されたようだ。

とりあえず、フォークさせていただいて、実行してみる。

commit, submitでスコアが出ると、そのスコアを上げる方法はないものかと思い、コードをながめまわすことになるのだが、このときに、経験値が生きてくる。

ハイレベルな人たちは、自分のコードと比較して良いところを取り込むだろうし、組み合わせの上手な人は、いろいろな公開コードから使えそうなパーツを借りてきて、組み上げていくんだろうな。このときに忘れてはならないのは、それぞれのパーツのオリジナルの引用元を明示しておくことだな。オリジナルが分からない場合でも、最低限、直前の引用元を明示しておくことが必要だな。

Kaggleのmicro courceを少し勉強しただけでも、コードは理解しやすくなるものだし、フォークしたコードのチューニングを繰り返している間も、少しづつはコードの理解が進んでいくものだ。

時にはレベルは低くても自前のモデルにこだわるのもいいし、時には、ベースモデルに、パーツを組み合わせていくのもいいし、ハイレベルのモデルからコーディングを学ぶのもいいし、いろんな使い方をして、前進していけばいいんだ。

とにかく、立ち止まらないことが大切だろうな。

 

10月22日(木)

RSNA:

昨日計算した結果は、timeout errorであった。パラメータの値の変更が裏目に出たようだ。公開コードの理解を進め、改善の可能性を探る。

 

自主学習:ニューラルネットワークと第一原理計算

4)  Z. Schätzle, J. Hermann and F. Noé, arXiv:2010.05316v1 [physics.comp-ph] 11 Oct 2020

Convergence to the fixed-node limit in deep variational Monte Carlo

・PauliNetとFermiNetの違い(同一内容の異称かどうか調べる)

・variational quantum Monte Carloからの改善点と発展性

45年くらい前に最も興味のあった分野なんだけど、言葉に慣れても、量子化学計算の式の理解力が不足しているために、途中で思考が途切れる、あるいは、停止する。それでも、当該分野の最近の展開を、インパクトのある文章に仕上げなければならないのだ。 

 

10月23日(金)

RSNA:

メダル圏内が見えてこない。

 

micro-cource:Data Visualization

f:id:AI_ML_DL:20201023090554p:plain

 

micro-cource:Data Cleaning

1. Handling Missing Values

Exerciseのデータベースが、building permits(建築許可)である。こんなデータに興味はない。そうすると内容を考えずに形式的に解答してしまう。やる気が失せることもある。NaNとなっている理由が理解できなければ、その次の処理の方法とその理由を理解することが難しくなる。データの意味が分からないと、そのカラムを無視して良いのか、仮のデータを代入すべきかなどを正しく判断できない。

Tutorialのデータはnfl_dataで、これも、面白いものではない。そのために、つい、読み飛ばしたり、内容を理解しないままに形だけ真似てしまって、必要なコードが頭に入っていなかった。Kaggleのコンペではよく出てくるようだ。アメフトのルールをある程度知らないと理解できないことが多い。

好き嫌いや興味の有無は、技術習得の段階では、邪魔者でしかない。

興味が無くても、その内容を理解して、必要な技術を1つづつ習得していかなければならない。

2. Scaling and Normalization

3. Parsing Dates

4. Character Encodings

5. Inconsistent Data Entry

 

10月24日(土)

RSNA:

final submission deadlineまであと3日となった。5日前に公開されたコードのLBスコアは、100番から320番まで並んでいる。3日前は、およそ、60番くらいから260番くらいまで並んでいた。ということは、3日間の間に、40名くらいが、0.233を超えていったということになる。

trainからやりなおせるなら、画素数を増やして、EfficientNetB0をB5以上にするとか いうことになるのだろう。

ハイスコアの公開コード、5回ほど、パラメータを変えて計算してみたが、予測データに変化がなかった。ようやく6回目にその値が変わったので、結果を楽しみに、commitしていたら、並行してmicro-courceのexaciseをやっているときに、パソコンがフリーズした。1時間くらいして復帰したが、動作不安定となった。commitは終了していて、submitまでできたが、スコアが出るかどうか不安。

ほぼ同じ条件で、再計算中。---> エラー発生(上記エラーの影響だろうな:windows10の性能が悪いということだろうな:4時間半のロス)

同一条件で再計算。結果は、0.696と、ひどいものだった。悪化させただけだ。

先ほど、別の条件で計算している途中で、あと1時間でメンテナンスのためコンピュータを停止するからcommitするようにとのメッセージがあった。

計算途中でcommitするとはどういうことなのだろうか。

途中の状態が維持されて、その状態から再開されるというのだろうか、やったことないからわからないけど、うまくいきそうに思えない。

何か仕掛けがあるのかどうか、どこかで時間をとって、調べてみよう。 

 

micro-cource:Data Cleaning:scaling and normalization

# for Box-Cox Transformation
from scipy import stats

# for min_max scaling
from mlxtend.preprocessing import minmax_scaling

in scaling, you're changing the range of your data

f:id:AI_ML_DL:20201024111020p:plain
in
 
normalization
, you're changing the shape of the distribution of your data.

f:id:AI_ML_DL:20201024111057p:plain

これは、非常にわかりやすい説明だ。

重要なのは、スケーリングや規格化をいつ、どこで(どのような場面で)、どのように使うかということだろうな。

micro-cource:Data Cleaning:parsing dates

earthquakes['date_parsed'] = pd.to_datetime(earthquakes['Date'], format="%m/%d/%Y") 

よくわからんが、10/24/2020 とか、2020-10-24とかの期日の表示方式に関すること。

micro-cource:Data Cleaning:character encodings

# helpful character encoding module
import chardet

UTF-8 is the standard text encoding. All Python code is in UTF-8 and, ideally, all your data should be as well. It's when things aren't in UTF-8 that you run into trouble.

Try using .decode() to get the string,

then .encode() to get the bytes representation, encoded in UTF-8.

micro-cource:Data Cleaning:inconsistent data entry

import fuzzywuzzy
from fuzzywuzzy import process

これは、かなりたくさんのデータを、手作業で眺めてみて、問題点を拾い出すことを丹念にやって、見つかった課題を、自動で正確に処理するために、便利な関数を使うことができるようにするということのようだ。

 

10月25日(日)

RSNA:

Data setの理解:数%

Metricの理解:数%

モデルの構築:ゼロ

目標達成度:ゼロ

たとえば、データの説明のために、わざわざ次の図が掲載されていたのだが、それぞれの項目の意味とともに理解しておかないとプログラムが作れないことが分かっていながら、理解しようとしなかった。もちろん、容易なことではない。でも、それをやらないと、この先はない。

 

<行事メモ>

応用物理学会・東海支部 基礎セミナー

「AIを用いた画像処理・認識技術の進展」

Zoomウエビナー

4件の講演があった。最も新鮮だったのは、AIチップの話である。そのほかの話は、わかりやすかったが、驚きはなかったので、省略する。

開発中のAIチップは、コンタクトレンズに組み込み、涙で発電してAIチップを駆動し、涙の中の糖分の量の情報を得て、それを電波発信してスマホ等で受信するというもので、類似のシステムは、Googleで開発が進められていた(採用している技術は本質的に異なるところがある)が、中止されたとのこと。

AIチップは、最先端の半導体バイス工場でしか生産できない。すでに衰退している日本の状況が心配である。AIチップの話をされた名古屋大学の先生は、設計したチップの製造を台湾のTSMC社に委託しているとのことである。悲しい話ではないか。

クラウドはもはや時代遅れで、あるべき姿はエッジということかもしれない。それも、AIマシン専用の電源が必要な設備ではなく、パソコンレベルでもなく、スマホレベルでもなく、ゆくゆくは、チップレベルということになるのか。

AIチップの開発は、世界中で競争が激化しているようだ。先を走っていたNVIDIAGoogleも安閑とはしていられないくらい多くの企業が参入しているようだ。

我に返ると、TPUを使うプログラムを書いたことがないというのは、もはや、時代遅れということになる。なんとかしないといけない。

 

<雑談>

コンペへの取り組み方:

これまでの取り組み方の全てを用い、どれかを捨てるということはしない。捨ててきたものとして、「ゼロからモデルを組み立てる」というのがある。これを捨ててきた理由は、コンペによって得るものが殆どない、すなわち、自前のプログラム作成に固執すると、プロや研究者の高度なプログラミング技術を学ぶ機会が殆どないまま、完成度もレベルも低いコードをつくることに終始していたことから脱却したいとの思いを強くしたからである。

しかし、公開コードをベースにしてコンペに参加すると、自らコードを作り上げていく際に必要となるデータの扱い方、metricsの理解とそのコードへの反映、特徴量の理解、判断、抽出方法など、課題毎に異なる様々な状況や要因を把握し理解する能力を養い向上させる機会が得られないなど、マイナス要素が大きく、プログラミング能力向上の機会が大きく損なわれている。

Kaggleコンペから、エキスパート、マスター、グランドマスターに認証されるだけの事をなす能力を獲得することは容易ではなく、重要であり、その過程で学ぶものは多いと予想されるが、その過程で獲得していくさまざまな技能や技術は、基本的には、他者が開拓、開発したものであることが大半であろうと推測される。

そのレベルに達してから考えるべきことかもしれないが、そのレベルに達するための道は複数あって、どの道をたどるかによって、同じランクであっても、質的に異なることは想像に難くない、というか、コンペに参加してきた経験から、容易に想像できる。

自分がそうありたいと思うあるべき姿は、明確に、かつ、継続的に意識し続けなければならない。それは、資格、技能、技術、理論、哲学、倫理、思想、のどれにも偏ることなく追求し続けていきたいと思う。息絶えるまで。

 

micro-cource:Computer Vision

In this course, you'll:

  • Use modern deep-learning networks to build an image classifier with Keras
  • Design your own custom convnet with reusable blocks
  • Learn the fundamental ideas behind visual feature extraction
  • Master the art of transfer learning to boost your models
  • Utilize data augmentation to extend your dataset

If you've taken the Introduction to Deep Learning course, you'll know everything you need to be successful.

1. The Convolutional Classifier

2. Convolution and ReLU

ReLUは指示されたとおりに使っていただけだったが、ここでの説明と、処理例をみて、納得した。フィルター処理したときには、特徴は浮かび上がるものの、境界がぼやけて見えるのだが、ReLUを通すと、境界が明瞭になる。それは、フィルター処理の後にReLU処理すると行列の負の値がゼロになるためだということで、それが境界を明瞭にしているということがよくわかった。

3. Maximum Pooling

2x2のmaximum poolingを学んだときに、average poolingも紹介されていた。maximum poolingだと、位置がずれる。直観的に、average poolingの方が良いのではないかと思ったが、画像を処理してみると、average poolingは、コントラストが下がり、max poolingはコントラストが上がったので、納得した。

4. The Sliding Window

5. custom Convnets

6. Data Augmentation

 Keras lets you augment your data in two ways.

The first way is to include it in the data pipeline with a function like ImageDataGenerator. The second way is to include it in the model definition by using Keras's preprocessing layers. This is the approach that we'll take. The primary advantage for us is that the image transformations will be computed on the GPU instead of the CPU, potentially speeding up training.

これは知らなかった。training timeを短縮できることは重要だ。

model = keras.Sequential([
    # Preprocessing
                              preprocessing.RandomFlip('horizontal'), # flip left-to-right
                              preprocessing.RandomContrast(0.5), # contrast change by up to 50%
    # Base
                              pretrained_base,
    # Head
                              layers.Flatten(),
                              layers.Dense(6, activation='relu'),
                              layers.Dense(1, activation='sigmoid'),
])

モデルを定義する ところ’model = keras.Sequential’で、最初にimage_transformationの処理、preprocessing.RandomFlip('horizontal')、を行なえばよいということだ。

 

10月26日(月)

RSNA:

明日の午前9時がsubmissionの締め切りだ。

残念だが、作業は終了としたし、メダル圏内に入る可能性もない。

 

 Courses:

今後は、公開コードのフォークと並行して、自分で作成したコードをもってコンペに参加できるように、Kaggleのコースを最大限、活用していく。

要注意

deep learningのCourseで、notebookを実行するとデフォルトでGPUが立ち上がる場合があり、放置しておくと、使ったことになって、気付かないうちに、10時間くらい消費していた。

GPUを使ってdeep learningのtrainをパラメータを変えながら体験できるようになっているためであり、すぐに使えるコードだということの証明でもある。

 

Intro to Deep Learning

知っているつもりで放置していた。あらためて勉強してみよう。

1. A Single Neuron

We could define a linear model accepting three input features ('sugars''fiber', and 'protein') and producing a single output ('calories') like so:

model = keras.Sequential([
                          layers.Dense(units=1, input_shape=[3])

このコースは、tabular dataのみを扱う。

  • apply neural nets to two classic ML problems: regression and classification

2. Deep Neural Networks

Be sure to pass all the layers together in a list, like [layer, layer, layer, ...], instead of as separate arguments.

model = keras.Sequential([
    # the hidden ReLU layers
                        layers.Dense(units=4, activation='relu', input_shape=[2]),
                        layers.Dense(units=3, activation='relu'),
    # the linear output layer 
                        layers.Dense(units=1),
])

F. Cholletさんのテキストから、ずいぶん変わったなと思う。第2版はまだかいな。

A. Geronさんのテキストは第2版でTF2対応になったし、複数の形式で説明している。

3. Stochastic Gradient Descent

4. Overfitting and Underfitting 

full connection modelでも、deepとwideがあるのか。単純に1層あたりのノード数を増やせばwideってあたりまえか。これから意識してみよう。たとえば、線形性が高い場合は幅を拡げる、非線形性が高い場合は深くする。これらは、意識していなかった。

earlystoppingはoverfittingを防ぐものだと思っていたが、underfittingをも防ぐとの記述に目からうろこ。言われてみれば、そうだよな。損失曲線の底付近得を見つけて、その付近で最適モデルになったとみなして、trainingを停止するわけだから。

Early Stopping Callbackは、使い方等がわかったが、GroupShuffleSplitについての説明が見当たらず、全く理解できていない。なぜこの場合に必要なのか、どういう効果があり、どういう作用があるのかなどまったく不明。

5. Dropout and Batch Normalization

 

10月27日(火)

RSNA:

午前9時00分、Final submission deadline 

暫定順位:274位

獲得技術:無

技術向上:無

今後に向けて:おんぼろでもいいから、自前のコードをつくる。

 

Cources:

Intro to Deep Learning

5. Dropout and Batch Normalization

batch normalizationの意味がよくわかった。

CNNでよく使っていたのだが、それほど大きな効果は認められなかった。

入力データの規格化もできるということは、知らなかった。

6. Binary Classification

layers.Dense(1, activation='sigmoid')
model.compile(
    optimizer='adam',
    loss='binary_crossentropy',
    metrics=['binary_accuracy'],
)

 

 

Cources:

 

Feature Engineering

1. Baseline Model

Using this data, how can we use features such as project category, currency, funding goal, and country to predict if a Kickstarter project will succeed?

これらのfeatureからprojectが成功する確率を計算するわけだが、これらのfeatureに、成功の要因がどれだけ含まれているか疑問である。

ラベルは、正解ではなく、結果であり、必然といえる要因が含まれているとは思えない。それでも、ここでは、技術を習得することを優先しないといけない。

Prepare the target column

First we'll convert the state column into a target we can use in a model. Data cleaning isn't the current focus, so we'll simplify this example by:

  • Dropping projects that are "live"
  • Counting "successful" states as outcome = 1
  • Combining every other state as outcome = 0

この作業に異論はない。ターゲットは、プロジェクトが成功するかどうかである。

Prep categorical variables

Now for the categorical variables -- categorycurrency, and country -- we'll need to convert them into integers so our model can use the data. For this we'll use scikit-learn's LabelEncoder. This assigns an integer to each value of the categorical feature.

文字情報を整数に置き換えるのだが、識別子としての意味しかないので、ここに、違和感を感じる。

2. Categorical Encodings

In this tutorial, you'll learn about count encodingtarget encoding, and CatBoost encoding.・・・識別子+αの意味を持たせる方法の説明のようだ。

Count encoding replaces each categorical value with the number of times it appears in the dataset. For example, if the value "GB" occured 10 times in the country feature, then each "GB" would be replaced with the number 10.

categorycurrency, and countryこれらを出現頻度数に置き換えると、AUCが0.7467から0.7486に上がった。

Target encoding replaces a categorical value with the average value of the target for that value of the feature. For example, given the country value "CA", you'd calculate the average outcome for all the rows with country == 'CA', around 0.28. 

これは、おかしいな。ターゲットの値を使っている。train_dataだけで、validation_dataとtest_dataに使わなければtarget leakではないと書かれているが、納得できない。

これを使うとAUCは0.7491になるとのこと。

Finally, we'll look at CatBoost encoding. This is similar to target encoding in that it's based on the target probablity for a given value. However with CatBoost, for each row, the target probability is calculated only from the rows before it.

これを使うとAUCは0.7492になるとのことだが、よくわからん。

3. Feature Generation

4. Feature Selection

 

Lyft

計算終了後のsaveでHDDが容量オーバーで停止した。なんてこった。

条件を変えて計算中に気がついたら停止していた。今日はついてない。

追加学習と思ってちょっと学習させてみたが、ゼロからの学習だったようで、話にならないことが分かった。なにかやろうとすれば、それだけコードを読みにいくので、まったく無駄な作業ということではない。

約3時間かかって、あと10分から20分くらいで終わるはずのところで、また、妨害された気がする。どうも、サーバー側でなにかやらかしている気がする。

Your notebook tried to allocate more memory than is available. It has restarted. 

全く問題ない状態で動いているはずなのに、突然停止した。

腹立つけど、無料だから、文句が言えないな。

午前3時くらいまでかけてcommitする予定だったのだが。

 

10月28日(水)

Lyft

Final submission deadline: November 25

今後の予定

1.train済みモデルを3種類作成し、これらのtrain済みモデルのパラメータをkaggle  datasetsとして保存した後、このパラメータを読み込んでinferenceする。

 

とりあえず、不十分だが、trainしたモデルのパラメータをkaggleのdatasetsにして、inferenceしてみる。

trainingにはかなり時間がかかりそうだ。

2.base_modelを変える。

3.画素数を変える。

 

Cource:

Deep LearningのExerciseは、立ち上げと同時にGPUがOnになるものがある。このとき、別画面でKaggle notebookをGPUで走らせていると、警告なしに、Kaggle notebookは停止する。計算はゼロからやり直しになるので、要注意。

Deep Learning以外のExerciseでも、立ち上げと同時にGPUがOnになるものは、同様の症状が生じるので要注意。

(コンペ間でも、GPU間で衝突すると、計算は即時停止となるので、要注意。)

Feature Engineering

Exercise 1 : 

q_1が要求している解答/正解とSolutionが異なっている。

Solutionを使うと、次に進めなくなる。出来上がるDataFrameの名称が異なる。

 

<雑談>

 画像を解釈するとき、ヒトは、全体から細部へ、細部から全体へ、視野を変えながら眺めまわす。こういうことを実現すれば、高精細な画像と大きなモデルの単純な組み合わせに優るものになるかもしれない。自然言語処理においても、ヒトが翻訳したり作文したり抄録を作成したりする過程をモデルに組み込むことができれば・・・。

 まだまだ単細胞的な働きしかできていないのかもしれないと思って、モデルの高度化を目指した取り組みをしていかないと、と思うのだが、それを実現するには、プログラミング技術が必要である。プログラミングは、Pythonに限る必要はない。適当なものがなければゼロから言語を創ればいいだけのこと。

 画像処理だと、複数の解像度の画像を、複数のモデルで学習/予測するだけでなく、複数の箇所に分割して学習/予測し、複数の標的を探し出し、標的毎に特徴量を抽出し、課題との関連を学習し、・・・。

 

10月29日(木)

MoA:

 

さあ、挑もう、と思っても、意味の分からない文字と数字の羅列。

結局、パラメーター最適化にはまってしまう。

 

10月30日(金)

MoA:

CVの改善を進めるだけなのだが、Lyftのtrainで3日前にGPUを使い果たしたので、tab_dataといえども、feature数が多く、hidden_sizeが比較的大きいNNを使うと、当然であるが、CPUだけでは、時間がかかるが、特定の指標の変化だけなら調べることができて、パラメータの最適化に、ある程度は使える。

NNの1層あたりのユニット層を増やすと、あるところまでは改善され、それ以上では飽和もしくは悪化する。また、NNの層数を増やすと、あるところまでは改善され、それ以上では飽和もしくは劣化する。underfittingとoverfittingの間を動いているだけ。

 

10月31日(土)

MoA:

GPUが使えるようになったので、お気に入りの条件で計算してsubmitしたら、1400-1500位相当であった。public_dataに無理に合わせるのはダメだと言われても、離れすぎているのもダメだし、Train_data(val_data)に合わせすぎるのもダメだしな。

コンペでは、最終的に、2件の投稿しかできないということの意味が、少しづつわかってきたような気がする。コンペが終わってから、あの結果を選んでおけばよかった、などというのは、だめなんだ。

ついこのあいだも、めんどくさいと思って最新の2件を選んだら、弾き飛ばされて、後でよく見たら、ゆうゆうメダル圏内のものがあった。それをsubmitしたときのメモを探して見返してみたら、NNの条件が偏っていたので、もっと汎用的なモデルにするためにパラメータを変えてみる、というメモ書きがあった。しかしながら88件もsubmitしていたのと、データ整理が悪いのと、そのような計算をしていたことを思い出せなかったことなどによって、適切なモデルを選ぶことができなかった。しかし、こういうのは、後出しじゃんけんでしかないだろう。仮に、そのことを思い出し、メモを見ても、そのときのスコア(public LB)では、60%くらいの順位だから、やはり、選ばなかっただろうと思う。

 

Lyft

データ量がハンパないコンペで、私でも使えるコードが公開されると、計算環境の勝負になる。もちろん、トップレベルの人たちの間の競争は、別次元だろうとは思うが。

とりあえず、350kのデータを学習させようとすると、KaggleのGPUで200時間くらいかかりそうだ。貧乏人には手が出せないコンペだな。kaggle kernelを、6時間毎に継いで使おうと思っても、途中データを出力するにはcommitしなければならず、時間が足りない。こういう不満を言うのは、初級レベルだということだ。小さくて速いモデルを探して使うとか、TPUやコラボを使うとか、探せば手段はありそうに思う。さぼっているだけなんだろうな。

 

GPU:初日に12時間25分も使ってしまった。

 

明日から11月だ。

6月中旬のPANDAコンペ、TReNDSコンペから、本格的に、Kaggleに参加した。

2019年のAPTOSが最初のKaggleだったと思うが、F. Cholle氏のテキスト片手にモデルを作成し、commit, submissionしたが、エラーばかりでリーダーボードに載らなかった。

その後もいくつか挑戦していたが、モデルを作ることもできず、submissionもできないことが続いた。

コンペに参加してもsubmissionしない、できない状況は、ARCでも同じだった。アルゴリズムを考えることに熱中し、文献も読み、公開コードにも学んでいたが、結局、submissionできずに終わった。

2020年5月8日に、Kaggleのリーダーボードに載ること、を目標に定めた。

最初から公開コードを使って参加することに躊躇もあった。

その躊躇の気持ちは今も変わらないが、公開コードは、非常に高度な内容を含んでおり、これほどのお手本に直に触れることができるというのは、非常に良い経験になると思っている。

はやく自前のコードで勝負できるようになりたいという思いがあるのだが、公開コードでもまだまだずいぶん先にあるように感じるけれども、コンペの後に出てくるトップクラスのコードは、さらに先をいっているので、コンペ後にGitHubやKaggleのコンペサイトに公開されるトップクラスのコードを時間をかけて理解することもやっていかないとだめである。

AIの学習も、多面的にやっていこう。Kaggle以外も含めて、いろんな方法をensembleしながら進もう。

 

11月につづく

 

f:id:AI_ML_DL:20200930212926p:plain

style=156 iteration=1

f:id:AI_ML_DL:20200930213016p:plain

style=156 iteration=20

f:id:AI_ML_DL:20200930213123p:plain

style=156 iteration=500

 

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 

f:id:AI_ML_DL:20200902233947p:plain

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

気になるキーワード:

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


f:id:AI_ML_DL:20200903000349p:plain

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

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


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

f:id:AI_ML_DL:20200903223111p:plain

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

f:id:AI_ML_DL:20200903224553p:plain

f:id:AI_ML_DL:20200903224707p:plain

f:id:AI_ML_DL:20200903225814p:plain

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

チューニングするだけで終わるかもしれないが、最低でも、関連論文2,3編には、目を通して、パラメータの意味を把握しよう。特に、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日目だからな。あっという間に、下がっていくんだろうな。というか、今なら、一瞬でも、トップに立てる可能性があるということだ。どうせ最後はメダル圏外。ならば、今のうちに、頑張ってみようか。

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

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

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

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

 

9月6日(日)

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

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

現状:

1.Overviewに目を通す。

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

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

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

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

改善したいポイント:

 スコアアップは、フォークした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と解析コードを公開されているので、学ばせていただこう。

 

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

1.自前のEDAコードを作成する。

2.自前の解析コードを作成する。

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

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

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

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

 

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

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

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

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

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

 

9月8日(火)

Cornell Birdcall Identification

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

f:id:AI_ML_DL:20200908172309p:plain


f:id:AI_ML_DL:20200908172223p:plain

f:id:AI_ML_DL:20200908172404p:plain


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であった。

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

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

たとえば、

f:id:AI_ML_DL:20200909212010p:plain

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.

f:id:AI_ML_DL:20200909213100p:plain

f:id:AI_ML_DL:20200909214620p:plain

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

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

 

9月10日(木)

新しいコンペが2つ始まった。1つはドローンで、もう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つ以上ならば、過密により死滅する。

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

ライフゲームの基本ルール
誕生 生存(維持) 死(過疎) 死(過密)
Game of life 3x3 cell arises.svg Game of life block with border.svg Game of life 3x3 cell dies2.svg Game of life 3x3 cell dies1.svg

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

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

パターンの例[編集]

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

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

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

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

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

固定物体の例[編集]

ブロック 蜂の巣 ボート
Game of life block with border.svg Game of life beehive.svg Game of life boat.svg Game of life 5x5 ship.svg Game of life 6x6 pond.svg

振動子の例[編集]

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

ブリンカー ヒキガエル ビーコン 時計
2-3 O1.gif 2-3 unruhe.gif 2g3 blinker.gif G3 unruhe.gif

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

パルサー 八角 銀河 ペンタデカスロン
JdlV osc 3.225.gif JdlV osc 5.64.gif Oscilador8periodos.gif JdlV osc 15.144.gif

移動物体の例[編集]

グライダー 軽量級宇宙船 中量級宇宙船 重量級宇宙船
Game of life glider.svg Game of life lwss.svg
⬜️⬜️⬜️⬛️⬜️⬜️
⬜️⬛️⬜️⬜️⬜️⬛️
⬛️⬜️⬜️⬜️⬜️⬜️
⬛️⬜️⬜️⬜️⬜️⬛️
⬛️⬛️⬛️⬛️⬛️⬜️
⬜️⬜️⬜️⬛️⬛️⬜️⬜️
⬜️⬛️⬜️⬜️⬜️⬜️⬛️
⬛️⬜️⬜️⬜️⬜️⬜️⬜️
⬛️⬜️⬜️⬜️⬜️⬜️⬛️
⬛️⬛️⬛️⬛️⬛️⬛️⬜️

繁殖型の例[編集]

グライダー銃
Game of life glider gun.svg

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

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

バリエーション[編集]

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

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

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

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

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

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

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

他にも様々な計算能力を持つパターンが発見されている。素数/乱数生成器や、ライフゲームを用いてライフゲームを計算する "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.

f:id:AI_ML_DL:20200915152850p:plain

f:id:AI_ML_DL:20200915153015p:plain

この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

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

一般論は、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を1つのモデルで実現したことであるが、現時点での自分にとっては、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した。

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

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

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

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

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

 

OpenVaccine:

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

f:id:AI_ML_DL:20200924104425p:plain

f:id:AI_ML_DL:20200924104611p:plain

f:id:AI_ML_DL:20200924104744p:plain

f:id:AI_ML_DL:20200924104954p:plain

f:id:AI_ML_DL:20200924105456p:plain

コンペの内容にもっと近い情報は、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位以内に入れる可能性がある。

1つは、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だけアップした。

残りの3つは、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:

今日は、最終日である。

5つのパターンを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月、新しいページを作ろう。

 

 

f:id:AI_ML_DL:20200902094042p:plain

style=153 iteration=1

f:id:AI_ML_DL:20200902094133p:plain

style=153 iteration=20

f:id:AI_ML_DL:20200902094214p:plain

style=153 iteration=500

 

OSIC Pulmonary Fibrosis Progression

OSIC Pulmonary Fibrosis Progression

Predict lung function decline

今日から、このコンペに挑戦しよう!

 

目的:予測モデルを1から作れるようになるためのコードの学習。

手段:お手本モデルから、徹底的に学ぶ。

方法:プログラムのすべての行に、初心者にもわかる注釈をつけよう。

目標1:徹底的に注釈をつけたお手本コードを、初学者(自分:me)のために、公開しよう。

目標2:メダル獲得

 

8月18日

お手本を探そう。

目的は、概要の最後の方に、次のように記述されている。

In this competition, you’ll predict a patient’s severity of decline in lung function based on a CT scan of their lungs.

You’ll determine lung function based on output from a spirometer, which measures the volume of air inhaled and exhaled.

The challenge is to use machine learning techniques to make a prediction with the image, metadata, and baseline FVC as input.

CT画像と、メタデータと、強制肺活量(Forced Vital Capacity)を入力とし、これらの情報を適切に組み合わせて、肺機能の変化を正しく評価できる機械学習プログラムを作ろう。

 

2つの公開ノートを組み合わせた公開ノートがある。

最初に、フォーク時のまま走らせてsubmitし、その次に、影響の大きそうなパラメータを変更してみたのだが、オリジナル性の高いモデルは、かなり最適化されていて、一見不自然に見える値でも、案外、最適値に近いことが多い。

ただし、難しいのは、グローバル最適値ではなく、局所最適値になっている場合で、このときは、不自然に見えるパラメータを自然な方向に動かしても、評価値が下がることもよくある。

さらに、出力のばらつきには、常に、注意しなければならない。

実際、今日は、適切と思われる公開コードで、いくつかパラメータを変えて最適化しようとしたが、いずれのパラメータについても、最適値は見つけられなかった。

それだけ再現性が良くないということなのか、それとも、すでにグローバル最適化がなされているということなのか。

 

明日から、コードの解読を進めながら、丁寧に、最適化を行なっていこう。 

 

8月19日

プログラムありきになってしまっている。

もっというと、Kaggleありきになってしまっている。

機械学習ディープラーニングは、課題解決の手段であって、目的ではない。

もちろん、Kaggleも目的であろうはずはない。

それなのに、メラノーマの検出も、前立腺がんの診断も、目的を十分に理解せぬまま、単に、目の前にあるプログラムを借りてきて、チューニングしてスコア出して、順位争いすることに集中していた。

正確な診断に役立つプログラムを開発するという目的はどこにいったのか。

良いプログラムにめぐりあえたなら、その性能をさらに引き上げるにはどうすれば良いのか、実用化への課題は何なのか、などを考えることが必要だったのではないのか。

スコアを上げるためだけに奔走し、医療の現場で役に立つプログラムを開発するということを、本気になって考え続けることができなかったことを、反省しよう。

 

OSICのホームページより、以下、引用

“OSIC was created to bring divergent groups together to look at new ways of fighting complex lung disease,” said Elizabeth Estes, the consortium’s executive director. “In addition to utilizing expertise from academia, industry and philanthropy, we wanted to introduce clinicians to the broader artificial intelligence and machine learning community to see if new eyes and new tools could help us move forward, faster. We are excited to see the progress that can be made for patients all over the world.”
OSIC is supported by a myriad of collaborative academic and industry institutions, including founding members Boehringer IngelheimSiemens HealthineersCSL BehringFLUIDDAGalapagosNational and Kapodistrian University of AthensUniversité de LyonFondazione Policlinico Universitario Agostino Gemelli, and National Jewish Health. All members work in pre-competitive areas for mutual benefit and, most importantly, the benefit of patients.

 

本当に求められていることは何か。

CT画像からどれだけの情報を引き出せるか。

教師データは正確か。

CT画像は、病気の進行状況を正確に表しているかもしれないが、それに対する値付けは正確ではない可能性がある。FTV(強制肺活量)は正確に測定できるものではない。必ず、ばらつく。実際、train_dataをみると、時間の経過とともに一様に変化しているものはない。ばらつきの大きさを見積もりながら、減衰曲線を評価する必要がある。病気の進行具合は、全体の平均値、よく似た変化曲線の平均の傾向を用いた方が、より正確かもしれない。unsupervised learningとしてCT画像を解析することも必要ではないか。

メラノーマのコンペでは、画像解析が、スコア競争、アンサンブル競争に置き換わってしまっていた。

医療応用では、画像からどれだけの情報を引き出せるかが重要なのだから、スコアではなく、医療診断画像から適切に情報を引き出すための方法(論)を確立することに集中しよう。

 

8月20日

tf.keras.callbacks.ModelCheckpoint

計算途中で、lossが最小、accが最大、などの条件が成立したときのモデルのパラメータを保存したり、保存したパラメータを呼び出したりする方法を、自分でゼロから作成するプログラムでは、まだ使えていない。

A. Geronさんのテキストや、TensorFlow/KerasのHPなどで勉強しよう。

明日は、書きかけの過去のブログに追記することにより、この部分を学習しよう。

 

肺のCT像に関して専門家が興味深い議論をしている。CT像に関しては、専門家がこれまでに多くの議論を重ねてきており、対象とする病気の種類によって、どこに着目すべきかは異なるものであり、今回の場合、何に着目したらよいかを考える指針になるようなことを、具体的に紹介している。

ただし、機械学習ディープラーニングで解析する場合に、専門知識をどう生かすかは難しいところである。何をどう学んでどう答えを出してくるか、使う機械学習モデルの性能に期待し、その性能を向上させる方法を模索しているわけで、そこに、専門家の専門領域の解析手法を持ち込む際には、どう持ち込むか、機械学習との役割分担を明確にしながら、慎重に進めていく必要があるように思う。

 

8月21日

フォークしたモデルのチューニングをしている。

再現性の確認から始めている。

cvとpublic LB、public LBとprivate LBとの乖離のことを考えながら進めることは、実案件でも重要であろうと思われる。単にコンペで失敗した、ということで終わらせないように、モデルの出力を正しく理解し、ばらつきを抑え、信頼性の高い結果を得るための方法を検討しながら、性能を評価する技術を磨いておこう。

 

Kaggleから、学習コースの案内がきたので、ちょっと覗いてみたら、データの前処理技術だった。Kaggleのコースは非常にわかりやすくかつ具体的な事例に即した内容になっているので、学習効率が高い。過去にいくつか取り組んだコースについても、身につくまで何度でも繰り返し学ぼう。

 

他のコンペ:birdcall identificationとlandmark recognitionにも参加してみた。my dear watsonにも参加してみようかな。これらに参加することで、視野が広がることを期待している。音声情報の扱い方とか、分類数が極端に多くかつラベル付きデータが非常に少ないものが含まれるとか、自然言語かつ多種類の言語を扱うものである。すぐには理解できなくても、いろいろなデータやモデルを見るのは面白く、経験を積み重ねることで異なる課題の理解が進むこともあるのではないかと思っている。

 

エポック数の多さに仰天したコードについて、Vall_scoreを落とさず、エポック数をどこまで下げることができるか調べた。最初に同じ条件で計算したときのばらつきを調べた。次に、エポック数を段階的に下げていって、評価値の変化を調べた。その結果、まあまあ常識的な範囲まで下げることができて、評価値は確実に良くなった。ところが、public LBは、明らかに悪くなっていった。ばらつきの範囲を超えていて、この関係は明白であった。以上のことから、エポック数は、public LBを向上させるために最適化していたのではないかと推測される。もちろん、エポック数を下げることがprivate LBを向上させることにつながるかどうかは、全く分からない。しかし、予測性能を上げるということに関しては、他のパラメータとも合わせて調整する必要があるのかもしれない。それらの作業を適切に行うためには、もっと正確にコードを解読する必要がある。

 

8月22日

Adamの学習率を0.1にしていることに驚いていたら、こんどは、0.00001(1e-5)に出くわした。

1e-5に対して、1e-4と1e-3と1e-6を試してみた。

20エポック程度では、いずれの場合にも殆ど学習できなかった。

3つのカテゴリーに分類するのだが、accが0.33+から殆ど変化しなかった。

この場合の適切なlrは、およそ、1e-5から3e-6の間であった。

これは、My Dear Watsonでのことである。

Kaggle staffらによるTutorial notebookから始めて、スコアの低い公開コードを適当に走らせてみた。

それぞれの公開コードには、それぞれの特徴があり、それぞれの性能があらわれる。

自然言語を扱ったモデルはあまり動かしたことがなかったのだが、最近急速に性能が上がっているようである。

このサイトの公開コードを十分に理解できているわけではないが、扱うデータ量に比例して性能が向上している(スコアが上がる)ことを強く感じた。

 

8月23日

明日から本格的にコードを組み立てよう。

まずは、できるところまで、自分の計算環境:Windows10, 64bit, Anaconda3のjupyter notebookでコードを組み立てていく。

*いまどきは、Google Colabなんかを使う方が便利そうなので、そうしたいのだが、まだ使い慣れていないので、今は、Anaconda3-jupyter notebookで進める。

このとき、お手本となるコードをjupyter notebookにアップロードしておく。

最初は、EDA

次に、予測モデル。

 

8月24日

まずは、metricの学習から。

FVCの標準偏差σ

標準偏差は70以上:σ-clipped=max(σ, 70)

FVCの予測値と真値の差Δ

Δは1000以下:Δ=min(|FVC-true - FVC-predicted|, 1000)

metric = - √2 * Δ/σ-clipped - ln(√2 * σ-clipped)

仮にσ=70, Δ=1000を代入すると、metric ≒ - 24.8

 

何を評価するか、およそ理解できたところで、公開コードの中からよさそうなEDAを探して、jupyter notebookにアップロードしておいて、それを参考にしながら、自分のnotebookを作っていく。

 

CT画像の読み込みには、pydicomが必要なので、Anaconda3にインストールする。

conda install -c conda-forge pydicom

 

コンペデータを読み込んで、Desktopに置こう。

22.35GBあるので、ネット環境にもよるが少し時間がかかる。解凍にも時間がかかる。

すでに何日か前にダウンロードし、解凍してあるので次に進む。

 

次は、train_dataを読み込もう。

df_train = pd.read_csv('D:/.../.../osic-pulmonary-fibrosis-progression/train.csv')

df_train.shape

(1549, 7)

1549行、7列

7列は、'Patient', 'Weeks', 'FVC', 'Percent', 'Age', 'Sex', 'SmokingStatus'である。

1549行は、1549人のPatientではない。

df_train['Patient'].nunique( )

176

患者の数は176人で、各人について、何週目かにおけるFVC値が、ml単位で、平均して9件程度、掲載されている。

FVCデータ数は、6件が2名、7件が7名、8件が25名、9件が132名、10件が10名である。

 

teat_dataをみてみよう。

df_test.shape

(5, 7)

なんと、5人分しかない。

その5名の患者の情報の種類は、train_dataとまったく同じだが、FVCは1回分だけしか与えられていない。FVCの経時変化と標準偏差を予測するのであるから当然である。

 

sample_submission.csvは、どうなっているのだろう。

df_submission.shape

(730, 3)

患者が5名しかいないのに、730行もあるのはなぜだろう。

3列は、それぞれ、Patient_Week, FVC, Confidenceである。

Pationt_Weekは、患者のIDの後に、-12週から+133週までの識別番号が付加されていて、1名の患者に、-12週から133週までの計136週ぶんのFVCの予測値を記入する。

 

最初に示したmetricsを式にしておこう。

sigma_clipped, delta, Y_true = FVC_true, Y_predicted = FVC_predicted, score = metricを用いて、

sigma_clipped = np.maximum(sigma, 70)

delta = np.minimum(np.abs(y_true - y_predicted), 1000)

score = - np.sqrt(2) * delta / sigma_clipped - np.log(np.sqrt(2) * sigma_clipped)

 

さて、もっと近づいて、FVCを眺めてみよう。 

週単位で測定された 6回から10回のFVCの変化を用いて、12週前から133週後までのFVCを1週間単位で予測することが求められている。

その6回から10回の測定の大半は、60週くらいまでの測定値であるため、求められている最後の3週、131,132、133週の値は、ほぼすべての場合、非常にラフな外挿となるように思う。

test_dataで与えられるのは、tab_dataの他には、どこかの時点でのFVC の値と、CT画像である。

 

明日は、CT画像について調べよう。

 

8月25日

train.csv, test.csvの Patient_ID が、DICOMフォーマットで保存されているCT画像のフォルダー名になっている。

train/ には、176のフォルダー、test/ には5つのフォルダーがあり、それぞれのフォルダーの中に、複数の連番のCT画像が含まれている。

train/のデータセットの場合、各フォルダー内の画像の数は、最小で12、最大で1018含まれている。1人の患者に対して1018ものCT画像って、どういうことなのか、さっぱりわからない。

 

まずは、CT画像を読み込んで、表示してみよう。

CT画像のファイル名は、番号だけで、拡張子が、dcmである。たとえば、1.dcm。

これは、DICOMファイルで、pydicomを使って開くことができる。

pydicomのホームページに、ファイルを読み込んで、画像を表示するための、次のようなコード例が示されている。

>>> import matplotlib.pyplot as plt
>>> import pydicom
>>> from pydicom.data import get_testdata_files
>>> filename = get_testdata_files("CT_small.dcm")[0]
>>> ds = pydicom.dcmread(filename)
>>> plt.imshow(ds.pixel_array, cmap=plt.cm.bone)

わかりやすくするために、dsを、dicom_fileと書き換える。

file_path = 'C:/Users/..../Desktop/osic-pulmonary-fibrosis-progression/train/ID00228637202259965313869/200.dcm'

dicom_file = pydicom.dcmread(file_path)
plt.imshow(dicom_file.pixel_array, cmap=plt.cm.bone)

f:id:AI_ML_DL:20200825145101p:plain

*この画像の解釈:白い部分は骨?:真っ黒い部分は空気なので、黒い部分が肺:肺の中の白い部分は固まった組織?血管?:灰色部分は水分が多く含まれる領域

*HU:空気-1000(黒い):肺-700 to -600:水 0(灰色):血液13 to 50:骨200 to 3000(白い)

このdicom_fileは、このような画像情報に加えて、次のようなメタデータが含まれている。

['BitsAllocated', 'BitsStored', 'BodyPartExamined', 'Columns', 'ConvolutionKernel',
'DeidentificationMethod', 'DistanceSourceToDetector', 'DistanceSourceToPatient',
'FocalSpots', 'FrameOfReferenceUID', 'GantryDetectorTilt', 'GeneratorPower',
'HighBit', 'ImageOrientationPatient', 'ImagePositionPatient', 'ImageType',
'InstanceNumber', 'KVP', 'LargestImagePixelValue', 'Manufacturer',
'ManufacturerModelName', 'Modality', 'PatientID', 'PatientName', 'PatientPosition',
'PatientSex', 'PhotometricInterpretation', 'PixelData', 'PixelRepresentation',
'PixelSpacing', 'PositionReferenceIndicator', 'RescaleIntercept', 'RescaleSlope',
'RescaleType', 'RotationDirection', 'Rows', 'SOPInstanceUID', SamplesPerPixel',
'SeriesInstanceUID', 'SingleCollimationWidth', 'SliceLocation', 'SliceThickness',
'SmallestImagePixelValue', 'SpecificCharacterSet', 'SpiralPitchFactor', 'StudyID',
'StudyInstanceUID', 'TableFeedPerRotation', 'TableHeight', 'TableSpeed',
'TotalCollimationWidth', 'WindowCenter', 'WindowCenterWidthExplanation',
'WindowWidth', 'XRayTubeCurrent']

 

一人の患者に対して何十枚、何百枚とある画像の中から、どれを選べばよいのだろうか。FVCの変化、病気の進行状態などとの相関性が高い画像をどうやって探せばよいのか。FVCの変化率とCT画像との間に相関があるのだろうか。その相関の有無や大きさをを判定するにはどうすればよいのだろうか。

 

train/の画像の全体像を知るためには、任意の患者の任意の番号のCT画像を表示できるようにする必要がある。それには、ffmpegが必要だ。

conda install -c conda-forge ffmpeg

 

その前に、1つのフォルダー内の全ての(一連の) .dcm データを一括して読み込む必要がある。

 

続きは、明日。

 

8月26日

今日は、公開コードのEDAで、CT画像の一部を確認した。

症状の違いをCT画像から学習させたいのだが、特定の1枚を抽出するのか、全ての画像を入力してしまうのか、それでCNNに何をどうやって学習させるのかをよく考えないといけない。

FVCとCT画像の相乗効果を出すことが期待されているように思うので、形式的な検討だけではダメ画と思う。

有効な画像を自動で抽出する方法を考える必要があるかもしれない。

フルに使うにしても、画像の枚数が患者によって大きく異なるので、それをどう処理していけばよいのかも考えないといけない。

解析に適したCT画像をどうやって抽出すればよいのかを、CT画像をじっくりながめながら検討しよう。

 

8月27日 

今日は、公開ノートのCT画像を順に眺めてみよう。

tabular_dataの表示の後に、CT画像を表示しているのだが、CT画像とFVCが全く結び付けられずにいる人がたくさんいるように感じた。

症状が現れている画像とそうでない画像を対比して説明しているものがみつからない。

一人の患者に1組のCT画像が与えられていて、それが、正常なのか、症状が現れているのかの判定ができない。

CT画像のどの部分が肺を表しているのかはおよそわかるのだが、どの部分が正常で、どの部分が異常なのかが、まだはっきりとは、わからない。

 

前進しているのかな。

 

8月28日

今日は、借り物でチューニングしただけである。

 

8月29日

借り物を解読しようとしているのだが、進まない。

明日こそ! 

 

8月30日

停滞

 

8月31日

ここ数日は、Kaggleの他のコンペで遊んでいた。

I'm Something of a Painter Myself - Use GANs to create art - will you be the next Monet? に参加して、公開コードを実行していた。賞金レースではないし、メダルも出ない。教育的なコンペで、チュートリアルコードが用意されている。チュートリアルコードをチューニングしてスコアを上げるのだが、何回かやれば、頭打ちになる。次のコードを探すのだが、つわものがやってきて、ハイスコアのコードを見せてくれる。チュートリアルにはなかった、augmentationを追加しており、見事な出来栄えになっている。ベースコードに機能が追加されているので、両者を比べることによって、何をどこに配置すればよいのかがわかるので、効果を肌で感じながら、コーディング技術を学べる。

チュートリアルコードは、CycleGANを使っている。David Fosterさんの著書にGenerative Deep Learning - Teaching Machines to Paint, Write, Compose and Play - というのがある。第5章のPaintでは、CycleGANが20ページ、Neural Style Transferが10ページほど、紹介されている。自分はまだNeural Style Transferしか使ったことが無いので、これは良い機会だ。

 

9月1日

進捗なし。 

 

9月2日

1.肺線維症がCT画像上でどのように観察されるのかを示すデータを探す。

2.コンペで提供されているCT画像から、肺線維症であるかどうかを判断するために用いる画像を抽出する方法を検討する。

・全画像を用いるのが良いのか、特定の場所の画像のみ用いるのが良いのか。

・全画像を用いる場合、画像の枚数の極端な違いをそのままにしておいてよいのか。

・特定の画像を用いる場合、適切な画像をどうやって決めるのか。

3.CT画像から、症状の程度を正しく判定するために必要な情報は何か。

・FVCの変化とCT画像との対応はとれるのか。

・FVCの経時変化はtrain_dataとして与えられているが、CT画像は、一時のデータのみ。

・CT画像はいつ測定したものか。

 

*思いつくまま書いてみたが、train_dataの内容が把握できていないことは明らか。

 

9月3日

Discussionに学ぶ

CT画像内の肺のセグメンテーションについては、Kaggleの過去のノートブック、GitHubなどを参照すればわかるとのこと。

肺のCT画像から、FVCの減衰率を予測する技術を競うもの。

疫学的要因もFVCの減衰率と相関性は認められるが、補助要因であり、CT画像との相関とは、区別して扱うべきもの。

CT画像とDICOMファイルの情報から、肺のサイズが計算できるので、FVCとの相関がわかる。

FINDING AND FOLLOWING OF HONEYCOMBING REGIONS IN COMPUTED TOMOGRAPHY LUNG IMAGES BY DEEP LEARNING
Emre EGR˘ ˙IBOZ1, Furkan KAYNAR1, Songul VARLI ¨1, Benan MUSELL ¨ ˙IM2, Tuba SELC¸ UK3

f:id:AI_ML_DL:20200903113419p:plain

黒い領域は空気もしくは肺胞?:肺の内部に生じている網目状の白い組織が、肺線維症の病巣?

f:id:AI_ML_DL:20200903135237p:plain

f:id:AI_ML_DL:20200903135350p:plain

やっと、CT画像中における、肺の構造、線維症の病巣の様子が少しわかったような気がする。

CT画像は、全て用い、その際には、マスクを使うということ。

公開コードは、あらかじめマスクを作成し、Kaggle内のpublicデータとして保存し、呼び出して用いている。最近は、.csvファイル以外は、あらかじめ加工してpublic_dataとして保存して用いるのが普通になっているようである。この方法であれば、外部データもあらかじめ使用許可を得て、public_dataとして保存して、Kaggle-kernelから呼び出せば、internet-offでも問題なく使えるということである。

 

9月4日(金)

今日は、気になるチューニングのみを行った。 

 

9月5日(土)

今日は、マスクの作り方を学ぼう。

手が回らなかった。

 

9月6日(日)

進捗なし。

順位が大きく下がっていたので調べたら、また、自分より良いスコアのコードが公開されている。

締切1週間くらい前までは、起こりうること。

目先のスコアを上げようとして、がんばりすぎると、public dataにoverfitしてしまって、蓋を開けたら大きな転落もあるので、難しい。

 

9月7日(月)

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

1.自前のEDAコードを作成する。

2.自前の解析コードを作成する。

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

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

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

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

 

9月8日(火) 

コピペして、変数を確認する、文法を調べる、動作を確認する、などなど、なかなかはかどらない。

進むにしたがって、複雑になり、こんがらがってくる。

ここに書いている時間がない。 

 

9月9日(水)

チューニングで少し前進するが、自分と似たようなスコアの公開コードが現れた。

 

9月10日(木)

今日もチューニング、つまらない作業だが、つまらなくしている原因は、コードを理解しきれず、自分で本格的なコーディングも本質的な改造もできないことにある。

 

9月11日(金)

Kaggle Kernel内で、新規にnotebookを用意し、数ある公開notebookの中から、自分に適した筋の良いものを選び出し、新規のnotebookにコピペし、解説を加え、できれば改造もして、機能アップして、再公開する、ということを目的としてここまでやってきたが、殆ど進んでいない。

このやり方の良くないところは、コピペをすること自体にある。コピペの何が悪いのかを考えてみた。

1.コピペ自体が手間である。

2.コードの理解が進まないのは、まとめてコピペするからだ。コードを覚えたければ、タイピングするか、理解できる単位ごとに、区切って、コピペするべきだと思っていたが、今日、ふと、そうではないだろうと思った。

3.コードを覚える瞬間というのは、書式と動作が結びついたときである。書式は見ればわかる。動作は、コードを走らせて、変数がどう変化したのか、書式がどうなっていたのか、書式はどう変化したのか、テンソルの値や書式や次元がどう変化したのか、計算結果はどうなったのかなどを具体的にみることによってしかわからない。

4.動作確認のとき、なぜそうなるかは、与えられたコードをそのまま走らせただけではわからないことが多い。書式や数値や並びや分離記号などを種々変えながら走らせてみることによって、それぞれの意味を理解できるようになる。

5.だとすれば、公開コードはKaggle Kernel上ですぐ動かせるし、編集も自由にできるのだから、新たにnotebookを作る必要などない。

6.新たにnotebookを作るのは、数十分もあれば、自前で、ゼロから、一通りのプログラムを書くことができる人がすることである。

7.新たにnotebookを立ち上げて公開コードをコピペあるいは転載するのは、愚の骨頂である。公開コードを直接編集モードに切り替えて、使えるところは使わせていただいて、不要と思う場所は切り捨てて、追加したいものがあれば、別のコードからコピペすればよいだけである。

8.ただし、以下のことは守らねばならない。

・転載に許可がいる場合は許可を得ること。

・特別に許可が要らない場合でも、引用部分に対しては引用元を明示すること。

・公開する予定が無くても、いつ公開しても良いように、引用元は明示し、変更部分はその概要を明示すること。

・編集モードにしたときは、必ず、引用元を最上部に記入しよう。

 

9月12日(土)

チューニングは、軽んじてはいけないと思うこともある。

コンペでは、Public dataに対してチューニングするしかないのだが、そうすると、Public dataに対して、overfitthingに向かうはずである。

Public dataに完璧にチューニングしたモデルが、Private dataに対しても完璧にチューニングされるということはありえない。

ではどうするか。

 

9月13日(日)  

チューニングの仕方を深く学ぶことは重要なんだろうなと思う。

 

9月14日(月)

Kaggleの他のコンペだけど、公開コードを借りた人が、重要な改善点を見つけてスコアを上げ、それを公開した。

そうすると、元の作成者は、改善点を見つけた人に礼を述べるとともに、その改善を行い、その改善内容について説明を加え、再度公開していた。

このように、公開コードを読み込んで、作成者の気付かないところを改善したり、改善や変更の提案などのやりとりに加われるようになりたいものだ。

(この世界では、提案ばかりして、やってみせないでいると、きらわれるようだ。実効性は課題によって違うので、実施した結果とともに示すことが求められている。)

 

9月15日(火)

今使っているコードは、不自然なことが多い。

その原因は、Lossが小さく、評価も良い結果が、LBの向上につながらず、LBスコアが下がってしまう。

LBスコアを上げるために、パラメータを、不自然な方向に変更しているように感じている。

 

9月16日(水)

public dataにオーバーフィットさせて、失敗を繰り返しているので、public dataのLBスコアに振り回されることのないように、もっと、よく考えながら、進めよう。

 

9月17日(木)

スコアの高い公開コードで計算してみた。

GPUの残り時間が少なかったので、GPU使用時間削減を最優先とした。

そのため、前半の9回の繰り返し計算を1回とし、後半は何も変更せず計算した結果、PublicLBスコアは、オリジナルでの値よりは低いが、その違いは予想外に小さかった。

その理由は、前半と後半の重みが後半に偏っているためである。

それにしても、漫然と9回も繰り返し計算していたのは何だったのかと思う。

 

9月18日(金)

今日は、Landmarkコンペにかかりっきり。

 

9月19日(土)

 

この記事はここで終了する。

 

*反省

1.手本になる公開コードが見つからず(コードを理解しきれない)注釈付与ができなかった。

2.CT画像から、症状の程度やFVCの減少を推定することができるようなモデルをつくろうと考えていたが、できなかった。

3.使っている公開コードのチューニングはある程度までは進んだが、モデルの理解が不十分であり、モデルを改善する方向が途中で見えなくなった。

4.個別モデルのval_lossの減少方向とpublic LBが逆相関になり、解消方法がわからない。CT画像の重みに対する疑問が残ったままである。

 

このコンペが終わったら、追記する予定。

 

                                    以上

                           

 

f:id:AI_ML_DL:20200818095420p:plain

style=152 iteration=1

f:id:AI_ML_DL:20200818095552p:plain

style=152 iteration=20

f:id:AI_ML_DL:20200818095656p:plain

style=152 iteration=500




 

 

 

 

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