今回の論文
今回取り上げるのは、Zhengbao Jiang、Frank F. Xu、Luyu Gao、Zhiqing Sun、Qian Liu、Jane Dwivedi-Yu、Yiming Yang、Jamie Callan、Graham Neubig による論文「Active Retrieval Augmented Generation」です。2023年12月に EMNLP 2023 で発表され、公開元は ACL Anthology です。研究分野は、RAG、長文生成、検索拡張推論です。URL は https://doi.org/10.18653/v1/2023.emnlp-main.495 です。
この論文を選んだ理由は、RAG の実装でよくある「最初に一度だけ検索して、そのまま最後まで生成する」という前提を崩しているからです。実務では、長い回答や調査メモ、要約、エージェントの報告文では、途中で必要な情報が変わります。この論文は、まさにその問題に対して「生成の途中で、必要になった時点で再検索する」という形で答えを出しています。
どんな技術か
Active Retrieval は、RAG における検索のタイミングと検索クエリを固定せず、生成の途中で動的に決める考え方です。論文ではその具体例として、FLARE（Forward-Looking Active REtrieval augmented generation）が提案されています。
普通の RAG は、ユーザーの質問をそのまま検索クエリにして関連文書を集め、その文書を見ながら一気に答えます。この方法は、短い質問応答には向いていますが、長文生成では途中から必要になる論点や固有名詞、細部の事実をうまく拾えないことがあります。
FLARE はそこを変えます。モデルが次の文を仮に生成し、その文に自信の低いトークンが含まれていたら、その文を手がかりに追加検索を行い、文を生成し直します。要するに、「書きながら、怪しい箇所が出たらその場で調べ直す」RAG です。
課題
この技術が解決しようとしているのは、長文生成では最初の検索だけでは情報需要をカバーしきれない、という課題です。
何が難しいのかというと、長文生成では答えの後半になるほど、最初の質問文からは見えない情報が必要になるからです。たとえば人物の概要を書くとき、最初は人物名だけでよくても、途中から学歴、受賞歴、特定イベントの日付など、より細かい論点が必要になります。
既存の方法では、質問文に対して一度だけ検索する RAG が主流でした。しかし、この方法だと取得される文書は入力時点の意図には合っていても、生成途中で必要になった新しい論点には追従しにくいです。逆に、一定間隔で機械的に再検索する方法もありますが、必要のない場面でも検索してしまい、ノイズや遅延が増えます。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは、短答よりも長いアウトプットの価値が高い場面が多いからです。調査レポート、FAQ 生成、比較記事、社内ナレッジ要約、リサーチエージェントの報告などでは、途中で情報不足が起きると、もっともらしい誤りが混ざりやすくなります。
実際の AI システムでは、RAG を入れたのに長文になると途中から事実が怪しくなる、最初に取ってきた文書だけでは論点が足りず話が浅くなる、といった形で問題になります。FLARE は、この「検索はあるが、検索のタイミングが鈍い」という弱点を狙っています。
用語解説
- RAG（Retrieval-Augmented Generation）
- 外部文書を検索してから生成する仕組みです。FLARE は RAG を否定するのではなく、検索を一回きりにせず、生成中に何度も差し込めるようにした点が重要です。
- Active Retrieval
- 検索するかどうか、いつ検索するか、何で検索するかを動的に決める考え方です。この論文では、モデルの不確実さと次文予測を使ってその判断を行います。
- トークン確率
- モデルが次に出す語にどれだけ自信を持っているかを表す値です。FLARE では低確率トークンを「知識が足りない兆候」とみなし、検索トリガーとして使います。
- 長文生成
- 短い一問一答ではなく、複数文や段落にまたがる生成タスクです。FLARE の価値は、まさにこの長文生成で、途中から必要になる情報を追いかけられるところにあります。
- クエリ生成
- 検索用の問い合わせ文をどう作るかという問題です。FLARE では、次に書こうとしている文そのもの、あるいはその中の低信頼部分から検索クエリを作るため、質問文だけで検索するより未来の情報需要に合いやすくなります。
技術の仕組み
FLARE の基本発想はかなり実務的です。モデルが「次に何を書こうとしているか」を一度先読みし、その内容に自信がないときだけ検索をかけて、検索結果を見てからその文を書き直します。
基本アイデア
通常の RAG は、入力 -> 検索 -> 生成 という一方向の流れです。これに対して FLARE は、入力 -> 仮の次文生成 -> 必要なら検索 -> 次文を再生成 -> 次の文へ というループを取ります。
大事なのは、検索クエリを過去の文脈から作るのではなく、次に書く予定の文から作ることです。論文ではこれを forward-looking と呼んでいます。過去ではなく未来を見て検索するので、これから必要になる情報に合わせやすい設計です。
モデル構造
この論文は新しい Transformer アーキテクチャを提案しているわけではありません。既存の言語モデルに、検索と再生成の制御ループを外付けしています。論文では主に text-davinci-003 をベースモデルとして使っています。
つまり、変わるのはモデル本体よりも推論オーケストレーションです。この点は実務上重要で、既存の LLM に対しても、周辺の推論制御だけで近い発想を実装しやすいことを意味します。
Active Retrieval の一般形
論文では、Active Retrieval を一般化して、各ステップでクエリ q_t = qry(x, y<t) を作り、取得文書を条件に次の生成を進める枠組みとして定義しています。ここで x は元の入力、y<t はそれまでに生成した内容です。
普通の RAG は q_1 = x の1回だけで終わりますが、Active Retrieval では生成中に q_t を何度も更新できます。これが「一回検索して終わり」ではないポイントです。
FLAREinstruct と FLAREdirect
論文では 2 つの実装形があります。1 つは FLAREinstruct で、モデルに [Search(query)] のような検索指示を few-shot で学習させ、必要時に検索クエリを自力で吐かせる方法です。
もう 1 つが、より重要な FLAREdirect です。こちらは、まず検索なしで仮の次文を生成し、その文の確率を見て検索するかを決めます。論文では最終的にこちらがより強い結果を出しています。
推論方法
FLAREdirect の推論フローは次のようになります。
1. 次の文を仮生成する
まず、取得文書を追加せずに次の文 ŝ_t を一度出します。ここでは、モデルが今の文脈だけで何を書こうとしているかを見ます。
2. 低信頼トークンがあるかを見る
仮生成した文の中に、確率がしきい値 θ を下回るトークンがあれば、「この文は知識不足の可能性がある」と判断して検索を起動します。θ = 0 なら検索しない、θ = 1 なら毎文検索する、という意味です。
3. 次文から検索クエリを作る
クエリの作り方も工夫されています。最も単純なのは、仮の次文をそのままクエリに使う方法です。ただし、文の中に誤った固有名詞が混ざると、その誤りに引っ張られた検索になるリスクがあります。
そこで論文では、低信頼部分をマスクして暗黙的なクエリにする方法と、低信頼スパンを答えにする質問文を別途生成する方法を比較しています。前者は「文の怪しい箇所を空欄にした検索」、後者は「その空欄を埋める質問を作って検索」というイメージです。
4. 検索結果を前置して文を再生成する
取得した文書を入力の前に付け直し、その上で次の文をもう一度生成します。こうして、怪しかった文だけを外部知識で補正してから先へ進みます。
データの扱い方
論文では、Wikipedia が中心のタスクには BM25 検索を、オープンウェブ依存のタスクには Bing 検索を使っています。つまり FLARE の本質は、特定のベクトル検索器ではなく、「推論途中で検索器を差し込む制御」にあります。
また、過去に取ってきた全文書を累積し続けるのではなく、その時点の取得文書だけを条件に使う設計です。これはコンテキスト長の肥大化を避けるための現実的な工夫です。
重要な工夫
過去ではなく次文を見る
過去の文脈で検索すると、これから必要な情報とずれることがあります。FLARE は次文の予測をクエリの土台にすることで、このずれを減らそうとしています。
不確実さを検索トリガーに使う
全部の文で検索すると遅くなり、不要なノイズも増えます。そこで、低確率トークンだけを見て「本当に怪しいときだけ検索する」ようにしています。
低信頼スパンだけを意識してクエリを作る
文全体をそのまま検索クエリにすると、誤った記述までクエリに混ざります。低信頼部分をマスクしたり、質問文へ変換したりするのは、その誤り伝播を抑えるためです。
実験と結果
論文では、FLARE が本当に長文生成で効くのか、単発検索や受動的な再検索より良いのかを検証しています。
何を検証したのか
検証の中心は 3 つあります。1 つ目は、単発の RAG より長文生成の品質が上がるかです。2 つ目は、過去文脈ベースの再検索より、次文ベースの forward-looking 検索が有効かです。3 つ目は、検索トリガーとクエリ生成の工夫がどれだけ効くかです。
使ったデータセットと評価指標
評価は、2WikiMultihopQA、StrategyQA、ASQA、ASQA-hint、WikiAsp の 5 系列で行われています。多段推論、常識推論、長文質問応答、曖昧質問応答、オープンドメイン要約まで含まれており、かなり幅があります。
指標はタスクごとに異なります。たとえば 2WikiMultihopQA と StrategyQA では EM、2WikiMultihopQA では F1 も見ています。ASQA では EM、Disambig-F1、ROUGE-L、DR、WikiAsp では UniEval、Entity-F1、ROUGE-L が使われています。
2WikiMultihopQA では質問分解より上回る
2WikiMultihopQA では、検索なしが EM 28.2、単発検索が 39.4、質問分解ベースの強いベースラインが 47.8 でした。これに対して FLAREdirect は EM 51.0、F1 59.7 を記録し、主要ベースラインを上回っています。
ここで重要なのは、手作業で分解例を強く与える手法よりも、次文先読みで検索するほうが強かったことです。長文や多段推論では、「未来に必要な論点」を見に行く価値が大きいと読めます。
長文QAと要約でも一貫して改善
StrategyQA では EM が、単発検索 68.6 に対して FLARE 77.3 まで上がっています。ASQA では EM が 40.0 から 41.3、ASQA-hint では 43.2 から 46.2 に改善しています。WikiAsp でも UniEval が 52.4 から 53.4 に伸びています。
改善幅はデータセットごとに違いますが、少なくとも「単発検索より悪化しない特殊手法」ではなく、複数種類の長文生成で広く効く設計であることが示されています。
次文を使うほうが過去文脈より強い
論文では、前の文を検索クエリにする方法と、次の文を検索クエリにする方法を正面から比較しています。2WikiMultihopQA では、前文クエリが EM 39.0、F1 49.2 に対して、次文クエリは EM 48.8、F1 57.6 でした。ASQA-hint でも前文クエリより次文クエリのほうが良い結果です。
これは FLARE の核そのものです。検索は「今まで書いたこと」ではなく「これから書くこと」に合わせたほうが有効だと、実験でも裏付けられています。
文を丸ごと検索するより、低信頼部分を意識したほうがよい
2WikiMultihopQA では、次文をそのまま検索するより、低信頼トークンをマスクした検索のほうが成績が上がっています。論文ではマスキングしきい値 β を変えた比較があり、β = 0.4 のとき EM 51.0、F1 59.7 で最良でした。β = 0.0、つまり文全体をそのまま使うと EM 48.8、F1 57.6 に下がっています。
結果から言えるのは、先読み文は有用ですが、そのまま信じ切るのではなく、「怪しい部分を外して検索に使う」ほうが堅いということです。
結果から何が言えるのか
この結果から言えるのは、RAG のボトルネックは検索器の精度だけではなく、検索のタイミング設計にもあるということです。最初の一回の検索で全部を賄おうとするより、生成の中で情報不足を検知して補うほうが、長文では自然です。
同時に、Active Retrieval は「検索回数を増やせばよい」という話でもありません。必要な場面を選ぶこと、誤った仮説をそのままクエリにしないこと、この 2 点が効いています。
何に使える？
FLARE は、長文生成や段階的な調査が必要な AI アプリにかなり応用しやすいです。
調査レポート生成
リサーチエージェントや社内調査ボットでは、最初に検索した文書だけだと、途中で論点が足りなくなることがあります。FLARE 型にすると、段落ごとに必要な情報を追加で引けるため、レポートの後半で急に浅くなる問題を減らしやすいです。
FAQ やナレッジ記事の自動生成
ヘルプ記事や比較記事では、製品名、仕様、制約条件など細かな事実が途中で必要になります。生成中に曖昧な箇所だけ再検索する設計は、記事全体の一貫性を保ちながら事実補強をしやすいです。
RAG チャットの長文回答モード
通常の RAG チャットは短答には向いていますが、「背景から説明して」「比較して」「手順も含めて」といった長い回答では弱くなりがちです。FLARE の考え方を入れると、回答途中で追加証拠を拾えるので、長文モードの品質改善に向いています。
エージェントの最終報告
ツールを複数回使うエージェントでも、最後の報告文生成は別問題です。報告の途中で新しい固有名詞や数値が出てきたときに再検索を差し込めば、ツール実行ログだけでは足りない補足情報を埋めやすくなります。
段階的な要約やプロフィール生成
人物・企業・技術テーマの紹介文は、最初は大まかな概要でも、途中から細部が必要になります。FLARE はこうした「だんだん詳細になる文章」と相性がよいです。
開発や事業へのヒント
この論文から得られるヒントは、RAG の改善は埋め込みや再ランキングだけではなく、推論制御レイヤーでも大きく伸ばせるということです。
検索を前処理ではなく推論の一部として扱う
多くのプロダクトでは、検索は最初に一度だけ走る前処理です。しかし FLARE の発想では、検索は生成と交互に走る推論部品です。これにより、同じ検索基盤でも、長文タスク向けの体験を別モードとして作り分けやすくなります。
小規模プロダクトでも段階導入しやすい
FLARE はモデル再学習が必須ではありません。論文でも推論時の工夫で実装されています。そのため、小規模なチームでも、まずは「段落ごと再検索」「低信頼文だけ再検索」といった簡略版から導入しやすいです。
回答品質だけでなくコスト制御にも効く
毎回検索する設計は品質が上がっても遅くなります。逆に検索を減らしすぎると幻覚が増えます。FLARE のように不確実な場面だけ検索する方式は、品質とレイテンシのバランス設計に向いています。特に API 課金型の検索や外部ツール呼び出しでは、この発想がそのまま事業上のコスト設計につながります。
今後注目すべき方向性
今後は、検索トリガーをトークン確率だけでなく、自己評価、引用整合性、外部ツール失敗率などと組み合わせる方向が有力そうです。ここは推測ですが、Active Retrieval は RAG だけでなく、ツール実行全般の「いつ追加行動するか」という意思決定層へ広がっていくはずです。
限界
FLARE にも注意点はあります。まず、検索回数が増えるぶん、単発 RAG より推論レイテンシは伸びやすいです。長文になればなるほど、どこで再検索するかの設計がコストに直結します。
また、モデルのトークン確率を検索トリガーに使うため、確率の較正が悪いモデルでは判定が安定しない可能性があります。論文でも、将来の情報需要を見に行く発想自体は有効でも、どのくらい正確に不確実さを測れるかはベースモデル依存です。
クエリ生成にも弱点があります。仮生成した文に誤情報が混ざると、その誤りを起点に検索してしまう危険があります。論文はマスキングや質問生成でこれを和らげていますが、完全には防げません。
実装の難しさもあります。単純な RAG より、文単位の生成制御、確率取得、再検索ループ、検索結果の差し込みなどが増えるため、推論パイプラインは複雑になります。
さらに、論文の評価は長文生成タスクが中心です。社内文書検索、コード RAG、マルチモーダル検索、ツール併用エージェントなどで同じ設計が最適かは、追加検証が必要です。
よくある質問
Q. Active Retrieval は普通の RAG と何が違うのですか？
A. 普通の RAG は最初に一回だけ検索して、その結果を見ながら最後まで生成することが多いです。Active Retrieval は生成途中でも再検索し、必要な情報を後から足します。長文や多段推論では、この差が効きやすいです。
Q. FLARE は学習し直さないと使えませんか？
A. 論文の中心は推論時の制御です。新しいモデル構造を学習するというより、次文の仮生成、不確実さ判定、検索、再生成のループを実装する考え方です。そのため、既存 LLM にも発想を移植しやすいです。
Q. なぜ前の文ではなく次の文で検索するのですか？
A. 前の文は、すでに書いた内容に引っ張られます。一方で次の文は、これから必要になる情報を含みます。論文でも、次文ベースの検索は前文ベースより高い性能を示しており、未来の情報需要を見たほうが効果的だと分かります。
Q. 実務ではどんな簡略版から試すとよいですか？
A. まずは、長文回答を段落単位に分け、各段落の下書きを作ってから不確実な段落だけ再検索する設計が現実的です。論文どおりの文単位制御が重ければ、段落単位でも発想は活かせます。
Q. ベクトル検索や再ランキングより優先して導入すべきですか？
A. それは現状次第です。検索結果そのものが弱いなら検索器改善が先です。ただ、検索品質はそこそこ高いのに長文で崩れるなら、検索器より先に Active Retrieval のような推論制御を見直したほうが効く可能性があります。
今日の学び
この論文は、長文生成では最初の一回の検索だけでは必要な知識を取り切れない、という課題を扱いました。そこに対して、FLARE は次の文を先読みし、不確実なときだけ追加検索して文を生成し直すという方法で解こうとしました。
ここから得られるヒントは、RAG の改善は検索器の入れ替えだけではないということです。検索をいつ呼ぶか、何をクエリにするかを推論の中で設計し直すだけでも、AI アプリの長文品質や調査能力はかなり変わり得ます。