RAGの精度が出ない原因を切り分ける方法：検索ミス・データ品質・設計の見直し

RAGで「答えが当たらない」ときに、まず疑うべき3領域

社内ナレッジ検索や問い合わせ対応にRAG（検索拡張生成）を入れたのに、「回答がズレる」「根拠が違う」「知らないはずのことを断言する」といった不満が出ることがあります。非エンジニアの立場だと、どこを直せば改善するのかが見えにくく、ベンダーや開発チームに丸投げになりがちです。

RAGの精度問題は、ざっくり言うと次の3領域のどこか（または複数）の不具合として現れます。

• 検索ミス（Retrievalの問題）：そもそも必要な資料・該当箇所が取れていない／違う資料を持ってきている
• データ品質（Knowledgeの問題）：登録している資料が古い・矛盾・粒度がバラバラ・権限や版管理が崩れている
• 設計（Generation/Orchestrationの問題）：プロンプトやルールが弱く、拾った根拠を使い切れていない／無理に答えを作る

ここで重要なのは、「モデルが賢くないから」ではなく、原因を分解して切り分ければ改善できるという点です。特に業務向けのRAGは、モデルの入れ替えよりも、検索・データ・設計を整える方が効果が大きいケースが多くあります。

本記事では、ITに詳しくない方でも実務で判断できるように、症状→確認ポイント→改善策の順で、原因を切り分ける手順を具体的に整理します。社内稟議・ベンダー調整で使える「質問リスト」も併せて紹介します。

最短で切り分けるための観察：まず「根拠が出ているか」を見る

RAGの挙動を早く切り分けるコツは、「回答文」だけを見ないことです。必ず根拠（参照した文書や該当箇所）を一緒に表示させ、根拠が妥当かどうかを確認します。根拠が妥当なら生成側、根拠がズレているなら検索側・データ側の疑いが濃くなります。

例えば「経費精算の上限額は？」と聞いたのに、根拠が「出張規程（旧）」や「例外申請の手順」になっているなら、検索のヒットがズレています。一方、根拠に上限額が書いてあるのに回答で別の数字を言うなら、生成（設計・プロンプト）側の問題です。

また、業務で頻出する失敗として「質問があいまい」があります。たとえば「この場合どうする？」は、前提条件（誰が・どの申請区分・いつ時点の規程）が欠けていることが多いです。この場合、RAGが勝手に前提を補ってしまい、もっともらしい誤答になります。改善の方向性は「質問の定型化」や「追加質問（確認質問）をさせる設計」です。

検索ミス（Retrieval）が原因のとき：症状・確認・改善

RAGで最も多いのが、検索（Retrieval）のミスです。必要な根拠が取れていないため、生成モデルは不十分な材料で回答を作り、結果としてズレや断言が増えます。ここを直すと、同じモデルでも精度が一気に上がることがあります。

よくある症状

• 根拠として出てくる資料が、質問と直接関係ない
• 似た単語に引っ張られて別文書を参照する（例：「契約更新」と「更新手続き」）
• ヒット件数が少なすぎる／毎回同じ文書しか出ない
• 社内用語・略語・製品名に弱い（例：「勤怠」ではなく「タイムカード」など）

非エンジニアが開発側に確認すべき質問

• 「検索結果の上位何件（top-k）を根拠にしているか」（少なすぎると漏れ、多すぎるとノイズ）
• 「全文検索なのか、ベクトル検索（意味検索）なのか、ハイブリッドなのか」
• 「検索語の正規化（表記ゆれ、半角全角、社内略語辞書）はあるか」
• 「フィルタ（部署、権限、年度、製品版）を検索に反映しているか」

改善策（優先度が高い順）

1) クエリ（検索文）を補強する
利用者の質問は短くあいまいになりがちです。そこで、質問をそのまま検索に投げず、社内用語の展開や条件付けを追加します。例：「経費 上限」→「経費精算 規程 上限額 立替 交通費 宿泊費」。この「検索用に言い換える」工程があるだけで、RAGのヒット率が改善します。

2) ハイブリッド検索を検討する
意味検索（ベクトル）だけだと、数字・条文・型番・固有名詞に弱いことがあります。キーワード検索（BM25など）と組み合わせると、規程・契約・仕様書に強くなります。RAGは「文章の意味理解」よりも「該当箇所を正しく持ってくる」方が重要な場面が多いです。

3) リランキング（再順位付け）を入れる
検索で拾った候補を、より精度の高いモデルで「質問に近い順」に並べ替えます。根拠の上位に正しい文書が来るだけで回答が安定します。ベンダー提案で「モデルを高性能に変更」が先に来たら、まずリランキングの有無を確認するのが実務的です。

4) チャンク設計（分割）を見直す
検索対象の文書をどの単位で分割（チャンク）しているかで、ヒットのしやすさが変わります。チャンクが大きすぎるとノイズが増え、小さすぎると文脈が欠けます。規程なら「条項単位」、FAQなら「Q単位」など、文書種類で分けるのが有効です。

データ品質（Knowledge）が原因のとき：整備しないと精度は頭打ち

RAGは「社内の正しい情報を引き出す仕組み」なので、登録データが不安定だと精度は必ず頭打ちになります。実務では、検索アルゴリズムよりもデータの版管理・重複・矛盾が原因で炎上することが少なくありません。

よくある症状

• 回答が部署や担当者によって変わる（根拠文書が複数あり矛盾）
• 昔のルールを平気で参照する（旧規程、旧テンプレート）
• PDFスキャン等で文字が取れておらず、検索で当たらない
• 同じ内容が複数フォルダにあり、どれが正か不明

確認ポイント（運用の観点）

RAGのデータ整備は、ITというより「情報管理」の課題です。次の項目は、情シスや総務・法務・品質管理などの部門横断で決めると効果が出ます。

• 正本（マスター）文書の定義：「このURL/このフォルダが正」と決める
• 改定ルール：改定日、版数、改定理由、廃止文書の扱い（検索対象から除外する等）
• メタデータ：部署、適用範囲、対象年度、製品バージョン、機密区分
• OCR/テキスト化：スキャンPDFは検索不能になりやすいので要注意

改善策（「手間が少なく効く」順）

1) 参照してほしい文書だけを先に絞る
全部の共有フォルダを食わせる前に、「まずは規程」「まずはFAQ」「まずは製品マニュアル」など、勝ちやすい領域に限定します。対象範囲を狭めるほどRAGは当たりやすいため、初期はスコープ設計が重要です。

2) 版と更新日を必ず持たせ、古い版を除外する
「最新版のみ検索対象」「旧版は検索対象外だが参照はできる」など、運用ルールを決めます。古い版が混ざると、検索が正しくても回答が誤ります。

3) 文書タイプ別に整形する
規程、手順書、議事録、メール、チャットログを全部同列に扱うと、ノイズが増えます。議事録は検討段階の情報が多く、RAGに入れると「決定事項」のように誤解されることがあります。まずは「決まっている情報」から優先し、議事録は慎重に扱うのが安全です。

設計（生成・プロンプト・ガードレール）が原因のとき：断言・幻覚を止める

根拠が正しいのに回答がズレる場合、生成側（プロンプト、ルール、ツール連携）の設計が原因です。ここでの目的は「賢い文章」を作ることではなく、根拠に忠実に答え、分からないときは分からないと言うことです。業務向けのRAGでは、このガードレールが信頼性を左右します。

よくある症状

• 根拠に書いていないことを補って断言する
• 複数根拠の矛盾を勝手に解釈し、誤った結論にする
• 「手順」を聞いているのに「説明」を返すなど、形式が揃わない
• 社内ルール上は判断できないのに、決裁するような回答を出す

改善の考え方

RAGは「検索→回答」の一発勝負にすると不安定です。実務では次のように段階を踏ませると、誤答が減ります。

• ステップ1：質問の条件を整理（対象年度・部署・契約形態など）
• ステップ2：必要な根拠を列挙し、不足があれば追加質問
• ステップ3：根拠の引用（該当箇所）→結論→例外条件の順に回答
• ステップ4：判断できない場合は「分からない」「担当窓口」を案内

具体的な設計ポイント

根拠優先のプロンプト
「必ず根拠に含まれる情報だけで答える」「根拠にない場合は不足情報を質問する」「推測で埋めない」といった指示を明文化します。加えて、回答フォーマット（結論→根拠→手順→注意点）を固定すると、利用者の体験が安定します。

引用の強制
業務用途では「根拠のない断言」が最も危険です。回答に「根拠の引用」を必須にし、引用が出せない場合は回答を保留する設計にします。これだけで、RAGの信頼性が大きく上がります。

権限・機密の扱い
人事・法務・顧客契約などはアクセス権が重要です。検索時に権限フィルタをかけ、回答にも「閲覧権限がないため参照できません」と出せるようにします。ここが曖昧だと、精度以前に情報漏えいリスクになります。

評価と運用：精度を「数字」で見える化するチェックリスト

RAGの精度は、担当者の体感だけだと改善が進みません。そこで、最低限の評価セット（テスト質問集）を作り、検索・データ・設計のどこが悪いかを継続的に観測します。専門的なベンチマークでなくても、業務に即した評価で十分効果があります。

テスト質問集（50〜100問）の作り方

• 実際の問い合わせ・チャット・メールから「頻出」を集める
• 難易度を混ぜる（簡単：用語説明、中：手順、難：例外・条件分岐）
• 質問ごとに「正しい根拠文書」と「期待する結論」をメモする
• 年度・部署・契約形態など、条件が変わる質問を入れる

切り分け用の採点（おすすめ）

例えば「検索×・回答×」なら検索改善が優先です。「検索○・回答×」なら生成側の設計（引用強制、追加質問、フォーマット）を強化します。「検索○・回答○・業務適合×」なら、回答テンプレートや用語の言い換え、導線（リンク、担当窓口提示）を整えると満足度が上がります。

また、運用で効くのがフィードバック導線です。利用者が「役に立った／立たない」「理由（根拠が古い、手順が不足、検索が違う）」を1クリックで送れるようにすると、改善の材料が集まります。RAGは導入して終わりではなく、育てる仕組みがあるほど強くなります。

現場で起きがちな失敗と、回避のための実務ポイント

RAGの精度改善は、技術だけでは完結しません。社内の合意形成、責任分界、スコープ設計を誤ると、いつまでも「使えない」状態が続きます。よくある失敗を先に潰しておくと、導入効果が出やすくなります。

失敗パターン

• 最初から全社文書を全部入れる：ノイズが増え、検索も評価も破綻する
• 「正解」を決めない：規程と現場運用が違うと、どちらが正しいか揉める
• 根拠表示がない：誤答の原因が分からず、改善が進まない
• 窓口が不在：更新・廃止・例外ルールが放置される

回避策（合意形成のコツ）

小さく始めて勝ちパターンを作る
最初は「問い合わせが多く、文書が比較的整っている領域」がおすすめです。例：人事の申請手順、情シスのアカウント申請、経費精算の基本など。ここでRAGの価値（問い合わせ削減、自己解決率）を示すと、次の範囲拡大が進めやすくなります。

責任分界を明確にする
「文書の正しさは業務部門」「検索と表示は情シス/開発」「回答の表現ルールは編集/広報」など、役割を決めます。特にデータ品質は放置されやすいので、更新責任者（オーナー）を必ず置くのがポイントです。

回答の限界を設計に含める
業務には例外がつきものです。RAGに万能を期待すると、誤答のリスクが増えます。「判断が必要なときは担当にエスカレーション」「判断材料を列挙して人が決める」など、安心して使える終着点を作ると現場定着が進みます。

まとめ

RAGの精度が出ないときは、やみくもにモデルを疑うのではなく、原因を「検索ミス」「データ品質」「設計」の3領域に分けて切り分けるのが近道です。特に業務用途では、根拠表示を前提に、検索が当たっているか／データが正しいか／根拠に忠実に答えているかを順番に確認すると、改善点が明確になります。

• 検索ミス：クエリ補強、ハイブリッド検索、リランキング、チャンク見直し
• データ品質：正本の定義、版管理、メタデータ、OCR、文書タイプの整理
• 設計：引用の強制、追加質問、回答フォーマット、権限フィルタ、エスカレーション

テスト質問集と採点（検索・忠実性・業務適合）を用意すれば、改善が「感覚」ではなく「数字と事実」で進みます。RAGは導入後の運用で大きく伸びる仕組みなので、まずは小さく始めて勝ちパターンを作り、範囲を広げていくのがおすすめです。