8月31日、Toward Data Scienceが「Why RAG Complexity Should Be Earned」と題した記事を公開した。RAGアーキテクチャの複雑性は「測定された失敗」に応じて段階的に導入すべきであり、まず検索サブシステムを正しく評価・改善することが先決だという実践的な設計指針を詳しく解説している。
「複雑にすれば改善する」という罠
現代のRAGシステムでよく見られるパターンがある。検索がうまくいかない。するとすぐに、クエリリライティング・ルーティング・複数回の検索・リフレクション・修正的検索・エージェントによる判断・リランキングモデル——と次々に機能を積み上げる。結果として一見精緻なアーキテクチャが完成するが、根本的な失敗原因は依然として残っている可能性がある。
その失敗原因とは単純なものだ。「必要な証拠が検索候補セットに入っていなかった」——つまり、最初の検索段階で関連ドキュメントがtop-kに入らず、モデルのコンテキストウィンドウに渡っていないケースだ。
記事はこの問題を明快に整理する：
アーキテクチャの複雑性は、実証された失敗モードに対応するものであるべきだ。
生成後にどれだけ推論を重ねても、コンテキストに存在しない証拠は取り戻せない。複雑化によって増えるのは、レイテンシ・トークン消費・非決定性・評価が必要なコンポーネント数だ。
検索と生成を「別の問題」として扱う
RAGシステムには概念的に異なる2つの処理がある：
- 検索（Retrieval）：クエリに回答するために必要な情報を含む文書を特定する
- 生成（Generation）：取得した情報を解釈し、適切な応答を構築する
この2つはユーザーに見えるアウトプットが「生成された回答」であるため、一括して評価されがちだ。しかしシステム設計の観点では、失敗モードを分離して診断する必要がある。
記事は「解約条項を問う契約書クエリ」を例に挙げる。検索結果に「一般的な取引先義務」「支払い条項」「service levelを含む文章」「契約違反の定義」が含まれていても、肝心の解約条項がtop-k圏外なら、どれだけ優秀なLLMでも正しく答えられない。出力された回答が「もっともらしく聞こえる」だけで、システムは検索段階で失敗している。
RAGシステムの基本的な診断問いはこうなる：
クエリに回答するために必要な証拠が、取得した候補セットの中に存在していたか？
この問いへの回答なしに、生成層やプロンプトを変更するのは、原因と対策がずれた対応だ。
BM25は「古い技術」ではない
埋め込みベースの検索が普及した結果、「意味的類似度検索がBM25の上位互換」という暗黙の前提が広まった。しかし記事はこれを否定する。
BM25（Okapi BM25）は語彙的検索の代表格で、クエリと文書の語彙が一致するケースに強い。エラーコード、契約識別子、法律引用、製品番号、関数名、ティッカーシンボル、略語、医学用語、日付など、完全一致が意味を持つ識別子が含まれるクエリでは、埋め込みモデルより正確に動作する。
例えば埋め込みモデルはTS-999という識別子を「技術エラー」として正しく解釈できるかもしれないが、TS-999という文字列を含む唯一のドキュメントより、意味的に近い別の文書を上位にランクする可能性がある。BM25は逆だ。完全一致する字句的証拠を強く優遇する。
金融ドメインを対象としたベンチマーク（23,088問・7,318文書を対象に10の検索戦略を比較）では、BM25が評価された最新の密ベクトル検索手法を上回った。このベンチマークの詳細は元記事内で参照されている。
ハイブリッド検索＋二段階リランキングが現時点の堅実な解
BM25が強い一方、限界もある。クエリと文書の語彙が異なる場合だ。例えばユーザーが「自発的に退職できる状況は？」と聞いても、社内規定が「従業員起因の契約終了」という表現のみを使っていれば、BM25は一致を見つけられない。こういった場面で密ベクトル検索（Dense Retrieval）が補完する。
ハイブリッド検索はこの相補性を活用する。語彙的検索と意味検索の両方で候補を生成し、ランキングを統合する。
ランキングを統合する手法として代表的なのがRRF（Reciprocal Rank Fusion）だ。BM25スコアと埋め込み類似度スコアは直接比較できないため、それぞれの相対的な順位を使って組み合わせる：
RRF(d) = Σ 1 / (k + rank_r(d))
その後、候補セットをクロスエンコーダー等のリランカーが精査する。この二段階構造は意味的に重要だ。
- 第一段階（検索）：リコールを最大化する——関連文書を候補に入れることが目的
- 第二段階（リランキング）：精度を最適化する——小さな候補セットに対して計算コストをかけて関連度を推定
前述の金融ドメインベンチマークでは、ハイブリッド検索＋ニューラルリランキングの二段階構成がRecall@5: 0.816、MRR@3: 0.605を達成し、単一段階の手法を大きく上回った。
AnthropicによるContextual Retrieval実験でも同様のパターンが確認されている。コンテキスト付き埋め込みとコンテキスト付きBM25を組み合わせることでtop-20の検索失敗率が49%低減し、リランキング導入でさらに67%低減した。
「取り込み時点」の設計が検索品質を決める
記事が強調するもう一つの重要な視点が、チャンキング（文書分割）の問題だ。
固定トークンで文書を分割する実装では、以下のような情報欠損が起きる：
チャンク41: Section 7 — Termination
The customer may terminate the agreement if service availability
チャンク42: falls below 99.5% for three consecutive months.
Notice must be provided within 30 days...
チャンク42には重要な条件が含まれているが、それが何に関する条件なのかという文脈が失われている。 埋め込みモデルはこの構造を再構築できない。
同様の問題は以下のケースでも発生する：
- 見出しとセクション本文が分離される
- テーブルヘッダーが値から切り離される
- PDFレイアウトが誤ってフラット化される
- タイムスタンプやレポート期間が除去される
AnthropicのContextual Retrieval実験ではこの問題に対処するため、各チャンクにインデックス前に短い文書由来コンテキストを付与した。その結果、top-20の検索失敗率は5.7%から3.7%に低下した。
検索品質はクエリ時ではなく、取り込み時点から始まる。
インデックス段階で構造的に劣化した情報を、クエリ時の精緻なアーキテクチャで補うことには限界がある。
エージェンティックRAGが本当に必要な場面
記事はエージェンティックRAGを否定していない。静的な検索が構造的に不十分な情報ニーズに対しては、適切な解決策だと述べる。
典型例は多段階推論が必要なクエリだ：
「A社とB社のどちらが2025年の営業利益率が高く、各社が前年比変化の主因として挙げたのは何か？」
このクエリは単一の文書から答えが得られない。A社の営業利益率→A社の経営説明→B社の営業利益率→B社の経営説明、という依存関係のある複数の検索ステップが必要だ。
質問分解（Question Decomposition）の効果は実証されている。LLMベースの分解とリランキングを組み合わせたパイプラインがMultiHop-RAGおよびHotpotQAデータセット上で、標準的RAGベースラインに対してMRR@10で36.7%、回答F1で11.6%の改善を報告した研究がある（元記事内で参照されている）。
エージェンティックRAGが適切なその他のケースとして記事が挙げるのは：
- 異種ソース選択：RDB・文書インデックス・ナレッジグラフ・APIなど、どこから検索するかを先に判断する必要がある場合
- 証拠依存型検索：中間結果を見てから次のクエリを組み立てる、分岐的な検索パスが実行中に決まる場合
- 曖昧性解消：初回検索で複数の解釈が浮上し、追加検索で絞り込む必要がある場合
ただし記事の主張は一貫している。証拠が適切な検索単位として存在しているのに失敗しているなら、問題は検索サブシステムにある可能性が高い。エージェントを追加するより、まず検索品質を正しく診断・改善する方が先だ。
詳細はWhy RAG Complexity Should Be Earnedを参照していただきたい。
