はじめに
2024年3月に、HEROZ Tech Blogで「Multi Query Retrieverを用いたRAGの精度向上」に関する記事を公開しました。
この記事では、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改善のフェーズがどう変わってきているのかを考察します。
今回比較した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 |
| Embeddingモデル | text-embedding-3-small |
| チャンクサイズ | 1200文字 |
| チャンクoverlap | 100文字 |
| retrieve_k | 基本は4。ReRank系のみ候補取得は12 |
| top_k | 4 |
| ベクトルDB / 検索方式 | Weaviate / LangChain WeaviateVectorStore.as_retriever によるベクトル類似検索 |
| ReRank | LLM rerank。同じ生成LLMをtemperature=0で使用し、候補文書indexをJSONで返す方式。cross encoderは未使用 |
| Agentの最大探索回数 | チューニング前比較では明示的な検索回数上限なし。LangGraphのrecursion_limit=25 |
| 評価回数 | 各質問・各手法につき1回評価。複数回平均ではない |
結果：Enhanced RAGでは平均改善が限定的だった
まず、Enhanced RAGの結果です。
| データセット | Naive | ReRank | Query Rewrite | Multi Query | HyDE |
|---|---|---|---|---|---|
| Allganize RAG Dataset | 2.80 | 2.79 | 2.72 | 2.82 | 2.80 |
| J-RAGBench | 2.48 | 2.57 | 2.48 | 2.50 | 2.42 |
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の結果です。
| データセット | Naive | ReRank | ReAct | Adaptive RAG | Deep Agent |
|---|---|---|---|---|---|
| Allganize RAG Dataset | 2.77 | 2.83 | 2.79 | 3.13 | 2.88 |
| J-RAGBench | 2.51 | 2.55 | 2.52 | 2.28 | 2.58 |
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との差分だけをまとめると、次のようになります。
| データセット | 系統 | 最良手法 | Naive | 最良スコア | 差分 |
|---|---|---|---|---|---|
| Allganize RAG Dataset | Enhanced | Multi Query | 2.80 | 2.82 | +0.02 |
| J-RAGBench | Enhanced | ReRank | 2.48 | 2.57 | +0.09 |
| Allganize RAG Dataset | Agentic | Adaptive RAG | 2.77 | 3.13 | +0.36 |
| J-RAGBench | Agentic | Deep Agent | 2.51 | 2.58 | +0.07 |
Enhanced RAGでは、最良手法でもNaiveとの差は+0.02〜+0.09でした。一方、Agentic RAGではAllganize RAG DatasetのAdaptive RAGだけが+0.36と目立ちましたが、J-RAGBenchでは同様の改善は見られませんでした。
コストやレイテンシも含めると、さらに悩ましい結果になります。
| データセット | 手法 | 評価 | 時間(ms) | LLM呼出回数 | コスト(円) |
|---|---|---|---|---|---|
| Allganize RAG Dataset | Naive | 2.77 | 3019.4 | 1.0 | 1.40 |
| Allganize RAG Dataset | Adaptive RAG | 3.13 | 8368.9 | 7.0 | 3.46 |
| J-RAGBench | Naive | 2.51 | 1394.6 | 1.0 | 0.86 |
| J-RAGBench | Deep Agent | 2.58 | 3158.8 | 2.1 | 5.05 |
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がノイズ文書や無関係文書に弱いことを背景に、複雑なdocument selectionやadversarial trainingのようなrobust trainingが、強力なLLM時代でも必要なのかを検証しています。複数のモデルアーキテクチャ、モデルサイズ、データセットで評価した結果、モデルが強力になるほど、複雑なrobust RAG trainingによる性能向上は大きく低下する傾向が報告されています。
これは、今回の「Naive RAGにさまざまな手法を足しても平均スコアが大きく動かなかった」という結果とかなり整合的です。
もちろん、この論文が扱っているのはrobust trainingであり、今回のQuery RewriteやMulti Queryそのものではありません。しかし、より強いLLMでは複雑なRAG周辺手法の限界効用が小さくなる、という大きな方向性は、今回の実験結果を解釈するうえで重要な補助線になります。
Agentic RAGは、性能だけでなくコストとのトレードオフで見る必要がある
Agentic 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の価値を再検討し、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のベースラインが以前より上がっている可能性です。
2024年頃は、検索クエリと文書中の表現が少しずれるだけで検索漏れが起きたり、取得文書にノイズが混じるとLLMがうまく回答できなかったりしました。そのため、Multi Queryのように検索クエリを増やすだけでも、平均精度が分かりやすく改善する余地がありました。
しかし現在は、EmbeddingモデルやLLMの性能向上により、単純なベクトル検索でも必要な文書を拾えるケースが増えている可能性があります。また、LLMの文脈読解能力が上がったことで、検索結果に多少ノイズが含まれていても、回答に必要な部分を抽出できるケースも増えているのではないかと考えています。
その結果、Query RewriteやMulti Queryを追加しても、「もともと解ける問題を、より高コストに解いているだけ」になりやすいのかもしれません。
検索や文脈を増やすことが、常に改善につながるわけではない
Multi Query、HyDE、Agentic RAGは、いずれも検索や文脈を増やす方向に働きやすい手法です。
しかし、関連研究でも示唆されているように、文脈は増やせば増やすほどよいわけではありません。必要な根拠が増える場合は有効ですが、不要な文脈が増えると、LLMの焦点がぼやけたり、矛盾した情報が混ざったり、コストだけが増えたりします。
今回の結果でも、Enhanced RAGやAgentic RAGを足したからといって、平均スコアが安定して伸びるわけではありませんでした。
これは、RAG改善が「検索を増やす」だけではなく、「必要な情報だけを、必要以上にノイズを増やさず渡す」問題になっていることを示しているように思います。
残る課題は平均改善ではなく、失敗モード別対応になっている
今回の検証と最近の研究動向を合わせて見ると、テキストRAGの改善は、平均点を上げる汎用手法の追加から、失敗モード別の対応へ移っているように見えます。
たとえば、型番や価格、日付のような厳密一致が重要なケースでは、ベクトル検索よりもキーワード検索やmetadata、DB検索が重要になります。
表やPDFレイアウトに情報が埋まっているケースでは、テキストRAGではなくOCR、table parser、マルチモーダルRAGが必要になります。
複数文書の関係性やmulti-hopが重要なケースでは、GraphRAGやAgentic RAGのような構成が効く可能性があります。
一方で、単純なFAQや文書検索では、Naive RAGで十分な場合もあります。
つまり、「どの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が終わったわけではありません。 ただし、汎用手法を足して平均精度を押し上げるフェーズから、失敗モードを見極めて適切な処方を当てるフェーズへ移っている。今回の検証は、その変化を実感する結果になりました。
