RAGの検索精度が上がらない本当の理由──チャンクとプロンプトだけでは解決しない課題

社内情報検索やカスタマーサポートなど、RAG（Retrieval-Augmented Generation）を活用したチャットボットの導入事例が急増しています。しかし、実際に構築した人の多くが同じ悩みを抱えています。「データベースには確実に存在する情報なのに、なぜかLLMが参照してくれない」という問題です。

ikedaさんの投稿は、まさにこの普遍的な課題を指摘しています。チャンクサイズの調整、ハイブリッド検索の導入、リランキングの実装、プロンプトの最適化──技術的な施策を一通り試しても、ユーザーの曖昧な一言で検索が空振りしてしまう。この現象は、RAGシステムの本質的な弱点を浮き彫りにしています。

RAGの検索精度を上げるための定石は、次のような技術的アプローチです。

よく使われる改善策

これらは確かに効果的です。実際、多くのケースで検索精度は向上します。しかし、投稿者が指摘するように「ユーザーの曖昧な一言」という現実の前では、技術的な改善だけでは不十分なのです。

問題の核心は、**検索クエリの品質**にあります。ユーザーは「あれ、どうだったっけ?」「前に見た資料」といった曖昧な表現で質問します。一方、データベースには「2024年度第3四半期売上報告書」といった具体的な名称で格納されている。この認識ギャップを、いくらチャンクサイズを調整しても埋められません。

他のアプローチとの比較で見えてくるもの

RAGの課題を理解するには、他の情報検索手法と比較すると本質が見えてきます。

**従来のキーワード検索**では、ユーザーは「適切なキーワードを入力する責任」を理解していました。Google検索でも、最初は広い検索語から始めて徐々に絞り込むという行動が一般的です。ユーザー側に「検索スキル」が求められ、それが前提とされていました。

**ChatGPTのような汎用LLM**では、膨大な学習データから確率的に応答を生成します。データソースが明確でないため、ユーザーも「参考程度」と割り切って使います。正確性への期待値は、実はそこまで高くありません。

**RAGシステム**は、この両者の中間に位置します。特定のデータベースを参照するため「正確な回答が得られるはず」という期待が生まれます。同時に、自然言語で質問できるため「キーワードを工夫する必要はない」とも思われます。この**期待値の高さ**と**クエリ品質の低さ**のギャップが、RAG最大の課題です。

RAGシステムが抱える構造的問題

RAGの精度問題には、技術的改善だけでは解決できない3つの構造的要因があります。

**1. 期待値のインフレーション**

投稿者が指摘するように、LLMツールの急速な進化により、ユーザーの期待値は常に上昇します。ChatGPTが流暢に答えられるのだから、社内チャットボットも同じように答えられて当然だと思われます。しかし、RAGシステムは検索結果に依存するため、検索が失敗すれば何も答えられません。この認識ギャップは説明しても理解されにくいのです。

**2. 質問の曖昧性という本質的課題**

ユーザーは自分が何を知りたいかを正確に言語化できません。「あの資料」「前に聞いた話」といった指示代名詞や時間的な曖昧さを含む質問は、ベクトル検索でも捉えきれません。人間同士の会話なら文脈で補完できますが、RAGシステムには過去の対話履歴や暗黙の共通理解がないため、文字通りの意味でしか処理できません。

**3. データ構造と検索クエリのミスマッチ**

組織のデータは、作成者の視点で構造化されています。報告書のタイトル、フォルダ名、メタデータはすべて「情報を整理する側」の論理で設計されています。一方、検索者は「自分の課題」を起点に質問します。この視点の違いを吸収するには、単なる意味的類似度以上の知識が必要です。

RAGに向いている場面、向いていない場面

これらの分析から、RAGシステムの適用範囲が見えてきます。

**RAGが有効な場面:**

**RAGが苦戦する場面:**

技術的改善だけでは限界があるとはいえ、実践できる対策はあります。システム側とユーザー側の両面からアプローチしましょう。

アクション1: クエリ拡張の自動化を実装する

ユーザーの曖昧な質問を、LLMに一度解釈させてから検索クエリに変換します。

# ユーザー入力: "前回の売上の資料"
# ↓ LLMで拡張
# 検索クエリ: "売上報告 OR 売上実績 OR セールスレポート 期間:直近3ヶ月"

ユーザーの質問をそのまま検索するのではなく、「この質問で探している情報は何か」をLLMに推論させ、複数の検索キーワードと条件を生成させます。これだけで検索のヒット率は大幅に向上します。

アクション2: 「検索失敗時の対話」を設計する

検索結果が不十分な場合、沈黙するのではなく、ユーザーに質問を返すフローを組み込みます。

ボット: 「売上に関する資料を探していますが、いくつか候補があります。
        - 月次売上報告書
        - 四半期業績サマリー
        - 年間売上推移分析
        どれに近いですか?または、部門や時期を教えていただけますか?"

一発で完璧な回答を目指すのではなく、対話を通じて絞り込む設計にします。これはユーザーに「検索の限界」を自然に理解させる効果もあります。

アクション3: 期待値調整のオンボーディングを用意する

システム導入時に、「このチャットボットができること/できないこと」を明示的に伝えるチュートリアルを用意します。

【このチャットボットの得意なこと】
✓ 文書名や日付が明確な資料の検索
✓ 社内規定やFAQの参照
✓ プロジェクト名や担当者名からの情報検索

【こんな質問がおすすめ】
◯ "2024年のセキュリティポリシーを教えて"
◯ "Aプロジェクトの進捗報告書はどこ?"
× "あの件どうなった?" (主語や時期が不明確)
× "なんかいい感じの資料ない?" (条件が曖昧)

ユーザー教育は地味ですが、期待値のギャップを埋める最も確実な方法です。

RAGシステムの精度問題は、単なる技術的なチューニングでは解決しません。ユーザーの認知特性、期待値のマネジメント、そして検索という行為そのものの本質的な難しさが絡み合っています。

完璧を目指すのではなく、「どこまでできて、どこからできないか」を明確にし、その境界線でユーザーとシステムが協力する設計が現実的です。技術の進化は続きますが、人間の認知の曖昧さは変わりません。その前提に立った設計こそが、実用的なRAGシステムを作る鍵となります。

この情報は @ikeda さんの投稿を参考にしています。