RAGハルシネーションとは、取得した正しい文書を引用しながら出力に虚偽が混じる現象である。
- 取得文書が正しくても、RAGは8〜15%の確率で「正しそうな嘘」を生成する
- 原因は「同一モデル自己評価の構造的盲点」と「検証ステップ未実装」の2つ
- 対処法は retrieve → generate → verify の3段階化。Python約15行で既存パイプラインに後付け可能
「取得した文書は3件とも実在する。LLMはそれを読んでいる。回答にはその出典が引用されている。それでも答えが間違っている」——RAGを本番に投入した直後、こうした報告がユーザーから上がってきます。引用が虚構ではなく、引用先も実在する。にもかかわらず、回答だけが事実と食い違っている。検索拡張生成（RAG）を運用したことがあるエンジニアなら、この症状に覚えがあるはず。
本記事では、この「正しそうな嘘」を本番投入前に検出するパターンと、Python約15行で書ける検証ステップの設計を整理します。検索層・生成層を変更せず、後段に独立パスを挟むだけで導入できる対処法です。
このエラーの症状: RAGが「正しそうな嘘」を出す3つの失敗モード
RAGパイプラインの幻覚は、典型的な3パターンに分類できます。出力が一見正常なため、開発者がレビューしても気づきにくいのが特徴。本番投入後にユーザー側からクレームが上がって発覚するケースが多発しています。
RAGの失敗モードは、近年の研究で体系的に分類されています。例えば、Gao, et al. (2024) の論文では、検索の失敗、生成の失敗など7つのカテゴリが提示されており、本記事で扱う「正しそうな嘘」は主に生成段階の失敗に該当します。
出典: “RAG” vs “Fine-tuning”: A Quantitative Analysis
引用の捏造（citations that point to nothing）
回答に [2] のような出典マーカーが付いていて、その出典自体は実在する文書を指している。ただし、回答の主張は出典に書かれていない、という症状。引用は存在するが、引用根拠が存在しない、というずれ方をします。
具体的には「ドキュメントAによれば2024年に発表された」と書かれているのに、ドキュメントAに「2024年」という記述は一切ない、というタイプの失敗。出典をクリックして開く運用ならともかく、本番のチャットUIではこの不整合がそのまま読者に届く構造。
事実の融合（plausible but invented composites）
取得された複数のチャンクから断片的に正しい事実を引っ張ってきて、それを1つの文に合成するパターン。Aチャンクの数値とBチャンクの主語が混ざり、結果として誰も書いていない主張が完成する。各要素は正しいので、文字列照合や個別のファクトチェックでは検出できません。
自信ある外挿（confident extrapolation）
取得文書に書かれた範囲を、もっともらしく超えて結論を導く失敗。「ドキュメントには増加傾向と書かれている」→「来年も同水準で伸びると見込まれる」のような外挿。出典文書には伸び率も予測も載っていないが、出力は断定形になる。
3パターンに共通するのは「出力テキストだけ読むと正しそうに見える」点です。BLEUやROUGEといった文字列ベースの評価指標も、人間の流し読みも、ここで滑り落ちます。これが「最も捕まえにくい幻覚クラス」と呼ばれる理由。
原因の構造: なぜ通常の指標と自己評価では検出できないのか
幻覚を出している側の問題ではなく、検出側の設計に問題があるケースがほとんど。原因を2層に分けて整理します。
取得品質指標の盲点
RAGの評価ではrecall・precision・MRRといった取得品質メトリクスがよく使われています。しかし、これらは「正しい文書を引っ張れたか」を測るもの。生成段階で発生する「正しい文書を読みながら間違える」失敗は、取得品質が満点でも起きます。
つまり、取得層の指標を磨き込んでも生成幻覚はゼロにならない。recall=1.0でも事実融合は発生する。指標の選び方を間違えると「数字上は健全なRAG」を本番に出した結果、現場で事故が起きる構図になります。
同一モデル自己評価が機能しない構造的理由
「LLMに自分の出力を検証させればよいのでは」と考える設計をよく見かけます。しかし同一モデルの自己評価は、構造的に同じ盲点を持ち込みます。理由は3つに整理できる。
第一に、同じ訓練データで学習しているため、誤りの傾向（よくする勘違いの方向）まで共通している。第二に、推論時のプロンプトに対する解釈バイアスも同じ。第三に、出力時に通った思考経路を「自分でもう一度なぞる」だけになり、矛盾を見つける動機が薄い。
結果として、生成と検証で同じ間違いを再生産することに。「自信を持って間違える」モードに入ると、自己評価でも高スコアが返ってくる。これが検出失敗の温床。
評価指標と本番現場のギャップ
学術ベンチマークで90点台を叩き出すRAGシステムが、本番投入後に「8〜15%の応答に何らかの幻覚が含まれる」結果になる、という乖離がこの構造から生まれています。ベンチマークは取得精度と表面的な回答品質を測っているが、本番運用で問題になるのは「行動可能な信頼性」の方。ここを揃える指標が業界全体でまだ標準化されていないのが現状。
対処法: retrieve → generate → verify の3段階化と15行実装
ここからが本題の対処法。検証ステップを独立した第3パスとして挟むのが、最小コストで効く設計です。
設計原則: 3軸を独立化する
検証層は「異なるモデル × 異なる証拠 × 異なるプロンプト」の3軸で生成パイプラインから切り離します。1軸でも共通だと、上述の同一モデル盲点が再侵入する。
従来型RAGとVerify付きRAGの比較
| 評価軸 | 従来型RAG (retrieve-generate) | 提案手法 (retrieve-generate-verify) |
|---|---|---|
| パイプライン | 2段階 (取得→生成) | 3段階 (取得→生成→検証) |
| ハルシネーション検出 | 困難（自己評価は機能しにくい） | 独立した検証層で体系的に検出 |
| 実装コスト | 低 | 中（検証パスの追加が必要） |
| 実行コスト/レイテンシ | 低 | 高（検証APIコールが追加） |
- 異なるモデル: 生成にGPT系を使うなら、検証にはClaude系やオープンソース系などプロバイダごと変える
- 異なる証拠: 生成時に渡したチャンクだけでなく、検証時に独立に再検索した結果と突き合わせる
- 異なるプロンプト: 「肯定的に説明せよ」ではなく「各主張は証拠に明確に書かれているか、書かれていないか」の二択判定で答えさせる
3軸独立化を守ると、検証層は「行動前の拒否ゲート」として機能します。エージェントが何かを実行する前に、出力の主張が証拠に支えられているかを確認し、未支持の主張があれば実行を止める設計。
検証ステップの実装フロー
実装の骨格は次の手順で構成されます。コードを書き起こす前に処理フローを言葉で押さえる。
ステップ1: 生成済み回答からclaimを抽出する — LLMに「以下の回答を独立した主張単位に分解せよ」と依頼し、JSON配列で受け取る。1つの長文回答が5〜10個のclaimに分解されるのが標準。
ステップ2: 各claimに対して独立検索を実行 — 元の質問ではなく、claim自体を検索クエリとして使い、ベクトル検索を再度回す。生成時に渡された3チャンクとは別の文書プールから引いてくる構成にする。
ステップ3: 4つの独立ソースで照合 — claimごとに上位4件の検索結果を取得し、検証用モデルに「このclaimは以下4件のいずれかに明示的に書かれているか」を問う。プロンプトは「supported / unsupported / contradicted」の3値で返させる。
ステップ4: verdictを統合して返す — claimのうち1つでも unsupported または contradicted があれば、回答全体を reject 判定にする。エージェント実行ループ側でこのverdictを見て次の行動可否を決める。
実装上は extract_claims() retrieve_evidence(claim) verify_claim(claim, evidence) の3関数を作り、 main 側で claims をループしてverdictsを集めるだけ。実コードはおよそ15行で完結します。既存パイプラインに手を入れず後段に追加できる点が、この設計の現実的な利点。
観測層との組み合わせで運用に乗せる
検証ロジックだけでなく、検証結果のログを観測可能にする層もセットで設計します。Datadog LLM Observability は LLM パイプラインのトレース・幻覚検出メトリクスを集約する観測基盤で、検証層が reject を出した件数や原因claimを追跡できる仕組み。検証層が誤検出を出していないか、本番のドリフトをどう拾うかを継続観測するために組み込む価値があります。
学術寄りのアプローチとしてはMetaRAGなどのメタ認知的検証フレームワークも提案されており、複数の検証戦略を切り替える研究が進んでいる。本番の検証層を成熟させていく方向感としては参考になる動向。
それでも詰まる場合: 運用設計と代替アプローチ
3段階化を実装しても、本番運用では新たな課題が浮上します。レイテンシ・コスト・誤検出の3つが代表的な詰まりポイント。
レイテンシとコストのトレードオフ
検証パスは生成パスのほぼ倍のトークン消費を発生させます。チャットUIで体感1秒以内のレスポンスを期待する用途では、検証層を同期実行するとSLOを割る。回避策は3つ。
- 検証を非同期に走らせ、UI上は「検証中」マーカーで暫定表示、終わり次第確定する
- 全クエリではなく、高リスク領域（金融・医療・法務・在庫操作など）のみ検証を必須化する
- 検証結果をclaimレベルでキャッシュし、同じclaimが再出現した場合に再計算しない
エージェント運用の場合、UIではなく行動の手前に検証を置くため、レイテンシ要件は緩い。むしろコスト最適化が主軸になります。1日数百万件の生成にすべて検証を回すと検証費が生成費を上回るケースがあるため、サンプリングか高リスク選別が必須。
誤検出（false reject）が出たときの対処
検証層は完璧ではありません。正しい回答を誤って unsupported 判定するケースが必ず出る。誤検出が増えると現場で検証層が信頼されなくなり、最終的に運用がショートカットされる事態に至る。
対策は2段構え。第一に、検証用のプロンプトで「文書に明示的に書かれていなくても、書かれた内容から論理的に直接導ける場合は supported とする」など、判定基準の中間階調を許す設計に調整する。第二に、誤検出ログを定期的にレビューし、しきい値や検索プールの広さを調整する観測サイクルを回す。Datadog LLM Observabilityのような観測基盤と組み合わせると、誤検出のラベリングをチーム横断で蓄積しやすくなります。
代替アプローチ: 検証層を入れない選択肢
検証層が現実的でない場合の代替も整理しておきます。最終ユーザー向けには「この回答は自動検証されていません」のディスクレーマを明示し、信頼度の表示を回答に含める。エージェント運用では、検証層の代わりにhuman-in-the-loop承認ゲートを物理的に設置する。検証層を諦めるのではなく、検証コストを人間の判断で代替する構造。
AIエージェント時代に検証層が必須化する流れ
検証層は単なる品質向上の話ではありません。AIエージェントが業務判断（在庫補充の指示・出荷スケジュール変更・顧客への通知発射など）に直結する時代では、ハルシネーション1件が物理的損失に直結します。実際、AIエージェントによる業務監視の事例として、ある物流現場では出荷の遅延傾向をシミュレーション環境上のエージェントが追跡する取り組みも報告されている。こうした現場運用では、生成された分析結果がそのままアラート発火やオペレーション指示に流れる構造。「行動前の拒否ゲート」を独立に置く設計は前提条件と言える状況になりつつあります。
よくある質問
Q. 検証用モデルは生成用と何を変えるべきですか？
プロバイダ・モデル系列・推論時のシステムプロンプトの3点を変えるのが原則です。同じプロバイダ内で別モデルを使うだけだと訓練データの重複により共通バイアスが残ります。OpenAI系で生成→Anthropic系で検証、のようなクロスプロバイダ構成が安全側。
Q. 検証層を入れるとレイテンシはどれくらい増えますか？
同期実行の場合、生成パスとほぼ同等の時間がかかります。claimを並列に検証すれば抑えられますが、それでも100〜500ミリ秒の追加は見込んでおいてください。非同期化やサンプリングでの緩和が現実的です。
Q. 既存のRAGに後付けで導入できますか？
後付けで導入できます。検証層は生成パイプラインの後段に独立したPython関数として挟むだけなので、既存の検索ロジック・生成ロジックには手を入れずに済みます。15行の追加でMVPは動きます。
Q. 検証が誤検出した場合の運用はどうすればよいですか？
誤検出ログを蓄積し、週次でレビューする運用が現実的です。誤検出が増えるとオペレーターが検証層を無視し始めるため、しきい値調整と判定基準のプロンプト調整を継続することが鍵。Datadog LLM Observabilityのような観測ツールと組み合わせると、誤検出ラベリングを継続蓄積しやすくなります。
まとめ
RAGが取得文書を引用しながら嘘をつく問題は、retrieve → generate → verify の3段階化で本番投入前に検出できます。「異なるモデル × 異なる証拠 × 異なるプロンプト」の3軸独立化を守り、Python約15行で書ける検証ステップから始めるのが現実的な第一歩。
AIエージェントが業務行動に直結する時代では、検証層はもはやオプションではなく、行動前の拒否ゲートとして前提条件になりつつあります。同一モデル自己評価では検出できない構造的盲点を理解した上で、検証パスを独立して設計してください。Datadog LLM Observabilityなどの観測ツールと組み合わせれば、検証結果の継続観測まで含めた運用設計に発展させられる構成です。
