社内RAGが的外れな回答を返す原因と改善方法｜検索・チャンク・抽出・評価の切り分け

社内RAGの回答精度が低いとき、最初に疑うべきはLLMそのものではありません。PDFから原文を正しく取れていない、見出しや表の関係を失ったまま分割している、必要なチャンクが検索候補に入っていない、候補にはあるが最終コンテキストから落ちている、根拠があるのに回答で使えていない、といった異なる失敗が同じ「的外れな回答」として見えていることが多いためです。

RAGは、外部メモリを検索し、その情報を使って生成する枠組みです。原論文でも、生成モデルと検索でアクセスする非パラメトリックなメモリを組み合わせています。したがって、最終回答だけで良し悪しを判定すると、検索の問題と生成の問題を混同します。RAG原論文

結論：モデルや埋め込みモデルを入れ替える前に、同じ質問に対して「原文」「抽出結果」「検索候補」「LLMへ渡した文脈」「最終回答」を横に並べてください。正解根拠が最初に消えた地点が、優先して直す箇所です。

本記事の診断フロー、優先順位、ログ設計、テンプレートはMojiによる実務上の提案です。RAGの基本的な仕組みや導入時の設計論は、RAG（検索拡張生成）とは？向く業務・他方式との違い・導入から評価までの実践ガイドを先に確認してください。

まずは6層に分ける：社内RAGの回答が悪くなる場所

回答品質を一つのスコアで扱わず、次の6層に分けます。RAGCheckerは、検索モジュールと生成モジュールを対象にした細粒度の診断指標を提案しており、RAGをモジュール別に評価する必要性を示しています。RAGCheckerの原論文

30分で行う診断フロー

以下は、障害が発生した質問を1件ずつ再現して原因を絞るための手順です。まずは「回答が悪かった」という印象ではなく、検証可能な問いに変えます。

1. 失敗質問を固定する。 本番ログから、回答が不正確だった質問を選びます。質問を後から言い換えず、ユーザー入力をそのまま保存します。
2. 正解根拠を人が特定する。 元文書のページ、見出し、段落、表の行・列、改訂日を記録します。複数資料が必要なら、すべて列挙します。
3. 抽出結果で根拠を探す。 元PDFにはあるのに抽出テキストにない、または値・列・対象期間が変わっているなら、検索以前の問題です。
4. チャンクを確認する。 正解根拠が含まれるチャンクに、問いの意味を保つ見出し、期間、単位、表ヘッダーが残っているか確認します。
5. 検索候補を確認する。 正解チャンクが設定した候補数内にあるかを見ます。なければ検索、あれば次工程を確認します。
6. 最終コンテキストを確認する。 正解チャンクが候補にあっても、再ランキング、重複除去、トークン上限、アクセス権フィルタで除外される場合があります。
7. 回答と根拠を照合する。 根拠が最終コンテキストに存在するのに回答が誤るなら、回答生成または抽出指示の問題です。
8. 失敗ラベルを一つ以上付ける。 例：OCR_TABLE_ALIGNMENT、CHUNK_HEADER_LOSS、RETRIEVAL_MISS、RERANK_DROP、UNSUPPORTED_ANSWER。

この順番にする理由は単純です。検索モデルを変えても、そもそも原文にない文字列、表ヘッダーを失ったチャンク、LLMに渡していない根拠は取り戻せないためです。

症状別：どこを疑うか、何を直すか

症状1：元PDFでは読めるのに、RAGが数値や表の意味を取り違える

有価証券報告書、中期経営計画、規程集では、表の列見出し、単位、対象期間、脚注が数値と同じくらい重要です。抽出テキストで「1,200」という値だけを保存しても、「何年度の何を、どの単位で示すか」が失われれば正しい回答はできません。

複雑な文書のRAG前処理では、表・図・見出しを含むレイアウトを保持することが重要です。Google CloudのDocument AI Layout Parserは、表、図、見出しを識別し、祖先見出しや表ヘッダーを含む文脈対応チャンクを作る設計を案内しています。また、財務報告書の複雑な表はRAGの失敗点になりやすいと明記しています。Google Cloud Document AI：Layout Parser

確認チェックリスト

• 元PDFと抽出結果で、表の列数・行数・ヘッダー・単位・脚注を比較したか
• ページをまたぐ表を、別の無関係な表として扱っていないか
• 「当期」「前期」「計画」「実績」などの列名がセルと同じチャンクにあるか
• 画像化されたグラフや注記が、必要な場合に説明文または構造化データとして残っているか
• ページ番号、文書名、版・改訂日をメタデータとして保存しているか

改善の判断基準：人が元文書を見て正解を確定できるのに、抽出テキスト上で同じ事実を再現できなければ、OCR・パーサー・構造化の改善を最優先します。チャンク長や検索アルゴリズムの調整はその後です。OCRの仕組みと業務上の確認観点は、AIOCR（画像文字認識）の開発方法や費用についても参照してください。

症状2：必要な段落は取れているが、見出し・条件・対象期間が抜ける

固定文字数だけで分割すると、見出しと本文、表ヘッダーとセル、例外規定と本文が分離しやすくなります。チャンクは「短いほどよい」「長いほどよい」と一律には決められません。埋め込みモデル、質問の粒度、文書構造、LLMに渡せる文脈量、許容できる誤り方によって変わります。

Azure AI Searchは、チャンク化が埋め込み・チャットモデルの入力制限への対応だけでなく、単一ベクトルでは表現しにくい内容の検索や、類似検索の精度に役立つと説明しています。さらに、分割時に小さな重複を持たせて文脈を保つ方法にも触れています。Azure AI Search：Chunk Documents

Mojiによる設計提案：チャンク本文だけでなく、次の情報を一緒に検索・投入できる形で持ちます。

• document_title：文書名
• section_path：大見出し > 中見出し > 小見出し
• page_range：ページ範囲
• effective_date：施行日・改訂日
• table_header：表ヘッダー、単位、注記
• parent_chunk_id：前後を再取得するための親ID
• access_scope：検索前に適用する権限情報

たとえば規程なら「原則」だけでなく「適用対象」「例外」「施行日」を近接した状態で扱えるか、有報なら「数値」「年度」「単位」「注記」を同時に回答文脈へ渡せるかを評価します。

症状3：正解文書は登録済みなのに、検索上位に出てこない

この症状では、最終回答を読む前に検索候補だけを評価します。正解チャンクが候補にないなら、回答プロンプトを改善しても根本解決にはなりません。

検索語と文書語が異なる社内文書では、ベクトル検索だけ、キーワード検索だけのどちらかに固定するより、両方を比較対象にする価値があります。Azure AI Searchは、キーワード検索とベクトル検索を同時に行うハイブリッド検索を、再現率を高めるための方法として案内し、必要に応じてセマンティックランキングやスコア調整を組み合わせる設計を示しています。Azure AI Search：RAG and Generative AI

検索の切り分け順：

1. 文書名・固有の制度名・年度を含むキーワード検索で正解根拠が出るか
2. 質問文そのままのベクトル検索で正解根拠が出るか
3. 両者を組み合わせた検索で順位が改善するか
4. 部門、文書種別、公開状態、対象年度などのメタデータフィルタで誤った母集団を除けるか
5. 略称、旧称、社内用語、製品名の表記揺れを同義語として扱う必要があるか

判断基準：正解根拠が候補数内に入らない質問が多い場合は、埋め込みモデルを替える前に、検索対象のテキスト、メタデータ、クエリ、検索方式を比較します。一方、候補数内に安定して入っているなら、問題は再ランキング以降にあります。

症状4：検索候補には正解があるのに、回答で使われない

初期候補の上位に正解根拠があっても、再ランキング、重複除去、コンテキストのトークン上限、アクセス権の後段適用、候補の並び順によって最終投入から落ちることがあります。ベクトル検索の結果をLLMへ渡すRAGでは、人間が読めるテキストとベクトルを併存させ、親文書・チャンクIDなどを保持する設計が重要です。Azure AI Search：Vector Index Overview

見るべきログ

改善の優先順位：候補にある正解を落としているなら、検索器の入れ替えよりも先に、再ランキング前後の順位変化と文脈の選択規則を直します。候補をただ増やすと、無関係な文脈も増え、生成時の判断が難しくなる場合があります。候補数、再ランキング対象数、最終投入数は、自社の評価セットで比較してください。

症状5：根拠を渡しているのに、LLMが条件や数値を誤る

ここで初めて、回答生成を主な対象にします。根拠が最終コンテキストにあり、かつ人間がその根拠だけで答えられるなら、モデル、プロンプト、回答形式、引用ルール、文脈の提示順が候補です。

Mojiによる回答設計の提案

• 回答本文の各主張に、チャンクIDまたは出典表示を対応させる
• 数値には「値・単位・対象期間・対象範囲」をセットで出すよう求める
• 複数文書で条件が異なるときは、統合せず差分を示すよう求める
• 根拠が足りない場合は推測で補わず、「資料内で確認できない」と返す分岐を置く
• 表に基づく回答は、行名・列名・単位・ページを明示する形式にする

ただし、プロンプトだけで常に改善できるわけではありません。見出し・条件・表ヘッダーが文脈にない場合、モデルに「正確に答えて」と指示しても不足情報を補うことはできません。また、モデル、入力品質、評価指標、許容誤差によって最適な形式は変わります。たとえば、要約の読みやすさを優先する業務と、監査向けに数値を一字一句照合する業務では、同じ回答形式を採用すべきとは限りません。

改善の優先順位を決める判定表

次の表は、改善候補を比較するためのMojiによる設計上の目安です。点数の絶対値ではなく、どの層が最初に失敗するかで優先順位を決めます。

評価データは「質問と正解回答」だけで作らない

RAGの評価セットに期待回答だけを置くと、最終回答が悪い理由を検索と生成に分けられません。少なくとも「どの根拠を取得すべきか」も持たせます。RAGCheckerも、検索と生成を分けて診断する指標群を提案しています。RAGCheckerの原論文

評価セットの作り方と更新方法は、RAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説で詳しく解説しています。

Mojiによる最小レコード案

question_id: FIN-014
question: （架空の例）2025年度の設備投資計画はいくらですか？
expected_answer: （架空の例）1,200億円。対象は連結ベース、2025年度計画。
required_evidence:
  - document_id: annual-report-2025
    page: 42
    section: 設備投資計画
    required_terms: ["1,200", "億円", "2025年度", "連結"]
allowed_sources: [annual-report-2025]
error_tolerance: 数値・単位・年度・対象範囲はいずれも一致必須
failure_labels: []

上記は架空の例です。実際には、業務ごとに許容誤差を決めます。FAQの案内なら表現ゆれを許容できても、契約条件、会計数値、人事規程では、単位・版・適用日・例外の不一致を不合格にする必要があります。

最低限、分けて追う指標

• 根拠到達率：正解に必要なチャンクが検索候補内に入った質問の割合
• 根拠採用率：候補にあった必要根拠が、最終コンテキストにも入った割合
• 根拠忠実性：回答の主張が最終コンテキストで裏付けられる割合
• 回答充足率：期待した数値、期間、対象、条件を過不足なく回答できた割合
• 回答不能の適切さ：根拠不足時に推測せず保留・案内できた割合
• 文書群別の失敗率：規程、議事録、PDF表、有報、FAQなど文書種別ごとの失敗傾向

これらの指標の目標値は一律に決めません。モデル、入力品質、質問の難易度、回答の用途、許容できる誤りによって変わります。たとえば、検索候補に正解が入ることを優先する段階と、外部送信前の回答で根拠忠実性を厳しく求める段階では、採用する閾値が異なります。

再現用の確認ログ・質問テンプレート

本番で問題を見つけた担当者が、エンジニアへ「精度が悪い」とだけ渡しても調査が長引きます。以下のテンプレートをチケットやスプレッドシートに残すと、再現と比較がしやすくなります。これはMojiによる提案です。

■ 問題報告テンプレート
- 質問原文：
- 回答日時：
- ユーザー権限・部署：
- 実際の回答：
- 期待する回答：
- 正解根拠：文書名 / 版 / ページ / 見出し / 表の行・列
- 誤りの種類：数値 / 単位 / 期間 / 対象範囲 / 条件 / 出典なし / 回答不能にすべき

■ システム確認ログ
- 原文抽出結果の該当箇所：
- チャンクIDと本文：
- 初期検索候補（順位・スコア・検索方式）：
- 再ランキング後の候補：
- LLMに渡した最終コンテキスト：
- 使用モデル・埋め込みモデル・インデックス版：
- 失敗ラベル：
- 改善案と再評価結果：

改善を本番へ入れる前のチェックリスト

• 同じ失敗質問で、元文書から期待根拠を人が明示できる
• 抽出結果に、期待根拠の文字・数値・表構造が残っている
• チャンク単体で読んでも、見出し、期間、単位、例外が分かる
• 初期検索候補と最終コンテキストの両方を保存している
• アクセス権フィルタを検索後ではなく、設計した位置で検証している
• 回答の各主張を、投入した根拠に対応付けられる
• 根拠がないときの回答不能・確認依頼の振る舞いをテストした
• 文書種別・難易度・失敗タイプが偏らない評価セットを用意した
• 変更前後を同一の評価セット、同一の判定基準、同一の許容誤差で比較した
• 改善内容、対象インデックス、モデル、評価結果を版として記録した

まとめ：モデル変更は「どこで根拠が消えたか」を確認してから

社内RAGの的外れな回答は、検索精度だけの問題ではありません。特に有価証券報告書、中期経営計画、規程、スキャンPDFのように構造が重要な資料では、抽出・表構造・チャンクが検索以前の品質上限になります。

改善の順番は、元文書 → 抽出結果 → チャンク → 検索候補 → 最終コンテキスト → 回答です。正解根拠が最初に消える場所を特定し、そこだけを変え、固定評価セットで再確認してください。RAGの評価を、最終回答の印象ではなく検索と生成の両面から継続的に行う考え方は、AIの評価とは？評価指標や評価方法、その費用についても参考になります。