失敗しないRAG（検索拡張生成）設計：回答精度が出ない時に見直すべき4つのポイント

社内文書や製品マニュアル、FAQデータを大規模言語モデル（LLM）と連携させ、独自のナレッジに基づいた回答を生成する手法として、RAG（Retrieval-Augmented Generation：検索拡張生成）の採用が急速に進んでいます。しかし、PoC（概念実証）の初期段階では良好に動作していたシステムが、データ規模を拡大したり実際の業務シナリオに投入したりした途端、「期待した情報が回答に含まれない」「無関係な文書を参照して誤った回答を出力してしまう」といった精度の壁に直面する事例は少なくありません。

RAGにおいて回答精度が上がらない場合、原因をLLM本体の性能に求めがちですが、実務においては「LLMに渡す前段の検索（Retrieval）パイプライン」にボトルネックが存在するケースが大半を占めていると分析されています。LLMに必要な情報が適切に届いていなければ、どれほど高度な推論能力を持つモデルを用いても正確な回答は期待できません。

本記事では、RAGシステムの回答精度に悩む開発者やアーキテクトに向けて、検索パイプラインを見直し、精度を実務レベルへ引き上げるための「4つの改善ポイント」を技術的な背景とともに解説します。

1. チャンク分割（Chunking）の最適化：文脈の分断を防ぐ

RAGにおける最初の工程であるドキュメントの分割（チャンキング）は、検索精度を決定づける極めて重要な基礎設計です。元の文書をどの単位で区切り、ベクトル化するのかによって、検索ヒット率とLLMが解釈できる文脈の質が大きく左右されます。

固定長分割の限界とセマンティックチャンキング

初期実装でよく用いられる手法が、文字数やトークン数で機械的に区切る「固定長分割（例: 500文字ごと）」です。実装が容易である反面、文の途中で切断されたり、関連する段落同士が前後のチャンクに分断されたりすることで、文脈情報が欠落しやすいという課題を抱えています。

この課題を緩和するために、以下のような段階的なアプローチが推奨される傾向にあります。

再帰的文字分割（Recursive Character Splitting）: 見出し（#, ##）、段落（改行2つ）、文（句点）といった文書構造の区切り文字を優先順位順に評価し、可能な限り意味のあるまとまりを保持して分割する手法です。
セマンティックチャンキング（Semantic Chunking）: 文単位でエンベディングを行い、前後の文同士のコサイン類似度を計測して、意味的な話題が切り替わった境界でチャンクを分割する高度なアプローチです。

親子チャンク（Parent-Child Retriever）構造の導入

検索時に求められる「ピンポイントな情報特定」と、生成時に求められる「十分な周辺文脈の提供」は、トレードオフの関係にあります。チャンクを小さくしすぎると文脈が不足し、大きくしすぎるとベクトルが抽象化されて検索ヒット率が低下します。

このジレンマを解消する構成として、**親子チャンク構造（Small-to-Big Retrieval）**の採用が増加しています。

階層	主な役割	特徴
子チャンク（小）	ベクトル検索用	100〜200トークン程度の小さな単位でインデックス化し、類似度計算の精度を高める
親チャンク（大）	LLMへのコンテキスト入力用	500〜1,000トークン以上のまとまった単位として保持し、子チャンクがヒットした際に親チャンク全体をLLMに供給する

この構造を採用することで、検索の高い適合率を維持しながら、LLMには欠落のない十分な文脈を渡すことが可能になります。

2. エンベディングモデルの選定とドメイン適応

ドキュメントやクエリを多次元ベクトルへ変換するエンベディングモデルの選定も、検索性能を根本から左右する要素です。汎用ベンチマーク（MTEBなど）のスコアが高いモデルであっても、自社の業務データや言語環境において最適であるとは限りません。

日本語性能とトークン長の確認

日本語テキストを対象とする場合、英語主体の多言語モデルではトークナイザーの語彙不足や日本語特有の文法構造への対応不足により、意味の捉え方に粗さが生じるケースが見られます。

選定時には以下の指標を検証することが望ましいとされています。

日本語特化ベンチマーク（JMTEBなど）での評価: 多言語モデルと日本語ネイティブ対応モデルの検索精度（NDCG@10など）を比較検証する。
最大入力トークン数: チャンクサイズがモデルの許容最大トークン数を超えた場合、超過部分が切り捨てられてベクトル化されるため、チャンク設計との整合性を確認する。
埋め込み次元数とメモリ・検索負荷: 1,536次元や3,072次元といった高次元モデルは表現力に優れる一方、ベクトルDBのメモリ消費量や検索レイテンシが増大するため、要件に応じたバランス検討が必要です。

ドメイン固有用語への対応

金融、医療、製造業、法務などの専門領域においては、業界特有の略語や社内用語が頻出します。一般的なエンベディングモデルではこれらの用語が未知語として扱われ、意図した類似度が算出されない事態が発生しやすくなります。

このような場合は、自社データを用いたエンベディングモデルのファインチューニング（Contrastive Learningを用いた微調整）を実施するか、後述するキーワード検索とのハイブリッド構成によって補完することが有効な手段として挙げられます。

3. リランキング（Reranking）処理の導入：検索精度の劇的向上

多くのRAG設計において、最も費用対効果が高く精度向上に寄与しやすい施策が「リランキング処理」の追加であると言われています。

Bi-EncoderとCross-Encoderの違い

ベクトル検索（Dense Retrieval）は一般的に「Bi-Encoder」と呼ばれる方式を採用しています。ドキュメントとクエリを事前に独立してベクトル化し、コサイン類似度などの内積計算で高速に候補を絞り込みます。計算効率に優れる反面、クエリとドキュメントの相互関係を微細に捉えきれない弱点があります。

一方、「Cross-Encoder（リランカー）」は、クエリとドキュメント候補を同時に入力し、全結合的なアテンションを用いて関連度スコアを直接算出します。

【Bi-Encoder (ベクトル検索)】
クエリ ──────> [Encoder] ──> ベクトルQ ──┐ 内積計算（高速・数万件規模）
ドキュメント ──> [Encoder] ──> ベクトルD ──┘

【Cross-Encoder (リランカー)】
[クエリ + ドキュメント] ────> [Joint Transformer] ──> 厳密な適合度スコア（高精度・数十件規模）

計算コストが高いため全ドキュメントに対する直接適用は現実的ではありませんが、「ベクトル検索で上位30〜50件の候補を粗く抽出し、リランカーで上位5件程度に精緻に並び替える」という2段階構成（Two-stage Retrieval）を採用することで、レイテンシと精度の両立が実現されます。

ハイブリッド検索（BM25 ＋ベクトル検索）との組み合わせ

ベクトル検索は「意味的な類似性」の抽出には優れていますが、「型番」「製品コード」「人名」「特定の日付」といった完全一致が求められるキーワード検索においては弱点を示す傾向があります。

そのため、全文検索エンジンの標準手法であるBM25（疎ベクトル検索）とDenseベクトル検索を並行して実行し、それぞれの結果を相互ランク融合（RRF: Reciprocal Rank Fusion）等で統合した上でリランキングにかける「ハイブリッド検索」アーキテクチャが、現代のエンタープライズRAGにおけるデファクトスタンダードになりつつあります。

4. メタデータフィルタリングの設計：無駄なノイズを排除する

どれほど優れたエンベディングとリランカーを備えていても、データベース全体から無差別に関連ドキュメントを探そうとすると、古い版の規定文書や別部門の無関係なファイルが上位に混入するリスクを排除できません。

事前フィルタリング（Pre-filtering）の威力

メタデータ（属性情報）を活用したフィルタリングは、検索対象空間そのものを事前に限定するため、無関係なノイズを完全に遮断し、回答精度を劇的に向上させます。

付与すべき代表的なメタデータ属性には以下のようなものがあります。

作成日時・有効期限: 「2026年度版の規程」と「2023年度版の規程」が混在している場合、古い文書を除外する、あるいは重み付けを下げる。
文書カテゴリ・部署コード: 質問者の所属やコンテキストに応じて、検索対象フォルダやカテゴリを限定する。
アクセス権限（ACL）: ユーザーが閲覧権限を持たない機密情報が検索結果に含まれないよう、ユーザーIDやロールに基づき絞り込む。

自己クエリ（Self-Querying）による自然言語からの動的メタデータ抽出

ユーザーが入力した自然言語のクエリから、LLMを活用して「検索キーワード」と「メタデータフィルタ条件」を動的に分離・生成する手法（Self-Querying Retriever）も実用化が進んでいます。

入力例: 「総務部が2025年10月以降に発行したテレワーク運用ガイドラインの規定はどうなっていますか？」

Self-Queryingによる解析結果:

セマンティック検索対象テキスト: テレワーク運用ガイドライン規定

構造化メタデータフィルタ: department == "総務部" AND created_at >= "2025-10-01"

このようにクエリを分解してデータベースに問い合わせることで、意味検索と条件検索の強みを最大限に引き出すことが可能になります。

まとめ：RAGパイプライン全体の継続的評価が成功の鍵

RAGシステムの回答精度を向上させるためには、単一の手法に過度な期待を寄せるのではなく、パイプラインの各段階における弱点を特定し、適切な改善策を適用することが不可欠です。

課題の兆候	推奨される見直し項目	主な技術的アプローチ
回答の文脈が途切れる・情報が断片化する	チャンク分割の最適化	親子チャンク構造、セマンティックチャンキング
専門用語や社内用語が検索でヒットしない	エンベディングの選定	日本語特化モデルの導入、モデルの微調整
検索上位に無関係な情報が混入する	リランキング処理の導入	Cross-Encoderリランカー、BM25とのハイブリッド検索
旧バージョンの情報や別部門の文書を誤読する	メタデータフィルタリング	事前フィルタの適用、Self-Queryingによる動的抽出

また、改善施策を推進するにあたっては、「Ragas」や「TruLens」などのRAG専用評価フレームワークを活用し、検索適合率（Context Precision）、検索再現率（Context Recall）、忠実性（Faithfulness）といった客観的なメトリクスを定期的に測定するプロセスの構築が推奨されます。定量的評価に基づき、仮説検証のサイクルを回し続けることこそが、実務において信頼されるRAGシステムを構築するための最も確実な道筋と言えるでしょう。