本文へスキップ
スキルアップカレッジ

ベクトル DB とハイブリッド検索・リランクの設計

レッスン4：ベクトル DB とハイブリッド検索・リランクの設計

このレッスンで学ぶこと

  • ベクトル DB の役割と、選定軸（マネージド／セルフホスト・規模・クエリパターン・統合性）を整理できる
  • 代表的なベクトル DB（pgvector・Elasticsearch／OpenSearch・Weaviate・Qdrant・Milvus・Pinecone・Chroma・Vespa）を系譜で捉えられる
  • ANN 索引（HNSW・IVF・PQ）の要諦を掴む
  • ハイブリッド検索（BM25＋ベクトル、Reciprocal Rank Fusion）の設計ができる
  • リランキング（Cross-Encoder・Cohere Rerank・LLM Rerank）の使い分けを把握する
  • メタデータフィルタでの絞り込み設計を組み立てられる

前レッスンではチャンキング戦略と埋め込みモデル選定を扱いました。本レッスンでは、索引化したベクトルを「実際に検索する側」に踏み込みます。ベクトル DB 選定、ハイブリッド検索、リランクを組み合わせて、社内 RAG の検索精度を作ります。検索の品質が生成の品質の天井を決めるという中核メッセージが、本レッスンの背骨です。

ベクトル DB の役割

ベクトル DB は、埋め込みベクトルを格納し、あるクエリベクトルに「近い」ベクトルを高速に取り出す専用のデータストアです。数百万〜数億のベクトルの中から、コサイン類似度や内積で最も近い数十件を、ミリ秒単位で返すために、通常の DB とは違う仕組みで作られています。

社内 RAG での主な役割は 4 つです。

  1. チャンクベクトルの格納：チャンク ID・埋め込みベクトル・メタデータをセットで保存
  2. 近傍検索（ANN）：クエリベクトルに近いチャンクを効率的に取り出す
  3. メタデータフィルタ：部署・期間・権限タグなどの条件で絞り込む
  4. 更新・削除：文書の追加・削除・改訂に応じて索引を更新する

ベクトル DB 選定軸

「どのベクトル DB を選ぶか」は、ベンダー人気ではなく次の 4 軸で判断します。

flowchart TB
  Axis[選定軸]
  Axis --> A1[運用形態<br/>マネージド／セルフホスト／既存 DB 拡張]
  Axis --> A2[規模<br/>数千〜億単位のチャンク数と QPS]
  Axis --> A3[クエリパターン<br/>ベクトル単独／ハイブリッド／メタデータ絞り込み]
  Axis --> A4[統合性<br/>既存基盤との親和・組織のスキル・言語]

運用形態

  • マネージド SaaS：Pinecone、Weaviate Cloud、Qdrant Cloud、Zilliz Cloud（Milvus）、Vespa Cloud、Elastic Cloud、Amazon OpenSearch Serverless など。運用の手間が省ける
  • セルフホスト（OSS）：Weaviate、Qdrant、Milvus、Elasticsearch、OpenSearch、Chroma、Vespa。オンプレやプライベートクラウドで動かせる
  • 既存 DB 拡張：pgvector（PostgreSQL）、Redis Vector Search、MongoDB Atlas Vector Search。すでに使っている DB を活用できる

規模

  • 数千〜数万チャンク：pgvector・Chroma で十分。運用も軽い
  • 数十万〜数百万チャンク：pgvector・Weaviate・Qdrant・Milvus・Elasticsearch など、選択肢が広がる
  • 数千万〜億単位のチャンク：Milvus・Vespa・Pinecone（大規模プラン）・Weaviate（分散構成）など、水平スケール前提で組む

クエリパターン

  • ベクトル単独検索：シンプルなベクトル DB で十分
  • ハイブリッド検索（BM25＋ベクトル）：Elasticsearch・OpenSearch・Vespa・Qdrant・Weaviate は BM25 とベクトル検索の両方に対応
  • 重いメタデータフィルタ：Qdrant・Weaviate は事前フィルタで強い。pgvector は SQL のクエリで柔軟に組める

統合性

  • 既存の PostgreSQL・Elasticsearch がある：それを拡張する方が学習コストが低い
  • Python のみの環境：Chroma のような Python 中心の実装が入りやすい
  • 多言語（Java・Go）：Vespa・Milvus・Elasticsearch・Qdrant がクライアント SDK を提供
  • 既存の全文検索スキル：Elasticsearch／OpenSearch なら現行スキルが活きる

代表ベクトル DB の系譜と特徴

主要なベクトル DB の系譜と、社内 RAG での位置づけです。

  • pgvector：PostgreSQL の拡張。「既存 DB でとりあえず始める」の第一選択。小〜中規模で十分な性能。SQL でメタデータ絞り込みが柔軟。組織で PostgreSQL 運用に慣れているなら、事実上の第一候補
  • Elasticsearch / OpenSearch：全文検索の代表格。8.x 以降 dense_vector と kNN 検索、ハイブリッド検索が組み込まれている。全文検索の資産があるなら、ハイブリッド検索に強い
  • Weaviate：オランダ発 OSS、GraphQL 中心の DSL、モジュール式のパイプライン（埋め込み・リランクをプラグイン化）が特徴
  • Qdrant：Rust ベース OSS、事前フィルタと HNSW の実装が速い。API が Python 中心で扱いやすい
  • Milvus：Zilliz が主導、Linux Foundation 傘下、Apache License。大規模水平スケールが得意。GPU 索引もサポート
  • Pinecone：フルマネージドで運用の手間が最も軽い。API が単純で立ち上げが速い
  • Chroma：軽量、Python エコシステム親和性が高い。プロトタイピングと小規模社内 RAG に向く
  • Vespa：Yahoo 発、大規模検索とランキングに強い。学習曲線は他より急

📝 補足 どれかが「絶対に正解」ではありません。組織の既存資産と将来の規模、運用スキルで決めます。小規模で立ち上げるなら pgvector か Chroma、全文検索の資産があるなら Elasticsearch／OpenSearch、大規模・低レイテンシが要件なら Milvus・Vespa・Weaviate・Qdrant、が実務での初期候補です。

講師の現場メモ——Pinecone で PoC してから pgvector に統合した話

ある中堅金融機関の社内 RAG の伴走で、こういう案件がありました。DX 推進部門が「短期間で見せられる形にしたい」ということで、初期は Pinecone で PoC を立ち上げました。ドキュメントも豊富、API も単純、マネージドで運用の手間もかからず、パイロットは 4 週間で立ち上がりました。

半年後、全社展開を検討する段階で、情シスから「既存の PostgreSQL クラスターの上でホストできないか」という相談がありました。当該金融機関はすでに PostgreSQL の高可用性クラスターと監視・バックアップの資産があり、監査ログの要件も PostgreSQL 側に統一されていました。ここで pgvector に移行し、既存の PostgreSQL 上で運用する形に落ち着きました。移行は 3 週間、ダウンタイムなし、監査要件も既存インフラで満たせました。

このケースが教えてくれたのは、「PoC で使うベクトル DB」と「本番で運用するベクトル DB」を最初から一致させる必要はない、ということです。PoC は「立ち上げの速さ」で選び、本番は「組織のインフラ・監査・運用スキル」で選ぶ。ただし、そのためにはチャンクとメタデータのスキーマを、初期からベンダーロックインしない形で設計しておくことが大前提です。Pinecone 特有の機能に依存したスキーマにしていれば、pgvector への移行はここまでスムーズにいかなかったでしょう。

ANN 索引の要諦——HNSW・IVF・PQ

数百万以上のベクトルから最近傍を「厳密に」求めると、線形時間になり実用にはなりません。ここで「近似最近傍探索（Approximate Nearest Neighbor、ANN）」の索引構造が使われます。代表的な 3 つを押さえます。

HNSW（Hierarchical Navigable Small World）

Yu. A. Malkov と D. A. Yashunin が 2016 年 arXiv で発表したアルゴリズム。多層のグラフで「近い点は近くに繋がる」構造を作り、上層から下層へ探索します。多くのベクトル DB で標準採用されており、精度と速度のバランスが良いのが特徴です。主要パラメータは M（各点の接続数）と efConstruction／ef（探索の広さ）で、精度と速度のトレードオフを制御します。

IVF（Inverted File Index）

空間を k-means などでクラスタに分け、クエリはまず「近いクラスタ」を選び、その中だけを厳密に探索する方式です。Milvus・FAISS などで採用。HNSW より学習フェーズが必要ですが、大規模データセットでのメモリ効率が良い場合があります。

PQ（Product Quantization、量子化）

Jégou et al. 2011 年の論文で示された、ベクトルを複数の部分に分割して各部分を「代表点の ID」で表現する圧縮技法。数十バイト程度までベクトルを圧縮でき、ストレージとメモリを大きく削減できます。「HNSW × PQ」「IVF × PQ」といった組み合わせがよく使われます。

💡 ポイント 索引方式の選定は、ベクトル DB を選んだ時点で自動的に絞られることが多いです。まずベクトル DB を選び、次に索引方式のパラメータチューニングに入る、が現実の順序です。索引方式単体の理論より、選んだベクトル DB での「デフォルト設定」がどれくらいの精度・速度になるかを、社内文書サンプルで実測することが有効です。

ハイブリッド検索——BM25 ＋ベクトル

ベクトル検索は「意味の近さ」に強い一方、キーワード完全一致には意外と弱いことがあります。「YM-3200」のような型番、「令和 6 年 3 月改訂」のような固有情報、社内略語などは、ベクトル検索だけでは取りこぼす場合があります。

古典的な全文検索アルゴリズムの代表格 BM25（Robertson & Zaragoza）は、この「キーワード完全一致」に強みがあります。両者を組み合わせる「ハイブリッド検索」で、社内 RAG の検索精度は多くの場合で明確に向上します。

flowchart LR
  Q[クエリ] --> V[ベクトル検索<br/>意味の近さ]
  Q --> B[BM25<br/>キーワード完全一致]
  V --> RRF[Reciprocal Rank Fusion<br/>など、ランクの融合]
  B --> RRF
  RRF --> R[統合された<br/>上位候補]

Reciprocal Rank Fusion（RRF）

ハイブリッド検索の融合方法として、最も使われているのが RRF です。各検索方法の順位（ランク）を、1 / (k + rank)（k は定数、通常 60）で重み付けし、合計スコアで並べ替える手法です。実装が単純で、方法間のスコアスケールが違ってもうまく機能する利点があります。

重み付け・パラメータ設計

BM25 とベクトル検索のバランスは、文書と質問の性質で異なります。「型番・固有名詞が多い技術ドキュメント」なら BM25 の比重を上げ、「概念的な質問が多い FAQ」ならベクトル検索の比重を上げる、といった具合です。RRF の k、あるいは加重和の重み係数を、評価データセット（レッスン 6）で最適化します。

リランキング——上位候補の再スコアリング

ハイブリッド検索の後、返ってきた 50〜100 件の上位候補を「もう一度、クエリとの関連度で並べ替える」段が、リランキングです。ここで精度がさらに底上げされます。

Cross-Encoder

Sentence-BERT（Reimers & Gurevych、EMNLP 2019）の系譜で、クエリと候補を 同時に Transformer に入れて関連度スコアを出力するモデル。埋め込みモデル（Bi-Encoder）よりも精度が高い一方、計算コストが高いため、上位候補 50〜100 件に絞ってから適用します。日本語には、MTEB／JMTEB の cross-encoder 系タスクで評価された OSS が使えます。

Cohere Rerank

Cohere 社が提供するリランク専用モデルの API。多言語対応で、日本語でも実用的な精度が出ます。マネージドで導入が軽く、社内 RAG のリランク層として広く採用されています。

LLM Rerank

GPT-4／Claude／Gemini のような汎用 LLM に「クエリと候補文書の関連度を 0〜10 で採点して」と頼むパターン。精度は高いが、コスト・レイテンシが最も高い。上位 5〜10 件の絞り込みなど、限定的な用途で使われます。

⚠️ 注意 リランクは強力ですが、コストとレイテンシが増えます。「リランクを入れれば入れるほど良い」ではなく、評価指標（レッスン 6）で「効果」と「追加コスト」のバランスを判定するのが実務の姿勢です。ハイブリッド検索だけで十分な精度が出るケースも多くあります。

メタデータフィルタでの絞り込み

社内 RAG では、ベクトルの近さだけでなく「部署が営業本部で、有効期間内で、権限タグが一般公開のもの」といった条件で絞り込む場面が多くあります。これがメタデータフィルタです。

  • 事前フィルタ：まずメタデータで絞り、その中でベクトル検索する方式。絞り込みが強いと候補が少なくなり、ANN 索引の効率が下がる場合がある
  • 事後フィルタ：まずベクトル検索した候補から、メタデータで絞り込む方式。上位候補が絞り込み条件でごっそり消える場合、必要件数が集まらない懸念がある
  • ハイブリッドな実装：Qdrant・Weaviate・Milvus・Pinecone・Vespa は、いずれも事前フィルタと ANN を組み合わせた実装を持ち、多くの場合で自動的に切り替わる

権限タグでの絞り込みは、次レッスンでも扱う「権限伝播」の中核です。検索時に権限フィルタを必ず通す設計にしておくことが、社内 RAG のセキュリティの前提です。

中核メッセージの再確認

本レッスンで扱った内容を、中核メッセージに戻して整理します。

  • RAG の 8 割は LLM の外側で決まる——ベクトル DB 選定、ハイブリッド検索、リランクは、生成 LLM を変えるより検索精度への効果が大きい
  • 検索の品質が生成の品質の天井を決める——ここで返せた文書の中からしか、生成 LLM は答えを作れない
  • 権限伝播とガバナンスは後から足せない——検索段階でメタデータフィルタが通っていなければ、生成側でどう頑張っても情報漏洩は防げない

まとめ

  • ベクトル DB は 4 軸（運用形態・規模・クエリパターン・統合性）で選定する
  • pgvector・Elasticsearch／OpenSearch・Weaviate・Qdrant・Milvus・Pinecone・Chroma・Vespa の位置づけを、組織の既存資産に照らして判断する
  • ANN 索引は HNSW・IVF・PQ が代表。多くの場合でベクトル DB のデフォルト設定＋実測が現実的
  • ハイブリッド検索（BM25 ＋ベクトル、RRF）は社内 RAG の精度を大きく上げる
  • リランキング（Cross-Encoder・Cohere Rerank・LLM Rerank）は上位候補の再スコアリング。効果と追加コストのバランスで判定
  • メタデータフィルタは事前・事後・ハイブリッドの実装があり、権限タグでのフィルタは必須
  • PoC のベクトル DB と本番のベクトル DB を一致させる必要はない。ただしスキーマはベンダーロックインしない形で設計

次のレッスンでは、返ってきた検索結果を LLM に渡す「生成段階」に踏み込みます。クエリ理解（HyDE・Multi-Query）、RAG 特化の生成側プロンプト、番号引用、Lost in the Middle 対策、フォールバック応答を扱います。

確認クイズ

このレッスンの内容の理解度をチェックしましょう。