「文の意味の固定ベクトル」はどこに?
【 「文の意味の固定ベクトル」はどこに? 】
前回見た Ilyaたちの翻訳にRNNを利用しようというアイデアは、一定の成功を収めるのですが、彼らの実装の問題点が指摘されます。
Ilyaたちのアプローチでは、どんな長さの文でもその意味は固定長のベクトルで表現されることになるのですが、Bengioのグループは、それはおかしいのではと異論を唱えます。
Bengioの「次元の呪い」というのは、語の数と文の数とは決定的に異なるという指摘でしたので、「語の意味」を表現するベクトルの次元と、「文の意味」を表現するベクトルの次元が同じだというのは変だと考えるのは当然かもしれません。
「近年、ニューラル機械翻訳として提案されたモデルは、多くの場合、Encoder-Decoderのファミリーに属している。そこでは、ソースの文が固定長ベクトルにエンコードされ、そこからデコーダが 翻訳文を生成する。この論文では、固定長ベクトルの使用が、この基本的なEncoder/Decoderアーキテクチャの性能を改善する上でのボトルネックになっていると推論し、モデルに自動的に、ターゲット・ワードを予測するのに重要なソース・文の一部分について、 (ソフト)検索を可能とすることによって、これを拡張することを提案する。」
「重要な部分は、各デコーダの出力するワード yが、Encoderの最後の状態だけでなく、すべての入力状態の重みづけられた結合に依存することである。」
Encoderの最後の出力を文の意味として、それに一つの固定長のベクトルを割り当てるのではなく、翻訳時に、ソース・文の一部分を 改めて見直して、その部分から提供される情報を翻訳に生かそうということです。それがAttention Mechanismです。
スライドでは、もう少し詳しく説明しておきました。参照ください。
直結していた EncoderとDecoderは切り離され、両者を結びつけていた「文の意味の固定ベクトル」は無くなります。固定ベクトルに代わって「文の意味」は、Encoderの内部状態全ての上に分散して存在することになります。
このアイデアは、「Google ニューラル機械翻訳」システムに採用され、それ以降の大規模言語システムのアーキテクチャーの基本になっていきます。
------------------------------
https://www.marulabo.net/docs/meaning/
コメント
コメントを投稿