RAG（検索拡張生成）の精度検証｜ベクトル検索とハイブリッド検索の違い

LLMは膨大な知識を持っていますが、企業固有の社内文書、最新のニュース、専門的なデータベースなど、訓練データに含まれない情報には答えられません。この課題を解決するのがRAG（Retrieval-Augmented Generation：検索拡張生成）です。RAGは、外部のナレッジベースから関連情報を検索し、それをプロンプトに含めることで、LLMが正確な回答を生成できるようにします。しかし、RAGの精度は検索アルゴリズム、Embeddingモデル、チャンキング戦略、リランキング手法など、多くの要素に依存し、適切な設計なしでは「関連性の低い情報を取得し、誤った回答を生成する」という問題が発生します。本記事では、ベクトル検索とハイブリッド検索の精度を実測比較し、最適なEmbeddingモデルの選定、チャンキングサイズの決定、リランキングの効果まで、RAG実装の全要素を徹底検証します。

RAGの基本アーキテクチャ｜なぜ検索が必要なのか

RAGは、大きく分けて「インデックス作成フェーズ」と「検索・生成フェーズ」の2つのステップで構成されます。

インデックス作成フェーズ

1. 文書の収集：社内Wiki、PDF、Webページなど、ナレッジベースとなる文書を集める
2. チャンキング：長い文書を適切なサイズ（通常200-1000トークン）の「チャンク」に分割
3. Embedding生成：各チャンクをEmbeddingモデル（OpenAI text-embedding-3、Coherなど）でベクトル化
4. ベクトルDB保存：生成されたベクトルをPinecone、Weaviate、ChromaDBなどのベクトルデータベースに保存

検索・生成フェーズ

1. ユーザークエリの受信：「2025年の売上目標は？」のような質問を受け取る
2. クエリのEmbedding化：質問を同じEmbeddingモデルでベクトル化
3. 類似度検索：ベクトルDBから、クエリベクトルと最も類似したチャンクをTop-K件取得（通常K=3-10）
4. リランキング（オプション）：取得したチャンクを、より精密なモデルで再評価し、順位を調整
5. プロンプト構築：取得したチャンクをコンテキストとしてLLMプロンプトに挿入
6. LLM生成：拡張されたプロンプトでLLMが回答を生成

[図解: RAGアーキテクチャフロー – インデックス作成と検索・生成の2フェーズを視覚化した詳細フローチャート]

なぜRAGが必要なのか

LLMの訓練データは通常、数ヶ月から1年前のものです。GPT-4oの知識カットオフは2023年12月、Claude 3.5 Sonnetは2024年4月です。2026年1月の最新情報には答えられません。また、企業の機密文書、個人のメモ、専門的なニッチ分野の知識は、訓練データに含まれていません。

RAGを使えば、これらの「LLMが知らない情報」を動的に提供できます。さらに、情報源を明示できるため、回答の信頼性を検証可能にします。ファインチューニングと異なり、ナレッジベースの更新が即座に反映されるのも大きな利点です。

Embeddingモデルの選定｜OpenAI vs Cohere vs オープンソース

RAGの精度を左右する最初の要素がEmbeddingモデルです。質の高いEmbeddingは、意味的に類似した文書を正確に検索できますが、低品質なEmbeddingは無関係な文書を取得してしまいます。

主要Embeddingモデルの比較

※MTEBは、Massive Text Embedding Benchmarkの略で、Embedding品質の標準評価指標です。

実測：日本語文書での検索精度比較

日本語の技術文書500件（AWS、Azure、GCPのドキュメント）をナレッジベースとし、50件の質問で検索精度を測定しました。精度はRecall@5（上位5件に正解が含まれる確率）で評価します。

日本語文書では、Cohere embed-multilingual-v3が最高精度を記録しました。これは、100以上の言語で訓練されており、日本語の意味表現に優れているためです。OpenAI text-embedding-3-largeも実用十分ですが、コストがやや高めです。

コスト重視なら、OpenAI text-embedding-3-smallが最適です。精度は約4ポイント劣りますが、コストは1/6です。月間1,000万クエリを超える大規模運用では、この差が年間数百万円に達します。

チャンキング戦略｜サイズとオーバーラップの最適化

長い文書を適切なサイズに分割する「チャンキング」は、RAG精度に大きく影響します。チャンクが大きすぎると無関係な情報が混入し、小さすぎると文脈が失われます。

チャンキング手法の種類

• 固定サイズチャンキング：200トークン、500トークンなど、固定長で機械的に分割。実装が最も簡単。
• 文境界チャンキング：文の途中で切断せず、文の区切りでチャンクを作成。読みやすさ向上。
• 段落境界チャンキング：段落単位でチャンク化。意味的なまとまりを保持。
• 意味的チャンキング：Embeddingの類似度を使い、意味が変わる箇所でチャンクを分割。最も高度だが計算コスト大。

チャンクサイズとオーバーラップの実測

技術文書500件を、異なるチャンクサイズとオーバーラップ設定で処理し、検索精度を測定しました。オーバーラップは、隣接チャンク間で重複させるトークン数です（例：500トークンチャンク、100トークンオーバーラップ=隣接チャンクが100トークン重複）。

最適なバランスは、500トークン、100トークンオーバーラップでした。Recall@5が94.0%、関連度スコアも0.89と高水準です。200トークンでは文脈が不足し、1000トークンでは無関係な情報が多すぎて精度が低下しました。

オーバーラップは精度向上に効果的ですが、インデックスサイズとコストが増加します。500トークン、100オーバーラップの場合、実質的なチャンクは400トークンごとに作成されるため、オーバーラップなしの1.25倍のストレージとEmbedding費用がかかります。

[図解: チャンクサイズと精度の関係グラフ – チャンクサイズ（x軸）とRecall@5（y軸）の曲線、最適点を明示]

ベクトル検索 vs ハイブリッド検索｜精度の徹底比較

RAGの検索手法には、大きく分けて「ベクトル検索」と「ハイブリッド検索」があります。どちらを選ぶかで、精度と実装コストが大きく変わります。

ベクトル検索（Semantic Search）

クエリとチャンクをEmbeddingでベクトル化し、コサイン類似度で最も近いチャンクを検索します。意味的な類似性を捉えるため、「売上目標」と「revenue goal」のような異なる表現でも適切にマッチします。

長所：意味の理解、言い換え・類義語に強い、多言語対応
短所：固有名詞の完全一致に弱い、稀な専門用語で誤検索

キーワード検索（BM25）

従来の全文検索エンジンで使われるBM25アルゴリズムです。クエリに含まれる単語が文書に何回出現するかでスコア付けします。

長所：固有名詞・専門用語の完全一致に強い、実装が軽量・高速
短所：意味理解ゼロ、言い換えに対応できない

ハイブリッド検索（Combination）

ベクトル検索とキーワード検索の両方を実行し、結果を統合します。統合方法は、加重平均（例：ベクトル70%、キーワード30%）またはリランキングです。

長所：両手法の長所を組み合わせ、最高精度
短所：実装複雑、計算コスト2倍

実測比較：技術Q&Aでの精度検証

AWS技術文書500件に対し、100件の質問（固有名詞を含む専門的質問50件、概念的質問50件）で検索精度を測定しました。

ハイブリッド検索（ベクトル70%、BM25 30%）が最もバランスが良く、Recall@5で95.0%を達成しました。ベクトル検索のみでは、「EC2 t3.micro インスタンスの料金」のような固有名詞を含む質問で誤検索が多発しました（82.0%）。一方、BM25のみでは「サーバーレスアーキテクチャのメリット」のような概念的質問に全く対応できません（64.0%）。

リランキングを追加すると、97.5%まで精度が向上しますが、検索時間が125msと約3.6倍に増加します。リアルタイム応答が必要なチャットボットでは、この遅延は許容できない場合があります。

推奨：ユースケース別の選択

• 固有名詞・製品名が重要（製品マニュアル、技術仕様）→ ハイブリッド検索
• 概念的・抽象的な質問が中心（FAQ、一般的な知識）→ ベクトル検索
• 最高精度が必須（医療診断支援、法律相談）→ ハイブリッド + リランキング
• コスト・速度重視（大量処理、リアルタイム不要）→ ベクトル検索

リランキングの効果｜Cohere Rerankと実装コスト

リランキングは、初期検索で取得した候補（通常Top-20～50）を、より精密なモデルで再評価し、最終的なTop-Kを選択する手法です。

リランキングの仕組み

1. ベクトル検索で上位20件を取得（高速だが精度は中程度）
2. 各候補について、クエリとの関連度を専用モデル（Cohere Rerank、Cross-Encoderなど）で詳細評価
3. 関連度スコアで再ソートし、上位5件を最終結果として返す

リランキングモデルは、クエリと文書を同時に入力し、両者の相互作用を詳細に分析します。Embeddingベースの検索より精密ですが、計算コストが高いため、全文書に適用するのは非現実的です。そのため、初期検索で候補を絞り込んでから適用します。

Cohere Rerankの実測効果

Cohere Rerank v3.0を使用し、リランキングの効果を測定しました。

Cohere Rerankは、Recall@5を95.0%から97.5%に向上させました。特にMRR（最初の正解が何位に現れるか）が0.82から0.91に改善し、1位に正解が来る確率が大幅に上がりました。これは、LLMが最も関連性の高い情報を最初に受け取ることを意味し、回答品質の向上につながります。

ただし、コストは11.5倍（$0.13→$1.50）に跳ね上がります。月間100万クエリでは、年間で$16,440の追加コストです。精度向上（2.5ポイント）がこのコストに見合うかは、ビジネス価値次第です。

RAG実装コストの全体像｜ベクトルDB・Embedding・LLM費用

RAGシステムの総コストは、複数の要素から構成されます。月間100万リクエストの企業向けFAQシステムを例にシミュレーションします。

前提条件

• ナレッジベース：10,000文書、合計500万トークン
• チャンク設定：500トークン、100オーバーラップ → 12,500チャンク
• 月間クエリ数：100万件
• 1クエリあたり取得チャンク：5件（平均2,500トークンをLLMに送信）
• LLM出力：平均150トークン

コスト内訳（ハイブリッド検索、リランキングなし）

驚くべきことに、LLM APIコストが全体の98.7%を占めます。Embeddingやベクトルデータベースのコストは、全体から見れば誤差レベルです。したがって、コスト最適化の焦点は、LLMへの入力トークン数削減にあります。

コスト削減戦略

• 取得チャンク数削減：5件→3件に減らせば、LLMコスト40%削減。ただしRecallが低下するリスク。
• Claudeのプロンプトキャッシング：固定のシステムプロンプトをキャッシュすれば、入力コスト90%削減可能。
• 小型LLM使用：GPT-4o → GPT-4o mini で、LLMコストが約1/10に。精度は妥協が必要。
• チャンク圧縮：取得したチャンクをLLMに送る前に、別の小型LLMで要約し、トークン数を50%削減。

これらを組み合わせると、年間コストを$173,270から$40,000以下に削減できる可能性があります。

[図解: RAGコスト内訳円グラフ – LLM API、ベクトルDB、Embeddingの割合を視覚化]

まとめ｜RAG実装の成功の鍵

本記事の検証から、RAG実装の成功には以下の要素が重要であることが明らかになりました。

• Embedding選定：日本語文書ならCohere embed-multilingual-v3、コスト重視ならOpenAI text-embedding-3-small
• チャンキング：500トークン、100トークンオーバーラップが最適バランス
• 検索手法：固有名詞が重要ならハイブリッド検索、概念的ならベクトル検索
• リランキング：精度が最重要なら投資価値あり、コスト重視なら不要
• コスト最適化：LLM APIが98.7%を占めるため、プロンプトキャッシングと取得チャンク数削減が最優先

RAGは、適切に実装すればLLMの能力を劇的に拡張できますが、検索精度が低いと「間違った情報に基づく誤った回答」を生成してしまいます。本記事のベンチマークと推奨設定を参考に、あなたのユースケースに最適なRAGシステムを構築してください。

著者: 生成AI総合研究所編集部
カテゴリ: knowledge
公開日: 2025年12月