RAGの検索精度を高める5つの設計手法——チャンク・ハイブリッド検索・再ランキングまで

RAGの精度問題——「導入したのに回答がズレる」は設計の問題

よくある症状——回答がズレる・古い情報を返す・文脈が途切れる

RAG（Retrieval-Augmented Generation：検索拡張生成）を導入したにもかかわらず、「期待していた回答が返ってこない」という声は少なくありません。現場でよく報告される症状には、大きく3つのパターンがあります。

• 回答がズレる：質問の意図とは異なる文書を参照し、的外れな回答を生成する
• 古い情報を返す：更新済みの規程や手順書があるにもかかわらず、旧バージョンの内容で回答する
• 文脈が途切れる：前後の文脈を失った断片的な情報を拾ってしまい、回答が不自然に途切れる

これらはいずれも、いわゆるハルシネーション（事実と異なる回答の生成）と混同されがちです。しかし実際には、LLM（大規模言語モデル）自体の問題ではないケースがほとんどです。

原因の所在——LLMではなく「検索」フェーズにある

RAGの仕組みを簡単に整理すると、「①ユーザーの質問に関連する文書を検索する」→「②取得した文書をLLMに渡す」→「③LLMが回答を生成する」という流れになります。回答の品質は、③よりも①と②の段階、つまり検索フェーズの設計に大きく依存しています。

検索フェーズで誤った文書を拾ってくれば、どれだけ高性能なLLMを使っても、出力される回答は的外れになります。RAGの精度向上を検討するうえで、まず「検索設計の問題として捉え直す」という視点が不可欠です。

本記事では、検索精度を左右する構成要素の整理から始め、チャンク設計・メタデータ付与・ハイブリッド検索・再ランキング・クエリ変換という5つの設計手法を順に解説します。

前提整理——RAGの検索精度を左右する3つの構成要素

RAG（Retrieval-Augmented Generation：検索拡張生成）の精度改善に取り組む前に、まずパイプライン全体の構造を整理しておく必要があります。「回答がズレる」「ハルシネーションが多い」といった症状は、3つのフェーズのどこかに原因があります。原因のフェーズを特定せずに対策を打っても、効果は限定的です。

インデックス構築フェーズ——文書をどう切り出し・どう格納するか

最初のフェーズでは、社内文書をベクトルデータベースに格納できる形に変換します。具体的には、文書をある単位に分割（チャンク化）し、各チャンクをベクトル（数値の配列）に変換してインデックスとして保存します。

このフェーズの設計が甘いと、後段の検索・生成がどれだけ優れていても精度の上限が低くなります。「何をどの粒度で切り出すか」「どのような付加情報を持たせるか」が、パイプライン全体の土台を決めます。

検索フェーズ——正しい文書を正しい順番で取り出せているか

ユーザーの質問を受け取り、インデックスから関連するチャンクを取り出すのが検索フェーズです。ベクトルの類似度で検索する方法が一般的ですが、キーワードの一致を見逃すケースや、関連度の低い文書が上位に来るケースが起きやすい箇所でもあります。

「検索はできているが、答えに必要な文書が含まれていない」という状況の多くは、このフェーズに改善余地があります。

生成フェーズ——渡すコンテキストの質がLLMの回答を決める

検索で取り出したチャンクをLLM（大規模言語モデル）に渡し、回答を生成するのが最後のフェーズです。LLMの性能自体は高くても、渡されるコンテキスト（文書の内容）が不正確・不足・冗長であれば、回答の質は下がります。

生成フェーズは「渡された情報の範囲内で最善を尽くす」構造であるため、前の2フェーズの品質がそのまま出力に反映されます。以降のセクションでは、この3フェーズそれぞれに対応する具体的な設計手法を解説します。

手法1：チャンク設計——文書の「切り方」が精度の土台を作る

チャンク設計とは、RAGに読み込ませる文書を「どの単位で区切るか」を決める工程です。地味に見えますが、検索精度への影響が最も大きい設計要素の一つです。どれだけ高性能なベクトル検索エンジンを使っても、チャンクの切り方が悪ければ、意味のある文脈が分断され、LLMに渡る情報の質が下がります。

固定長チャンクの限界——意味の分断が検索ミスを生む

最もシンプルなチャンク分割は「500トークンごと」「1,000文字ごと」といった固定長分割です。実装コストが低い反面、文の途中や段落の途中で強制的に切断されるため、意味のまとまりが破壊されるケースが少なくありません。

例えば、規程文書の「例外処置の条件」が前後のチャンクに分かれてしまうと、LLMはその条件を正しく参照できなくなります。結果として、不完全な情報に基づく回答が生成されてしまいます。

意味単位チャンキングとオーバーラップ設計の考え方

固定長の問題を補う手法が、意味単位でのチャンキングとオーバーラップ設計です。

• 意味単位チャンキング：段落・箇条書きのまとまり・センテンスグループなど、文書の構造に沿って分割します。意味の途切れが生じにくく、検索クエリとの関連性が高まります。
• オーバーラップ設計：隣接するチャンク間で一定のテキストを重複させる手法です。例えば100トークン分を前後で共有することで、チャンク境界をまたぐ文脈の欠落を防ぎます。

ドキュメント種別ごとのチャンク設計の違い

社内で扱う文書の種類によって、推奨するアプローチは異なります。

• PDF（規程・マニュアル類）：章・節・条項の単位でチャンクを切り、ページまたぎには注意が必要です。見出しを区切りの基準にするのが基本的な方針です。
• 社内Wiki：ページ単位が短いことが多いため、1ページ＝1チャンクが適することがあります。長すぎる場合はH2・H3見出しで分割します。
• Excel・表形式データ：行単位・列単位のどちらで意味が完結するかを確認した上で設計します。ヘッダー行の情報を各チャンクに付与することが重要です。

チャンク設計に正解は一つではありませんが、「文書の種類と意味のまとまりに合わせて設計する」という原則を守ることで、RAG精度向上の土台が整います。

手法2：メタデータ付与とフィルタリング——「何を検索するか」を絞り込む

メタデータ設計の基本——部門・日付・ドキュメントタイプをどう定義するか

ベクトル検索は「意味的な近さ」でチャンクを取得する仕組みです。しかし、意味が近いだけでは不十分なケースが少なくありません。たとえば「営業部門向けの最新の価格表」を求めているのに、3年前の全社向け資料が上位に来てしまう——こうした「的外れな参照」は、属性情報を検索に組み込んでいないことが原因です。

この課題に対処するのが、メタデータの構造化付与です。各チャンクに対して、以下のような属性情報をあらかじめ定義・付与しておきます。

• 部門・組織：営業部、人事部、経営企画など
• 日付・バージョン：作成日、更新日、有効期限
• ドキュメントタイプ：規程、マニュアル、議事録、提案書など
• アクセス権限：公開範囲（全社・部門・役職）

設計のポイントは、「検索時に絞り込む条件として使えるか」を基準にすることです。粒度が粗すぎると絞り込みが効かず、細かすぎると付与コストが高くなります。まずは部門・日付・ドキュメントタイプの3軸から始めるのが現実的です。

フィルタ+ベクトル検索の組み合わせで的外れな参照を防ぐ

メタデータを付与したら、次は「フィルタ検索」と組み合わせて使います。具体的には、ベクトル検索を実行する前にメタデータ条件で対象チャンクを絞り込み、その範囲内でのみ類似度検索を行う流れです。

たとえば「2024年度の人事規程を教えて」というクエリであれば、ドキュメントタイプ＝規程、部門＝人事、作成年度＝2024でフィルタをかけてからベクトル検索を走らせます。これにより、意味的には近くても条件が合わない古い文書や他部門の資料が混入するリスクを大幅に下げられます。

この手法はRAGの検索精度改善において即効性が高い一方、競合記事では十分に取り上げられていない論点です。メタデータの設計と付与に初期コストはかかりますが、回答の的外れを減らす効果は大きく、精度向上と検索速度の両立にも貢献します。

手法3：ハイブリッド検索——ベクトル検索とキーワード検索を組み合わせる

RAGの検索精度改善を進めるうえで、ベクトル検索だけに頼る設計には見落としやすい弱点があります。意味的な近さを捉えるのは得意でも、特定の文字列を正確に拾う場面では精度が落ちやすいためです。この弱点を補う手法が、ハイブリッド検索です。

ベクトル検索だけでは拾えないケース——固有名詞・社内略語の落とし穴

ベクトル検索は、文章の意味をベクトルに変換し、類似度をもとに関連ドキュメントを取得します。たとえば「契約を解除したい」と「解約手続きを教えてほしい」のように、表現が違っても意味が近ければ検索にヒットします。

一方で、次のようなケースでは精度が下がりやすい傾向があります。

• 製品型番（例：「MX-2400B」）や規格番号など、完全一致が必要な文字列
• 社内でのみ通じる略語・プロジェクトコード（例：「SKJ案件」「Aシステム移行PJ」）
• 人名・部署名など、意味的な関連性よりも文字列の一致が重要な情報

これらはベクトル空間上で「意味的に近い語」が存在しないため、類似度スコアが上がらず、検索結果から漏れてしまうことがあります。

BM25とベクトル検索の統合——RRFによるスコア統合の仕組み

ハイブリッド検索RAGでは、BM25（キーワードの出現頻度と希少性をスコア化する古典的な検索アルゴリズム）とベクトル検索を並列で実行し、それぞれの結果を統合します。

スコアの統合には、RRF（Reciprocal Rank Fusion：逆順位融合）がよく使われます。RRFは各検索手法の「順位」だけを使い、スコアの絶対値に依存しない点が特徴です。たとえばあるドキュメントが、ベクトル検索で2位・BM25で5位だった場合、それぞれの順位から融合スコアを算出し、最終的な並び順を決定します。スコアの単位が異なる2つの検索結果を、シンプルかつ安定した方法で統合できます。

ハイブリッド検索が特に有効なドキュメント構成の例

すべてのRAG環境にハイブリッド検索が必要なわけではありません。効果が出やすいのは、次のようなドキュメント構成です。

• 製品マニュアル・仕様書など、型番や規格番号が頻出するドキュメント
• 社内規程・契約書など、条番号や固有の用語を正確に引く必要がある文書
• 部署名・担当者名・システム名など、社内固有の名称が混在するナレッジベース

逆に、一般的な質問応答や概念説明が中心のドキュメントであれば、ベクトル検索単体でも十分なケースがあります。自社のドキュメントにどちらの要素が多いかを見極めたうえで、ハイブリッド検索の導入を検討するのが適切です。

手法4：再ランキング（Re-ranking）——取得した候補をLLMに渡す前に並び替える

再ランキングが必要になる場面——検索上位≠LLMにとって有益ではない理由

ベクトル検索やハイブリッド検索で上位に取得されたチャンクが、LLMにとって最も有用なコンテキストとは限りません。ベクトル検索はクエリとの意味的な近さを数値化しますが、その類似度スコアは「LLMが回答を生成するうえでの有用性」とは異なる指標です。たとえば、質問と語彙的に近いチャンクが上位に来ても、実際の回答に必要な情報が含まれていないケースは少なくありません。

再ランキング（Re-ranking）は、この乖離を補正するための処理です。検索で取得した複数のチャンク候補を、LLMに渡す前にもう一段階評価し直し、本当に有益な順に並び替えます。

クロスエンコーダーとLLMによる再ランキングの違い

再ランキングの実装方法は、主に2種類あります。

• クロスエンコーダーモデルによる再ランキング：クエリとチャンクをセットで入力し、関連度スコアを直接算出する専用モデルです。Cohereの「Rerank」やBAAI/bge-rerankerなどが代表例です。処理速度が速く、コストも比較的低く抑えられます。
• LLMを使った再ランキング：GPT-4などの大規模言語モデルに「この質問に対して最も有益なチャンクはどれか」を判断させる手法です。精度は高くなりやすい一方、APIコストと処理時間が増加します。

多くの場面では、クロスエンコーダーモデルが費用対効果の高い選択肢になります。上位20件前後を取得し、そこから上位3〜5件に絞り込む用途であれば、十分な精度改善が見込めます。

導入コストと効果のバランス——どのフェーズで導入すべきか

再ランキングRAGの導入は、チャンク設計やハイブリッド検索などの基礎的な施策を整えた後に検討するのが適切です。検索候補の質そのものが低い状態では、再ランキングで並び替えても改善幅は限られます。

一方、基礎設計が整っているにもかかわらず回答精度が伸び悩んでいる場合は、再ランキングが有効な打ち手になります。特に社内ドキュメントのように文書の質がばらつきやすい環境では、検索上位チャンクのノイズを除去する効果が出やすい傾向があります。RAG精度向上を段階的に進めるなかで、精度の「上限を引き上げる」施策として位置づけると判断しやすくなります。

手法5：クエリ変換（Query Transformation）——ユーザーの質問を検索しやすい形に整える

ユーザーが入力する質問文は、必ずしも検索に適した形とは限りません。「先月の売上どうだっけ」「例の件どうなってる」といった口語的・省略的な表現は、ベクトル検索でも意図した文書にヒットしにくいケースが少なくありません。クエリ変換は、ユーザーの質問をそのまま検索にかけるのではなく、LLMを使って検索しやすい形に「翻訳」してから処理する手法です。

クエリ拡張とHyDE——検索前に質問を「翻訳」する発想

代表的な手法がクエリ拡張とHyDE（Hypothetical Document Embeddings）です。

クエリ拡張は、ユーザーの質問に関連するキーワードや言い換え表現をLLMで補完し、複数の検索クエリを生成してから検索にかける手法です。たとえば「契約解除の手続きは？」という質問に対して、「解約フロー」「退会手順」「契約終了条件」といった表現も同時に検索することで、表記ゆれや用語の違いによる検索漏れを防げます。

HyDeはさらに踏み込んだアプローチです。ユーザーの質問に対してLLMが「もし理想的な回答文書があるとしたらこういう内容のはず」という仮説的な文書を生成し、その文書をベクトル化して検索に使います。実際の質問文よりも、仮説文書のほうが正解文書と意味的に近い位置に配置されるケースが多く、検索精度が向上しやすい点が特徴です。社内規程や技術仕様書など、文書の語彙が専門的で固定されている場合に特に有効です。

複合質問の分解——マルチホップ検索に対応するクエリ分解の考え方

「A社向けの見積もり条件と、標準価格表の違いを教えて」のように、1つの質問に複数の情報源が必要な場合、単一のクエリでは十分な文書を取得できません。このようなマルチホップ検索が必要な質問には、クエリ分解が有効です。

クエリ分解では、LLMがユーザーの質問を複数のサブクエリに分割します。上記の例であれば「A社の見積もり条件は？」と「標準価格表の内容は？」の2つに分けてそれぞれ検索し、取得した文書をまとめてLLMに渡して最終回答を生成します。

手法の選び方の目安は次のとおりです。口語・省略表現が多い社内チャットボットにはクエリ拡張、専門文書への質問にはHyDE、複数部門をまたぐ業務フローや比較質問にはクエリ分解が適しています。いずれもLLMの呼び出しが増えるため処理コストは上がりますが、検索精度の改善効果と照らし合わせて優先度を判断することが重要です。

5手法の比較——自社の課題タイプ別に優先すべき施策

5つの手法をひとつずつ理解したうえで、次に必要なのは「自社はどれから着手すべきか」という判断です。以下の比較表と優先順位の考え方を、意思決定の材料としてご活用ください。

課題タイプ別の優先施策マトリクス

各手法を「効果の大きさ」「実装コスト」「有効な課題タイプ」の3軸で整理すると、次のようになります。

段階的な改善ロードマップ——まず着手すべき順序

RAG精度の向上は、土台から順に積み上げる考え方が有効です。まず着手すべきはチャンク設計です。切り方が適切でなければ、どの上位手法を追加しても改善幅は限られます。

次に、社内ドキュメントに部門・製品・バージョンなどの属性情報がある場合は、メタデータ付与とフィルタリングを早期に実装することで、検索範囲を絞り込む効果が得られます。

固有名詞や型番を含む業務文書が多い場合は、ハイブリッド検索の導入を並行して検討してください。ベクトル検索だけでは取りこぼしやすい表記に対応できます。

これらの基盤が整ったうえで、回答品質をさらに引き上げたい段階に入ったら、再ランキングやクエリ変換を追加していくのが、コストと効果のバランスが取りやすい進め方です。

社内データ固有の難しさ——企業ドキュメントでRAG精度が下がりやすい理由

ここまで解説してきた5つの手法は、いずれも「良質なデータが前提」として設計されています。しかし社内RAGの現場では、その前提が成立しないケースが少なくありません。CLANEが社内RAG基盤の構築を支援するなかで、技術的な設計よりも先に「データそのものの問題」がボトルネックになる場面に繰り返し直面しています。

非構造化ドキュメントの多様性——PDF・Excel・Slackが混在する現実

社内文書は、形式が統一されていないことがほとんどです。規程類はPDF、進捗管理はExcel、日常的なやり取りはSlackやTeams、仕様書はConfluenceやNotionといった具合に、複数のフォーマットと複数のプラットフォームにデータが分散しています。

チャンク設計やメタデータ付与は、テキストとして整形されたデータを前提とします。PDFのレイアウト崩れ、Excelのセル結合、Slackのスレッド構造といった要素は、そのまま取り込むと意味のない断片として切り出されるリスクがあります。RAG精度向上を図るうえで、前処理の設計がいかに重要かが分かります。

社内用語・略語問題——一般的な埋め込みモデルが対応できない壁

ベクトル検索の精度は、埋め込みモデルの語彙知識に依存しています。一般公開されているモデルは汎用テキストで学習されており、「PJT管理表」「本部承認フロー」「SKU統合案件」といった社内固有の略語や業界方言には対応できていないことがあります。

結果として、担当者が検索するクエリと実際のドキュメントの表現が意味的に近くても、ベクトル空間上では遠い位置に配置されてしまいます。この問題はハイブリッド検索やクエリ変換である程度補えますが、根本的には社内用語の辞書整備やファインチューニングを検討する必要があります。

鮮度管理とアクセス制御——精度だけでなく信頼性に関わる設計

社内ドキュメントは更新頻度にばらつきがあります。半年前に改定された規程と最新版が同じインデックスに混在すると、RAGは古い情報を根拠に回答を生成します。利用者が誤りに気づかないまま意思決定に使うリスクは、ハルシネーション以上に深刻です。

加えて、社内RAGではアクセス権管理（RBAC：Role-Based Access Control）の設計が不可欠です。人事情報や経営資料が一般社員の質問に対しても検索対象に含まれる設計は、情報漏洩リスクに直結します。RAG検索精度の改善と同時に、「何を誰に検索させるか」という制御設計を組み込まないと、運用段階で深刻な問題が発生しやすくなります。

まとめ——RAG精度向上は「検索パイプライン全体」の設計問題

ここまで解説してきた5つの手法を振り返ると、RAGの検索精度改善に共通するひとつの構図が見えてきます。

• チャンク設計：文書の切り方と粒度が、検索精度の土台を決める
• メタデータ付与とフィルタリング：「何を検索対象にするか」を絞り込み、ノイズを排除する
• ハイブリッド検索：意味検索とキーワード検索を組み合わせ、取りこぼしを防ぐ
• 再ランキング：取得した候補をLLMに渡す前に並び替え、質問との関連度を高める
• クエリ変換：ユーザーの曖昧な問いを、検索しやすい形に整えてから処理する

これらはいずれも、LLMそのものの性能とは切り離された「検索パイプライン」の設計に関わるものです。どれほど高性能なLLMを採用しても、パイプラインの上流で誤った文書チャンクを渡してしまえば、生成される回答の質は上がりません。RAGの精度問題の多くは、LLMの選定ではなく、この検索パイプラインの設計精度にかかっています。

また、5手法はすべてを同時に導入する必要はありません。回答が的外れになりやすい場合はチャンク設計やハイブリッド検索の見直しから、ハルシネーションが多い場合は再ランキングやクエリ変換の追加から着手するなど、自社の課題タイプに合わせて優先順位を決めることが現実的です。

CLANEでは、こうした検索パイプライン全体の設計を含めた社内RAG基盤の構築を手がけています。ドキュメントの種類や業務フローの特性に応じて、どの手法をどの順序で実装するかを設計段階から整理することが、精度向上の近道になります。