RAGと検索拡張の実装最前線——ベクトルDB・ハイブリッド検索・リランクで精度を稼ぐ

RAGとは何か——なぜ「検索」と「生成」をつなぐのか

RAGは、LLMの推論時に外部の知識源から関連情報を取り出し、それをプロンプトに組み込んでから回答を生成する手法である。モデルがパラメータに持つ「暗黙の記憶」だけで答えるのではなく、検索で持ってきた「明示的な根拠」をもとに答えるため、ハルシネーション（もっともらしい嘘）を減らし、出所を提示しやすくなる。特に企業内FAQ、契約書Q&A、社内マニュアル検索、技術文書の要約といった「自社固有の知識」を扱う場面で威力を発揮する。

生成だけでは届かない三つの壁

なぜ検索拡張が必要なのか。実務上は三つの壁がある。

• 知識の鮮度：モデルの学習データには期限があり、その日以降の出来事や社内の最新情報は答えられない。
• 固有知識の欠如：自社の用語、製品仕様、過去の決定事項は公開されておらず、モデルの訓練データに含まれない。
• 根拠の提示：回答の根拠となる文書を添えられないと、業務では「誰が何を根拠に言ったか」が証明できず、採用されない。

RAGはこれらの壁を、検索で拾った文書を「コンテキスト」としてモデルに渡すことで乗り越える。いわば、LLMに「調べてから答える」という作業を許す仕組みだ。

「RAGの本質は、モデルの記憶を信じるか、検索で持ってきた事実を信じるかの選択ではない。両方をつなぎ、根拠のある回答を作るためのパイプラインだ。」

全体像——RAGパイプラインの五つのステージ

実用RAGは、単なる「ベクトル検索＋プロンプト」ではない。文書の取り込み（取り込み側）と、質問への応答（推論側）の二つの流れから成る。全体を五つのステージに分けて設計するのが、2026年時点の定石である。

ステージ1：文書の収集と前処理

PDF、HTML、Markdown、スライド、社内Wikiなど異なる形式の文書をテキストに変換し、不要なヘッダ・フッタ・広告を除去する。ここでノイズを減らすほど、後の検索精度が上がる。表や画像のキャプションも扱えるよう、構造をできるだけ保って取り込むのが望ましい。

ステージ2：チャンク分割

長文書をそのまま埋め込むと、一文ずつ意味が薄れたり、検索時にノイズが混じったりする。そのため、文書を適切な大きさの「チャンク」に分割し、それぞれをベクトル化する。分割単位は経験則的に300〜800トークン程度が many 現場で使われるが、文書の性質（法務なら条項単位、マニュアルなら手順単位）で調整する。

ステージ3：埋め込み（エンベッディング）

各チャンクを、意味を数値列（ベクトル）に変換する埋め込みモデルに通す。ここで使うモデルの良し悪しが、検索の土台の精度を決める。多言語対応や日本語の扱い、文長の上限に注意し、自社ドメインに近いものを選ぶ。

ステージ4：検索とリランク

ユーザーの質問も同じ埋め込みモデルでベクトル化し、ベクトルDBから類似チャンクを取り出す。その後、より精度の高い「リランカー」で順位を並べ替え、上位のみをコンテキストとして採用する。この検索拡張のステップが回答の質を左右する。

ステージ5：生成と引用

選ばれたチャンクをプロンプトに組み込み、LLMに回答を書かせる。実用では「必ず引用元を添える」「知らないことは答えない」という制約をプロンプトに入れ、根拠の透明性を保つ。

チャンク分割の設計——検索精度の半数はここで決まる

RAGの実装でいちばん手間をかけるべきは、チャンク分割である。分割が粗いと検索にノイズが混じり、細かすぎると文脈が欠ける。現場で効く工夫を三つ挙げる。

オーバーラップで文脈をつなぐ

チャンク同士に少し重なり（オーバーラップ）を持たせることで、文の途中で切れて意味が分からなくなるのを防ぐ。100トークン程度の重なりが一般的だ。段落の境界を尊重しつつ重なりを持たせるのが、手堅いやり方である。

親子チャンクで粒度を両立する

「検索用の小チャンク」と「回答用の大チャンク（親）」をペアで持つ「親子チャンク」が広く使われる。小チャンクで精密に検索し、ヒットしたらその親（より大きな文脈）をLLMに渡す。細かさと文脈の豊かさを両立できる定番手法だ。

構造を保つ分割

見出しや箇条書きの構造を壊さずに分割し、チャンクに「どの章の何」かを示すメタデータを付ける。これにより、後のリランクやフィルタで「該当章だけを優先」といった制御が効くようになる。

「チャンクはRAGの単語だ。どう切るかで、モデルが見る世界の解像度が決まる。ここを雑にすると、どんな高性能DBも救えない。」

ベクトルDBとハイブリッド検索——意味検索とキーワード検索の使い分け

チャンクを蓄積し、類似検索するのがベクトルDBの役割だ。代表的なものにFAISS、Chroma、Qdrant、Milvus、Weaviate、pgvector（PostgreSQL拡張）がある。規模や運用形態（組み込み、自前サーバ、マネージド）で選ぶ。重要なのは、ベクトル検索だけでなく「キーワード検索」も混ぜるハイブリッド検索の採用である。

ベクトル検索の強みと弱み

ベクトル検索（意味検索）は、「言い回しが違っても意味が近い」文書を見つけられるのが強みだ。しかし「製品型番ABC-1234」「令和8年度予算」のように、特定の文字列の一致が決定的に重要な場合には弱い。意味が近くても、文字列が違えば拾えないケースがある。

キーワード検索（BM25）との融合

そこで、古くからあるキーワード検索（BM25など）を併用する。正確な用語や固有名詞はキーワードで確実に拾い、漠然とした意図はベクトルで拾う。両者のスコアを統合する手法（RRF：Reciprocal Rank Fusionなど）で順位を合成するのが、ハイブリッド検索の標準的な形だ。

• ベクトル検索：言い換えや意図の類似に強く、曖昧な質問に効く。
• キーワード検索：固有名詞・型番・専門用語の完全一致に強く、誤検知が少ない。
• ハイブリッド：両者を融合し、再現率と精度のバランスを取る。

リランクで精度を稼ぐ——検索と生成の間の「仕分け役」

最初の検索で上位に来たチャンクが、必ずしも回答に使えるとは限らない。ここで「リランカー」が登場する。クロスエンコーダ型のリランカーは、質問とチャンクを一緒にモデルに読ませて「本当に関連するか」を精密に判定する。計算コストは高いが、チャンク数が絞られている後段なら十分に回せる。

二段階検索（Retrieve-then-Rerank）

実用の定石は「広く拾って、厳しく絞る」の二段階だ。ベクトルDBで数十件をざっくり取り、リランカーで上位5〜10件に絞る。これで、ノイズを減らしつつLLMに渡すコンテキストの質を高められる。検索拡張の精度は、この仕分けで大きく伸びる。

メタデータとフィルタ

「2026年以降の文書だけ」「人事部の文書だけ」といった絞り込みは、ベクトル検索の前にメタデータでフィルタすると効果的だ。日付や部門、言語といった構造情報をチャンクに持たせ、検索前に門戸を絞ることで、無関係なチャンクが混ざるのを防ぐ。

「検索は『広さ』、リランクは『深さ』。両方そろえて初めて、LLMは使える文脈を手に入れる。」

生成と引用——根拠を提示する責任ある出力

検索拡張の価値は、回答に根拠を添えられる点にある。生成ステップでは、拾ったチャンクへの引用を必ず残し、モデルが「文脈にないこと」を答えないよう制御する。これを「接地（グラウンディング）」と呼ぶ。

プロンプトでの制約

「提供された文脈のみを根拠に答え、文脈にないことは『わからない』と述べよ」「各主張の末尾に引用番号を付けよ」といった指示をプロンプトに入れる。これでハルシネーションを抑え、ユーザーが根拠をたどれるようになる。

引用の表示と評価

回答に引用元（チャンクIDや文書名）を付け、ユーザーが原文を開けるようにする。さらに、回答が本当に文脈から導けるかを自動評価する仕組み（事実一致のチェックなど）を入れると、運用の信頼性が高まる。

• 回答の各文に、参照したチャンクの出所を明示する。
• 文脈にない推論は「不確実」として扱わせる。
• 引用クリックで元文書へ飛べるようにする。

評価と改善——RAGは「作って終わり」ではない

RAGの導入は、一度組めば終わりではない。検索の精度、回答の正しさ、引用の適切さを継続的に測定し、改善し続けるのが運用の鉄則だ。評価なしに「なんとなく動いている」は、いつか致命的な誤答を生む。

測るべき三つの指標

現場で見る指標は主に三つ。検索の再現率・精度（狙ったチャンクを拾えているか）、回答の正答率（文脈から正しく答えられているか）、引用の正確さ（引用が実際の根拠と一致しているか）だ。これらを小さなテストセットで定期計測する。

失敗からの改善ループ

「拾えていないチャンクがある」ならチャンク分割や埋め込みを見直す。「拾っているのに答えがおかしい」ならリランクやプロンプトを見直す。ボトルネックを特定し、一つずつ直すのが、RAG改善の基本の流れだ。

「RAGの品質は、リリース時の設定ではなく、その後の評価と改善の密度で決まる。作るのは半分、育てるのが残りの半分だ。」

実装の落とし穴と対策——現場でよく踏む地雷

RAGは設計通りに動かないことも多い。現場で頻発する落とし穴と、その対策を挙げておく。これらを事前に織り込むだけで、運用開始後の苦労は大幅に減る。

落とし穴1：チャンクが大きすぎてノイズが混む

一つのチャンクに長文を詰め込むと、ベクトルが「平均的な意味」になり、具体的な質問にヒットしにくくなる。対策は、親子チャンクの導入とオーバーラップの調整だ。小さく切りつつ文脈は親で補う構成に直す。

落とし穴2：埋め込みモデルとドメインの乖離

汎用の埋め込みモデルをそのまま使うと、自社用語や専門用語の類似度がいびつになる。対策は、ドメインに近いモデルの選定や、必要に応じた再学習（ファインチューニング）である。まずは多言語・日本語対応を確認し、それでも足りなければ独自調整を検討する。

落とし穴3：引用のねじれ

リランクでチャンクを並べ替えた際、引用番号と実際のチャンクがずれることがある。対策は、チャンクIDを不変で持ち、生成時にそのIDをそのまま引用として出力させることだ。後段で番号を振り直すと、必ず元のIDと紐づけてから表示する。

• チャンクの大きさは、測定しながら小さめに寄せる。
• 埋め込みはドメイン適合を確認し、不足なら再調整する。
• 引用はチャンクIDで管理し、表示時にのみ番号化する。

「RAGの失敗の九割は、検索側の地雷だ。生成モデルをいくら替えても、拾ってくる文脈が悪ければ答えは良くならない。」

まとめ

RAGと検索拡張は、LLMを「何でも答える頭」から「調べて根拠を示すアシスタント」へと押し上げた、現代のAI実装の基盤技術である。本稿では、文書の前処理からチャンク分割、埋め込み、ベクトルDBによる検索、ハイブリッド検索、リランク、生成と引用、そして評価までの一連の流れを整理した。鍵となるのは、意味検索とキーワード検索を融合するハイブリッド検索、検索と生成の間に挟むリランクによる精密な仕分け、そして根拠を提示するグラウンディングであった。RAGは魔法ではなく、チャンクの切り方やメタデータの設計といった地道な規律の上に成り立つ。まずはベクトル検索単体で小さく始め、ハイブリッド検索とリランクを足し、評価ループで育てるのが、2026年時点の最も確実な進め方だ。検索拡張の実装最前線は、まさに「検索の質が生成の質を決める」という一点に集約されている。