ブログ一覧

2026.11.10

RAG幻覚対策で根拠ある回答を実現する方法

RAG幻覚対策の要点は、AIに「答えさせる」前に、信頼できる根拠を十分に検索し、根拠外の断定を止めることです。自然な文章であっても出典と一致しない回答は、業務では誤情報になり得ます。

RAGは社内規程、製品資料、FAQなどを検索してLLMへ渡す仕組みですが、導入しただけで誤答が消えるわけではありません。検索漏れ、古い文書、OCR誤読、矛盾した根拠、生成時の補完が重なると、もっともらしい誤回答が生まれます。

本記事では、AIハルシネーションの切り分けから、RAGチャンク設計、ハイブリッド検索、RAG再ランキング、RAG引用表示、AI出力検証までを一続きの運用として解説します。精度と回答可能範囲を両立する判断基準も示します。

RAG幻覚対策で最初に診断すべき3つの失敗

RAGシステムの検索と生成の失敗箇所を確認するチーム

幻覚は検索・文脈・生成に分けて原因を特定する

RAGの誤答は、検索失敗・コンテキスト不足・生成時の捏造に分解して調べるべきです。検索結果に正解文書がないのか、あっても必要箇所が欠けるのか、根拠があるのにモデルが逸脱したのかで、打つべき施策はまったく変わります。

まず質問、検索上位文書、LLMへ渡した抜粋、最終回答、引用箇所を同じログで確認します。回答だけを採点すると、検索の問題をプロンプトで直そうとしたり、生成の問題をインデックス再構築で解こうとしたりする遠回りが起こります。

RAG幻覚対策では「根拠なし」「根拠不足」「根拠矛盾」「根拠逸脱」のラベルを失敗ログに付けます。たとえば規程の改定日を旧版から答えたなら、生成品質よりも版管理と検索フィルターの問題として扱うのが実務的です。

  • 検索上位に正解根拠が含まれるかを先に確認する
  • 回答文の各主張を、提示コンテキストの一節へ対応付ける
  • 回答不能を誤答と区別して記録する

AIハルシネーションは自信の強さでは判定できない

AIハルシネーションとは、事実と異なる内容、または与えられた根拠にない内容を、確からしく生成する現象です。文体の流暢さや断定的な表現は正確性の証拠ではないため、回答の自信度表示だけに依存してはいけません。

内在的ハルシネーションは、与えた資料の記述を取り違える問題です。外在的ハルシネーションは、資料にない制度、数値、引用元をモデルが補う問題であり、RAGでも検索文書の外へ知識を持ち出せば発生します。

外部調査では、OpenAIの新しいo3モデルが、それが置き換えた旧モデルと比較して、約2倍の頻度で誤った回答を捏造したと報告されています。モデル選定だけで解決しようとせず、根拠制約と検証工程を設計する必要があります。

  • 流暢さではなく根拠との一致を確認する
  • 資料内の誤読と資料外の捏造を分ける
  • 高リスク回答は人が最終承認する

回答拒否は失敗ではなく安全な機能として設計する

検索根拠が弱い場合は、無理に回答させず「該当する根拠を確認できません」と返す設計が有効です。これは利用者を見放すためではなく、誤った断定を避け、追加情報や担当窓口へ安全につなぐためのLLMガードレールです。

拒否率だけを下げると、回答カバレッジは上がって見えても、根拠のない説明が混じります。反対に拒否を厳しくし過ぎれば有用性が落ちるため、質問タイプごとに必要な根拠数と、人手確認へ送る条件を決めておきます。

実務では、規程の数値や医療・金融・法務の助言は引用必須、雑談や文書要約は引用推奨とする段階設計が現実的です。高リスク領域では、回答文の末尾に確認日、対象文書、担当部署を示す導線まで用意します。

  • 根拠不足なら回答せず、次の確認方法を案内する
  • 高リスク質問では引用なしの断定を禁止する
  • 拒否・保留・人手確認を別々に計測する

検索品質を上げるRAG精度改善の基本設計

ハイブリッド検索で表記ゆれと固有名詞に対応する

RAG精度改善では、ベクトル検索だけに頼らず、キーワード検索と組み合わせる方法が基本です。意味が近い文章を探すベクトル検索と、製品型番、条番号、部署名を正確に拾うBM25系検索は、失敗しやすい場面が異なります。

日本語の社内文書では、全角半角、旧称、新称、略称、送り仮名が検索漏れを起こします。質問と文書を正規化し、同義語辞書とメタデータを併用すると、固有名詞を意味的な近さだけで誤って置換する危険を下げられます。

ベクトル検索単体のMRR（Mean Reciprocal Rank）は56.72%にとどまったという報告もあります。検索方式の優劣を一般論で決めず、自社の質問セットでRecallと上位順位を測り、混合比を調整することが重要です。

  • 意味検索と完全一致検索を併用する
  • 文書種別・部署・版・公開状態で絞り込む
  • 略称と表記ゆれを検索辞書に登録する

クエリを明確化して検索対象を狭める

質問が曖昧なら、検索器を高度化しても誤った資料を集めます。問い合わせ文から対象制度、時点、部署、製品、求める回答形式を抽出し、不足している場合は確認質問を返すことが、検索前の重要なRAG幻覚対策になります。

複数条件を含む質問は、「対象者」「条件」「例外」「手続き」に分解して検索します。一度に長い質問を埋め込み化するより、論点ごとの根拠を集めてから統合するほうが、条件の取り落としを見つけやすくなります。

検索クエリの書き換えは便利ですが、モデルが質問の意図を変えないよう原文も必ず残します。書き換え後の検索語、ヒット件数、採用文書を保存すれば、利用者からの指摘時にも検索過程を再現できます。

  • 質問の対象時点と対象範囲を抽出する
  • 複合質問は論点単位で検索する
  • 書き換え前後のクエリを監査ログに残す

検索結果の品質は正解文書の有無で評価する

検索品質は、最終回答が正しそうかではなく、正解の根拠が上位候補にあるかで測定します。特にRecallは「必要な文書を取り逃がしていないか」を表すため、生成モデルの表現力と混同せず、検索段階の指標として確認します。

評価用の質問は最低50〜100件用意し、定義、数値、比較、例外、複数文書横断、更新履歴などの型を混ぜます。実ユーザーが尋ねない簡単な質問だけで高得点でも、本番の問い合わせに耐えるとは限りません。

初回検索で上位20〜50件に絞り、後段で根拠を精査する構成は有効です。ただし権限外文書を候補へ出さないアクセス制御は先に適用し、精度改善が情報漏えいにつながらないようにします。

  • 質問ごとに正解文書と正解箇所を付与する
  • Recallと順位指標を検索工程で別管理する
  • アクセス権フィルターを検索前に適用する

RAGチャンク設計で文脈の切れ目をなくす

チャンクは文字数ではなく意味と文書構造で区切る

RAGチャンク設計では、固定文字数で分割する前に、見出し、条、表、注記、改定履歴といった文書構造を保つことが重要です。特に規程文書は、本文だけを切り出すと適用条件や例外条項が失われ、誤った一般化を招きます。

短すぎるチャンクは検索には当たりやすい一方、主語や条件が欠けます。長すぎるチャンクは関連しない文章まで混入し、LLMが重要箇所を見失います。親チャンクに章全体、子チャンクに節単位を持たせる階層設計が扱いやすい選択肢です。

OCR済みPDFは、段組み順序、表の列、脚注、縦書きの読み順を必ず確認します。検索前に構造を崩した文書を投入しても、後段のプロンプトでは復元できません。原本へのリンクをメタデータとして保持することも欠かせません。

  • 見出しと条文番号をチャンクへ継承する
  • 表は行・列の関係を保って構造化する
  • 親子チャンクで詳細と前後関係を両立する

サイズとオーバーラップは評価データで決める

最適なチャンク長に万能な正解はありません。一般的には256 から 1024 トークン程度が出発点になりますが、FAQ、契約書、技術仕様書では必要な文脈量が違うため、質問セットを用いた比較検証が必要です。

チャンクサイズを1,000文字から2,000文字に変更するだけで精度が73.3%から100%に向上した事例が報告されています。一方で別の検証では3,000文字（オーバーラップ900文字）が最高精度を記録しており、単純な小分けが最適とは限りません。

オーバーラップ率は10〜30%が目安とされます。ただし重複を増やせば検索候補と入力トークンも増えるため、精度だけでなく応答速度、費用、同じ根拠を複数回渡していないかを同時に確認します。

  • 文書種別ごとに複数サイズを比較する
  • 境界をまたぐ条件文にはオーバーラップを使う
  • 精度・遅延・トークン量をセットで記録する

メタデータと版管理で古い根拠を排除する

チャンク本文だけでは、最新性と適用範囲を判断できません。文書ID、版番号、公開日、失効日、部署、権限、原本URLをメタデータ化し、検索時に現行版を優先することで、過去規程を根拠にする誤答を減らせます。

改定がある文書は、旧版をただ削除するのではなく、失効済みとして保存し、通常検索からは除外します。過去時点を指定する質問にだけ旧版を許可すれば、監査時の再現性と日常回答の安全性を両立できます。

データ更新後は、以前に正答だった質問で再試験します。インデックス更新、埋め込みモデル変更、PDF差し替えは検索順位を変えるため、変更前後の失敗件数と引用先を比較する回帰テストが必要です。

  • 版番号と有効期間を必須メタデータにする
  • 現行版と旧版の検索条件を分ける
  • 更新ごとに代表質問で回帰テストを行う

RAG再ランキングで根拠の優先順位を整える

再ランキングは候補検索の後に適用する

RAG再ランキングは、初回検索で集めた候補を質問との関連性で再採点し、LLMへ渡す根拠を絞る処理です。検索器が広く候補を拾い、rerankerが精密に順位付けする二段構成は、ノイズ文書の混入を抑えるのに役立ちます。

初回検索で上位20〜50件に絞り、リランキングは上位5〜10件に再スコアリングする構成が代表的です。候補数を最初から少なくし過ぎると正解文書を失い、多過ぎると再ランキングの遅延と費用が増えます。

リランキングの採用基準は順位だけでは不十分です。上位候補のスコア差が小さい、文書間で条件が矛盾する、重要な数値の根拠がない場合は、回答を保留するルールへ接続することで安全性が上がります。

  • 広く検索してから精密に順位付けする
  • 再ランキング後の根拠数を質問別に制御する
  • スコア差が小さい回答は断定を避ける

精度向上と遅延のトレードオフを可視化する

再ランキングは万能ではなく、追加推論による待ち時間とコストが発生します。それでも、検索精度が62%から79%に向上し、リランキングを加えることで91%に到達した報告があり、正確さが優先される業務では検討価値があります。

ベクトル検索単体比14〜30%の精度向上が見込めるという報告もありますが、文書の均質性や質問の難易度で効果は変動します。すべての質問に同じ重い処理を掛けず、短いFAQと複数規程をまたぐ質問で経路を分けると効率的です。

試験では、検索だけ、検索とrerank、検索とrerankと回答拒否の3条件を並べます。正答率だけでなく、根拠付き正答率、回答不能の適切さ、p95応答時間、1回答当たりのコストを比較して採用を判断します。

改善施策ごとに主な効果と運用上の負担を比較できます。
施策 主な効果 主な負担
ハイブリッド検索 固有名詞の取り漏れ低減 検索設定の調整
再ランキング 上位根拠の関連性向上 追加レイテンシ
回答拒否 根拠なき断定を抑制 回答カバレッジ低下
実際の効果は、自社の文書と評価質問で確認します。
  • 正答率と根拠付き正答率を分けて見る
  • 質問の難度に応じて処理経路を切り替える
  • p95応答時間と回答単価を運用指標に含める

プロンプトは根拠利用のルールを明文化する

検索が成功しても、LLMが一般知識で文章を補えば誤答は残ります。システム指示には「提示された根拠にない事実を追加しない」「根拠が不足する場合は不明と答える」「主張ごとに引用を付ける」と明記します。

temperatureを下げても、根拠のない内容が真実になるわけではありません。生成設定は表現のばらつきを抑える補助であり、RAG幻覚対策の中心は、根拠選択、制約付き生成、出力後の照合という三層に置くべきです。

検索文書にはプロンプトインジェクションが混入する可能性があります。「前の指示を無視せよ」といった文書内容を命令として扱わないよう、検索結果はデータであり命令ではないことをモデルへ明示し、危険な文言を検査します。

  • 根拠外の補完禁止をシステム指示に書く
  • 生成パラメータを安全性対策の代替にしない
  • 検索文書の命令文を無害化・検査する

RAG引用表示とAI出力検証を回答画面に組み込む

引用はリンクだけでなく主張との対応を示す

RAG引用表示は、単に文書一覧を付ける機能ではありません。回答中の数値、条件、結論ごとに、どの文書のどの節が支えるかをたどれるようにし、利用者が短時間で検証できる状態を作ることが目的です。

引用カードには文書名、版、該当見出し、抜粋、公開状態、原本リンクを表示します。利用者が全文を読めなくても根拠の範囲を確認でき、古い資料や別部署の文書をAIが混ぜていないかを発見しやすくなります。

引用が付いていても、引用箇所が結論を実際に支えていなければ危険です。数値の近くに引用があるか、例外条項を落としていないか、複数文書の矛盾を隠していないかを、UIと評価の両面で確認します。

  • 主張単位で出典と抜粋を対応付ける
  • 版・見出し・原本リンクを表示する
  • 引用の有無ではなく支持関係を評価する

出力検証は忠実性と関連性を分けて行う

AI出力検証では、FaithfulnessとAnswer Relevancyを分けて測ります。Faithfulnessは回答が与えた根拠に忠実か、Answer Relevancyは質問に直接答えているかを表すため、片方だけ高くても安全で有用とは言えません。

RAG評価指標には、検索段階のContext Recall・Precision、生成段階のFaithfulness・Answer Relevancyを置くと原因を追跡しやすくなります。Context Recallが低ければ検索漏れ、Faithfulnessが低ければ生成逸脱を優先して改善します。

RAGASなどの自動評価は大量ログの傾向把握に便利ですが、正解判定を完全に代替しません。特に日本語の敬語、否定、法令の例外、表の条件は人手で抜き取り確認し、評価器の見落としも評価対象にします。

  • 検索指標と生成指標を混ぜない
  • 自動評価と人手評価を併用する
  • 否定・例外・数値の誤りを重点監査する

LLM評価基準は業務リスクに合わせて閾値を決める

LLM評価基準は、全業務で同じ合格点にする必要はありません。社内ナレッジの所在案内と、契約条件や医療情報の回答では、誤答時の影響が違うため、必要な引用率、許容できる保留率、人手承認の基準も変えるべきです。

評価セットには、正答だけでなく「回答してはいけない質問」も含めます。権限外情報、根拠が存在しない質問、矛盾する規程、最新情報が未投入の質問に対して、適切に保留できるかは、正答率と同等に重要です。

評価の結果は、検索、チャンク、再ランキング、プロンプト、UIの変更単位で保存します。改善後に一部の質問だけ悪化する回帰を見逃さず、変更を戻せるようにモデル名、インデックス版、評価日時を記録します。

  • 業務リスク別に合格条件を定義する
  • 回答禁止・保留すべき質問も評価に入れる
  • 変更ごとの評価結果を比較可能に保存する

LLMガードレールを継続運用して誤答を減らす

本番ログから失敗パターンを継続的に学習する

LLMガードレールは導入時の設定で終わりではありません。本番ログから、根拠なしの断定、引用不一致、検索ゼロ、低評価、回答拒否、エスカレーションを定期的に抽出し、原因別に優先順位を付けて改善します。

監視では、回答数だけでなく、根拠付き回答率、検索ゼロ率、引用クリック率、低評価率、適切な保留率を追います。急な悪化は文書更新、インデックス障害、権限設定、モデル変更などの兆候になり得ます。

RAG幻覚対策の効果は、単純な誤答件数だけでは測れません。根拠のない回答を適切に保留できた件数と、利用者が必要な根拠へ到達できた割合を併せて見れば、安全性と業務有用性のバランスを判断できます。

  • 失敗ログを原因別にラベル付けする
  • 引用・保留・検索ゼロを継続監視する
  • 文書更新後の指標変化にアラートを出す

人手レビューは高リスク判断へ集中させる

すべての回答を人が読む運用は拡張しません。金額、期限、法的義務、健康影響、顧客への外部送信など、誤りの影響が大きい回答にレビューを集中させ、低リスクの所在案内や要約は自動処理を基本にします。

レビュー担当者には、文章の自然さではなく、根拠の版、引用範囲、質問条件との一致、例外の有無を確認するチェックリストを渡します。指摘は単なる修正文で終わらせず、検索漏れやデータ不備の学習材料として蓄積します。

金融庁が2026年3月3日に公表した「AIディスカッションペーパー（第1.1版）」のように、AI利用では説明可能性と管理態勢が問われます。誰が何を承認し、どの根拠で回答したかを追える記録が実務上の信頼につながります。

  • 高影響の回答だけを承認フローへ送る
  • 根拠確認用のレビュー観点を標準化する
  • 承認者・根拠・回答履歴を保存する

段階導入で精度・費用・速度の均衡を取る

RAGの高度化は、一度にすべて実装する必要はありません。まず対象文書を限定し、評価質問と引用表示を整え、検索品質を測った後に、チャンク改善やRAG再ランキングを加える順序なら、投資効果と不具合箇所を見極めやすくなります。

Naive RAG（基本的な検索＋生成）で構築したが、正答率は50%程度にとどまったという報告があります。一方、DeNAの社内AIヘルプデスクはAmazon Bedrock Knowledge Basesを活用し、正答率80%を達成したとされ、運用設計と評価の差が成果を左右します。

高度なモデルとしてGemini 1.5を採用しても、データ品質と検証工程は省略できません。施策によっては2023年比で80-90%削減という改善報告もありますが、自社のリスク、文書量、利用頻度で再現性を検証してから本番範囲を広げます。

  • 小さな対象範囲で評価可能なPoCを行う
  • 精度改善の前後を同じ質問で比較する
  • 高度なモデルでも引用と検証を省略しない

まとめ

RAG幻覚対策は、モデルを替えるだけの施策ではありません。検索で正しい根拠を集め、文書構造を保って渡し、再ランキングで絞り、引用で示し、評価と人手レビューで継続的に監視する運用全体の設計です。

要点

  • 誤答は検索失敗・文脈不足・生成逸脱に分けて診断する
  • ハイブリッド検索、RAGチャンク設計、RAG再ランキングを評価結果に基づいて調整する
  • RAG引用表示とAI出力検証で、利用者が根拠を確認できる回答にする
  • LLMガードレールと人手レビューで、高リスク回答を安全に扱う
  • 評価セットと本番ログを使い、更新後も回帰テストを続ける

まずは実際の問い合わせから50〜100件を選び、正解根拠、期待回答、回答禁止条件を付けてください。その評価セットを起点に、検索・生成・引用のどこで失敗しているかを可視化すると、優先すべき改善策が明確になります。

よくある質問

Q1. RAGを導入すればAIハルシネーションはなくなりますか？

なくなりません。RAGは根拠を取得する仕組みですが、検索漏れ、古い文書、文脈不足、生成時の根拠外補完が残ります。引用表示、回答拒否、出力検証、継続評価を組み合わせる必要があります。

Q2. RAG幻覚対策で最初に改善すべき点は何ですか？

まず評価質問と正解根拠を用意し、検索結果に必要な文書が含まれているかを確認してください。正解根拠が取得できていない場合、プロンプトだけを調整しても安定した改善は期待できません。

Q3. RAG再ランキングは必須ですか？

必須ではありませんが、候補文書にノイズが多い、複数の類似規程がある、質問が複雑といった場合に効果的です。精度向上と追加レイテンシを、同じ評価セットで比較して判断します。

Q4. 引用表示では何を見せるべきですか？

文書名だけでなく、版、該当見出し、根拠の抜粋、原本リンクを表示するのが有効です。回答中の主張と引用箇所が対応していることも確認できるようにしてください。

Q5. 無料クレジット最大 $300 分の環境でRAG評価を始められますか？

小規模な評価セットで検索・引用・回答拒否の挙動を確認するPoCは始められます。ただし本番判断では、実データの権限管理、継続的な評価、人手レビューを含めた運用コストも別途見積もる必要があります。

参考文献・出典

RAG精度向上の実践手法8選｜チャンキング・リランキングで回答精度を73%→100%に改善 | OptiMax AI情報

[rag](/ai-information/technology/rag/)[llm](/ai-information/technology/llm/)[生成AI](/ai-information/technology/generative-ai/)[業務自動化](/ai-information/usecase/aut…

www.optimax.co.jp

AIハルシネーションとは？ | Databricks Blog

[メインコンテンツへジャンプ](#main) [Data + AIの基盤](/jp/blog/category/data-ai-foundations) # AIハルシネーションとは？…

www.databricks.com

AI ハルシネーションとは | Google Cloud

# AI ハルシネーションとは AI のハルシネーションとは、[AI モデル](https://cloud.google.com/learn/what-is-artificial-intelligence)が生成する不正確な結果や誤解を招く結果のことです。こうしたエラーは、不十分なトレーニング…

cloud.google.com



ブログ一覧へ戻る