今回の論文
今回取り上げるのは、Patrick Lewis、Ethan Perez、Aleksandra Piktus、Fabio Petroni、Vladimir Karpukhin、Naman Goyal、Heinrich Küttler、Mike Lewis、Wen-tau Yih、Tim Rocktäschel、Sebastian Riedel、Douwe Kielaによる「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」です。2020年5月22日にarXivへ初版が投稿され、NeurIPS 2020で発表されました。研究分野は情報検索、自然言語生成、知識を必要とする質問応答です。arXivの書誌情報
本記事では、公開元であるNeurIPSの会議版論文をもとに説明します。選んだ理由は、検索を生成モデルに付け足すだけでなく、「正しい回答を作るために、どんな文書を検索すべきか」まで学習対象にした技術だからです。検索と回答のつなぎ方を見直すヒントが得られます。
どんな技術か
RAG（Retrieval-Augmented Generation、検索拡張生成）は、モデル内部の知識に加え、外部の文書を検索して回答生成に使う技術です。モデルの重みにすべてを記憶させる代わりに、必要な情報をその都度取り出します。
この原論文のRAGは、質問から文書を探すDPRと、質問・文書から文章を作るBARTを組み合わせます。重要なのは、検索上位の文書を一つに決め打ちせず、文書ごとの生成確率を検索確率で重み付けして統合することです。その回答が正解に近づくように、検索器の質問側と生成器を一緒に調整します。
たとえば製品の保証条件を答える場合、モデルが覚えている一般的な保証知識に加え、対象製品の規程を検索して回答材料にできます。これは用途を説明する例であり、原論文で製品保証を評価したわけではありません。
課題
事前学習済みモデルは多くの知識を持ちますが、知識を更新するには追加学習などが必要です。また、回答がモデルのどの記憶に由来するのかを、人が確認できる資料として取り出すことは容易ではありません。
一方、文書検索だけでは、関連資料の一覧は出せても、利用者が欲しい形の回答を作れません。抽出型の質問応答は文書中の文字列を抜き出せますが、情報を言い換えたり、説明文に整えたりする自由度に制約があります。
実際のAIアプリでは、検索で似た文書を取得できても、その文書が回答に役立つとは限りません。質問と語句が似ている資料よりも、条件や例外を正確に説明する資料が必要な場面があります。RAGの原論文は、検索の関連度と回答の良さを別々に考えるだけでなく、最終回答を良くする方向へ検索を学べるかを検証しています。
用語解説
- パラメトリックな記憶
- モデルの重みに蓄えられた知識です。本論文ではBARTが担当し、文章を構成する能力や既に学んだ知識を生成に使います。
- ノンパラメトリックな記憶
- モデルの重みの外に置く、検索可能な文書集合です。本論文ではWikipedia本文とそのベクトル索引を使い、重みを再学習せずに参照先を交換できるようにします。
- デュアルエンコーダ
- 質問と文書を別々にベクトル化する構造です。文書を事前に索引化でき、質問時には質問ベクトルから高速に候補を探せるため、RAGの検索部分を支えます。
- 潜在変数と周辺化
- どの文書が正解の生成に役立ったかを、直接の正解ラベルとして与えず扱う考え方です。候補文書ごとの回答確率を重み付きで足し合わせる周辺化により、文書を一つに固定せず学習できます。
- シーケンス・ツー・シーケンスモデル
- 入力テキストを読み、別のテキスト列を出力するモデルです。BARTは質問と一つの検索文書を入力し、回答を一トークンずつ生成します。
技術の仕組み
質問に対して候補文書の確率を作る
DPRは、質問と各文書のベクトルの内積を関連度にします。内積が大きい文書を上位k件取得し、そのスコアから候補間の検索確率を作ります。文書側のベクトルは事前に計算しておき、FAISSの近似探索で候補を探します。
質問と文書を独立に符号化する学習や、紛らわしい負例の作り方は、DPRのデュアルエンコーダと検索学習で詳しく説明しています。RAGは、この事前学習済み検索器を出発点にします。
生成器には約4億パラメータのBART-largeを使います。各候補について「質問＋その文書」を連結し、同じ回答候補がどの程度生成されやすいかを計算します。複数文書を一つの長い入力へ連結する方式とは異なります。
RAG-Sequenceは回答全体の確率を統合する
RAG-Sequenceの計算は、概念的には次の式です。
回答の確率 ≈ Σ文書［検索確率 × その文書を読んだときの回答全体の確率］
例えば候補文書AとBがあれば、それぞれを読んで同じ回答が出る確率を計算し、検索確率を掛けて足します。一つの項の中では、回答の最初から最後まで同じ文書を条件にします。ただし、最初に文書を一つ選び、他の候補を捨てる方式ではありません。
推論では文書ごとにビーム探索で回答候補を作り、その候補を文書間で再評価します。厳密寄りのThorough Decodingは、ある文書のビームに出なかった候補も追加の順伝播で評価します。Fast Decodingはその分の確率をゼロと近似し、計算を減らします。
RAG-Tokenは次の一トークンの確率を統合する
RAG-Tokenでは、各生成位置で文書ごとの次トークン分布を重み付きで足します。その統合された分布で次のトークンを決めるため、回答の途中で異なる文書の情報が寄与できます。
次トークンの確率 ≈ Σ文書［検索確率 × その文書を読んだときの次トークンの確率］
ここで「トークンごと」とは、確率を統合する単位のことです。生成のたびに新しい質問で検索し直す意味ではありません。候補集合は入力の質問から取得した上位k件です。また、文書ごとに作った文章を最後に貼り合わせる方式でもありません。
複数文書の表現そのものをデコーダのAttentionで統合するFiDの多文書読解構造と比較すると、RAGの「生成確率を統合する」設計の位置付けがわかりやすくなります。
正解回答から検索器も調整する
学習に使うのは入力と正解出力のペアです。周辺化した正解回答の確率を高めるように、質問エンコーダとBARTを更新します。正解を生成しやすい候補へ検索確率を割り当てる方向に、質問側の表現も学習できます。原論文の手法・学習・デコード（2節）
文書エンコーダと索引は固定します。文書側まで変更すると、大規模な文書集合を再度ベクトル化して索引を更新する必要があるためです。共同学習という言葉から、全コンポーネントを毎回更新すると理解しないことが大切です。離散的な上位k件の選択そのものを通常の微分で更新しているわけでもありません。
このタスク調整では正解根拠の直接ラベルは不要ですが、初期化に使うDPRは質問・根拠の教師情報で学習済みです。検索に関する教師情報を一切使わない手法ではありません。
実験と結果
Wikipediaを検索して短い回答を生成する
検索対象は2018年12月のWikipediaで、本文を非重複の100語単位へ分けた約2,100万パッセージです。学習時の取得数は5件または10件を試し、評価時の取得数は開発データで決めています。
短い回答を評価するオープンドメインQAでは、正規化後に回答が正解と一致するExact Match（EM）を測りました。会議版の表1から主なtest結果を示します。
| 手法 | Natural Questions | WebQuestions | CuratedTREC |
|---|---|---|---|
| DPRの検索＋抽出型QA | 41.5 | 41.1 | 50.6 |
| RAG-Token | 44.1 | 45.5 | 50.0 |
| RAG-Sequence | 44.5 | 45.2 | 52.2 |
RAG-SequenceはNatural QuestionsでDPRを3.0ポイント上回ります。一方、CuratedTRECのRAG-TokenはDPRを下回り、二つの統合方式の優劣はタスクで変わります。検索器と読解器を含むシステム比較であり、周辺化の変更だけの効果を表す表ではありません。
TriviaQAでは、通常のオープンドメインQAのtest設定でRAG-Sequenceが56.8、DPRが57.9でした。別のTQA-Wiki設定ではRAG-Sequenceが68.0、検索なしのT5-11B＋SSMが60.5です。異なるtest設定を混ぜて「全タスクでDPRを超えた」と読むことはできません。原論文の表1（6ページ）
検索器の学習と、索引の交換を検証する
検索器を固定した場合との比較では、Natural Questionsのdev EMがRAG-Sequenceで41.2から44.0へ改善しました。test表の44.5とは別の評価です。回答を学ぶだけでなく質問側の検索表現も調整することが、最終品質へ寄与するとわかります。
また、2016年と2018年の間に交代した82人の世界の指導者を対象に、Wikipedia索引の交換を試しています。各年の指導者を正解としたとき、対応する年の索引では正答率が70%と68%でした。年の対応が逆の索引では12%と4%です。限定された質問集合の結果ですが、外部記憶の交換で回答を更新できることを示します。原論文の表6・索引交換実験（8ページ）
自由文の回答や分類にも利用できる
MS MARCO NLGでは、データセット付属の正解パッセージを使わずWikipediaを検索する設定で、RAG-SequenceのROUGE-Lは40.8、BARTは38.2でした。ROUGE-Lは参照回答との語の並びの重なりを評価する指標で、事実性そのものの保証ではありません。
FEVERの3クラス分類では、主張を「支持・反証・情報不足」の出力へ変換して学習し、RAGのラベル正解率は72.5%、BARTは64.0%でした。これは分類ラベルの評価であり、根拠文の正しさまで要求するFEVER scoreとは区別が必要です。原論文の表2（6ページ）
何に使える？
以下は原論文の仕組みに基づく応用の考察です。業務文書や日本語で同じ改善幅が得られることは、論文では検証されていません。
更新されるマニュアルに基づく回答
社内手順や製品仕様を外部記憶に置けば、文書更新を回答へ反映する経路を作れます。言い換えや文章構成をモデルに任せ、変わりやすい数値や条件を資料で管理する役割分担です。ただし索引を替えただけで必ず新しい規程に従うとは限らず、旧版と新版を取り違えない評価も必要です。
問い合わせログを使った検索の改善
正しい回答文は残っていても、参照した根拠の細かなラベルがないサポート業務で、回答を目標に検索器を調整する方向が考えられます。単に似た問い合わせを探すより、正答に必要な資料へ到達するよう学ぶ狙いです。実装では、誤った回答ログを教師にしないよう品質を確認します。
文書に基づく判定を返す社内ツール
要求と規程を照合し、適合・不適合・情報不足を返すようなツールにも発想を転用できます。FEVERが示したのは、外部資料を検索する構造を文章生成だけでなく分類にも使えることです。規程適合の業務性能は別途検証し、判定とともに確認用の資料を提示する設計が必要です。
開発や事業へのヒント
回答に役立つ検索を評価する
この論文から得られる大きなヒントは、文書の類似度だけを最適化せず、取得後に回答できたかまで見ることです。小規模なRAGでも、質問、検索結果、正解回答をセットで保存すると、検索器の改善を最終回答で比較できます。
初めから共同学習を再現する必要はありません。まず固定の検索器と生成器で基準を作り、根拠を取得できた割合と、その根拠から正答できた割合を分けて測ります。そのうえで、検索側が主な失敗原因ならタスクに合わせた調整を検討できます。
変わる情報を外部記憶へ置く
製品仕様、料金表、運用手順のように更新される情報は、モデルの重みへ覚え込ませるより、版を持つ文書集合として管理する設計が考えられます。索引交換実験は、その方向を技術的に支えています。
実務では、文書の更新日時と索引の世代を記録し、切り替え前後で同じ質問を評価するとよいでしょう。変更後の正答率だけでなく、旧情報を答える割合も測れば、知識の更新が回答へ届いたかを確認できます。
統合の単位を設計対象にする
RAG-SequenceとRAG-Tokenの違いは、情報をどの単位で混ぜるかという設計です。一つの資料に整合した短答を作る場合と、複数資料から文章を組み立てる場合では、適した統合方法が変わる可能性があります。
これはAPI利用だけのアプリでも、「資料を全部連結する」「資料ごとに候補を作って検証する」といった比較を考えるヒントになります。ただし複数回答を投票させるだけでは、原論文の生成確率の周辺化と同じアルゴリズムにはなりません。
限界
文書ごとに生成計算が必要なため、取得数を増やすとメモリや遅延が増えます。RAG-SequenceのThorough Decodingは候補の追加評価も必要です。大量の文書を検索できることと、低コストで全部読めることは別です。
上位k件に必要な資料が入らなければ、外部記憶から使える情報は不足します。また、モデル内部の知識も使えるため、正答が出ても取得文書で裏付けられているとは限りません。検索候補や文書の寄与は、文章の各主張に対する検証済み引用の代わりにはなりません。
文書エンコーダを固定することで再索引化の負担は抑えられますが、専門分野に合わない文書表現を質問側の調整だけで十分に補えるとは限りません。文書追加には埋め込み計算が必要で、文書側のモデルを変えるなら索引全体の再構築を検討する必要があります。
主な実験は英語Wikipediaを中心としています。日本語の社内略語、表、厳しいアクセス権限、頻繁な更新がある環境への適用は、別の検証課題です。論文の結果をそのまま業務品質の保証として使うことはできません。
よくある質問
Q. 現在よく作られる検索付きチャットと同じですか？
A. 外部資料を検索して生成する基本発想は共通です。ただし原論文は、文書ごとに生成確率を計算して周辺化し、質問エンコーダと生成器を共同学習します。検索結果を一つのプロンプトに連結するだけでは、この学習・推論方式を再現したことにはなりません。
Q. RAG-Tokenは生成中に何度も検索するのですか？
A. この論文では入力の質問で候補文書を取得し、生成位置ごとに候補からの次トークン確率を統合します。途中の文章を検索クエリにして、新しい文書を取りに行く方法ではありません。
Q. 正解の根拠ラベルがなくても学習できますか？
A. タスクの調整には質問と正解回答のペアを使えます。ただし初期化するDPRは検索の教師情報で学習済みです。さらに、手元の回答が誤っていれば、その誤答を生成する方向へ学ぶため、回答データの確認は必要です。
Q. 外部文書を更新すればファインチューニングは不要ですか？
A. 既存の文書エンコーダで新しい資料を索引化するだけで、更新が回答へ届く場合があります。索引交換実験はその例です。ただし新しい用語や資料形式を理解できない場合は別で、モデル調整の必要性を更新後の質問セットで判断します。
Q. RAGを使えばハルシネーションはなくなりますか？
A. なくなりません。検索の誤りに加え、生成器が文書から離れた回答を作る可能性もあります。根拠文書の取得、回答中の主張との対応、情報がない場合の応答を別々に検証する必要があります。
今日の学び
この論文は、モデル内部の記憶だけでは知識の参照や更新に限界があり、検索で得た資料もそのままでは回答に結び付きにくいという課題を扱いました。
DPRとBARTをつなぎ、文書ごとの生成確率を統合し、正解回答から質問側の検索器と生成器を共同学習するRAGで解こうとしました。
開発へのヒントは、知識をすべてモデルに覚えさせるだけでなく、更新できる外部記憶を持たせ、検索の良さを「最終回答に役立ったか」で評価することです。