RAGで検索結果を増やしすぎると精度が落ちる理由｜top-k・重複排除・再ランキング・要約の設計

社内RAGで回答が的外れになると、「もっと多くの文書を検索すれば改善する」と考えがちです。しかし、検索候補を増やした結果、同じ文書の隣接チャンク、質問と関係の薄い文書、古い版と新しい版などが最終コンテキストを占めると、かえって回答に必要な根拠が埋もれることがあります。

結論：取得件数を増やすかどうかは、最終回答だけを見て決めません。まず、候補集合に正解根拠があるか、最終コンテキストに残っているか、重複・ノイズがどの程度含まれるかを分けて確認してください。候補を広く取る工程と、LLMへ渡す情報を厳選する工程は別に設計します。

RAGは、生成モデルと、検索でアクセスする外部メモリを組み合わせる枠組みです。検索結果をすべてそのままプロンプトへ貼り付けることがRAGの要件ではありません。RAG原論文でも、生成モデルと非パラメトリックな検索メモリを組み合わせる構成が示されています。

なぜ検索結果を増やすと回答精度が下がりうるのか

検索件数の増加が常に悪いわけではありません。候補内に正解根拠が入る可能性を高められる場合があります。一方で、候補数の増加とLLMへ渡すコンテキスト量の増加を同じ変更として扱うと、次の問題が起きます。

• 重複：同じ規程・同一段落・前後チャンクが複数入り、限られたトークン枠を消費する。
• ノイズ：検索スコアは近いが、質問への回答には不要な説明が混ざる。
• 根拠の競合：改定前後の文書、部署ごとに適用範囲が異なる手順、例外規定が同時に渡される。
• 位置の問題：重要な根拠が長い入力の中央に置かれ、モデルが十分に使えない。
• 生成時の選別負荷：モデルが比較・統合すべき根拠が増え、回答の焦点や引用対応が崩れる。

長いコンテキストでは、関連情報の位置によって性能が変わり、特に中央付近の情報を使う性能が低下しうることが報告されています。したがって、「モデルのコンテキスト上限に収まる」ことだけでは、必要な根拠を確実に使えるとは判断できません。Lost in the Middle

これは「短いコンテキストほど必ず高精度」という意味ではありません。モデル、質問の複雑さ、文書構造、検索器、再ランキング器、正解根拠が複数必要かどうかで最適な量は変わります。大切なのは、top-kを一律の定数として固定せず、候補取得・選別・生成を別々に評価することです。

最初に分けるべき2つのtop-k

RAGの「top-k」は、少なくとも次の2つに分けて記録します。

候補top-kは再ランキングやフィルタリングのための母集団、最終top-kは回答根拠としてモデルに読ませる集合です。この2つを同じ値にする必要はありません。LlamaIndexの公式ドキュメントでも、クエリ処理を検索、取得ノードの後処理、応答生成に分け、後処理で再ランキング・変換・フィルタリングを行えると説明しています。LlamaIndex: Querying

改善の優先順位：増やす前に「削る・整える」

候補に正解根拠が存在するのに回答品質が低い場合、Mojiでは次の順番で検証することを提案します。

1. メタデータで候補範囲を絞る
2. 同じ情報源・近接チャンクの重複を減らす
3. 質問に対する関連度で再ランキングする
4. 最終コンテキストを必要最小限に圧縮する
5. それでも候補に根拠がないときだけ候補top-kや検索方式を見直す

この順番は、検索件数を増やす施策を否定するものではありません。正解根拠が候補に入らない「再現率不足」と、候補にはあるのに最終文脈で使えない「選別不足」を混同しないための順序です。RAGの検索・生成を分けて診断する方法は、社内RAGが的外れな回答を返す原因と改善方法でも詳しく解説しています。

1. メタデータフィルタ：検索前に「探す場所」を限定する

部署、対象製品、国・地域、文書種別、版、有効開始日、公開状態、閲覧権限などが質問から特定できるなら、ベクトル検索の候補範囲を絞ります。たとえば「2026年度の経費精算規程」を問う質問であれば、年度・文書種別・有効状態を条件にし、旧規程や他制度の説明を初めから候補外にします。

メタデータフィルタは、単なる表示用の属性ではありません。利用するベクトルストアが対応している場合、検索クエリのフィルタとして使えます。LlamaIndexの公式ドキュメントでも、ベクトルストアごとのメタデータフィルタ対応状況が整理されています。LlamaIndex: Vector Stores

確認項目

• 各チャンクに文書ID、版、有効期間、部署、文書種別、権限などが引き継がれているか。
• 「最新版」「自部門」「日本法人」など、質問から取得できる条件を検索フィルタへ変換できるか。
• フィルタを厳しくしすぎて、正解根拠を除外していないか。
• 版や有効期間が欠ける文書を、回答根拠に使う運用になっていないか。

社内文書を扱う場合、権限フィルタは精度改善だけでなく情報保護の要件です。検索後に回答文だけを隠すのではなく、検索段階で閲覧不可の文書を候補外にする設計を検討してください。社内RAGの権限管理も参照してください。

2. 重複排除：似ているチャンクを全部渡さない

重複には、完全一致だけでなく、同じ見出し配下を分割した隣接チャンク、同一文書の改訂前後、同じ内容を転載したFAQとマニュアルなどがあります。文字列の完全一致削除だけでは不十分です。

Mojiでは、重複排除を次の3層に分けることを提案します。

ただし、似ているから必ず1件にまとめるわけではありません。質問が「制度Aと制度Bの違い」のように比較を求める場合、似た説明でもそれぞれの対象・例外・適用条件を保持する必要があります。重複排除の目的は情報量を減らすことではなく、同じトークン予算で、異なる判断材料を増やすことです。

3. 再ランキング：候補の類似度順を、質問への有用性順へ置き換える

埋め込み検索の上位候補は、意味が近い順であって、必ずしも質問へ直接答える順ではありません。候補top-kを取得した後、質問と各候補の組み合わせをより細かく評価し、最終top-kを選び直すのが再ランキングです。

実装ではクロスエンコーダ、専用reranker、LLMベースの判定器などを使えます。LlamaIndexは、検索結果のノードを取得後に再順序化し、上位N件を返す複数の再ランキング手段を案内しています。LlamaIndex: Node Postprocessor Modules

再ランキング時の採点軸の例（Mojiによる提案）

• 質問へ直接答える記述があるか。
• 対象となる組織・製品・期間・版が質問と一致するか。
• 結論だけでなく、条件・例外・手順を支える根拠を含むか。
• 既に選んだ候補と内容が重複しすぎていないか。
• 一次情報、最新版、管理者が定めた正本など、根拠としての優先度が高いか。

再ランキング器を入れれば必ず改善するわけではありません。質問文と社内用語のずれ、ドメイン不一致、長文チャンク、比較・集計のように複数根拠が必要な質問では、順位付けの基準自体を評価する必要があります。

4. 多様性の確保：関連度だけでなく「すでに選んだ根拠と違うか」を見る

関連度だけで上位を選ぶと、同一文書の連続チャンクが並びやすくなります。そこで、質問への関連度と、既に選択した候補との非類似性を両方見る考え方が有効です。Maximal Marginal Relevance（MMR）は、関連性と選択済み候補との差異を両立させるために使われる代表的な考え方です。

近年のRAG研究では、推論集約的な質問応答を対象に、質問への関連性と候補間の多様性を組み合わせて候補集合を選ぶ設計が提案されています。DF-RAG: Query-Aware Diversity for Retrieval-Augmented Generationは、MMRを基に、質問ごとに多様性の度合いを選ぶ方式を評価しています。この結果は、同論文で扱われた推論集約的な質問応答ベンチマークにおけるものです。

ただし、多様性を強くしすぎると、必要な補足根拠まで落ちます。たとえば規程の本文とその例外条項は似ていても、両方が回答に必要なことがあります。多様性は「異なる文書を機械的に増やす」指標ではなく、質問を正しく答えるために必要な論点が揃っているかを確認する補助指標として扱います。

5. 要約・文脈圧縮：最後に、根拠を失わず短くする

再ランキング後にもチャンクが長すぎる場合は、質問に関係する文・表の行・箇条書きだけを残す文脈圧縮を検討します。これは文書全体を短く要約することとは異なります。RAGでは、圧縮の過程で条件、例外、数値、否定表現、出典位置が落ちると、読みやすくなっても根拠性が下がります。

そのため、Mojiでは次の順序を提案します。

1. 文書・チャンクを選ぶ。
2. 選んだ根拠ごとに、質問に必要な文または構造化項目を抽出する。
3. 抽出片へ文書ID・見出し・版・参照位置を付与する。
4. LLMには抽出片と出典を渡し、根拠にない場合は回答しない、または不足を明示するよう指示する。

LLMへ渡す情報全体の選択・構成は、検索結果に限らない設計課題です。会話履歴、システム指示、ツール結果も含めた考え方は、コンテキストエンジニアリングとはで解説しています。

top-kを増やすべきか判断する診断表

この表はMojiによる実務上の診断基準です。モデル、埋め込み方式、文書の品質、評価指標、許容できる誤りによって結論は変わります。

評価は「最終回答の正しさ」だけで終わらせない

RAGは検索と生成からなるため、最終回答だけでは、検索候補が不足したのか、選別で根拠を落としたのか、根拠があるのに生成で使えなかったのかを判別しにくい構造です。RAG評価では、関連するコンテキストを取得できたか、取得した根拠に忠実な回答か、回答が質問へ適合するかなど、複数の観点を分けて扱う必要があります。Ragas: Automated Evaluation of Retrieval Augmented Generation

以下はMojiによる評価シートの最小テンプレートです。

評価質問と正解根拠の作り方、更新方法は、RAG評価データセットの作り方で確認できます。質問と期待回答だけでなく、「どの根拠が必要か」を明記すると、top-k変更の影響を検索・選別・生成に分けて追跡しやすくなります。

実験の進め方：一度に全部変えない

次の手順はMojiによる提案です。候補数、再ランキング、重複排除、要約を同時に変えると、改善または悪化の原因を特定できません。

1. 評価セットを固定する：日常的な質問、比較質問、例外を含む質問、回答不可にすべき質問を含める。
2. 現状を保存する：質問ごとに候補一覧、候補スコア、最終コンテキスト、回答、引用をログに残す。
3. 候補top-kだけを変える：必須根拠が候補に残る割合と候補数の関係を確認する。
4. 重複排除だけを加える：最終根拠保持を落とさず、重複率とコンテキスト長を下げられるかを見る。
5. 再ランキングだけを加える：必須根拠が最終文脈へ残る割合、論点充足、回答忠実性を比較する。
6. 必要な場合だけ圧縮を加える：圧縮前後で必須条件・例外・数値・出典位置が失われていないかを人が確認する。
7. 採用条件を決める：正答率だけでなく、許容できない誤答、回答不可時の挙動、遅延、コストも含めて選ぶ。

たとえば、候補top-kを増やすことで候補根拠保持は改善しても、最終根拠保持や回答忠実性が悪化するなら、課題は検索量ではなく選別工程にある可能性があります。反対に、どの設定でも候補根拠保持が低いなら、検索クエリ、チャンク、メタデータ、索引方式を見直す段階です。

よくある誤解

「ロングコンテキストモデルなら、全部入れてよい」

入力上限が大きいことと、長い入力内の各根拠を同じ精度で使えることは別です。関連情報の位置や長さによる性能差が報告されているため、長い文書を扱えるモデルでも、必要根拠を選び、配置と引用を評価してください。Lost in the Middle

「再ランキング器を入れればtop-kは考えなくてよい」

再ランキング器は候補集合にない根拠を復元できません。候補top-kが小さすぎれば選び直す対象がなく、逆に候補が大きすぎれば遅延・費用・誤順位の影響が増える場合があります。

「要約すればノイズ問題は解決する」

要約は、不要な情報を減らせる一方で、例外・否定・数値・版情報を落とすリスクもあります。正解根拠の選別前に文書全体を要約するより、根拠選別後に質問へ必要な箇所を抽出し、出典を保持する方が検証しやすくなります。

導入前・改善前チェックリスト

• 候補top-kと最終top-kを別の設定値・ログ項目として管理している。
• 質問ごとに、候補一覧と最終コンテキストの両方を確認できる。
• 文書ID、版、有効期間、文書種別、部署、権限などのメタデータがある。
• 同一文書・隣接チャンク・類似内容の重複を検出できる。
• 再ランキング後に、必須根拠が残るかを評価している。
• 比較・例外・複数条件を含む質問では、論点ごとに必要根拠を定義している。
• 要約・圧縮後も、条件・例外・数値・出典位置を確認している。
• モデル、入力品質、評価指標、許容誤差が変われば結論も変わる前提で、変更を一つずつ比較している。

まとめ

RAGの精度が落ちたとき、検索件数を増やすことが正解とは限りません。候補に正解根拠がないなら検索範囲や候補top-kを見直し、候補にあるのに回答が悪いなら、メタデータフィルタ、重複排除、再ランキング、文脈圧縮を優先して検証します。

目指すのは「最も多くの文書を渡すこと」ではなく、質問へ答えるために必要で、版・適用範囲・根拠が明確な情報だけを、モデルが使える形で渡すことです。RAG全体の適用判断や導入・評価の流れは、RAG（検索拡張生成）とは？もあわせて確認してください。