今回の論文
今回取り上げるのは、Gautier Izacard、Edouard Grave による論文「Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering」です。2020年7月2日に arXiv へ初版が投稿され、2021年2月3日に改訂版が公開されています。公開元は arXiv、研究分野はオープンドメイン質問応答、情報検索、生成モデルです。URL は https://arxiv.org/abs/2007.01282 です。
この論文を選んだ理由は、今では当たり前になった「検索した複数文書を LLM に読ませて答える」という発想を、かなり実装しやすい形で定式化しているからです。特に、複数の検索結果をどう統合するかという問題に対して、検索器を極端に複雑化せず、読解器の構造を変えることで精度を伸ばしている点が、いまの RAG 設計にもそのまま効きます。
どんな技術か
Fusion-in-Decoder は、検索で集めた複数のパッセージを、エンコーダでは別々に読み、デコーダでまとめて参照しながら答えを生成する技術です。
通常の質問応答では、検索した文書を1本ずつ読んで最もそれらしい答えを選ぶか、あるいは複数文書を前段で無理やり連結して1回で読ませることが多いです。しかしこの方法だと、文書数が増えたときに計算が重くなったり、複数文書をまたいだ証拠統合がうまくいかなかったりします。
FiD はここを切り分けます。質問と各パッセージの組をそれぞれ独立にエンコードし、最後にデコーダが全パッセージ由来の表現へまとめて注意を向けます。要するに、前処理で情報を混ぜず、答えを作る直前に必要な証拠だけを融合する設計です。
この発想により、検索結果を 10 件程度で打ち止めにせず、50 件や 100 件まで増やしても性能が伸びやすくなります。論文でも、生成モデルは多数の文書から証拠を寄せ集めるのが意外に得意だと示されています。
課題
この技術が解決しようとしているのは、オープンドメイン質問応答における「複数文書をどう読ませるか」という課題です。
何が難しいのかというと、現実の質問は1つの文書だけで答えが完結しないことが多いからです。ある人物の経歴、製品の仕様変更、法制度の関係、社内手順の依存関係などは、複数パッセージをまたいで情報を集める必要があります。
既存の方法では、検索器は良さそうな文書を持ってこられても、読解器側がそれをうまく統合できない場面がありました。抽出型 QA は、文中のスパンを抜き出すのは得意でも、複数文書から情報をつなぎ合わせて答えるのは苦手です。逆に巨大な生成モデルへ外部知識なしで全部覚えさせる方法は、モデルサイズも推論コストも重くなります。
なぜこの課題を解く必要があるのかというと、検索を使う AI システムの価値は、単に関連文書を出すことではなく、それらを踏まえて正しい答えを作れることにあるからです。RAG、社内ナレッジ検索、調査エージェント、FAQ 自動化では、複数ソースから筋の通った回答を作れるかどうかが品質の分かれ目になります。
実際の AI システムでは、検索結果を増やすほどノイズも増えます。単純にチャンク数を増やすだけでは、かえって誤答を作ることもあります。FiD はこの状況で、「文書をたくさん集めても、それを扱える読解構造にしておけば性能が伸びる」という方向を示しました。
用語解説
- オープンドメイン質問応答
- 特定文書が与えられず、Wikipedia のような大規模コーパスから必要な情報を探して答える設定です。FiD はこの設定で、検索結果をどう読ませるかに焦点を当てています。
- Dense Passage Retrieval（DPR）
- 質問と文書を密ベクトルに変換し、内積で関連度を測る検索手法です。FiD 論文では主に NQ と TriviaQA の検索段で使われており、後段の生成器がどんな証拠を受け取るかを決める重要な部品です。
- シーケンス・ツー・シーケンスモデル
- 入力列を受けて出力列を生成するモデルです。FiD では T5 のような seq2seq モデルを読解器として使い、検索結果を読んで答え文字列そのものを生成します。
- 抽出型 QA と生成型 QA
- 抽出型は文書中の該当スパンを抜き出す方式で、生成型は答え文字列を新しく出力する方式です。FiD は生成型を採ることで、複数文書から情報をまとめた自然な回答を作りやすくしています。
- Evidence Fusion
- 複数の証拠文書から必要な情報を統合することです。FiD の核心は、この融合をエンコーダではなくデコーダ側で行う点にあります。
技術の仕組み
FiD の仕組みはかなりシンプルですが、どこで情報を混ぜるかの設計が効いています。
基本アイデア
基本の流れは2段です。まず BM25 や DPR のような検索器で質問に関連するパッセージを複数件取ってきます。次に、それらを seq2seq モデルへ渡して答えを生成します。
ここで重要なのは、検索したパッセージ群を1本の長い入力にまとめるのではなく、質問 + 1 パッセージ を1単位として個別に処理することです。つまり、質問と 100 パッセージがあれば、エンコーダは 100 本の独立した入力列を読む形になります。
モデル構造
エンコーダでは各パッセージを独立に処理する
論文では、各検索結果のタイトルと本文に対して question: title: context: という特別トークンを付け、質問と連結したうえでエンコーダへ入れます。ただし、別パッセージ同士はエンコーダ内で相互作用しません。
この構造の利点は、自己注意が1パッセージ単位で完結することです。複数文書を最初から全部連結してエンコードすると、トークン数が増えるほど自己注意コストが急増します。FiD はそれを避け、文書数に対してほぼ線形に伸びる形へ変えています。
デコーダで全パッセージの表現をまとめて参照する
エンコード後は、各パッセージの隠れ表現を連結し、デコーダがそこ全体へクロスアテンションを向けながら答えを生成します。ここが Fusion-in-Decoder の名前の由来です。
つまり、文書どうしの統合は「読む段階」ではなく「答える段階」で起きます。ある文書に人物名があり、別の文書にその人物の役職があるような場合でも、デコーダは両方の表現を見ながら最終回答を組み立てられます。
学習方法
論文では T5 の事前学習済みモデルを初期値に使い、各データセットごとに教師ありファインチューニングしています。モデルサイズは base が約 2.2 億、large が約 7.7 億パラメータです。
学習時も推論時も、基本的には検索で取ってきた複数パッセージを入力にして、正解答え文字列を生成するよう最適化します。Natural Questions と SQuAD では複数の正解候補から学習ターゲットをサンプリングし、TriviaQA では人手の単一回答を使っています。
推論方法
推論時は、まず検索器が上位 100 パッセージを取得します。NQ と TriviaQA では DPR、SQuAD では BM25 が使われています。各パッセージは 250 word pieces に切り詰められ、質問と組にしてエンコードされます。
その後、デコーダが greedy decoding で答えを1トークンずつ出力します。FiD 自体は特殊な探索や再ランキングを入れておらず、構造の工夫だけで性能を出しているのがポイントです。
なぜこれで多文書統合がうまくいくのか
FiD が効く理由は、検索結果を前段で雑に圧縮しないことにあります。1本ずつ独立にエンコードしておくので、各文書の局所情報は比較的きれいに保たれます。そのうえで、答え生成のタイミングで必要な証拠だけを横断的に参照できます。
抽出型 QA だと、「どの文書のどのスパンが正解か」を強く決めにいく必要があります。一方 FiD は、複数文書の部分証拠を少しずつ拾って答えを作れるため、単独文書では完結しない質問に向いています。
実験と結果
論文では、FiD が本当に既存手法より強いのか、またパッセージ数を増やしたときにどう振る舞うのかを検証しています。
何を検証したのか
主な検証点は3つです。1つ目は、Natural Questions、TriviaQA、SQuAD Open で既存の open-domain QA 手法より高精度かどうかです。2つ目は、検索パッセージ数を増やすと性能がどこまで伸びるかです。3つ目は、100 パッセージ学習が重い場合に、少ないパッセージ数で学習してから後段で追加微調整する妥協案が成立するかです。
どんなデータセットや評価指標を使ったのか
データセットは Natural Questions、TriviaQA、SQuAD v1.1 の open-domain 設定です。Wikipedia から 100 語ずつの非重複パッセージを切り出したコーパスを使い、検索器がそこから候補を取ってきます。
評価指標は Exact Match（EM）です。生成した答えが正解表記と正規化後に一致するかで判定します。生成モデルの評価としては厳しめですが、QA 系論文では標準的です。
既存手法との比較
Table 1 では、FiD-base が Natural Questions 48.2 EM、TriviaQA 65.0 EM、SQuAD Open 53.4 EM を出し、FiD-large はそれぞれ 51.4、67.6、56.7 EM を記録しています。比較対象として、RAG は NQ 44.5、TriviaQA 56.1、DPR は NQ 41.5、TriviaQA 57.9 でした。
この差から分かるのは、検索器の改善だけでなく、検索後に複数文書をどう読むか がかなり効いているということです。特に TriviaQA のように複数証拠が散りやすい設定で差が大きく、FiD の設計意図と結果がきれいにつながっています。
パッセージ数を増やすと性能が伸び続けた
論文の Figure 3 では、FiD-base に与える検索パッセージ数を 5、10、25、50、100 と増やしたときの性能変化が示されています。著者らは、10 から 100 パッセージへ増やすと、TriviaQA で約 6 EM、Natural Questions で約 3.5 EM 改善したと報告しています。
これは重要です。多くの抽出型モデルでは、パッセージ数を増やすとノイズが増えて頭打ちになりやすいのに対し、FiD は多数の候補を渡したほうがむしろ強くなりました。検索精度を少し犠牲にしてでも、広めに拾って後段で統合する設計が有効だと読めます。
学習コストとのトレードオフ
100 パッセージでの学習は当然重いので、論文は 5、10、25、50 パッセージで学習し、評価時だけ 100 パッセージを使う設定も調べています。たとえば Natural Questions では、25 パッセージ学習だと 45.3 EM、50 パッセージ学習だと 45.7 EM でした。
そこから 100 パッセージで 1000 ステップだけ追加ファインチューニングすると、Natural Questions で 46.0 EM まで戻せています。論文では、この方法で 147 GPU hours で済み、最初から 100 パッセージ学習する 425 GPU hours よりかなり軽くなると報告しています。
つまり FiD は、高性能なだけでなく、計算予算に応じた段階的学習もしやすいです。この点も、実装上かなり扱いやすい特徴です。
何に使える？
FiD の考え方は、いまの RAG や検索付き生成アプリにもかなり直接的に応用できます。
社内ドキュメント検索と回答生成
社内 Wiki、仕様書、議事録、障害報告書のように情報が散らばる環境では、単一チャンク検索だけでは答えが足りないことが多いです。FiD 的な設計なら、関連チャンクを広めに取っておき、後段で統合して回答を作る方針が取りやすくなります。
これは特に、「A の変更が B にどう影響したか」のような関係性を問う質問で有効です。1チャンク完結型の QA より、複数証拠を合わせた説明を返しやすくなります。
調査エージェントの読解器
エージェントが検索やツール実行で複数候補を集める場合、最後にどの情報を信じて答えるかがボトルネックになります。FiD のような後段融合型の読解器は、候補を狭く削ってから読むより、広めに集めて最後に必要な証拠をまとめる設計に向いています。
最近の LLM エージェントでも、retriever と reasoner を分けて考える実装は多いです。FiD はその古典的で分かりやすい原型として参考になります。
FAQ より複雑なナレッジ QA
単純な FAQ ならベクトル検索上位 3 件をそのままプロンプトへ入れても動きます。しかし、質問が複雑になり、複数文書の関係をまたぐほど、その方法は限界が出ます。FiD は「文書を増やすと逆に強くなる読解器」の方向を示しており、中〜高難度のナレッジ QA と相性がよいです。
再ランキング前提の RAG 設計見直し
多くの実務 RAG は、retrieve → rerank → top-k を厳しく絞る流れを取ります。もちろんそれは有効ですが、FiD 的に考えると、再ランキングで絞りすぎること自体が情報損失になる可能性もあります。
そのため、検索結果を少数精鋭にしすぎず、「多少ノイズがあっても後段が統合できるなら残す」という設計判断の根拠として使えます。
開発や事業へのヒント
この論文から得られるヒントは、RAG の改善は検索器だけではなく、検索後の読ませ方で大きく変わるということです。
top-k を減らすことが常に正解ではない
実務では、入力トークン節約のために top-k を小さくしがちです。ただし、それで複数証拠の片方を落としてしまうと、回答品質が頭打ちになります。FiD は、後段の読解器が複数証拠を扱えるなら、広めに取ってから統合する方がよいケースを示しています。
検索と読解は別最適化で考える
retriever の精度改善ばかり追うと、何を何件渡すかまでは考えても、それを downstream モデルがどう読むかが置き去りになりがちです。FiD は、retriever は広めに拾い、reader が証拠融合を担うという分業が効くことを教えてくれます。
これは小規模プロダクトでも応用できます。たとえば、検索器は recall 重視にして、後段で統合・要約を強くする設計です。
モデルの巨大化以外にも道がある
論文では、外部知識なしの巨大 T5 よりも、Wikipedia を検索して読む FiD のほうが少ないパラメータで高い精度を出せる場面が示されています。これは、モデルの重みへ全部覚え込ませるより、外部知識を検索して組み合わせたほうが効率的な場合があるということです。
いまのプロダクトでも、すべてをファインチューニングで解こうとせず、検索と読解の設計を先に見直す価値があります。
長文文脈時代でも通用する設計思想
これはやや推測を含みますが、コンテキスト長が伸びた現在でも、何でも1本の長いプロンプトへ詰め込めば十分というわけではありません。情報をどの単位で保持し、どの段階で統合するかという FiD の発想は、長文 LLM やマルチホップ RAG でも引き続き重要です。
限界
まず、FiD の強さは検索品質に依存します。retriever が必要な文書を上位 100 件に入れられなければ、後段がいくら強くても拾えません。つまり、後段融合だけで検索失敗を完全に埋めることはできません。
次に、文書数を増やすほど性能が伸びる一方で、計算コストとメモリ負荷は確実に増えます。論文でも 100 パッセージ学習は高価で、追加ファインチューニングで妥協する案が必要でした。実運用でも、top-k を大きくするほどレイテンシ管理が難しくなります。
また、FiD は答え生成に強い反面、どの文書を根拠にしたかをそのまま説明してくれるわけではありません。根拠提示や引用整形が必要なプロダクトでは、別途アトリビューション設計が要ります。
さらに、この論文は主に Wikipedia ベースの open-domain QA で評価されています。社内文書、表形式データ、コードベースのような別ドメインで常に同じ傾向になるとは限りません。とはいえ、複数証拠を後段で統合するという設計原理自体は十分汎用的です。
よくある質問
Q. Fusion-in-Decoder は普通の RAG と何が違うのですか？
A. 普通の RAG は検索した上位数件をそのまま1本の入力へ詰めて LLM に読ませることが多いです。FiD は、各文書を別々にエンコードし、デコーダでまとめて参照します。複数証拠の扱い方がより構造化されています。
Q. なぜ文書を最初から連結しないほうが良いのですか？
A. 最初から全部連結すると、自己注意コストが重くなり、文書数が増えたときに扱いにくくなります。FiD はエンコーダ側を文書ごとに分離することで、より多くの文書を読みやすくしています。
Q. いまの長コンテキスト LLM があれば FiD は不要ですか？
A. 不要とは言えません。長コンテキスト化で単純連結はやりやすくなりましたが、どの段階で情報を統合するかの設計は依然として重要です。特に複数候補を広く集めて後段で読ませる発想は、いまの RAG パイプラインでも有効です。
Q. 実務で応用するなら、まず何を真似すべきですか？
A. まずは retrieve の recall を少し高めに取り、reader 側に複数証拠を統合させる設計を試すのがよいです。必ずしも FiD をそのまま再現しなくても、再ランキングで絞りすぎない、根拠統合前提で回答を作る、といった思想はすぐ応用できます。
Q. FiD の弱点は何ですか？
A. 検索ミスに弱いこと、文書数を増やすと計算が重くなること、根拠提示が自動ではきれいに出ないことです。精度だけでなく、レイテンシと説明可能性も一緒に設計する必要があります。
今日の学び
この論文は、検索で集めた複数文書をそのまま雑に詰め込むだけでは、オープンドメイン QA の精度が伸びにくいという課題を扱いました。
それに対して、各文書を独立にエンコードし、デコーダでまとめて証拠融合する Fusion-in-Decoder という構造で解こうとしました。
そこから得られるヒントは、RAG や検索付き AI の品質は検索器だけで決まらず、検索後の情報統合の設計で大きく変わるということです。特に、複数ソースをまたぐ質問へ強くしたいなら、「何件取るか」だけでなく「どの段階で融合するか」を設計対象にするべきです。