RAGの精度が上がらない7つの原因｜社内文書検索を改善する実務チェックリスト

社内規程やマニュアルを読ませたRAGを作ったのに、実際に使うと「惜しいけれど違う」「古い文書を根拠にする」「欲しい箇所を拾えていない」という状態になることがあります。

結論から言えば、RAGの精度が悪いときに、最初からLLMを高性能モデルへ替えるのは遠回りになりやすいです。

先に確認すべきなのは、次の4段階です。

正しい情報が知識ベースに入っているか
質問に対して正しい文書・chunkを検索できているか
取得した根拠をAIが正しく使えているか
本番利用で権限・鮮度・例外処理まで維持できているか

RAGは「検索」と「生成」を組み合わせた仕組みです。検索段階で間違った情報を渡せば、AIがその情報に忠実でも回答は間違います。反対に、正しい根拠を取得できているのに回答がずれるなら、生成側の指示や評価方法を疑うべきです。

Google CloudもRAGの品質ではretrieval mechanismが重要であり、取得情報が不適切なら、生成結果が根拠付きでも質問に合わない可能性があると説明しています。また、検索設定、データ整理、レイアウト解析、chunking、質問の改善などを評価指標に基づいて調整する考え方を示しています。

参考：Google Cloud – What is Retrieval-Augmented Generation (RAG)?

この記事では、RAGの精度が上がらない原因を7つに分け、社内FAQや社内検索で何をどの順番で直すべきかを実務向けに整理します。

まず切り分ける：検索が悪いのか、生成が悪いのか

RAG改善で最初にやるべきことは、回答だけを見て「精度が悪い」と判断しないことです。

1問ごとに、最低でも次の3つを保存して確認します。

ユーザーの質問
検索で取得した上位文書・chunk
最終回答

この3点を並べると、失敗を大きく2種類に分けられます。

パターンA：正しい根拠を検索できていない

たとえば「育児休業中の社会保険料」を聞いたのに、検索上位に出てくるのが「介護休業」や古い福利厚生資料なら、生成モデルを替えても根本解決にはなりません。

この場合は、文書品質、chunking、embedding、keyword search、metadata、rerankingなど検索側を改善します。

パターンB：正しい根拠は取れているのに回答が間違う

検索結果には正しい就業規則が入っているのに、回答で条件を省略したり、根拠にない例外を補ったりするケースです。

この場合は、プロンプト、回答フォーマット、引用方法、回答拒否ルール、モデル選択など生成側を改善します。

Microsoft LearnのRAG解説でも、RAGをretrieval、augmentation、generationだけで終わらせず、evaluationとmonitoringを含めて品質・コスト・レイテンシを確認することが重要とされています。

参考：Microsoft Learn – RAG on Azure Databricks

原因1：検索対象の社内文書そのものが整理されていない

RAGは、間違った資料を正しい資料に変えてくれる仕組みではありません。

知識ベースに次のような状態があると、検索精度以前に回答品質が安定しません。

旧版と新版が両方残っている
同じ制度を複数部署が別表現で説明している
正式文書と個人メモが区別されていない
更新日がない
文書オーナーが不明
PDFの表や見出し構造が崩れている
重要なルールが口頭運用だけで文書化されていない

改善する順番

まず「AIが読む文書」ではなく、会社として正とする情報源を決めます。

最低限、各文書に次の情報を持たせます。

項目	例
文書名	経費精算規程
正式版か	official / reference
所管部署	経理部
更新日	2026-08-01
有効開始日	2026-09-01
旧版扱い	廃止 / 参照不可
対象者	全社員 / 管理職のみ

RAGのデータパイプラインでは、モデルに入れる前のデータ品質が検索結果を左右します。AWSのRAGガイダンスも、本番RAGを単なるLLM呼び出しではなく、データ取り込み、検索、生成など複数コンポーネントを持つシステムとして扱っています。

参考：AWS Prescriptive Guidance – What is retrieval-augmented generation?

原因2：文書の分割方法（chunking）が質問単位と合っていない

RAGでは、長い文書をそのまま検索するのではなく、一定の単位に分割して検索対象にすることが一般的です。

この分割単位が悪いと、必要な情報が途中で切れます。

たとえば規程に、

対象者
申請期限
承認者
例外条件

が連続して書かれているのに、chunkが細かすぎると「申請期限」だけ取得し、「誰が対象か」が落ちることがあります。

反対にchunkが大きすぎると、1つのchunkに複数制度が混ざり、検索結果に余計な情報が増えます。

改善ポイント

見出し単位で分割できる文書は構造を活用する
表の行と見出しを切り離さない
前後文脈が必要な場合は適度なoverlapを持たせる
PDFページ番号だけを基準に分割しない
FAQは「質問＋回答」を1単位として扱う
規程は「条・項」と見出しの関係を保持する

Google CloudのRAG Engineでも、文書取り込み時にchunk sizeやchunk overlapを調整できる設計が提供されており、文書タイプに応じて分割戦略を調整する必要があります。

参考：Google Cloud – Vertex AI RAG Engine

原因3：ユーザーの言葉と社内文書の言葉が一致していない

社内検索では、ユーザーが正式名称で質問するとは限りません。

たとえば文書には「時間外勤務申請」と書いてあっても、社員は、

残業申請
残業の事前承認
何時から申請が必要？
上司の許可いる？

のように聞きます。

ベクトル検索だけで吸収できる場合もありますが、社内略語、製品名、部署固有語、似た制度名が多い環境では検索ミスが残ります。

有効な打ち手

query rewriting：検索前に質問を検索向けに言い換える
同義語辞書：社内略語と正式名称を対応付ける
hybrid search：semantic searchとkeyword searchを併用する
reranking：一次検索後に関連度を再評価する

Google Cloudは、semantic searchとkeyword searchを組み合わせるhybrid searchや、検索結果を再スコアするrerankerをRAG品質改善の手段として説明しています。

検索方式を1つに固定するより、質問の種類に応じて検索の弱点を補うほうが実務では安定します。

原因4：top-kや類似度thresholdを勘で決めている

検索結果を何件LLMへ渡すかは、RAGの品質とコストの両方に影響します。

少なすぎると必要文書を落とし、多すぎると関係ない文書が混ざります。

ありがちな設定は「とりあえずtop 5」「類似度0.7以上」のように固定することですが、数字だけ先に決めても意味はありません。

評価用質問で比較する

たとえば50問の評価セットを作り、次の設定を比較します。

設定	正しい根拠がtop-k内に入った率	不要文書の混入	回答品質	レイテンシ
top-k=3
top-k=5
top-k=10
hybrid + rerank

ここで見るべきは「最終回答がなんとなく良かったか」だけではありません。

正しい文書を検索できたかを検索段階で評価することが重要です。

MicrosoftのRAG評価ドキュメントでも、retrieval品質を回答生成と分けて評価し、取得文書の関連度を測る考え方が示されています。

参考：Microsoft Foundry – RAG evaluators

原因5：鮮度・権限・正式度を検索ランキングに入れていない

意味的に近い文書が、業務上もっとも正しい文書とは限りません。

たとえば、

2024年の旧規程
2026年の正式規程
部門内の補足メモ

が同じテーマで存在すると、意味だけでは旧版を拾う可能性があります。

そこで、検索時にmetadataを使います。

metadataの例

effective_date
updated_at
owner_department
document_type
official=true/false
security_level
region
employee_type

権限は検索時点で絞る

特に重要なのがアクセス制御です。

回答を生成した後で機密部分を消すのではなく、そのユーザーが閲覧できない文書を最初からretrieval対象にしない設計が基本です。

RAGのvector/embedding基盤について、OWASPはアクセス制御の不整合による情報漏えい、cross-context leak、data poisoningなどを代表的リスクとして挙げています。

参考：OWASP GenAI – LLM08:2025 Vector and Embedding Weaknesses

社内利用ルールやデータ分類が未整備なら、RAGの技術調整だけを先に進めず、生成AIの社内利用ルールの作り方もあわせて整備してください。

原因6：正しい根拠を取れているのに、AIが勝手に補っている

retrievalは正しいのに回答が間違う場合、生成側の制約を見直します。

ありがちな問題は次の通りです。

根拠にない一般知識を補う
複数文書の条件を混ぜる
例外条件を省略する
情報不足なのに断定する
出典を表示しない

回答ルールの例

生成プロンプトでは、単に「以下を参考に回答してください」より、業務上の制約を明示します。

取得した根拠に含まれる情報を優先する
根拠にない条件を推測で追加しない
必要情報が不足する場合は回答不能とする
制度・数値・期限には出典を付ける
文書間で矛盾したら新しい正式文書を優先し、矛盾を明示する
個別判断が必要なケースは担当部署へエスカレーションする

RAGはハルシネーションをゼロにする技術ではありません。

OWASPも、RAGやfine-tuningを使ってもprompt injectionのリスクが完全にはなくならないと説明しています。外部文書や利用者が編集できる文書を知識ベースへ入れる場合は、取得コンテンツ自体を信頼しすぎない設計が必要です。

参考：OWASP GenAI – LLM01:2025 Prompt Injection

原因7：評価データセットがなく、改善が「体感」になっている

RAG改善で最も危険なのは、10問ほど手で試して「良くなった気がする」で本番投入することです。

本番では、開発者が想定していない質問が来ます。

そのため、実際の業務質問をもとに評価セットを作ります。

最初の評価セットは30〜100問でよい

質問を次のタイプに分けます。

単一文書で答えられる基本質問
言い換え・略語を含む質問
複数条件がある質問
最新版を選ぶ必要がある質問
回答してはいけない権限外質問
情報が存在しない質問
個別判断が必要で人へ回す質問

重要なのは、正答だけでなく「正しく答えない」ケースも含めることです。

評価シート例

ID	質問	正しい根拠	期待回答	回答不可か	権限条件
Q01	残業申請はいつまで？	就業規則 8-2	事前申請	No	全社員
Q02	役員報酬を教えて	なし	回答不可	Yes	権限外
Q03	旧制度と新制度の違い	新旧規程	差分説明	No	全社員

設定を変えるたび、この同じ評価セットを再実行します。

これで「モデルを変えたら良くなった」ではなく、「検索recallは上がったが、レイテンシが増えた」のように比較できます。

RAGで最低限持ちたい評価指標

RAGの評価は1つの「正答率」にまとめないほうが改善しやすくなります。

1. Retrieval品質

正しい根拠がtop-kに含まれた率
上位文書のrelevance
不要文書の混入率
旧版を取得した率

2. Answer品質

factual correctness
groundedness / faithfulness
必須条件の網羅性
引用・出典の正しさ
回答不可にすべき質問を断れた率

3. 運用品質

応答時間
1回答あたりコスト
no-answer率
人へのエスカレーション率
ユーザー再質問率
重大な誤回答件数

Google CloudのRAG解説でも、coherence、groundedness、safety、question answering qualityなど複数の評価観点を使い、評価値を起点に検索・データ・chunking等を改善する方法が紹介されています。

精度改善はこの順番でやる

RAGの設定項目は多いため、同時に全部変えると原因がわからなくなります。

実務では次の順番が安全です。

Step 1：失敗質問を分類する

まず20〜50件の失敗を、

文書不足
retrieval失敗
generation失敗
権限・鮮度問題
質問自体が対象外

に分けます。

Step 2：文書を直す

旧版、重複、解析しにくいPDF、タイトル不足を整理します。

Step 3：chunkingを直す

情報が途中で切れているケースを優先します。

Step 4：検索を直す

query rewriting、hybrid search、filter、top-k、threshold、rerankingを評価セットで比較します。

Step 5：生成制約を直す

正しい根拠が取れた質問だけを対象に、groundingと回答拒否ルールを調整します。

Step 6：本番ログで監視する

評価セットだけでなく、本番質問で新しい失敗パターンを収集します。

この順番なら「高いモデルへ替えたのに改善しない」という無駄を減らせます。

生成AI全体をPoCから本番へ進める条件を整理したい場合は、生成AIのPoCが本番導入で止まる7つの理由も参考になります。

典型的な症状から原因を逆引きする

症状	最初に疑う場所	代表的な打ち手
欲しい文書が検索結果にない	retrieval	hybrid search、query rewriting、metadata
旧版を答える	data / metadata	廃止処理、effective_date filter
回答の条件が欠ける	chunking / generation	見出し単位chunk、回答フォーマット
根拠は正しいのに結論が違う	generation	grounding指示、モデル評価
質問表現を変えると弱い	retrieval	同義語、query rewriting
機密情報を拾う	access control	retrieval前の権限制御
わからないのに断定する	generation	abstention、confidence条件
一部ユーザーだけ精度が悪い	corpus / permission	部門別文書・権限の確認

この表を使うと、最初から「embeddingモデルを交換する」「LLMを大型化する」といった大きな変更をせずに済みます。

社内FAQなら「100点」を目指さず、エスカレーションを設計する

社内FAQのすべてをAIだけで完結させる必要はありません。

むしろ、次の質問は人へ回したほうが安全です。

個別の人事判断
契約・法務判断
例外承認
根拠文書が見つからない質問
複数の正式文書が矛盾している質問
権限によって回答内容が変わる質問

「回答できない」を失敗扱いすると、AIは無理に答える方向へ最適化されます。

本番KPIには、正答率だけでなく適切なエスカレーション率も入れてください。

費用対効果まで含めて運用判断をしたい場合は、生成AIの費用対効果はどう測る？ROI・KPIの作り方で、品質・利用・コストを同時に見る方法を整理しています。

RAGを使わないほうがよいケースもある

すべての社内AIにRAGが必要なわけではありません。

たとえば、

対象文書が数本しかない
毎回同じ短い資料だけを読む
文書比較そのものが目的
厳密な計算やデータ集計が中心
SQLやAPIで直接取得したほうが正確

という場合は、長いcontextへ直接渡す、検索APIを使う、データベースから構造化取得するなどのほうが単純なことがあります。

MicrosoftのRAGガイダンスでも、RAGは知識ベースからの事実検索やFAQには適していますが、長文書の深い比較や複雑な判断には別の設計が必要になる場合があるとされています。

RAGを導入すること自体を目的にせず、質問に必要な根拠を最も安全かつ安定して渡せる方法を選ぶことが重要です。

本番前チェックリスト

RAGを本番へ出す前に、最低限次を確認します。

データ

[ ] 正式文書と参考文書を区別した
[ ] 旧版を検索対象から外した
[ ] 文書オーナーと更新日を持たせた
[ ] PDF・表・見出しの解析結果を確認した

Retrieval

[ ] 評価質問で正しい根拠がtop-kに入るか測った
[ ] 略語・言い換え質問を試した
[ ] chunkingを文書構造に合わせた
[ ] top-k / thresholdを評価データで決めた
[ ] 必要ならhybrid search / rerankingを比較した

Generation

[ ] 根拠外の推測を抑える指示がある
[ ] 出典を表示する
[ ] 情報不足時の回答拒否ルールがある
[ ] 人へエスカレーションする条件がある

Security

[ ] retrieval前にアクセス権を適用する
[ ] 外部・ユーザー編集文書を無条件に信頼しない
[ ] prompt injection / data poisoningをテストする
[ ] 検索ログに機密情報を残しすぎない

Operations

[ ] 評価セットを保存した
[ ] 本番ログから失敗質問を収集できる
[ ] 品質・レイテンシ・コストを継続監視する
[ ] 文書更新時に再indexする運用責任者がいる

まとめ：RAG精度改善は「モデル交換」より先に検索工程を見える化する

RAGの回答が不安定なとき、最初に高性能なLLMへ交換しても、検索で間違った根拠を渡していれば改善しません。

まず、

情報源が正しいか
正しいchunkをretrievalできているか
取得した根拠を生成が正しく使えているか
権限・鮮度・運用が本番でも維持できるか

を分けて確認します。

そのうえで、文書整理、chunking、query rewriting、hybrid search、reranking、generation制約を同じ評価データセットで一つずつ比較します。

RAGの精度改善で重要なのは、「どの設定が一番賢そうか」ではありません。

どの工程で失敗しているかを観測でき、変更前後を数字で比較できる状態を作ることです。

その状態ができれば、RAGはPoCのデモから、継続的に改善できる業務システムへ変わります。