RAG運用の落とし穴：埋め込み空間のドリフト検知とハルシネーション対策の実務

「PoC（概念実証）のときはあんなに賢かったのに、なぜ本番運用を始めた途端に見当違いな回答をするようになったのか？」

これは、RAG（検索拡張生成）システムの運用現場において、非常によく聞かれる悩みの一つです。開発環境で入念にテストし、関係者全員が「これならいける！」と確信してリリースしたはずのAI。しかし、日が経つにつれて、あるいは新しいデータを追加した直後から、まるで別人のように不正確な情報を出力し始めることがあります。

多くのエンジニアはここで、プロンプトを修正したり、LLM（大規模言語モデル）自体を疑ったりします。もちろんそれらも重要ですが、実はもっと根本的な部分、「データの居場所」がズレていることが原因であるケースが非常に多いのです。

これを専門的には「埋め込み空間のドリフト（Embedding Drift）」と呼びます。

本記事では、この見えにくい「ズレ」を可視化し、精度が低下し始めたRAGシステムを正常な軌道に戻すための実践的なテクニックを解説します。複雑な数式を並べるのではなく、実証データに基づき、明日から現場で使える論理的な診断フローと解決策を整理しました。

AIシステムの健康状態を維持するためのアプローチとして、具体的な仕組みを見ていきましょう。

本ガイドの活用と前提：ハルシネーションの「質」を見極める

トラブルシューティングを始める前に、まず冷静に状況を整理する必要があります。AIが間違った回答をしたとき、その原因は大きく分けて3つの領域に潜んでいます。

1. 生成モデル（LLM）の暴走: 前提知識がないのに無理やり回答を作ろうとした場合。
2. プロンプトの不備: 指示が曖昧で、意図しない解釈をされた場合。
3. 検索（Retrieval）の失敗: そもそも回答に必要な情報が取得できていない、あるいは間違った情報を渡している場合。

今回フォーカスするのは、3番目の「検索の失敗」、その中でも特に時間の経過やデータの変化によって引き起こされる問題です。

プロンプトの問題か、検索の問題か

まず最初に実施すべき切り分けはシンプルです。「検索されたドキュメント（チャンク）の中に、正解が含まれていたか？」を確認します。

もし、検索結果の中に正解が含まれているのにAIが間違えたなら、それはプロンプトやLLMの問題です。しかし、検索結果に関連性の低いドキュメントばかりが並んでいたなら、それは検索システム、つまりベクトル検索側の問題と判断できます。

RAGにおける「ハルシネーション（幻覚）」の多くは、AIが自ら幻覚を見ているのではなく、「間違った参考書を渡されて、それを元に真面目に答えた結果」であることが少なくありません。これは一般に「ゴミ情報の注入（Garbage In, Garbage Out）」と呼ばれる現象です。

「埋め込み空間のドリフト」とは何か

では、なぜ検索に失敗するのでしょうか。ここで登場するのが「埋め込み空間のドリフト」です。

ベクトル検索の仕組みでは、全ての言葉や文章は、多次元空間上の「座標」として表現されます。似た意味を持つ言葉は近くに、異なる意味を持つ言葉は遠くに配置されます。これは、巨大な図書館の中で、関連する本が同じ棚に並んでいるような状態です。

ドリフト（Drift）とは、この「棚の並び方」や「利用者の探し方」が、時間の経過とともにズレてしまう現象を指します。

• Concept Drift（概念の漂流）: ユーザーが使う言葉の意味やニュアンスが変わったり、全く新しい用語（未知語）が検索されたりすることで、既存の座標配置が役に立たなくなる状態。例えば、開発時には想定していなかった俗語や略語をユーザーが使い始めた場合などが該当します。
• Data Drift（データの漂流）: 新しいドキュメントを追加・更新したことで、空間内の密度が変わり、本来近くにあるべき情報が遠ざかってしまう（検索されにくくなる）現象。本棚の特定ジャンルにだけ本が大量に詰め込まれ、整理がつかなくなった状態をイメージすると分かりやすいでしょう。

本番運用における監視のゴール

運用において目指すべきゴールは、エラー率を完全にゼロにすることではありません。それは現実的に困難です。目指すべきは、「ズレが発生した瞬間にそれを検知し、自動または手動で修正できる状態」を構築することです。

ユーザーから「最近、回答の精度が落ちた」と指摘されてから調査するのではなく、ダッシュボードの数値から「ベクトルの分布が偏り始めたため、再インデックスの時期が近い」と先回りして対応できる論理的な運用体制を目指します。

診断フロー：精度低下の原因を特定する3つのステップ

問題が発生した際、闇雲にパラメータを調整するのは得策ではありません。まずは実証データに基づいた正確な検査が必要です。論理的に原因を特定するための3ステップの診断フローを紹介します。

Step 1: 検索結果のRelevance（関連性）確認

まず、ユーザーの質問（クエリ）と、システムが検索してきた上位K件のドキュメント（チャンク）の関連性をスコアリングします。

これにはコサイン類似度（Cosine Similarity）という指標を用います。ベクトル同士がどれくらい同じ方向を向いているかを表す数値で、1に近いほど似ていることを示します。

• チェック項目: 検索結果上位のコサイン類似度スコアが、PoC（概念実証）時と比較して低下していないか。
• 目安: 例えば、導入時の平均スコアが0.85だったのに対し、直近のログでは0.72まで落ちている場合、明らかに検索精度が劣化しています。

ただし、数値だけでなく、実際に内容を目視（あるいはLLMに判定させる）することも重要です。「数値は高いのに内容は無関係」というケースも稀に存在します。これは、埋め込みモデルが特定のキーワードだけに過剰反応している場合に起こり得ます。

Step 2: ユーザー質問の分布変化を確認

次に、ユーザーがどのような質問をしているかを分析します。運用開始直後は想定通りの質問が入力されていても、時間が経つにつれてユーザーもシステムに慣れ、より専門的な質問や、略語を使ったラフな質問を入力するようになります。

ここで確認すべきは、「入力されたクエリのベクトルが、学習データの分布から外れていないか」です。

もし、クエリのベクトルが、データベース内のどのドキュメント・ベクトルとも遠い場所（孤立した空間）にプロットされるなら、それはシステムにとって「未知の領域」の質問が来ていることを意味します。これがConcept Driftの兆候です。例えば、社内で新しいプロジェクト名が使われ始めたにもかかわらず、知識ベースにはその定義が存在しない場合などがこれに当たります。

Step 3: ベクトルDB内の埋め込み分布を確認

最後に、データベース側の状態を確認します。新しいデータを追加した後、特定のトピック周辺だけ密度が異常に高くなっていないかをチェックします。

HNSW（Hierarchical Navigable Small World）などのアルゴリズムを用いたベクトル検索インデックスでは、データの密度や分布が大きく変わると「近傍探索」の精度やパフォーマンスに影響が出ることがあります。一部のジャンルだけドキュメントが大量に追加された結果、そのジャンルの検索精度だけでなく、隣接する他のジャンルの検索結果まで歪んでしまうことがあるのです。これがData Driftの一種です。

このような偏りが発生した場合、単にデータを追加するだけでなく、検索エンジンのチューニングが必要です。例えば、Apache Luceneやpgvectorといった主要な実装環境では、インデックス構築時のパラメータ（ef_construction や M など）を現在のデータ量や分布に合わせて再調整することが推奨されます。定期的にデータの偏りを監視し、必要に応じてインデックスの再構築を行うことで、安定した検索精度を維持できます。

ケーススタディ1：ユーザーの質問傾向が変わり、検索がヒットしない

RAG運用において直面しやすい具体的なトラブルシューティングのアプローチを解説します。まずは「ユーザーの変化」による検索精度の低下に焦点を当てます。

症状：未知の用語に対する「もっともらしい嘘」の増加

社内ヘルプデスクAIなどの運用において、導入当初は「パスワードのリセット方法は？」といった定型的な質問に的確に答えていたシステムが、時間の経過とともに精度を落とすケースは珍しくありません。

例えば、「VPNが繋がらないんだけど、どうすれば？」という質問に対し、全く関係のない「プリンターの接続方法」を回答してしまうような現象です。ログを確認すると、検索スコア（類似度）が著しく低下していることがよくあります。

この背景には、ユーザーが「VPN」という略語を使用しているのに対し、ナレッジベース内には「仮想プライベートネットワーク」という正式名称でしか記述がなく、埋め込みモデル（Embedding Model）がこの2つを十分に関連付けられていない（ベクトル空間上の距離が遠い）という問題が潜んでいます。

原因：Out-of-Distribution（分布外）データの流入

これは典型的なOut-of-Distribution（分布外）の問題です。モデルが学習した（あるいはインデックス作成時に想定した）言葉の空間と、ユーザーが実際に使う言葉の空間にズレが生じています。

特に業界固有の略語や、社内スラング、新製品のプロジェクトコードなどは、一般的な事前学習済みモデル（OpenAIの埋め込みモデルなど）では、正確な意味上の位置関係を捉えきれないことがあります。モデルにとって「VPN」と「仮想プライベートネットワーク」は、人間が直感的に理解するほど「同じ意味」として認識されていないのです。

解決手順：クエリ拡張の実装とファインチューニングの判断基準

この問題への即効性のある対策として、クエリ拡張（Query Expansion）が挙げられます。

特に効果的な手法として知られるのが、HyDE（Hypothetical Document Embeddings）です。これは、ユーザーの質問をそのまま検索にかけるのではなく、一度LLMに「この質問に対する理想的な回答」を（内容は不正確でも構わないので）生成させ、その生成された回答のベクトルを使って検索を行うアプローチです。

1. ユーザー質問: 「VPNが繋がらない」
2. LLMによる仮回答生成: 「VPN（仮想プライベートネットワーク）の接続トラブルには、まずWi-Fiの設定を確認し...」
   • ※ここでは推論能力の高いLLMを利用することが重要です。OpenAIのAPIを利用する場合、GPT-4oやGPT-4.1などのレガシーモデルは順次廃止されており、高度な推論機能（ThinkingとInstantの自動ルーティング）や100万トークン級のコンテキスト処理を備えたGPT-5.2が新たな標準モデルとして提供されています。こうした最新の業務標準モデルを活用することで、文脈をより正確に補完した適切な用語を含む仮回答が生成されやすくなります。既存のシステムで旧モデルを使用している場合は、提供終了によるシステム停止を避けるため、プロンプトをGPT-5.2で再テストし、速やかに移行を進めることが推奨されます。
3. ベクトル検索: この仮回答を使って検索を実行

こうすることで、「VPN」と「仮想プライベートネットワーク」という用語のギャップをLLMの広範な知識で埋めることができます。これにより、ベクトル空間上の「検索の起点」を、正解ドキュメントの近くに強制的に移動させるわけです。

もし、HyDEを使っても精度が改善しないほど専門用語が特殊な場合は、埋め込みモデル自体のファインチューニング（再学習）を検討するフェーズに入ります。しかし、これにはコストと専門的なデータセット作成が必要となるため、まずは最新のLLMを用いたクエリ拡張で対応できないか検証するのが定石です。

ケーススタディ2：データ追加後に過去の回答精度が落ちた

次に、運用側のオペレーションによって起こりがちな「データ追加による劣化」について解説します。

症状：古いドキュメントが検索されなくなる

技術検索システムの運用事例において、新製品のマニュアルを大量に追加した翌日から、「旧製品の仕様」に関する質問の回答精度が落ちるという現象が報告されることがあります。新製品に関する回答は正確ですが、旧製品について質問しても、なぜか新製品の情報を無理やり参照して回答してしまう状態です。

原因：埋め込み空間の密度変化と「近傍」の変質

これは、インデックスの汚染とも言える現象です。新製品のマニュアルと旧製品のマニュアルは、用語や文脈が非常に似通っています。大量の類似データが空間に追加されたことで、ベクトル空間内のある領域が過密状態になりました。

近似近傍探索（ANN）アルゴリズムは、効率的に検索するために空間をクラスタリング（区分け）しています。データが偏って追加されると、このクラスタリングの境界線が不適切になり、本来検索されるべき古いデータが「探索候補」から漏れてしまうことがあるのです。つまり、新しい本が大量に入荷したせいで、古い本が奥の方に追いやられて見えなくなってしまった状態と言えます。

解決手順：再インデックス化とチャンク戦略の見直し

この場合の解決策は主に2つあります。

1. インデックスの再構築（Re-indexing）:
   データの追加（Upsert）を繰り返していると、インデックス構造が最適化されていない状態（断片化のような状態）になります。定期的に、あるいは大量データ追加後は、インデックスをゼロから作り直すことで、空間の区分けを最適化できます。これはデータベースのデフラグや再編成に相当する処理です。

2. メタデータフィルタリングの徹底:
   ベクトル検索だけに頼るのではなく、明示的な条件で検索範囲を絞ります。例えば、ドキュメントに「製品名」や「年度」といったメタデータを付与し、検索時に filter={product_id: "old_model_A"} のように指定します。これにより、ベクトル空間全体から探すのではなく、最初から「旧製品の棚」に絞ってから類似検索を行うため、ノイズ（新製品の情報）を確実に排除できます。

予防と監視：寝ている間にシステムを壊さないために

トラブルが起きてから対処するのは、いわば「対症療法」です。理想的なのは、問題が表面化する前に予兆を検知する「予防医療」のアプローチです。ここでは、安定稼働を実現するための監視体制について解説します。

監視すべきKPI：類似度分布と検索順位の安定性

日々の運用でモニタリングすべきは、以下のKPIです。

• 平均コサイン類似度（Average Cosine Similarity）: 全クエリに対する検索結果トップ1の類似度の平均値。これが下がり始めたら、ドリフトの兆候です。
• ヒット率（Hit Rate）: ユーザーのフィードバック（Good/Badボタンなど）に基づき、検索結果が役に立った割合。
• 検索順位の変動率: 定点観測用の質問セット（ゴールデンセット）を用意し、定期的に同じ質問を投げます。昨日まで1位だった正解ドキュメントが、今日は5位に落ちているなら、インデックスになんらかの歪みが生じています。

自動テスト：Golden Datasetを用いた回帰テストの組み込み

ソフトウェア開発における回帰テスト（リグレッションテスト）と同様に、RAGシステムでも自動テストが必要です。

「正解となるドキュメント」と「質問」のペアを100件ほど用意し、これをGolden Dataset（黄金のデータセット）とします。データの更新やモデルの変更を行うたびに、このデータセットに対して検索を実行し、正解ドキュメントが正しく上位に来るかをチェックします。

評価の自動化には、RagasやArize Phoenixといった評価フレームワークの活用が効果的です。これらをCI/CDパイプラインに組み込むことで、「Faithfulness（忠実性）」や「Context Precision（文脈精度）」といった指標を継続的に監視できます。「精度スコアが基準値を下回ったらデプロイを停止する」というガードレールを設けることで、システムが意図せず劣化するのを防ぐことが可能です。

※各評価フレームワークの対応モデルや最新の仕様については、必ず公式ドキュメントをご確認ください。

運用体制：アラート発報時のエスカレーションフロー

最後に、人間が介入すべきタイミングを定義しておきましょう。

全てを自動化することはできません。例えば、「類似度スコアが0.6を下回るクエリが全体の5%を超えた場合」にアラートを通知し、担当者がそのクエリを確認するフローを作ります。確認の結果、それが新しいトレンドワードであれば辞書やナレッジベースに追加し、単なるノイズであれば無視する。この地道なフィードバックループこそが、長期間にわたって精度の高いAIを維持するための実践的なアプローチです。

まとめ

RAGシステムの精度維持は、モデルを導入して終わりではありません。むしろ、そこからが本当の運用フェーズの始まりです。本記事の重要ポイントを振り返りましょう。

1. ハルシネーションの多くは検索ミス: プロンプトを疑う前に、検索結果の関連性（Relevance）を確認する。
2. ドリフトは避けられない: ユーザーの言葉もデータも変化する。それを前提とした監視体制を作る。
3. HyDEとメタデータで武装する: クエリ拡張とフィルタリングは、ドリフトに対する強力な防波堤になる。
4. 自動テストを習慣化する: Golden Datasetを使った定点観測で、劣化を早期に発見する。

データは常に変化するものです。その変化を恐れるのではなく、実証データに基づいてシステムを適応させていくプロセス自体が重要です。ベクトル空間の配置を常に最新に保つことで、AIシステムはビジネスにおける信頼できる基盤であり続けるはずです。

もし、運用中のRAGシステムの精度に課題を感じた場合は、まずはログを開いてコサイン類似度を確認してみてください。そこには論理的な改善へのヒントが隠されているはずです。