知識集約型NLPタスクのための検索拡張生成（RAG）

Lewisらによる「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（NeurIPS 2020）は、おそらく今日のプロダクションAIシステムのアーキテクチャ設計に最も大きな影響を与えた単一の論文でしょう。発表から5年が経過した今でも、ドキュメントに基づいた言語システムのほぼすべてが比較対象とするベースラインであり続けています。私が今この論文を読んでいるのは、Bean Labsのバックログにある元帳のQAから異常検知の解説に至るまで、最終的にはすべてが「検索」の問題に行き着くためです。後継の技術に進む前に、オリジナルの設計思想を明確に理解しておきたいと考えました。

論文の概要

RAGが解決しようとする核心的な問題は、事前学習済み言語モデルが学習時に知識を重みに焼き付けてしまうため、その知識が静的で不透明になり、再学習なしには更新できなくなるという点です。Lewisらは、パラメトリックメモリ（生成器としてのBART-large）と非パラメトリックメモリ（2,100万件のWikipediaパッセージに対する密なFAISSインデックス）を組み合わせたハイブリッドアーキテクチャを提案しました。これらは、Dense Passage Retrieval（DPR, Karpukhinら 2020）に基づく学習済み検索器によって接続されています。推論時、モデルは上位K個の関連パッセージを検索し、それらを周辺化（marginalize）して最終的な出力を生成します。

この論文では2つのバリアントが導入されています。RAG-Sequenceは、一度検索を行い、生成されるシーケンス全体で同じドキュメントセットを使用します。これは一貫性は高いですが、適応性には欠けます。RAG-Tokenは、生成のステップごとに異なる検索ドキュメントを参照することを可能にし、文の途中で複数のソースからの情報を統合できるようにします。どちらのバリアントも、ファインチューニング中に検索器と生成器を共同で学習しますが、ドキュメントエンコーダーは学習中にFAISSインデックスを再構築するコストを避けるために固定（フリーズ）されます。

主なポイント

• RAG-Sequenceは、Natural Questionsで44.5 Exact Match (EM)、TriviaQAで56.8 EM、WebQuestionsで68.0 EMを達成しました。これらは発表当時の最高水準（SOTA）でした。
• MS-MARCOの要約型QAにおいて、RAG-Sequenceは40.8 ROUGE-Lを記録し、BARTのみのベースライン（38.2）を僅差ながら安定して上回りました。
• Jeopardy（クイズ番組）の問題生成では、人間による評価でRAGの出力の方がBARTよりも事実に基づいていると判断されたケースが42.7%に達しました（BARTの方が事実に基づいているとされたのは7.1%）。
• FEVERの事実検証において、RAGはタスク固有のエンジニアリングなしで72.5%の3クラス分類精度を達成しました（特化型のSOTAより4.3ポイント低い結果）。
• 学習中にドキュメントエンコーダーを固定することによるNQでの損失はわずか約3 EMポイント（44.0 → 41.2）であり、インデックスの知識が古くなるリスクと引き換えに、計算能力の面で現実的なアプローチとなりました。
• 密な検索（Dense retrieval）は、エンティティ中心のクエリで単語の重なりが重視されるFEVERを除くすべてのタスクでBM25を上回りました。これは、スパース検索が必ずしも劣っているわけではないという具体的なシグナルです。

評価されている点と課題

「知識ストレージ」と「推論エンジン」を分離するという根本的な洞察は、時間の経過に非常によく耐えています。これにより、知識の更新（再インデックスのみ）、ソースの帰属（検索されたパッセージの検証可能性）、そしてタスク固有のアーキテクチャなしでオープンドメインQA、生成、事実検証に一般化できる能力が得られます。これらの特性は、実際の運用においては特定のExact Matchの数値よりも重要です。

NeurIPSの査読者が指摘した通り、技術的な新規性は限定的です。DPRもBARTもすでに存在しており、RAGはそれらを注意深く統合したものであって、根本的なアルゴリズムの進歩ではありません。また、ドキュメントエンコーダーを固定するという決定は、論文ではやや軽く扱われていますが、微妙な問題を引き起こします。インデックスは一度構築されるとスナップショットになります。インデックス構築後に変化した事実は、モデルには見えません。SEC（証券取引委員会）への提出書類のような静的なコーパスであれば許容されますが、リアルタイムの価格や日々の取引フィードといったライブシステムにおいては、これは些細なディテールではなく、真のアーキテクチャ上の制約となります。

「検索崩壊（retrieval collapse）」の知見は、もっと注目されるべきです。物語生成タスクにおいて、モデルは検索されたドキュメントを完全に無視し、パラメトリックメモリから生成することを学習してしまいました。論文では、タスクが「特定の知識を必要としない」場合にこれが起こると述べていますが、そのメカニズムの説明や、実務者がそれを検出するための原則的な方法については触れていません。正常に動作しているように見えながら、裏で密かに検索を止めてしまっているエージェントは、金融システムを本番運用する際に最も懸念される失敗モードです。

メモリフットプリントも無視できません。Wikipediaのインデックスだけで約100GBのCPU RAMを必要とします。論文ではこれを機能（非パラメトリックメモリは「更新が速い」）として位置づけていますが、これは運用上の実質的なコストであり、その後の数年間でインデックスの圧縮や近似検索へと技術が進化した背景となっています。

なぜ金融AIにとって重要なのか

検索アーキテクチャは、Beancountの問題構造に自然に当てはまります。Beancountの元帳は、個々のエントリが意味的にリンクされた大規模な追記型（append-only）のドキュメント集合です。税控除の対象となる費用はカテゴリを参照し、カテゴリはルールを、ルールは会計年度を参照します。公開データで学習されたパラメトリックモデルは、ユーザー固有の勘定科目表（chart of accounts）を知りません。推論と知識を分離する RAGは、構造的に正しい答えです。つまり、生成器を会計タスクの形式でファインチューニングし、事実の照合はユーザーの実際の元帳インデックスに基づいて行うのです。

実務上の懸念は、論文でも特定されていながら軽視されている「インデックスの陳腐化」です。Beancountエージェントが昨日作成されたインデックスから検索を行う場合、今日の取引を見落とす可能性があります。増分インデックス作成や元帳への書き込み時の再インデックスのトリガーは、後付けではなく、最初からシステム設計に組み込む必要があります。もう一つの懸念は、構造化データに対する検索精度です。RAGはWikipediaの文章（散文）向けに設計されました。Beancountの元帳には日付範囲、勘定科目の階層、通貨単位が含まれており、文章に最適化された検索器はこれらをネイティブにはうまく扱えません。私が以前に調査した「LLMは表形式のデータを推論できるか」という問いは、RAGが有用に検索できる内容を直接的に制約します。

次に読むべきもの

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — 検索された各パッセージを個別に処理し、デコーダーで融合します。RAGよりもアーキテクチャが単純でありながら、NQでより高いスコアを達成しています。RAG-Tokenの共同読み取りアプローチを採用する前に理解しておく価値があります。
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — 生成中にモデルが幻覚（ハルシネーション）を起こしそうなタイミングを予測し、オンデマンドで検索を行います。RAGのアイデアをより適応的なエージェントへと進化させた、最も自然な拡張です。
• 「Fine-Tuning or Retrieval?」 Ovadia et al. 2023 (arXiv:2312.05934) — さまざまなタスクにおける知識注入手法の系統的な比較です。元帳に特化した生成器をファインチューニングすべきか、単に検索を改善すべきかを決定する前に必要な、経験的な証拠を提示しています。