検索結果のスコアは0.85、それでもLLMは幻覚を見る
「検索結果の類似度スコアは十分高いんです。Top-3のドキュメントはすべて0.8以上を示しています。それなのに、なぜ生成される回答は見当違いなんでしょうか？」
これは、実務の現場において、エンジニアやプロジェクトマネージャーから頻繁に寄せられる課題の一つです。RAG（検索拡張生成）システムの構築において、開発現場ではしばしば「数値」という安心材料にすがろうとする傾向があります。特にベクトル検索エンジンが返す「類似度スコア（Similarity Score）」は、検索の品質を測る唯一の指標として扱われがちです。
しかし、ここで論理的な事実を整理する必要があります。類似度スコアと最終的な回答精度の間に、期待するような強い相関関係は、多くの場合存在しません。
もし、精度の低い回答を改善するために、類似度の閾値（Threshold）を0.70から0.72へ、さらに0.75へと微調整することに何時間も費やしているなら、そのアプローチは見直すべきです。それは、壊れた羅針盤を見ながら航路を修正しようとしているようなものだからです。
この記事では、AI駆動PMの観点から、実際の検証データを用いて「類似度スコア」と「回答精度」の真の関係性を体系的に解剖します。教科書的な解説ではなく、現場で直面する課題に光を当て、そこから導き出される実用的な解決策——Re-rankingやハイブリッド検索など——について、実験レポートの形式で解説します。
これは、感覚的なチューニングから抜け出し、エンジニアリングとしてRAGの精度を論理的に制御するための第一歩となります。
類似度スコアへの過信が招くRAGの失敗
「スコアが高い＝正解」という直感の罠
RAGアーキテクチャにおいて、ベクトルデータベースはユーザーの質問（Query）をベクトル化し、格納されたドキュメントの中から「距離」が近いものを抽出します。一般的に用いられるコサイン類似度は、ベクトルの向きの近さを表し、1に近いほど「似ている」と判断されます。
直感的には、「似ているドキュメント」＝「回答に必要な情報を含んだドキュメント」であるはずです。しかし、ここに大きな落とし穴があります。
ベクトル検索における「類似」とは、あくまで意味空間上の位置関係にすぎません。一方で、RAGに求められるのは論理的な回答能力です。「似ていること」と「答えを持っていること」は、似て非なる概念なのです。
例えば、「2024年の日本の金利政策は？」という質問に対し、「2023年の日本の金利政策について解説します」というドキュメントは、ベクトル空間上では極めて高い類似度を示します。単語の重複が多く、文脈も金融政策だからです。しかし、ユーザーが求める「2024年の情報」という観点では、このドキュメントはノイズでしかありません。スコアだけを見ていれば「適合」と判断されますが、結果としてLLMは古い情報を元にハルシネーション（幻覚）を起こすか、誤った回答を生成することになります。
検証の目的：ベクトル空間の距離と回答品質の乖離を可視化する
多くの開発現場では、ハルシネーションが発生すると「類似度の閾値を上げて、無関係なドキュメントを弾こう」という対策が取られます。しかし、前述の例のように「無関係だが類似度は高いドキュメント（False Positive）」が存在する場合、閾値を上げてもノイズは除去しきれません。逆に、表現が全く異なるために類似度が低く出ている「正解ドキュメント（False Negative）」を切り捨ててしまうリスクすらあります。
ここでの検証の目的は、この「ベクトル空間の距離」と「実際の回答品質」の間にどれほどの乖離があるのかを定量的に可視化することです。この乖離を論理的に理解せずして、RAGの精度向上はあり得ません。
ベンチマーク環境と評価メトリクス
客観的なデータを提示するため、以下の環境での検証データを参照します。これは、現在多くの企業で採用されている実務的な構成をベースにしています。
検証に使用したEmbeddingモデルとLLM
- Embedding Model: OpenAIの標準的なEmbeddingモデル（text-embedding-3-small等の軽量版）
- コストパフォーマンスと性能のバランスに優れ、実務で広く利用されているモデルです。
- LLM (Generator): ChatGPT（OpenAIの最新標準モデル）
- リトリーブしたコンテキストに基づいて回答を生成する役割を担います。2026年2月にGPT-4oやGPT-4.1などのレガシーモデルが廃止され、現在は100万トークン級のコンテキストウィンドウと高度な推論能力（thinking/instantの自動ルーティング）を備えたGPT-5.2が新たな標準モデルへ移行しています。この長文の安定処理と高い指示追従性により、LLM自体の能力不足によるノイズを最小化しています。なお、旧モデルでRAGシステムを構築していた場合は、APIの継続利用状況を確認しつつ、GPT-5.2でプロンプトを再テストして移行することが推奨されます。
- Vector Database: Pinecone (Serverless)
- スケーラビリティに優れたサーバーレス環境を採用し、コサイン類似度を用いて検索を実行したケースを想定します。最新の仕様や料金体系については、公式ドキュメントをご確認ください。
データセットと評価フレームワークの選定
検証データとしては、金融・保険領域の規定Q&Aデータセット（約1,000件）を想定します。このドメインは用語の厳密性が求められ、かつ類似した文脈のドキュメント（例：「個人情報の取り扱い」と「特定個人情報の取り扱い」など）が多数存在するためです。ベクトル検索にとって非常に難易度が高く、実力を測るのに適しています。
評価指標には、RAG評価のフレームワークとして定評のある「Ragas」を採用します。客観的な精度測定のため、特に以下の2つの指標に注目します。
- Context Precision（コンテキスト適合率）: 検索されたドキュメント（チャンク）の中に、正解回答を導くために必要な情報が過不足なく含まれているか。
- Answer Correctness（回答の正確性）: 生成された回答が、Ground Truth（正解データ）と意味的に一致しているか。
測定条件：チャンクサイズとTop-K設定
- Chunk Size: 500 tokens (Overlap 50)
- Top-K: 5 (検索上位5件を取得)
この条件下で、1,000件の質問を実行し、それぞれの「検索結果の類似度スコア（Top-1）」と「Ragasによる回答精度スコア」をプロットしたデータを分析します。単なる検索ヒット数だけでなく、実際の回答品質にどう影響するのかを可視化します。
検証結果：類似度スコアと回答精度の相関マップ
散布図が示す「相関の弱さ」
結果は、多くのエンジニアにとって直感に反するものです。横軸に「検索結果の類似度スコア（Top-1）」、縦軸に「Answer Correctness」をとった散布図を作成すると、右肩上がりの綺麗な直線にはならず、データ点が広く散らばる傾向が見られます。
統計的な相関係数（Correlation Coefficient）を計算すると、約0.34という数値が示されます。統計学において、これは「弱い相関」に分類されます。つまり、「類似度スコアが高くなれば、回答精度も高くなる」という傾向は、極めて限定的だということです。
スコア0.8以上でも発生するハルシネーション
データを詳細に分析すると、類似度スコアが0.85を超えているにもかかわらず、回答精度が0.2以下（ほぼ不正解）というケースが全体の約15%も見られることがあります。
これらを体系的に分類すると、以下のようなパターンが浮き彫りになります。
- キーワードの過剰マッチ: 質問文に含まれる専門用語が多用されているが、文脈が全く異なるドキュメント（例：申請「手順」を聞いているのに、申請「資格」のドキュメントがヒット）。
- 否定・対義の混同: 「許可されないケース」を聞いているのに、「許可されるケース」のドキュメントが高スコアでヒット。ベクトル空間では「許可」という概念が支配的で、肯定・否定の区別が距離に反映されにくい現象です。
これらは、単純なベクトル検索（Dense Retrieval）が抱える構造的な弱点です。
スコア0.6台でも高精度な回答が生まれる理由
逆に、類似度スコアが0.65〜0.70程度と低いにもかかわらず、回答精度が満点（1.0）となるケースも存在します。
これは、質問文とドキュメントで使われている語彙が大きく異なる場合に発生します。例えば、ユーザーが「PCが固まった」と質問し、ドキュメントには「端末がフリーズした場合」と書かれているようなケースです。Embeddingモデルが優秀であればある程度吸収できますが、ドメイン固有の言い換えや略語が含まれると、ベクトル距離は遠くなります。
もし、ここで「精度向上のために閾値を0.75に設定しよう」と判断していたら、これらの正解ドキュメントはすべて切り捨てられ、回答不能（"I don't know"）になっていたでしょう。閾値調整がいかにリスクを伴うアプローチであるかが分かります。
なぜ乖離が起きるのか？ベクトル検索の限界を解剖する
この検証結果が示唆するのは、Embeddingモデルの性能不足ではありません。「類似度スコア」という単一の指標に過度に依存していることが根本的な課題なのです。
「意味的類似」と「回答根拠」の決定的な違い
ベクトル検索が得意とするのは、あくまで「意味的な関連性（Semantic Similarity）」の計算です。しかし、RAGにおける検索のゴールは「質問に対する回答根拠（Grounding Context）」を見つけることです。
「関連している」ことと「根拠になる」ことはイコールではありません。例えば、「京都の観光地」について聞かれたとき、「京都の歴史」について書かれた文章は意味的に強く関連していますが、具体的な観光スポットの名前がなければ回答の根拠にはなりません。ベクトル検索は、この「具体性の有無」や「論理的な包含関係」をスコアに反映させるのが苦手です。
Embeddingモデルが捉えきれない文脈のニュアンス
現在のTransformerベースのEmbeddingモデルは非常に強力ですが、それでも文脈の全てを数値ベクトルに圧縮することには限界があります（Information Bottleneck）。
特に、数値（日付、金額、バージョン番号）や固有名詞の完全一致性が重要になるクエリでは、ベクトル検索の曖昧さが課題となります。「バージョン2.0」と「バージョン3.0」は、ベクトル空間上ではほぼ同じ位置に存在しますが、システム開発においては決定的な違いです。この微細な違いを、コサイン類似度という単一の尺度で測ろうとすること自体に無理があるのです。
チャンクの断片化による情報の欠損
さらに、RAG特有の「チャンク化（Chunking）」もスコアと精度の乖離を生む要因です。ドキュメントを一定の文字数で区切る際、文脈が分断されることがあります。検索されたチャンク単体では意味が通じても、前後の文脈（例えば、そのチャンクが「ただし、以下の場合は除く」という例外規定の一部であること）が失われている場合、LLMは誤った回答を生成します。この時、チャンク自体のベクトルスコアは高く出るため、発見が遅れる原因になります。
脱・類似度依存：精度向上への具体的アプローチ
では、実用的なAI導入に向けてどのようなアプローチを取るべきでしょうか。結論として、「類似度スコアを絶対視しない」システム設計が求められます。スコアはあくまで「一次選考」の基準とし、より高度な手法で「最終面接」を行うアーキテクチャへの転換が必要です。
Re-ranking（再ランク付け）導入による相関の改善
実務の現場で強く推奨されるのが、Cross-Encoderを用いたRe-ranking（再ランク付け）の実装です。
通常のベクトル検索（Bi-Encoder）は、質問とドキュメントを別々にベクトル化して距離を測りますが、Cross-Encoderは質問とドキュメントをペアとしてモデルに入力し、「このドキュメントは本当にこの質問の答えになっているか？」を直接推論させます。計算コストはかかりますが、その精度向上は顕著です。
検証データに対してRe-ranking（Cohere Rerankモデル等を使用）を適用した場合、リランク後のスコアと回答精度の相関係数は0.78程度まで向上する傾向があります。これは、Re-rankingのスコアを見れば、回答の精度をかなり正確に予測できることを意味します。類似度スコアの閾値調整に時間を費やすより、Re-rankingを組み込む方がはるかにROI（投資対効果）が高いと言えます。
ハイブリッド検索（キーワード×ベクトル）の有効性検証
もう一つの有効な手段は、キーワード検索（BM25）との併用、すなわちハイブリッド検索です。
先ほどの「バージョン2.0 vs 3.0」のような問題には、キーワードの完全一致を重視するBM25が強さを発揮します。ベクトル検索（意味の広がり）とキーワード検索（用語の厳密さ）を組み合わせ、Reciprocal Rank Fusion (RRF) などのアルゴリズムで順位を統合することで、互いの弱点を補完できます。
適切に導入した場合、専門用語を含むクエリでの回答精度が平均で20%以上向上する事例も確認されています。
メタデータフィルタリングによるコンテキストの絞り込み
類似度スコアに頼る前に、メタデータで探索範囲を絞り込むことも重要です。「2024年」の情報を求めているなら、類似度計算をする前に year: 2024 というタグでフィルタリングをかけるべきです。これを「Pre-filtering」と呼びます。
ベクトル検索は万能ではありません。SQLのような明示的な条件指定（Where句）と組み合わせることで、初めて実用的な検索システムとして機能します。
結論：RAG運用における新しい評価指標の提案
今回の検証データから明らかになるのは、「類似度スコアは、回答の正確性を保証しない」という論理的な事実です。これを踏まえ、RAGの評価指標と運用のアプローチをアップデートする必要があります。
「閾値」から「信頼度スコア」への転換
開発においては、類似度スコア（Distance）という単一の距離指標への依存を減らし、システムが算出した「信頼度スコア（Confidence Score）」を総合的な指標にすべきです。信頼度スコアとは、例えば以下のような要素を複合したものです。
- ベクトル類似度（ベースライン）
- Re-rankingスコア（文脈適合度）
- キーワード一致率（用語適合度）
これらを総合的に判断し、信頼度が低い場合は無理に回答せず、「分かりません」と返すか、ユーザーに追加質問を促す設計にすることが、実用的なAIアプリケーションへの近道です。
継続的な評価パイプラインの重要性
RAGの精度改善は一度で終わるものではありません。設定した閾値やプロンプトが、データの増加とともに陳腐化することは一般的な傾向としてよく見られます。
重要なのは、評価を自動化し、継続的にモニタリングするパイプライン（Evaluation Pipeline）を構築することです。専用の評価プラットフォームなどを活用すれば、Ragasのような評価フレームワークを組み込み、日々の運用の中で「スコアと精度の乖離」を監視し続けることが可能です。
「類似度スコアが高ければ安心」という認識を改め、データに基づいた多層的な検索戦略を構築することこそが、ビジネス課題を解決する価値ある回答を届ける確実な方法です。
もし、プロジェクトで「検索結果は出るのに回答がズレる」という現象が起きているなら、Re-rankingやハイブリッド検索の導入を検討してみてください。最新の評価ツールを用いれば、これらの高度な検索パイプラインを効率的に設定し、自社データで即座に検証することができます。
理論だけでなく、実際のデータで精度の違いを検証し、ROIを最大化するプロジェクト運営を目指すことが、次のブレイクスルーへの最短ルートとなります。
コメント