FLARE: 能動的検索拡張生成
先週、Lewisらによる基礎的なRAGの論文を読んでいました。一度検索し、結果を先頭に付加し、生成する。これは機能しますが、何が必要になるかを事前にすべて把握していることが前提となります。FLARE (EMNLP 2023) は、その前提を直接攻撃します。モデルが確信を持てなくなった瞬間、つまり文の途中で検索するのが最適なタイミングだとしたらどうでしょうか？この問いは、単一のコンテキストウィンドウには収まりきらない元帳履歴に基づいて推論を行う必要があるBeancountエージェントのようなシステムにとって、慎重に検討する価値があります。
論文の概要
Zhengbao Jiang、Frank F. Xu、Luyu Gao、Zhiqing Sun、Qian Liu、Jane Dwivedi-Yu、Yiming Yang、Jamie Callan、Graham Neubigによる「Active Retrieval Augmented Generation」は、FLARE (Forward-Looking Active REtrieval augmented generation) を提案しています。彼ら が解決しようとしているのは、長文生成におけるハルシネーション（幻覚）の問題です。モデルが長い出力を生成する際、複数の知識を断続的に取り出す必要があります。標準的なRAGはクエリ時に一度だけ検索を行い、取得した文章が生成に必要なすべてをカバーしていることを期待します。これは短い回答には適していますが、数段落にわたる回答では脆弱になります。
FLAREは生成を文レベルのステップに分解します。各ステップで、まず次の一文の候補を生成します。その候補内のいずれかのトークンの予測確率がしきい値 θ を下回った場合、FLAREはそれら低確信度のスパンを検索シグナルとして扱い、それらを使用して（マスキングまたは補完によって）クエリを形成し、Wikipediaから検索を行って、取得したコンテキストをもとに文を再生成します。その結果、モデルが確信を持てない場合にのみ、かつその場所においてのみ検索を行うシステムが実現します。決して必要のないコンテンツのために検索をフロントローディングすることはありません。すべての実験は、ファインチューニングなしのGPT-3.5 (text-davinci-003) で実行されました。
主なアイデア
- 検索トリガーとしての確信度: トークンの確率が θ を下回ることは、モデルがハルシネーションを起こす可能性が高いことを示唆します。検索はデフォルトではなく、その時にのみトリガーされます。著者らは、40〜80%の文でトリガーするのが通常最も効果的であることを発見しました。
- 前方向きのクエリ (Forward-looking queries): すでに生成された内容のみをクエリとして使用するのではなく（「過去ウィンドウ」アプローチ）、FLAREは予測された「次に来る文」—モデルが言おうとしていること—を、よりターゲットを絞った検索クエリとして使用します。
- 2つのバリアント: FLARE-instructは低確信度トークンをマスクし、そのマスクされたスパンをクエリとして使用します。FLARE-directは予測された文全体を使用します。2WikiMultihopQAでは、directバリアントが51.0 EMに達したのに対し、instructバリアントは42.4でした。
- 単一検索に対する利得は実在するが不均一: 2WikiMultihopQAでは、FLARE-directが51.0 EMを記録し、単一検索の39.4、検索なしの28.2に対して決定的な改善を見せました。一方、ASQAではその差ははるかに小さく（41.3 vs. 40.0）、WikiAsp（UniEval 53.4 vs. 52.4）ではほぼ同等でした。
- 明示的な失敗ケース: 著者らは、出力が短いWizard of WikipediaやELI5では、多段階検索が利益をもたらさずオーバーヘッドを増やすだけであるため、利得がないことを報告しています。
- コスト: 生成と検索がインターリーブされるため、各例で複数のLM補完と検索コールがトリガーされる可能性があります。キャッシングは単純ではありません。
有効な点とそうでない点
前方向きのフレーミング（Forward-looking framing）は、真に巧妙な部分です。予測されたコンテンツを検索クエリとして使用することは、プレフィックス単体よりも情報量が多く、特に中間的な結論が次に必要な事実を決定するマルチホップタスクにおいて有効です。2WikiMultihopQAにおける51.0 vs 39.4のEMの差がこれを裏付けています。
しかし、FLAREの確信度シグナルは、モデルがどれほど適切にキャリブレーション（較正）されているかに完全に依存します。text-davinci-003のようなベースの補完モデルからのトークン確率は、不確実性と合理的に相関します。しかし、指示調整済み（instruction-tuned）やRLHF済みのチャットモデルでは、そうではありません。これらはしばしば「過信（overconfident）」しており、ハルシネーションを起こしている時でさえ高い確率のトークンを出力します。2024年の追跡調査であるUnified Active Retrieval (UAR, arXiv:2406.12534) では、より広範な検索決定スイートでFLAREをベンチマークし、UARの分類器ベースのアプローチが85.32%の精度を達成したのに対し、FLAREは56.50%にとどまったことが示されています。キャリブレーションの問題は例外的なケースではなく、この手法が依拠している核心的な前提です。
また、論文では十分に扱われていない検索粒度の問題もあります。文レベルのトリガーは妥当なヒューリスティックですが、事実は節の境界をまたぐこともあれば、単一のエンティティ名に局在することもあります。数値トークン（ドル金額や日付など）の低確信度は、接続詞の低確信度とは異なる方法で検索をトリガーすべきでしょう。本論文では、すべての低確信度トークンを対称的に扱っています。
最後に、「不確実な場合は再生成する」ループはレイテンシを増大させます。著者らはこれを認めていますが、対話型や準リアルタイムのアプリケーションで重要となるレイテンシ予算に対する定量化は行っていません。
なぜこれが金融AIにとって重要なのか
数年分にわたる元帳を要約するBeancountエージェントは、すべての履歴エントリを事前に取得することはできません。コンテキストが溢れてしまい、そのほとんどは当面の回答には無関係だからです。FLAREの設計はこの問題によく合致しています。まず照合コメントの下書きを生成し、特定のベンダーの現在残高に対する確信度の低さに気づき、関連するトランザクションのみを取得して、その一文を再生成する。このパターンは健全です。
しかし、キャリブレーションの問題は深刻な懸念事項です。実務用の金融エージェントは、ベースの補完モデルではなく、ほぼ例外なく指示調整済みチャットモデル（GPT-4、Claude、Geminiなど）を使用します。これらのモデルが数値的な主張に対して過信している場合（実際によくあります）、検索をトリガーすべきまさにその瞬間に検索をスキップしてしまいます。高い確信度で取引日をハルシネーションし、検証のための検索を一度も行わないBeancount書き戻しエージェントは、役に立たないどころか有害です。
実用的な教訓としては、FLAREの前方向きのクエリ構築を、トークン確率のみに依存しない検索トリガーと組み合わせることです。明示的な不確実性マーカー（ぼかした表現、キリのいい数字、モデルが最近見ていない名前付きエンティティなど）が確信度シグナルを補完できるかもしれません。あるいはUARのアプローチをとり、生のロジットよりも誤キャリブレーションに対して堅牢な、モデルの隠れ状態に基づいた軽量な分類器を訓練することです。
次に読むべきもの
- IRCoT: "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions" (arXiv:2212.10509) — トークンの確信度ではなく、CoT（思考の連鎖）ステップと検索を結合します。マルチホップタスクにおいてFLAREと直接比較する価値があります。
- Unified Active Retrieval (UAR, arXiv:2406.12534) — FLAREのキャリブレーションの欠陥を露呈させ、4つの検索シナリオにわたる分類器ベースの検索決定を提案する直接の続編です。
- "Adaptive Retrieval without Self-Knowledge? Bringing Uncertainty Back Home" (arXiv:2501.12835) — 2025年の論文で、トークン確率ベースのトリガーが、より優れたキャリブレーション技術によって再評価できるかどうかを検証しています。
