RAGが答えられないとき、最初に疑うべきはLLMではなく検索です
木村 優志
Published: 8/9/2026, 4:30:00 AM
「社内文書をRAGに入れたのに、質問へうまく答えられない。もっと性能の高いLLMに替えるべきでしょうか」
RAGの導入では、よくある相談です。しかし、モデルを替える前に確認したいことがあります。その質問に答えるための根拠が、実際にLLMへ渡っているかです。
RAGでは、LLMが社内文書全体を読んでから回答するわけではありません。質問に対して検索した一部の文書断片（チャンク）をコンテキストとして渡し、LLMはその範囲をもとに回答を作ります。必要な断片を取得できなければ、どれほど高性能なモデルでも正しい回答は難しくなります。
もちろん、指示文、コンテキストの長さ、モデルの推論性能、回答の制約が原因になる場合もあります。それでも、「知識は登録したはずなのに答えられない」問題では、まず検索結果を確認するのが合理的です。
RAGを、図書館の流れとして考える
RAGは、概ね次の流れで動きます。
原本の管理 → 抽出・分割 → 索引化 → 検索 → 関連チャンクをLLMへ渡す → 回答LLMは、質問を受けて図書館の棚を自由に歩き回る担当者ではありません。検索システムが渡した数ページの資料を読み、回答を書く担当者です。
たとえば、社内規程の「出張費精算」の質問に対して、検索が「休暇申請」や「経費システムの操作手順」だけを渡したとします。この場合、LLMが「規程には記載がありません」と回答したとしても、必ずしもモデルの知識不足や能力不足とはいえません。必要なページが最初から渡されていないからです。
調査の最初の一歩は、回答ではなく検索結果の上位数件を見ることです。質問、返ってきたチャンク、元文書のタイトル、見出し、更新日、検索スコアを並べるだけで、問題の場所が見えてくることがあります。
RAGを改善する前に、データを管理する
検索方式やチャンクサイズを工夫しても、元の文書が古い、重複している、誰が更新するのか分からない状態では、RAGの品質は安定しません。RAGは、散らかったファイル置き場を自動的に正しい知識ベースへ変換する仕組みではありません。
たとえば、同じ制度について「2024年版」「2025年改定版」「最終版」「最終版_修正」のような複数ファイルが残っているとします。どれが正本か分からなければ、検索は古い文書ももっともらしい候補として返します。LLMは文書の正しさを保証できないため、検索結果に含まれた古い情報を根拠に回答してしまうおそれがあります。
RAGへ投入する前に、少なくとも次の項目を決めます。
- 正本はどれか：文書ごとに、業務上の責任者と参照すべき正式な保管場所を決める
- いつ有効か：公開日、更新日、版数、有効開始日・終了日を記録する
- 誰が見てよいか：部門、役割、顧客、プロジェクトごとのアクセス権を定義する
- いつ索引を更新するか：文書の追加・更新・削除を、検索インデックスへ反映する運用を決める
- 何を投入しないか：個人情報、機密情報、下書き、重複資料、期限切れ資料の扱いを決める
特に重要なのは、原本を更新してもRAGの索引が更新されなければ、利用者は古い知識を検索し続けることです。文書管理システムと検索インデックスの同期、更新失敗の監視、削除済み文書の検索除外を、RAGの機能ではなくデータ運用の責任として扱います。
また、アクセス制御は回答生成の後ではなく検索時に適用します。閲覧権限のない資料を検索してからLLMへ渡し、最後に表示だけを隠す設計では、プロンプトやログを経由した情報露出のリスクが残ります。利用者の権限に応じて、検索対象そのものを絞り込むことが必要です。
失敗の多くは、LLMの前に起きている
1. 文書が正しく取り込まれていない
PDF、表、スキャン画像、複数段組の文書は、テキスト抽出の時点で崩れることがあります。表の列が混ざる、脚注が本文へ入り込む、見出しが消える、画像内の文字が抽出されない、といった問題です。
検索用のテキストが壊れていれば、埋め込みモデルや検索方式を変更しても改善しません。まず、索引に入る前後のテキストを確認します。特に、質問に答えられるはずの原文が、実際にどのような文字列として取り込まれているかを見る必要があります。
2. チャンクの分け方が文書構造を壊している
RAGでは通常、長い文書を小さなチャンクへ分割して検索します。チャンクが大きすぎると、関係のない情報が混ざり、検索精度とLLMへ渡す情報量の両方が悪化します。小さすぎると、主語、条件、例外、表の見出しなど、回答に必要な文脈が分断されます。
固定文字数で機械的に分けるだけでなく、見出し、段落、箇条書き、表といった文書構造をできるだけ保つことが重要です。MicrosoftのRAG設計ガイドでも、意味的に関連する内容を含むチャンクに分割すること、文書の構造に応じた分割方法を選ぶことが重要だと説明されています。
「出張費精算は経理規程の第3章」のような見出し、文書名、版数、更新日を各チャンクと一緒に持たせると、検索と引用の両方で役立ちます。
3. ベクトル検索だけでは、固有名詞や番号に弱いことがある
ベクトル検索は、「休暇の取り方」と「有給休暇の申請」のような意味の近さを扱うのに有効です。一方で、製品型番、契約番号、エラーコード、規程番号、固有の略語など、文字列が完全一致することに意味がある質問では、キーワード検索の方が強い場合があります。
そのため、実務ではベクトル検索だけに頼らず、キーワード検索と組み合わせるハイブリッド検索を検討します。検索結果を統合して再ランキングすることで、意味の近さと用語の一致を両方扱いやすくなります。
ただし、ハイブリッド検索は万能ではありません。どの質問群で改善したか、逆に悪化したかを評価セットで確認し、重みや再ランキングの設定を調整します。
4. 検索件数、フィルター、更新日の扱いが合っていない
検索で上位3件だけをLLMへ渡している場合、必要な根拠が4件目以降にあるかもしれません。反対に、数十件を無差別に渡すと、関係のない情報が増え、LLMが重要な条件を見落としやすくなります。
また、部門、製品、地域、権限、文書の有効期間によるフィルターも重要です。現行版ではない規程が上位に出れば、もっともらしいが誤った回答になります。各チャンクには、少なくとも文書ID、タイトル、見出し、更新日、版数、対象組織、アクセス権を持たせ、検索時に使えるようにします。
5. 正しい資料は取れているが、LLMに使わせていない
検索結果に正しい根拠が含まれていても、LLMへの指示が「一般知識で自由に答えてよい」状態なら、資料を十分に使わないことがあります。
回答のプロンプトには、少なくとも次の方針を明示します。
- 回答は与えられた資料を優先する
- 資料に根拠がないときは、推測せず「確認できない」と答える
- 参照した文書名や見出しを示す
- 質問の対象外の情報を補わない
これは検索の問題ではありませんが、検索・生成を分けて確認しなければ、どちらが原因か判別できません。
「回答が悪い」ではなく、検索のどこで落ちたかを測る
RAGを改善するとき、最終回答の印象だけで判断すると、原因が混ざります。評価セットを用意し、質問ごとに「正しい回答に必要な根拠チャンク」を定義します。
次に、少なくとも二つの指標を分けて確認します。
- 検索の再現率（recall）：必要な根拠が検索結果の上位
k件に入っているか - 回答の忠実性・正確性：取得した根拠に沿って回答しているか。根拠のない内容を加えていないか
検索の再現率が低ければ、分割、抽出、メタデータ、検索方式、フィルター、検索件数を疑います。検索の再現率が高いのに回答品質が低ければ、プロンプト、コンテキストの並べ方、モデル、出力形式を見直します。
この切り分けがないままモデルだけを変更すると、原因が残ったままコストだけが上がることがあります。
改善は、次の順序で進める
- 質問と検索結果をログに残す
個人情報や機密情報を適切にマスキングしたうえで、質問、検索されたチャンク、スコア、フィルター、最終回答を記録します。 - 答えられなかった質問を評価セットへ追加する
運用中の失敗例こそ、次の改善に最も役立つテストケースです。 - 正解の根拠が上位に出るかを見る
回答の文面を直す前に、必要な資料が検索されているか確認します。 - 一度に一つの要素を変える
チャンクサイズ、オーバーラップ、メタデータ、検索方式、検索件数、プロンプトを同時に変更すると、効果の理由が分かりません。 - 回答品質と検索品質を分けて再評価する
改善後も、質問群ごとに悪化していないか確認します。
お客さまへ説明するときのポイント
RAGの課題を説明するとき、「AIの精度が悪い」とだけ伝えると、モデルを高性能なものへ替えれば解決するように聞こえます。
代わりに、次のように説明すると役割分担が伝わりやすくなります。
RAGは、資料を探す仕組みと、資料を読んで答える仕組みの組み合わせです。
いま確認すべきなのは、回答役のAIそのものより、必要な資料を正しく渡せているかです。
まず検索結果を評価し、必要な資料が取れている状態を作ってから、回答の表現やモデルを改善します。
この順序なら、モデルの比較だけでなく、社内文書の管理、更新フロー、検索品質の評価にも目を向けられます。
まとめ
RAGが答えられないとき、LLMはしばしば最後の工程にすぎません。最初に確認すべきは、質問に必要な根拠を検索で取得し、LLMへ渡せているかです。
文書の抽出、チャンクの分割、メタデータ、キーワードとベクトルの使い分け、検索件数、版管理、評価セットを整えることで、モデルを替えずに改善できるケースは少なくありません。RAGの品質は、生成モデルだけでなく、情報検索の設計で決まります。
