MLを実装する際の方法論1

いきなりまとめ

MLのアルゴリズムの調査にはとても時間がかかる。
問題に応じたベストプラクティス知ることで開発効率を上げることができる。

Today I Learned

11 Practical Methodology
を参考に。

背景

MLを現実の問題にうまく適用するにはアルゴリズムや原理を知っているだけでは不十分。
特定の問題にどのアルゴリズムが適しているか、得られた結果をどのようにモニターし対応すればいいのかを知らなければならない
もっとデータを集めるか、モデルキャパシティを変更するか、どの程度一般化するか、ソフトをデバッグするか、最適化を促進するか、といったことにはとても時間がかかるため。

デザインプロセス

• ゴールを決める（エラー指標、ターゲット、パフォーマンス指標）
• ベースモデルを作る
• システムの問題を調べる（overfitting、underfitting、a defect in the data、software）
• 徐々に修正を加える（データ追加、ハイパーパラメーター調整、アルゴリズム）

ゴールを決める

エラー目標はアカデミックならばそれまでの論文の値をベンチマークとするし、実践ならば費用対効果が良く消費者に望ましい値を決める。
パフォーマンス指標はaccuracyが一般的だがエラー指標に応じて決める。
実践では複雑なパフォーマンス指標が用いられる（スパムフィルター、レアイベントなど）。
PRカーブのAUC、Fスコア、coverageとaccuracy（グーグルマップのアドレス解読）など。

ベースモデルを作る

データの構造に応じてモデルのカテゴリーを決める。
たとえば、固定長ベクトルをインプットとするならFCレイヤーを持ったモデル。
入力が画像ならCNNを使う。
入出力がsequenceならGRUを使う。

optimization algorithmは SGD with momentum with a decaying learning rateがよい。
もしくはAdam。

データセットが1000万ないときはmild form of regularizationを導入した方がよい。
Early stoppingはマスト。
dropoutは実装しやすく、多くのモデルやトレーニングアルゴリズムに適合する。
batch normalizationはgeneralization errorを減らすことがあり、dropoutが不要になることもある。

事前に研究されている分野ならばそのモデルをコピーするだけでうまくいくかもしれない。

unsupervised-learningから始めるべきかどうかは分野による。
NLPではunsupervised word embeddingsがとても有益だと知られている。

Evolution Strategyについて

いきなりまとめ

Evolution Strategyの概要

• Reinforcement Learningと同様の行動探索のためのアルゴルズム
• black-box stochastic optimization techniquesのこと
• ランダムに生成したパラメーターを元に探索を行う

Evolution Strategyの利点

• back-propagationが不要
• 高い並列性
• 高い頑健性
• long time scaleに向いている

Today I Learned

Evolution Strategies as a Scalable Alternative to Reinforcement Learning
を参考に。

Reinforcement Learning

ある環境（ゲーム）に置かれたagentがどうふるまうか(policy function)を決める。
policy functionとはたとえば、ゲームの状態をinputとして許された行動のそれぞれの確率を出力するneural networkのこと。
パラメーターの数は100万にもなり、ゲームをうまくプレイするための最適なパラメーターを見つけることがゴール。

Evolution Strategies

evolutionとついているがbiological evolutionとはほとんど関係ない。
black-box stochastic optimization techniquesのこと。
black-box stochastic optimizationでは100万のパラメーターが入力され、1つのtotal rewardが出力される。
数学的にはf(w)をwに関して最適化する。
ただしfについてはいかなる仮定も置かない。

最適化のアルゴリズムは“guess and check” process。
ランダムなパラメーターからスタートして、1:ランダムに少し調整、2:その結果を元に変更、を繰り返す。

具体的には、wに対してgaussian noiseを加え100個の少しずつ異なったパラメーターベクトルを生成。
それぞれ独立にpolicy networkを使用してシミュレーションを実施しrewadsの合計を取得。
アップデートするパラメーターベクトルはそれら100個のパラメーターをrewardsで重みづけした加重平均。

ESではパラメーターに直接ノイズを入れるが、RLではアクション選択にノイズを入れる。

Evolution Strategiesの利点

• バックプロパゲーションが不要
• 高い並列性
• 高い頑健性
• long time scaleに向いている

バックプロパゲーションが不要

これによって、

• コードが短い
• 2，3倍はやい
• メモリー消費が少ない
• gradients explodingの心配がない
• はるかに多くの関数の探索が可能

となる。

高い並列性

RLでは全パラメーターを同期させなければならない。
ESではノイズを入れたパラメーターに関するrewardを同期させるだけでよい。

高い頑健性

RLではハイパーパラメーターの値を変えると結果が大きく変わることがある。
たとえばframe-skip hyperparameterを変えるとRLでは結果が大きく異なる。
ESではどんな値でも同じくらいうまくいった。

long time scaleに向いている

1エピソードの時間が長い場合やアクションが長時間の影響を及ぼす場合などはESは望ましい。

Dual Encoderによる自動応答システム(Chatbot)

いきなりまとめ

Dual Encoder LSTM networkの概要

• 2つのLSTMレイヤー
• 会話文と応答をそれぞれのレイヤーに入力
• 会話側のLSTMレイヤーのstateより応答側のLSTMレイヤーのstateを予測 
• 両者の類似度から応答分の正答確率を出力

Dual Encoder LSTM networkのパフォーマンス

• recall@1ではベースラインモデルと同程度
• recall@2,@5ではDual Encoderが勝っていた

Today I Learned

Deep Learning for Chatbots, Part 2 – Implementing a Retrieval-Based Model in Tensorflow
を参考に。


Dual Encoder LSTM networkによるRetrieval-based-modelの実装例。

データセット

ubuntu Dialog Corpusを使用。
トレーニングには会話文、応答分、応答分の正誤ラベル。
テストには会話文、応答分、9つの誤った応答分。

モデル構造

embedding+LSTMレイヤーを2つ用意。
会話文と応答分をそれぞれのレイヤーに入力。
会話文側のレイヤーから出力されるfinal stateを用いて、
応答分側のレイヤーから出力されるfinall stateを予測する。
両者のdot productより類似度を算出し、
sigmoidアクティベーションで応答分の正答確率を出力する。
loss functionにはcross entropyを使用する。

モデルの評価

テストデータに対するリコール@1,2,5で評価。
ベースラインモデルとしてランダムモデル、tf-idfモデル。
ランダムモデル:0.09, 0.19, 0.49
tf-idfモデル:0.49, 0.59, 0.76
Dual-Encoder:0.50, 0.68, 0.91%
リコール@2,5でDual-Encoderのパフォーマンスが大幅に上回った。

Deep Learningによる自動応答システム(Chatbot)の概要

いきなりまとめ

自動応答システムは2種類

• Retrieval-based model
• Generative model

DeepLearningはどちらのモデルにおいても使用される。
よく使われるのはクローズドドメインのRetrieval-based model。

Today I Learned

Deep Learning for Chatbots, Part 1 – Introduction
を参考に。


自動応答システムにはRetrieval-based modelとGenerative modelの2種類がある。
DeepLearningはどちらでも使用されうる。

Retrieval-based modelの特徴

• 新しい応答を生み出さない。
• 事前定義された応答集より取り出す。
• その際にルールベースもしくはMLによるクラス分類を使用。
• 文法的にミスがない。
• 名前などの文脈情報を返せない。

Generative modelの特徴

• 新しい応答を生み出す。
• MachineTranslationと同様の技術を使用。
• 名前などの文脈情報を返せる。
• 文法的ミスがありうる。
• 膨大なトレーニングが必要。
• Sequence to Sequenceモデルが適している。

共通事項

• 入出力のテキストが長くなるほど難易度が高い。
• オープンドメインよりもクローズドドメインの方が難易度が高い。 

共通する困難

• 会話文脈を取り込むこと。
• 意味的に同じ質問に対して一貫した応答をすること。
• 人の評価に匹敵するモデル評価の指標がないこと。
• 一般的な応答ばかりすること。

Retrieval-based modelにせよGenerative modelにせよ、オープンドメインでのシステムは実現するのが困難。
文法ミスや不適切な応答の可能性があるGenerative modelよりもRetrieval-based modelが実際には用いられている。

Elixir（関数型言語）で再帰関数を作る方法

いきなりまとめ

公式サイトのガイドより。

再帰関数を作るアルゴリズムは2通り

• MAPアルゴリズム
• REDUCEアルゴリズム

Enumモジュールを使えば再帰関数は簡単に実装可能。

背景

なぜ再帰関数が必要か？
関数型言語の変数はimmutable（変更不可）だから。
ループ処理(for,while,etc)で前回の値を使用して次回の値をアップデートしていく場合には再帰関数を作る必要がある。
        for(i = 0; i < sizeof(array); i++) {
          array[i] = array[i] * 2;
        }

 関数型言語はなぜimmutableか？
 参照透過的であるため。

 参照透過性とは何か？
 f(x)→yにおいてxが定数で置き換え可能であること。
 非関数型言語でxの値を代入により次々にアップデートしていくと置き換えは不可能。

なぜ参照透過性が必要か？
コードのメンテナンス性を向上させるため。
同じ変数を次々にアップデートしていくと、どの段階の処理に問題があるか検証に時間が掛かる。

Today I Learned

関数型言語において再帰関数を作る方法は主に2つ。
REDUCEアルゴリズムとMAPアルゴリズム。

REDUCEアルゴリズム

引数リストの要素を関数の呼び出しごとにpop、
popされ要素が減ったリストを引数として再帰的に関数を呼び出す。
たとえば、[1,2,3]の総和を求めたい。

#
# 1:引数パターンによって同名関数のマッチング
#    リストの長さ≠0　→　def sum_list([head | tail], accumulator)
#    リストの長さ=0　→　def sum_list([], accumulator)
#
# 2:リスト要素のパターンマッチング
#     [head|tail]で引数リストを先頭の1要素とそれ以外の要素とにわけheadとtailにマッチさせる
#
# 3:関数の再帰呼び出し
#
defmodule Math do
  def sum_list([head | tail], accumulator) do
    sum_list(tail, head + accumulator)
  end

  def sum_list([], accumulator) do
    accumulator
  end
end

IO.puts Math.sum_list([1, 2, 3], 0) #=> 6

MAPアルゴリズム

引数リストの要素を関数の呼び出しごとにpop、
popされた要素に処理を加え、
popされ要素が減ったリストを引数として自己関数を呼び出す。
各回の関数の呼び出しでは上記の先頭要素と後続要素を結合したリストを返す。
たとえば、[1,2,3]の各要素を2倍にする場合。

defmodule Math do
  def double_each([head | tail]) do
    [head * 2 | double_each(tail)]
  end

  def double_each([]) do
    []
  end
end

IO.puts Math.double_each([1, 2, 3]) #=> [2, 4, 6]



Enumモジュール

Enumモジュールを使えば再帰関数は簡単に実装可能。

iex> Enum.reduce([1, 2, 3], 0, fn(x, acc) -> x + acc end)
6

iex> Enum.map([1, 2, 3], fn(x) -> x * 2 end)
[2, 4, 6]

バッハっぽい賛美歌を自動作曲するDeepBach

いきなりまとめ

DeepBachモデルの特徴

• DeepBachは4つのレイヤーを持つ4つのモデルからなる
• それぞれのモデルは異なる音域を出力
• 過去と未来の情報を取り扱う2つのLSTMレイヤー
• 同時に発生する他の音を扱うレイヤー
• それらを統合し音を出力するレイヤー
• ユーザーの創意を取り入れ作曲することが可能

DeepBachのパフォーマンス

• 出来上がった曲に対して専門家を含め50%前後がバッハと回答
• 盗作の恐れも低い

Today I Learned

DeepBachモデルの詳細。
自動作曲されたサンプル。

モデルの構造

入力データ=(V1,V2,V3,V4,S,F),
４つの音域に対応したMIDI音声（ソプラノ、アルト、テノール、バス）、ビート番号、fermatasの有無。

それぞれの音域ごとに4つのモデルを構築。
1つのモデルは4つのレイヤーからなる。
過去と未来の音を入力とする2つのembedding+LSTMレイヤー。
同時に発生する他の音を入力とするレイヤー。
それらをマージしピッチの確率を出力するレイヤー。

サンプルの生成

gibbs-samplingを使用。
4つの音に対応した長さLのリストをランダムに生成。
時間と音域をランダムに選び推定したモデルよりサンプリング。

利点はユーザーの好みを出力に反映できること。
たとえば、ある音域を固定、それ以外をサンプリング。
farmatasの調整。
音域ごとのサンプリングレンジの制限。

モデルの評価

人間に対するリスニングテストと盗作分析を実施。

リスニングテストでは3つのモデルを使用。
DeepBach、Maximum Entropy model、Multilayer Perceptron (MLP) model。

知覚テストでは同一のバッハのメロディーから2つのメロディーを生成し、どちらがよりバッハっぽいか聞いた 。
アンケートをもとにBradley-Terry modelによりスコアを推定。
DeepBachモデルは他のモデルより成績が良かった。

判別テストではメロディー1つを聞かせ、本物バッハか自動作曲か尋ねた。
DeepBachモデルは他のモデルより成績が良かった。
DeepBachを聞かせたところおよそ50%はバッハと判定。
バッハのむずさ考えればすげーよとのこと。

When presented a DeepBach-generated extract, around 50% of the voters would judge it as composed by Bach.
We consider this to be a good score knowing the complexity of Bach’s compositions and the facility to detect badly-sounding chords even for non musicians

盗作分析では生成されたメロディーがトレーニングに使ったメロディーと一致するその最大長を計測。
盗作の傾向はみられなかった。

Encoder-Decoder/Sequence-to-Sequenceについて

いきなりまとめ

Encoder-Decoder/Sequence-to-Sequenceモデルの特徴

• 2014年に開発されたRNNモデル
• inputとoutputが共に可変長
• 2つのRNNから構成
• input→RNN(Encoder)→final state/context C
• context C→RNN(Decoder)→output

Encoder-Decoder/Sequence-to-Sequenceモデルの応用例

• 音声認識
• 翻訳
• 自動応答

Today I Learned

10.4 Encoder-Decoder Sequence-to-Sequence Architecturesを参考に。

背景

Encoder-Decoder/Sequence-to-Sequence登場以前のRNNは3種類。
SEQ→VEC、VEC→SEQ、SEQ→SEQ（ただし入出力の長さが同じ）。
入出力が固定長のベクトルであり、入出力の順序を考慮できていなかった。
順序を考慮できても入出力が同じ長さであった。
Encoder-Decoder/Sequence-to-Sequenceは順序を考慮しつつ、入出力の可変長を実現。

モデルの構造

encoderとdecoderと呼ばれる2つのRNNからなる。
encoderはinput X = (x(1), . . . , x(nx))に対して、final state/context Cを出力する。
decoderはcontext Cををinputとして、Y= (y(1), . . . , y(ny))を出力する。
nx=ny=τでなくてもよい。
だからインとアウトの長さが異なる自動応答や機械翻訳に使える。
それを可能にするのが2つのRNNをつなぐcontext C。

モデルの弱点

context Cの情報量が少ないと長い情報を要約できない。

じゃあどうするか

context Cを固定長vectorじゃなく可変長sequenceにする。

他には、attention mechanismを取り入れる。（Bahdanau et al. (2015) ）
出力１ステップごとに別々のcontext Cを参照する。
それらのcontext Cは単にencoderのfinal state1つだけからじゃなく入力1ステップごとのstateの加重平均から作る。