Multi Query Retrieverから2年後：テキストRAG改善のフェーズは変わったのか

はじめに

2024 年 3 月に、HEROZ Tech Blog で「Multi Query Retriever を用いた RAG の精度向上」に関する記事を公開しました。

techblog.heroz.jp

この記事では、Naive RAG に対して Multi Query Retriever を適用することで、社内 Wiki を対象とした評価において正答数が 19/25 から 24/25 に改善しました。当時としては、クエリの表現揺れや検索漏れを Multi Query で補うことに明確な価値があり、Enhanced RAG の効果が分かりやすく出た検証だったと思います。

一方で、この記事は今でも継続的にアクセスされています。RAG 改善への関心は今も高いのだと思いますが、最近いろいろな RAG 改善手法を試していると、以前ほど分かりやすく精度が伸びない感覚もありました。

Query Rewrite、Multi Query、HyDE、ReRank、Agentic RAG、Router RAG、Hybrid Search、チャンク設計など、RAG 改善としてよく挙げられる手法を試しても、平均スコアが大きく動かないことが増えています。

そこで今回は、2024 年の記事から約 2 年経った現在、あらためて次の問いを検証してみました。

今でも Enhanced RAG や Agentic RAG は、Naive RAG に対して平均精度を大きく押し上げるのか？

結論から言うと、今回の検証では、手法間の平均スコアの差はかなり限定的でした。

もちろん、特定の条件では改善する手法もあります。特に Agentic RAG の一部は、データセットによっては Naive RAG を上回りました。しかし、Query Rewrite、Multi Query、HyDE、ReRank、ReAct、Adaptive RAG、Deep Agent を横並びで比較しても、「これを入れれば平均的に大きく改善する」と言える手法は見つかりませんでした。

そこで本記事では、今回の横並び比較の結果を紹介したうえで、近年の RAG 関連研究も参照しながら、この結果をどう解釈すべきかを考えます。

最近の研究を見ても、RAG 改善の論点は、単体の Enhanced RAG 手法で平均精度を押し上げる方向だけではなく、LLM の性能向上による複雑な RAG 改善の限界効用、Agentic RAG のコストと探索制御、Long Context との使い分け、検索結果を増やしすぎることの副作用といった方向に広がっています。

本記事では、社内検証の結果と関連研究を踏まえて、テキスト RAG 改善のフェーズがどう変わってきているのかを考察します。

今回は、大きく Enhanced RAG 系と Agentic RAG 系に分けて比較しました。

Enhanced RAG

手法

概要

Naive

通常のベクトル検索 + 回答生成

ReRank

取得文書を質問への有用度で並び替える

Query Rewrite

質問を検索しやすいクエリに書き換える

Multi Query

複数の検索クエリを生成し、検索漏れを減らす

HyDE

検索用の仮想文書を生成して検索する

2024年の記事で扱ったMulti Query Retrieverも、このEnhanced RAG系の一種です。

Agentic RAG

手法

概要

Naive

通常のベクトル検索 + 回答生成

ReRank

参考値として比較

ReAct

検索ツールを使うReAct型エージェント

Adaptive RAG

検索や回答可否を適応的に判断するRAG

Deep Agent

より複雑な探索を行うAgent構成

Agentic RAGは、単発の検索で回答するのではなく、必要に応じて検索クエリを変えたり、複数回探索したりする構成です。うまく機能すれば、単純なRAGでは拾えない根拠を見つけられる可能性があります。一方で、LLM呼び出し回数、トークン数、コスト、レイテンシが増えやすいという難しさもあります。

評価データセットと評価方法

評価には、以下の2つの日本語RAG評価データセットを使用しました。

データセット

問題数

特徴

Allganize RAG Dataset

207問

エンタープライズサーチ寄り

J-RAGBench

114問

難問寄り

Allganize RAG Datasetは、業務文書検索に近い性質を持つデータセットとして扱いました。一方でJ-RAGBenchは、より難問寄りのRAG評価として扱っています。

評価は、独自プロンプトによるLLM as a Judgeで行いました。JudgeにはClaude Sonnet 4.5を使用し、1〜5点の5段階でスコアリングしています。

なお、LLM as a Judgeによる評価には、評価モデル固有のバイアスやスコアのばらつきが含まれる可能性があります。そのため、本記事ではスコアの絶対値や0.01〜0.1程度の小さな差を厳密な優劣として扱うのではなく、手法間の相対的な傾向を見るための参考値として扱います。

また、今回のスコアは多くの手法で3点未満となっています。これは、RAG全体として十分に高品質な回答ができている、というよりも、今回の評価プロンプト・回答生成プロンプト・データセットの難易度を含めた結果です。本記事では、絶対スコアの高さよりも、同一条件で比較したときに手法間でどれくらい差が出るのかに注目します。

実験条件

本文中のスコアは、手法間の傾向を見やすくするため、チューニング前の横並び比較結果を掲載しています。各手法のプロンプトやAgent制御を一定程度整えた追加実験も行いましたが、全体の結論は大きく変わらなかったため、本文では割愛します。

再現性に関わる主な条件は以下です。

項目

設定

生成LLM

gpt-5.4

埋め込みモデル

text-embedding-3-small

チャンクサイズ

1200文字

チャンクオーバーラップ

100文字

retrieve_k

基本は4。ReRank系のみ候補取得は12

top_k

4

ベクトルデータベース / 検索方式

Weaviate / LangChain WeaviateVectorStore.as_retriever によるベクトル類似検索

ReRank

LLM rerank（LLM再ランク付け）。同じ生成用大規模言語モデルをtemperature=0で使用し、候補文書のインデックスをJSON形式で返す方式。クロスエンコーダーは未使用

エージェントの最大探索回数

チューニング前比較では明示的な検索回数上限なし。LangGraph の recursion_limit（再帰制限）=25

評価回数

各質問・各手法につき1回評価。複数回の平均ではない

結果：Enhanced RAG では平均改善が限定的だった

まず、Enhanced RAG の結果です。

imageEnhanced RAG の結果

Allganize RAG Dataset では、Multi Query が 2.82 で最も高く、Naive の 2.80 に対して +0.02 でした。J-RAGBench では、ReRank が 2.57 で最も高く、Naive の 2.48 に対して +0.09 でした。

どちらも改善はしていますが、5 点満点の平均スコアとしてはかなり小さい差です。

ここで重要なのは、Multi Query や ReRank が無意味だった、ということではありません。これらの手法は、検索漏れや表現揺れ、検索結果のノイズが問題になるケースでは有効に働く可能性があります。

ただし、今回のようにデータセット全体の平均で見ると、Naive RAG を大きく押し上げる結果にはなりませんでした。

2024 年の記事では、Multi Query Retriever による改善がかなり分かりやすく出ました。しかし今回の検証では、少なくとも平均スコアを見る限り、同じような大きな改善は確認できませんでした。

結果：Agentic RAG も安定した万能薬ではなかった

次に、Agentic RAG の結果です。

imageAgentic RAG の結果

Allganize RAG Dataset では、Adaptive RAG が 3.13 で最も高く、Naive の 2.77 に対して +0.36 でした。これは今回の結果の中では比較的大きな改善です。

一方で、J-RAGBench では Adaptive RAG は 2.28 となり、Naive の 2.51 を下回りました。J-RAGBench で最も高かったのは Deep Agent の 2.58 ですが、Naive との差は +0.07 にとどまりました。

つまり、Agentic RAG は特定の条件では有効に働く可能性があります。しかし、少なくとも今回の範囲では、データセットをまたいで安定して大きく改善する手法とは言えませんでした。

Naive との差分だけをまとめると、次のようになります。

imageNaive との差

Enhanced RAG では、最良手法でも Naive との差は +0.02〜+0.09 でした。一方、Agentic RAG では Allganize RAG Dataset の Adaptive RAG だけが +0.36 と目立ちましたが、J-RAGBench では同様の改善は見られませんでした。

コストやレイテンシも含めると、さらに悩ましい結果になります。

imageコストとレイテンシ

Allganize RAG Dataset の Adaptive RAG は、Naive に対して +0.36 改善しています。一方で、時間は約 2.8 倍、LLM 呼び出し回数は 7 倍、コストは約 2.5 倍です。

J-RAGBench の Deep Agent は、Naive に対して +0.07 の改善に対して、コストは約 5.9 倍です。

この結果を見ると、Agentic RAG を常に使うというより、複数回探索が必要な質問や、回答可否判定が重要な質問に限定して使う方が自然だと感じました。

また、Adaptive RAG が Allganize RAG Dataset では改善し、J-RAGBench では悪化した点も重要です。Allganize RAG Dataset はエンタープライズサーチ寄りであり、質問に対して「根拠があるか」「追加検索すべきか」「回答できないか」を判断する Adaptive RAG の制御が噛み合いやすかった可能性があります。一方で、J-RAGBench のような難問寄りのデータセットでは、回答可否判定や追加検索判断が過剰に働き、必要な推論に進む前に回答を控えたり、余計な文脈を取り込んだりした可能性があります。

なお、本記事での Adaptive RAG は、前回の記事で扱った LangGraph の実装例を参考にした構成です。詳細な考え方は前回記事も参照してください。

この点はログ分析を深掘りしないと断定できませんが、Agentic RAG がタスク依存であることを示す重要な結果だと考えています。

関連研究から結果を読み解く

今回の検証では、Enhanced RAG や Agentic RAG を追加しても、平均スコアの改善は限定的でした。

この結果を解釈するうえで参考になるのが、近年の RAG 関連研究です。ここでは、今回の結果と特に関係が深い 4 本に絞って紹介します。

強い LLM 時代には、複雑な RAG 改善の限界効用が下がる可能性がある

今回の結果に最も近いと感じたのが、2025年の"Revisiting Robust RAG: Do We Still Need Complex Robust Training in the Era of Powerful LLMs?"です。

この論文は、RAG（Retrieval-Augmented Generation：検索拡張生成）がノイズ文書や無関係文書に弱いことを背景に、複雑なドキュメント選択や敵対的学習のような堅牢性トレーニング（robust training）が、強力な大規模言語モデル（LLM）の時代でも必要なのかを検証しています。複数のモデルアーキテクチャ、モデルサイズ、データセットで評価した結果、モデルが強力になるほど、複雑な堅牢性 RAG トレーニングによる性能向上は大きく低下する傾向が報告されています。

これは、今回の「Naive RAG にさまざまな手法を足しても平均スコアが大きく動かなかった」という結果とかなり整合的です。

もちろん、この論文が扱っているのは堅牢性トレーニングであり、今回のクエリ書き換え（Query Rewrite）やマルチクエリそのものではありません。しかし、より強い LLM では複雑な RAG 周辺手法の限界効用が小さくなる、という大きな方向性は、今回の実験結果を解釈するうえで重要な補助線になります。

Agentic RAG は、性能だけでなくコストとのトレードオフで見る必要がある

Agentic RAG（エージェント型 RAG）については、以前の記事で"Is Agentic RAG worth it? An experimental comparison of RAG approaches"を紹介しました。

この論文では、Enhanced RAG と Agentic RAG を複数シナリオ・複数観点で経験的に比較し、どちらが常に優れているというより、性能とコストのトレードオフを踏まえて RAG 設計を選ぶ必要があると整理しています。Agentic RAG は LLM がどの行動をいつ行うかを判断する柔軟性を持つ一方で、その分、計算資源やコストの問題が生じます。

今回の結果でも、Agentic RAG は Allganize RAG Dataset では改善した一方で、J-RAGBench では安定した改善にはなりませんでした。また、改善したケースでも LLM 呼び出し回数やコストは増えています。

この意味で、Agentic RAG は「導入すれば精度が上がる万能手法」というより、タスクや失敗モード、コスト制約に応じて使うべき構成だと考えています。

検索結果やコンテキストは、増やせばよいわけではない

Multi Query や Agentic RAG は、検索回数や投入文脈を増やす方向に働きやすい手法です。しかし、検索結果やコンテキストは増やせば増やすほどよいわけではありません。

"In Defense of RAG in the Era of Long-Context Language Models"では、Long Context LLM（長文コンテキストを持つ大規模言語モデル）の時代におけるRAG（Retrieval-Augmented Generation：検索強化生成）の価値を再検討し、OP-RAGという手法を提案しています。この論文では、取得チャンク数を増やすと回答品質が一度上がってから下がる、逆U字型の挙動が報告されています。つまり、適切な取得量にはスイートスポットがあり、文脈を増やしすぎると品質が下がりうるということです。

これは、今回の結果を考えるうえでも重要です。Multi QueryやAgentic RAGによって取得文書が増えても、それが必要な根拠であれば有効ですが、不要な文脈やノイズが増えるだけであれば、改善にはつながりません。

RAGかLong Contextかの選択も、条件依存になっている

2025年のLaRAは、RAGとLong Context LLMを体系的に比較するベンチマークです。2,326のテストケース、4つの実用QAカテゴリ、3種類の長文テキストを対象に、7つのOSSモデル（オープンソースソフトウェアモデル）と4つの商用モデルを評価しています。その結果、RAGとLong Contextのどちらが適しているかは、モデルサイズ、長文処理能力、context length（コンテキスト長）、タスクタイプ、retrieved chunk（取得チャンク）の性質などに依存すると報告されています。

つまり、外部知識を扱う方式そのものも、単純な優劣ではなく条件依存です。

これらの研究を合わせると、最近のRAG研究は「単体手法を足せば平均的に伸びる」というより、「タスクや失敗モードに応じて、検索・文脈・Agent化（エージェント化）・Long Context利用の度合いを選ぶ」方向に進んでいるように見えます。

なぜ差がつきにくくなったのか

ここからは、今回の実験結果と関連研究を踏まえた考察です。

Naive RAGのベースラインが上がっている可能性

一番大きいのは、Naive RAG（単純なRAG）のベースラインが以前より上がっている可能性です。

2024年頃は、検索クエリと文書中の表現が少しずれるだけで検索漏れが起きたり、取得文書にノイズが混じるとLLMがうまく回答できなかったりしました。そのため、Multi Queryのように検索クエリを増やすだけでも、平均精度が分かりやすく改善する余地がありました。

しかし現在は、EmbeddingモデルやLLMの性能向上により、単純なベクトル検索でも必要な文書を拾えるケースが増えている可能性があります。また、LLMの文脈読解能力が上がったことで、検索結果に多少ノイズが含まれていても、回答に必要な部分を抽出できるケースも増えているのではないかと考えています。

その結果、Query Rewrite（クエリ再構成）やMulti Queryを追加しても、「もともと解ける問題を、より高コストに解いているだけ」になりやすいのかもしれません。

しかし、関連研究でも示唆されているように、文脈は増やせば増やすほどよいわけではありません。必要な根拠が増える場合は有効ですが、不要な文脈が増えると、LLM の焦点がぼやけたり、矛盾した情報が混ざったり、コストだけが増えたりします。

今回の結果でも、Enhanced RAG や Agentic RAG を足したからといって、平均スコアが安定して伸びるわけではありませんでした。

これは、RAG 改善が「検索を増やす」だけではなく、「必要な情報だけを、必要以上にノイズを増やさず渡す」問題になっていることを示しているように思います。

今回の検証と最近の研究動向を合わせて見ると、テキスト RAG の改善は、平均点を上げる汎用手法の追加から、失敗モード別の対応へ移っているように見えます。

たとえば、型番や価格、日付のような厳密一致が重要なケースでは、ベクトル検索よりもキーワード検索や metadata、DB 検索が重要になります。

表や PDF レイアウトに情報が埋まっているケースでは、テキスト RAG ではなく OCR（Optical Character Recognition）、table parser、マルチモーダル RAG が必要になります。

複数文書の関係性や multi-hop が重要なケースでは、GraphRAG や Agentic RAG のような構成が効く可能性があります。

一方で、単純な FAQ や文書検索では、Naive RAG で十分な場合もあります。

つまり、「どの RAG 手法が最強か」ではなく、「どの失敗モードに、どの処方を当てるか」が重要になってきているのだと思います。

今回、2024 年の Multi Query Retriever 記事から約 2 年後の再検証として、Enhanced RAG と Agentic RAG を横並びで比較しました。

Allganize RAG Dataset と J-RAGBench で評価したところ、Query Rewrite、Multi Query、HyDE、ReRank といった Enhanced RAG は、Naive RAG に対して平均スコアを大きく押し上げる結果にはなりませんでした。

Agentic RAG についても、Allganize RAG Dataset では Adaptive RAG が改善した一方で、J-RAGBench では安定した改善は見られませんでした。少なくとも今回の範囲では、単に Agent 化すれば RAG が強くなる、とは言えなさそうです。

関連研究を見ても、強力な LLM 時代における複雑な RAG 改善の限界効用、Agentic RAG の性能とコストのトレードオフ、取得チャンク数のスイートスポット、RAG と Long Context の条件依存な使い分けが議論されています。今回の結果は、そうした流れとも整合的に見えます。

実務で見るなら、全質問に同じ Enhanced RAG を常時適用するより、失敗モードごとに処方を選ぶ方が自然です。

失敗モード

対応候補

検索意図が曖昧

Query Rewrite

表現揺れ・検索漏れ

Multi Query / HyDE

取得文書にノイズが多い

ReRank / Context Compression

multi-hop・関係性が重要

GraphRAG / Agentic RAG

型番・価格・日付が重要

Keyword Search / Metadata / DB 検索

PDF・表・図に情報がある

OCR / Table Parser / Multimodal RAG

回答可否判定が重要

Adaptive RAG / Abstention 設計

テキスト RAG が終わったわけではありません。

ただし、汎用手法を足して平均精度を押し上げるフェーズから、失敗モードを見極めて適切な処方を当てるフェーズへ移っている。今回の検証は、その変化を実感する結果になりました。