Hedgehog機械学習と気になる技術を語るはりねずみこの広告は、90日以上更新していないブログに表示しています。medical創薬においてコンピュータの活用はますます盛んになってきており、2012年にはKaggleでコンペも開催されました。このコンペは標的に対する分子の活性を推定するというタスクでした。Learningの適用可能性を示したことで当時は話題になったそうです。Learningがどのようなアプローチで適用されたのかを紹介してみます。!Caution!できる限りの調査をしましたが、私は製薬や医療に詳しい人ではないので誤った解釈をしてしまっている可能性があります。「ここ間違っている」と言う点がありましたら指摘いただけると幸いです。はじめにコンペのタスク背景となる創薬について概要を説明してみます。いったステップで進んでいきます。基礎研究と呼ばれるフェーズでは一般的に以下の様な流れとなるそうです。体の中のタンパク質等の働きをもとに、病気の改善につながるターゲットを選定します。炎症を引き起こす物質としてプロスタグランジンの一種があるそうですが、これは酵素「プロスタグランジンH合成酵素」によって合成されるそうです。この酵素をターゲットとして働きを弱める化合物が発見できれば、それはすなわち抗炎症薬と言われるものとなります。このように、ターゲットを探すことから薬作りが始まります。リード化合物の探索ターゲットに対して反応を示す化合物であるリード化合物を探します。リード化合物を探す理由は全くヒントがない状態から薬となる化合物を作るのでは無く、効果がある化合物をベースに発展させていくほうが現実的なためです。リード化合物を探す方法の一つとしては、経験的に効果があると知られている物質から求める方法です。19世紀に生まれた炎症薬であるアスピリンは、ヒポクラテスが熱や痛みに対して処方したとされるヤナギからリード化合物を見つけ、発展させていったそうです。化合物に対して活性の反応を得る方法でスクリーニングと呼ばれる手法です。候補とする化合物は分子量や形など一定の条件をもとに用意し、様々な活性を一度に調べる中からリード化合物となるものを見つける方法です。以上の方法から薬のタネを探すのがこのフェーズの目的です。リード化合物の最適化リード化合物に対して様々な合成を行い、薬候補となる化合物を作成します。発見したリード化合物そのままでは効果が限定的であったり、副作用がある場合もあります。その後のフェーズでは動物や人間を用いた試験(前臨床・臨床(1相、2相、3相))において効果や安定性が確認された後、国に承認されて晴れて市販されるようになります。基礎研究から承認まで平均で13~14年もかかり、候補として研究を始めた分子が新薬として世に出る確率は3万分の1とも言われているようです。各フェーズにおいて、効果があまり出ない、副作用が強すぎる、製造工程を安価にできないなどで研究が中止されることも多々あるそうです。お金も莫大に掛かるでしょうから厳しい世界ですね...Kaggle創薬コンペここで話題を変えてKaggleに目を向けると、このコンペはリード化合物の探索をコンピュータ上で行うバーチャルスクリーニングを想定しているのでは無いかと思われます。コンペの目的は15種類のターゲットに対して各分子の活性がどれくらい示すかを推定するタスクであり、これはまさにタンパク質に対してどの化合物が反応を示すかを調べることを意識していそうです。Learningの手法を見ていきます。Setデータセットはすべてコード化されているため何を意味しているかは分かりません。ドメイン知識を用いることができません。15個のターゲット毎にファイルが分かれており「ACT1」のように表現されています。3A4」に関する各化合物の反応を記したものでありそうです。ちなみに、この酵素は主に肝臓や小腸に分布しており、薬物治療の最適化(薬が代謝排出されずに吸収されやすいようにするなど)を考える上で重要な酵素であるとみなされることが多いそうです。Set以下の通り情報が与えられています。「ACT1_M_80」のように、「ターゲットコード+分子コード」で表現されています。分子コードはすべてのターゲットで共通であり一意につけられているようです。ターゲットごとに単位が異なっているため同一のスケールでは無いことは留意しておく必要があります。pair(DP)であると明かされました。いずれも原子同士の組み合わせを表現しているようです。もとにラベル付けされているようです。その他で分類しているそうです。(ここまで来るとちょっと追いきれないのでそれぞれの意味は他に譲ります...)中身を見てみると0以上の数値データで表現されている非常にスパースなデータであり、5%のみが0以外と論文では説明されています。記述子のラベルそれぞれがどんな意味を持つのかは論文でも言及されておらず最後まで不明なままでした。Setトレーニングセットから活性値を除いたフォーマットになっています。コンペでは15種類のテスト用データセットに記載されている分子について、それぞれの活性値を推定して提出することとなります。コンペの評価は相関係数Rの二乗で求められます。Leaderboardは以下の表となっています。Learningを用いた手法でした。Hintonもアドバイサーとして参加していたようです。SVMなど)を用いた手法でした。Robot社ですが、この年の年初に企業してコンペに参加したようです。Learning手法が上回った結果となりました。Learning手法を見ていきます。Relationshipsをもとに手法を見ていきます。これは、1位になった手法をベースに少し改良を加えたモデルのようです。Leariningを適用し、他の手法と同等以上の性能を示すことができた点です。forestといった手法が用いられてきたようですが、Deep系の手法が実問題に適用できたということが注目されたようです。ネットワークを見ると基本的には全結合層を重ねただけのシンプルなネットワークです。論文ではハイパーパラメータ(隠れ層の数やニューロン数、ドロップアウト、事前学習など)によって性能がどう変化するかを様々実験し、考察されています。Network次に論文中の2つの実験について紹介します。Joint筆者達は15個のターゲットに対するデータセットについて、別々のデータセットで学習すべきか、全てのデータセットを用いて学習するべきかを実験しています。言い換えるとACT1用、ACT2用、...と一個づつモデルを用意するか、ACT1〜ACT15まで全てのターゲットに対して推定できるモデルを1つ用意するかで性能がどのように異なるかを確認したということです。DNNと名付けられています。ネットワーク図のイメージとしては以下です。DNNでは学習データが足りずに性能が向上しない可能性があると筆者達は考えたようです。DNNは問題に対して、全てのデータセットを用いて1つのモデルとして学習することでデータ不足を補います。それぞれのターゲットを予測する部分はアウトプット層で分けたニューロンを分ける事で出力されています。全てのデータセットを用いることで大量のデータから獲得した分子構造の知識のようなものが隠れ層に蓄積され、性能向上に役立てることを期待しています。これら2つのモデルの性能を比較した結果は以下の通りと報告されています。DNNの性能が良いことを示しています。DNNの方が良いことを示しています。13個のデータセットにおいて(右)、性能が良い理由としては学習に用いた分子のうち85%が単一のデータセット、97%が2つ以下のデータセットでしか出現していないため、他のデータセットの特徴をうまく活用できたからではないかと考察されています。逆に大きいデータ量を持つ2個のデータセットおいて(中央)性能が悪い原因としては、重複する分子はこの2つのデータセット間によるものであったため悪くなったではないかと述べられています。個々の部分の説明はあまりしっくり来ていませんが...。DNNの疑問点としてデータセット間で記述子と分子が揃っておらずどのように扱っているのか、またそれによる性能への影響があります。ACT1にD_1はあるが、ACT2にはD_1が存在しないといった風です。想像するに記述子も活性も単純に0としていると思うのですが実装が見つからなかったので不明でした。RFこの論文では最終的に以下ハイパーパラメータでモデルで性能が良かったと述べられています。DNNで学習されたものとなっています。パラメータ初期値はランダム。コンピュータ資源が許す限り多く。パラメータは学習率0.05、モメンタム0.9、重み減衰0.0001。forestについて、データセット毎に比較した結果が以下となります。values)が上回っています(太字部分)。forestより性能が良かったと筆者らは言っています。Learningがどのように適用され、実用可能性があるかをKaggleのコンペを通して見てみました。Learningを用いる事について、筋は悪くないのではと感じました。Learningの課題として解釈が難しいという点があり、研究対象にもなっています。一方で、数多ある候補からリード化合物となる可能性が高いものを見つけるこのタスクにおいては、なぜそのように推定したかよりも1%でも性能が高い方が優先されるのではないでしょうか。Learningは選択肢の一つとしては十分にあげても良いのではないかと思います。この点については専門家の方にどこを重要視するのか聞いてみたいです。データセットについても考えさせられました。コンペで用いたデータセットの記述子が実際の活性予測する上で妥当であるのかや特徴量の学習は可能なのか、よく用いられるフィンガープリントではどうなるのかなど、データセットに起因する懸念点もあるようです。Convolutionなど、新たな手法によって利用できるデータセットも変わってきているとも言えると思います。embeddingword2vecなど分散表現が活躍するシーンは多いですが、実行速度やメモリなど利用する上で気がかりになる面もあります。この記事では分散表現をすばやく便利に使うためのパッケージであるMagnitudeの説明と実行速度について実験した結果を紹介します。簡単にすばやく単語ベクトルを扱うためのライブラリです。代替を想定しているようです。ついてMagnitudeではベクトル取得を高速化するために、事前に分散表現を変換したものを用います。それぞれの分散表現ごとに独自のフォーマット".magnitude"のオブジェクトとして用意しています。初期ロード時は遅延ロードするようになっているためオブジェクトの読み込みに時間がかからないようにし、一度呼び出された単語はメモリ上にキャッシュすることで再取得時には高速に取り出すことができます。SQLiteを用いることにより実現されているようです。3種類が用意されています。用意されているモデルはword2vecやGlove、ELMoなど様々であり、今後は話題のBERTも追加される予定のようです。ついてここではMagnitudeの特徴的な機能(だと私は思っている)である、未知語(Out-of-Vocabulary)に関する機能を紹介します。基本的な機能を含めて利用方法自体は簡単であり、githubのREADMEを見ていただければ困らないと思います。Keys新しい単語やスペルミスなど、分散表現を構築する際の学習データに含まれない未知語に対し、Magnitudeは適当であるランダムなベクトル値を割り振ります。言うと、同じ単語であれば2回目以降は同じベクトルを返すようにすること(辞書に新規登録するイメージ)と、n-gramが近しい未知語はベクトルも近しくなるように割り振るようにしているそうです。Lightモデルで利用することが可能です。Keysこちらも未知語に対する処理方法ですが、ランダムにベクトルを割り当てるのではなく、辞書に登録されている近しい単語に似るようにベクトルを割り当てます。スペルミスやtypoも近似できるようになっています。MediumやHeavyモデルで利用することができます。内部でどのような処理を行っているのかの説明と、日本語に対しても処理できるようにした実装が以下の記事で紹介されています。key)では110倍高速に処理することができるとされています。その他のベンチマーク結果はこちらから確認することができます。以下からはMagunitudeを用いることで学習速度を向上させることができるのか、実験で確かめていきます。速度実験Magnitudeが他のライブラリに比べて学習に掛かる時間を短縮させることができるのか確認してみます。今回は速度比較を主眼とするため、いずれもライブラリの場合でも全結合層を1層だけ用いただけのモデルであり、違いは分散表現の取得処理だけが違いとなるように実装しています。私のgithubにおいてますのでよければ見てみてください。Hubとの比較ではELMoを用いて比較しました。映画ジャンルにおけるマルチラベル分類。紹介されているものを利用。うち特定の9種類ジャンルに関するデータだけを抽出した14,993件を用いています。このうち80%を学習データとして、20%をテストデータとして利用します。Gensimword2vecを利用した場合以下の通りになりました。Magnitudeはword2vecのMediumを利用しています。結果を確認してみましょう。0.8877すべてのエポックをトータルで見るとGensimのほうが速いですね...ただGithubにあげているソースを見ると分かるように、Gensimはword2vecのモデルをロードする際に2,3分時間がかかっていましたが、Magunitudeは一瞬でロードが終わっています。加えて、2エポック目以降はMagnitudeのほうが速かったです。実装上の問題で全く同じ処理にできているかと言うと異なります。Gensimでは未知語をすべて同一の特定単語に置き換えている一方、Magnitudeでは未知語の推測を行っているためです。この当たりが速度に影響を及ぼしているかは今回は確認できていません。HubELMoを利用した場合の結果は以下の通りになりました。MagnitudeはELMoのMediumを利用しています。ELMoの概要については以前に以下の記事で紹介しました。0.8963こちらは明確にMagnitudeの方が速くなりました。あまりにも速くなっているので心配になるのですが、学習が進んでいるところを見ると実装が明らかに間違えているわけではなさそうです。Hubと比較してやってもよかったかも)速度以外に確認した点として、MagnitudeでどのようにELMoを実装しているのかソースを確認しました。NLPのELMoを用いて計算しているようでした。まとめMagnitudeを用いることでEmbeddingを高速に取り出すことができることを確認しました。Hubより高速に取り出すことができました。Magnitudeは速さ以外にも未知語の処理やメモリ使用量なども強みがあるので、公開されている事前学習済みモデルを用いる際は利用する価値があるのではないかと思います。Objectに変換できるようなので、自作に挑戦しても良いですね。フォローやコメントなどで応援して頂けると励みになります。おけるword2vecや画像処理におけるInceptionなど、一般的に広く用いられているモデルを上流で用いる事は多くあります。汎用的な知識を扱えるメリットがある一方、学習には大量のデータセットの準備と膨大な学習時間がかかってしまいます。この問題に対して、あらかじめ学習させた状態のモデル(事前学習済みモデル)を用意しておき上流に転移させる方法があります。HubはGoogleの大量リソースを用いて学習したモデルを手軽に実装できるほか、自作したモデルを別環境で利用しやすいように自作することも可能です。本記事では概要と特徴、利用方法を紹介します。ついて実験したコードはGitHubにあります。利用方法は生TensorFlowとKerasにおいてFine-tuningを行う実験を行っています。作成を行う例はネット上でもなかなか無かったので、誰かのお役に立てたら幸いです。(チュートリアルでは大雑把にしか書いてなかった)スターしていただけると嬉しいです。HubはGoogleが提供している事前学習済みモデルです。以前から事前学習済みモデルは様々なフレームワークでも提供されており、TensorFlowにおいてもグラフと学習済みチェックポイントが公開されています(現在も更新されているようです)。利用する際にはグラフを定義したファイルの読み込みやチェックポイントの解凍やロードが必要であるなど手軽ではない印象を受けます。Hubの特徴はなんといっても手軽に実装できる点が特徴です(しかもGoogleが大量リソースを用いて学習したモデル)。HubはGoogleの潤沢なリソースを用いて学習させたモデルが無料で提供されています。Modelsでは2,000億単語を用いて学習したモデルなどがあります。Hubにおいてグラフと重みはひとまとめに提供されており、モジュールと呼ばれます。モジュールという単位にすることによってグラフの読み込みや重みのロードなどそれぞれの操作を意識することなく利用することができます。現時点では提供されているモジュールのグラフ構造を読み解くことはできないようになっています。Issueより)ざっくりとしたイメージではモジュールはクラスのようなものと考えることができ、インプットを与えれば求めた処理を行い、アウトプットを返却するものです。モジュール内部のグラフなどを考える必要はありません。Hubのモジュールの用語・機能について説明します。シグネチャモジュールが持つメソッドのような機能です。モジュールは複数のシグネチャを持つことができ、指定したシグネチャによってインプットや処理内容などが変わります。指定しない場合はdefaultが指定されます。アウトプット複数のアウトプットを持つモジュールがあります。何も指定しない場合はdefaultのアウトプットのみが返却されますが、as_dict=Trueを指定することで定められたoutputがリストで返却されます。Hubでは様々な分野の事前学習済みモデルが用意されています。同一のモデルであっても返却される次元数や学習させる言語について異なるモジュールが用意されている場合があります。2018年8月現在では以下の通りですが、今後映像や音声系のモジュールの提供も予定しているとのこと。それぞれmultiplierが25,50,75,100%のものを用意。Hubを用いた実装例を紹介します。利用するのは難しくないのですが、モジュールの作成は少し面倒なところがあります。以下で説明する機能の実装例はGitHubにあります。以下は公式サイトに記載されているサンプルコードです。前回の記事で紹介したELMoを例に紹介します。与えた文について単語ごとにELMoの分散表現を得る事を目的とした例です。Hubを利用するにはモジュールのURLを指定してモジュールのダウンロードし、インスタンス生成を行います。その際にFine-tuning行わせたい場合は"trainable"をTrueにしておきます。これだけでグラフと重みのロードが終わっています。モジュール適用インスタンスに対してモジュールで定められた形式で引数を与えます。Googleが提供する各モジュールは仕様が公開されており、今回のELMoの場合はこちらのページに記載されています。ここでは分散表現を得る対象の文、シグネチャ、返り値の形式を指定します。ここではシグネチャを"default"にしています。仕様ではこのモジュールは2つのシグネチャを持っており、一文を与えて処理させる"default"と、トークナイズした単語配列を与えて処理させる"tokens"が用意されています。アウトプットについては"elmo"を指定しています。これは"default"のアウトプットでは文中単語の分散表現の平均を返すようになっており、目的とした単語ごとの分散表現は"elmo"で返却されるためです。"default"以外のアウトプットを用いるので"as_dict=True"としています。実行セッションで実行すればOKです。他の計算を足すことも可能です。Fine-tuningしたい場合は通常通りloss関数やオプティマイザを設定する必要があります。作成についてはコードを書くと長くなるので大まかな流れを図とともに説明します。本記事では概要の説明だけを行いますが、実装はGitHub上にあります。モジュール作成で特にポイントとなるのはグラフの定義と重みを分けて扱う必要がある点です。これはエクスポート時にグラフ定義の関数と重みの割当は別々に行う必要があるためです。以下説明で順に説明していきます。作成したいモデルを構築し、学習を行わせます。目標の性能が発揮することが確認できたら一度モデルを保存します。重みをFine-tuning(再学習)させる想定が無いのであれば、convert_variables_to_constantsを用いてVariableをconstantに変換させておくと後の手順が一部スキップできます。2モジュールスペック定義モジュール内のグラフである"Module_Spec"を定義する関数を作成します。「1作成モデル準備」で保存したモデルをロードし、インプットとアウトプットのテンソルの変数を取得します。取得したインプットとアウトプットを用いてモジュールのシグネチャを追加することでスペック定義に用いる関数を用意します。3モジュール作成スペック定義を用いてモジュールのインスタンス生成を行います。この時点で作成したモデルと同じように利用することができますが、この時点ではVariableの値つまり重みは初期化されたままです。4重み割り当て「1作成モデル準備」で保存しておいたモデルの重みをロードして割り当てることで、事前学習した状態のモジュールとすることができます。Fine-tuningさせる予定がなく、constantに変換済みであればここの手順は不要です。(重みはグラフ中のconstantとして既に含まれているため)5エクスポート最後にこのモジュールを"export"したら事前学習済みモデルのモジュール完成です。指定したフォルダにモジュール一式であるpbファイルと重みであるVariableの値が出力されます。作成したモデルは2つの方法で別環境で利用することができます。モジュールファイルを直接受け渡しexportしたモジュールを利用したい環境へ配置し、モジュールのダウンロードURLの部分でディレクトリを指定すれば利用かのうです。作成したモジュールが以下通りexportされた場合、ディレクトリmnist_moduleを指定すればOKです。variablesクラウドストレージを用いたホスティングモジュールを圧縮した上でクラウドストレージに配置したものを利用することが可能です。その際は「.tar.gz」に圧縮すれば良いと説明があります。圧縮方法は公式の説明に任せますが、利用する際はダウンロードURLにクエリ「?tf-hub-format=compressed」を追加する必要があります。試した結果、両者とも問題無く使用することができました。実際に使用している中で感じた良い点とあと一歩の点を挙げて見ようと思います。・大量リソースで学習された事前学習済みモデルが無料で利用出来る。hubを用いた場合、Fine−Tuningさせた結果の保存が不可能?生のTenforFlowでは再学習結果も含めモデルを保存できたが、KerasのLambdaレイヤ内の重みの保存は実験する限りでは無理そうだった。カスタムレイヤで実装するしか無いかもしれない。保存してあるモデルをサクッと読ませるだけでモジュール作成出来るようになると便利だと思います。Hubによって事前学習済みモデルの恩恵を手軽に受けれるため、自分が取り組んでいるタスクに対して注力できるのはとても良いと感じました。有益な事前学習済みモデルを自作した場合にも他者が利用しやすい形で公開できるのは魅力ですね。NLP文脈を考慮した単語表現を獲得する深層学習手法のELMoを紹介します。「アメ」は「Rain」と「Candy」どちらの意味か?それを文脈から考慮させるのがこの手法です。機械学習で取り組まれている複雑なタスクは、部分問題を解決する技術を組み合わせて実現されます。文書分類というタスクに取り組む場合、文書特徴を獲得するために単語分割や単語表現などの手法を用いた上で、SVMやナイーブベイズといった分類器を用いる方法があります。部分問題を解決する技術は特定のタスクだけではなく、様々な問題で利用することができます。単語分割は文書分類にだけではなく質問応答など自然言語処理において幅広く利用されます。上記のように部分問題は様々なタスクで用いられるため、部分問題の性能向上は様々なタスクの性能向上に寄与できる可能性があります。部分問題がうまく解決できていないと、それらを組み合わせて実現する応用タスクも望んだ結果が得られない恐れがあるためです。単語分割でいうと、単語がうまく区切れないまま文書分類を行ったとしても結果は芳しくないであろうという事は直感的に理解してもらえると思います。今回は単語表現という部分問題において、文脈を考慮した表現を獲得するELMoと呼ばれる深層学習手法を紹介します。embedding)が注目されていますが、手法の多くは1単語毎に1つの表現しか得ることができません。これは「bank」という単語は「銀行」と「土手」という複数の意味を持ちますが、どちらか一方しか表現できていない可能性があります。ELMoではどの意味で用いられているのかを文脈から汲み取った上で、単語の表現を獲得することができていると主張されています。本記事ではELMoの手法と、論文中で行われている複数の実験のうち「他手法との性能比較」と「文脈を考慮した表現獲得の確認」について紹介します。ELMoELMoは事前学習によって文脈を考慮した単語表現方法を獲得する手法です。一つにも選ばれています。この手法の注目すべき点は、文脈を考慮した単語表現が獲得できる点です。Disambiguation)の助けとなると言えると思います。embeddingは様々なタスクや手法でよく用いられるため活用シーンは多くあります。論文では6つのタスクにおいてELMoを既存手法で用いた結果、性能を上乗せできることを確認しています。以降biLMと呼ぶ)を大量なコーパスを用いて獲得する事で実現されます。Benchmarkを用いて事前学習させたそうです。双方向を用いる理由としては、順方向だけでなく文を逆方向からも読み進めることで語義を正しく捉えられる可能性があるためだと思います。credit.」という文において「bank」の表現を獲得しようとした場合、順方向からは「A」だけの情報しか用いることができませんが、逆方向からだと「financial」や「deposit」、「credit」など金融に係る情報を利用することができます。LSTM(biLSTM)を複数層重ねた物となっています。論文の実験では2層のもので行われています。この手法の工夫としては各層の重みを調整(学習)させることでタスク特有の問題に適合させていると説明されています。獲得された表現は他の単語表現と組み合わせることによって利用すると論文では説明されています。他の単語表現ベクトルと接続(concatenate)してモデルのインプットとします。embedding)を利用することを目指しているのではないかと思います。論文中では様々なタスクに対して性能評価を行っています。analysis)の6種類です。実験では各タスク毎に用意したベースライン手法に対してELMoの有無で性能差がどれくらいであるか評価を行っています。ELMoを適用したベースライン手法と最先端手法(state-of-the-art:SOTA)の比較も行っています。ELMo適用有無による性能比較はいずれのタスクにおいても適用後のほうが優れています。SOTAとの比較においてもすべて上回っています。この実験によりELMoは多様性を含み幅広いタスクにおいて有用であるモデルだと論文で主張されています。ELMoは文脈を考慮した表現を獲得できたのか?各タスクにおいて性能向上に寄与していることは上記の通り確認しています。一方で、論文中では以下の3つの実験から文脈を考慮した単語表現を獲得していることを確認しています。1つ目の実験はELMoと他の単語埋め込み手法であるGloVeにおいて、似ている単語表現を持つ単語の比較です。ここでは「play」という単語が例として挙げられています。GloVeではざっくりと意味が似ている単語(「playing」や「game」など)が似た表現として取れています。一方で、ELMoでは文脈を考慮してスポーツを競技する「play」と、劇を演じる「play」は分けて表現できていると提示されています。GloVeでは1単語から1つの単語表現を得るので、意味が似ている単語が多くなるのは想定通りなのかなと感じます。ELMoは文を与えて各単語の表現を得ており、用いる情報が多いためアドバンテージがあるためのではと思います。disambiguation)の実験です。ここではELMoではなく用いる言語モデル(2層biLM)の各層別々を対象として、他の手法と比較を行っています。5)を見ると2層目のbiLMが性能良く、教師あり学習手法のSOTAであるIacobacciらに迫っていると確認されています。tagging)の実験です。6)も同様に言語モデル(2層biLM)の各層別々を対象としており、1層目のbiLMがSOTAであるLingらに近づいています。これらの実験によりELMoは文脈を考慮した表現が獲得できるていると説明されています。個人的疑問点ここで個人的な疑問点として、上記の実験だけでELMoは文脈を考慮した表現を獲得できたと言えるのかが気になりました。1つ目の実験ではELMoとGloVeの比較を例に文脈を考慮した単語が獲得できた例が挙げられましたが、なぜか2,3つ目の実験ではELMoではなく中で用いている言語モデルであるbiLMの各層を用いて実験していました。ELMoは各層の重みをタスクごとに学習することができるので各層の性能は参考にすることはできると思いますが、ELMo全体としての結果を見てみたいと思いました。性能向上したのは文脈を考慮した表現が獲得したからと言えるのかという点も気になります。チームで話題にした際、ELMoは10億単語を超える大量のコーパスを用いて学習しているため、タスクで利用する際には未知語が少なくなっているのではないかという仮説が挙げられました。未知語が少ないほど性能が向上する可能性があるため、他の手法においても同程度の学習データを用意して実験したほうが良かったかもしれません。「文脈を考慮できた=各タスクで性能向上に寄与できた」というのは少し論拠が弱いかもと感じました。おわりに文脈を考慮した単語表現であるELMoを紹介しました。実験でも確認できたように性能向上の助けとすることができる事が確認できました。ELMoが良いなと思った点としては、大規模なコーパスから汎用的で文脈を考慮した表現を獲得できる点ではないかと思います。学習させるデータを毎回用意するのは手間がかかるため、事前に他のコーパスで事前学習しておくことができる点は利用シーンを広げることができるのではないかと思います。次回はELMoを使った簡単な実験を記事にしようかと思います!よろしければTwitterのフォローやいいねをお願いします。Classificationの代表的な手法と特徴を紹介します。機械学習においてアヤメの分類など10数個までのラベルやクラスへの分類タスクはチュートリアルなどで多く取り上げられています。一方で商品をカテゴリに分類したい場合など大量のラベルやクラスで分類したい場合、既存手法では計算量が膨大になるなど様々な問題に直面します。Classificationと呼び研究が進められています。Classificationは10万〜100万にも及ぶ膨大なラベルやクラスを用いて対象を分類するタスクです。このタスクは少なくとも10年以上前から研究が行われており、学会のワークショップなどでも取り組まれています。日本からはYahooの田頭さんが既存手法を改善させたAnnexMLを発表されています。AnnexMLの論文紹介として、u++さんのこちらの記事が参考になります。Classificationはマルチクラス(multi-class)とマルチラベル(multi-label)の2つの問題に分けて考えられます。Classificationと呼ばれ、対象に対して一つのクラスを割り当てる問題を想定しています。(XMCと略されることが多い)と呼ばれ、近年の研究ではこちらの問題に取り組んだものが多く見受けられます。これはマルチラベル問題はマルチクラス問題を包含しているためだと思います(マルチラベルでの推定結果1番目だけ採用すればマルチクラスと同等とみなせる)。Repositoryが参考になると思います。Basedの3つについて、それぞれ代表的な手法を交えながら紹介します。Basedこのアプローチの基本的な考え方は、分類したいラベルを減らして既存手法を適用可能にさせることをベースとしています。XMCが難しい原因はラベル数が多すぎるためであり、1-vs-Allなどの既存の手法が扱えないためです。そこでラベルを低ランクに近似させることで、扱えるラベル数にしようというわけです。このアプローチにおける手法の違いは、低ランクにするcompression(圧縮)処理や推定結果を得るために圧縮前の次元にdecompression(本記事では解凍と呼称)処理などに現れます。このアプローチの利点としては仕組みとしてシンプルかつ理論的に説明が可能であり、実装が比較的容易である点です。問題点としては現実世界のデータにおいて、ラベル毎の訓練データが不均衡である場合など低ランクに仮定するのが困難な(圧縮の際に情報が落ちる)場合があるという点があります。代表的な手法としてはSLEECがあります。学習フェーズでは高次元(各値は0or1)で表現されるラベルベクトルを低次元へ圧縮(と同時に解凍)する方法を学習させます。次に入力である特徴ベクトルから低次元ラベルを推定させるモデルを学習させます。推論させる場合は低次元ラベルを求めた後、その結果を解凍することによって分類結果を得ることができます。性能向上と計算量を減らすための工夫として、入力である特徴ベクトルをk-means法で大まかに分割させ、それぞれのクラスタで圧縮(解凍)方法を学習させています。推論時にはkNN(k近傍法)で所属するクラスタを求めてから低次元ラベルの推定と解凍を行います。Basedこの方法では大量ラベルでの分類を決定木などの木構造を用いて推定させます。このアプローチではラベル数が多いことによる計算量の増加や性能の低下という問題に対して、既存手法を適応させるために改良したものが多く存在します。このアプローチの利点は木構造のアルゴリズムと同様に、バランスのとれた構造を作れた場合に推定時の計算量がある程度で抑えられる点です。アンサンブルにしたり多くの特徴量と重みを用いることでロバスト性を獲得することができます。代表的なものとしてFastXMLがあります。これはランダムフォレストをマルチラベルに適応させた手法です。impurity)やエントロピー(entropy)を用いていましたが、ラベルが多すぎるために計算量が膨大になってしまう問題があります。そこで目的関数にランキングの評価指標であるnDCG@kを用いる事で、計算量を抑えつつ大量ラベル分類の学習することができます。nDCG@kやこのタスクで良く用いられている評価指標についてはこちらで紹介しています。Learningを用いた手法も提案されており、NAACLなどの学会などでも採択されてきています。Networkで学習させる方法や、分類ラベルをグラフとみなしてEmbeddingを求めて目標関数に用いる方法など研究が盛んになってきています。今回紹介するのは、文書特徴を畳み込んで分類を行うXML-CNNです。少ない隠れ層の追加などでより対処しています。それぞれの工夫については論文輪講にて紹介しました。Classificationは検索や広告などでも応用されてきたように、活用されるシーンが増えてくるのではないかと感じています。今後も研究は活発に行われると思いますので、引き続き注目していきたいと思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。