RAG用埋め込みインデックス（アールエージーヨウウメコミインデックス）
RAG用埋め込みインデックスは、テキストチャンクのベクトル表現を効率的に格納・検索するためのデータ構造であり、HNSW・IVF・PQ等のアルゴリズムとベクトルDBの選択がRAGの検索速度と精度を決定する。
埋め込みインデックスとは
埋め込みインデックス（Embedding Index）は、RAGパイプラインにおいてテキストチャンクのベクトル表現（Embedding）を格納し、クエリベクトルとの類似度に基づく高速な近傍探索を実現するためのデータ構造である。数百万〜数十億件のベクトルを効率的に検索するため、近似最近傍探索（ANN: Approximate Nearest Neighbor）アルゴリズムが使用される。
ベクトルの次元数は使用するEmbeddingモデルによって異なり、OpenAI text-embedding-3-largeが3072次元、BGE-M3が1024次元、Voyage-3が1024次元である。これらの高次元ベクトルに対して全件線形探索（Brute-force）を行うと計算量がO(N×d)となり、大規模データセットでは実用的なレイテンシを達成できない。ANNアルゴリズムは、100%の正確性を犠牲にして劇的な速度向上を実現する。
主要なANNアルゴリズム
RAGで使用される代表的なANNアルゴリズムを比較する。
| アルゴリズム | 検索速度 | メモリ使用量 | 精度（Recall@10） | インデックス構築速度 | 動的追加 |
|---|---|---|---|---|---|
| HNSW | 非常に速い | 高い | 95〜99% | 遅い | 可能 |
| IVF-Flat | 速い | 中程度 | 90〜95% | 速い | 限定的 |
| IVF-PQ | 速い | 非常に低い | 85〜92% | 中程度 | 限定的 |
| ScaNN | 非常に速い | 中程度 | 95〜98% | 中程度 | 可能 |
| DiskANN | 速い（SSD活用） | 低い | 93〜97% | 遅い | 可能 |
HNSW（Hierarchical Navigable Small World）
HNSWは、現在最も広く採用されているANNアルゴリズムであり、グラフベースの階層的構造を用いて高速な近傍探索を実現する。Yuri Malkov らが2016年に提案し、2018年に改良版を発表した。
HNSWの基本原理は、データポイント間の近傍関係をSmall Worldグラフとして構築し、複数の階層（レイヤー）に分けて探索を行うことである。上位レイヤーは少数のノードによる粗い探索を、下位レイヤーは多数のノードによる精密な探索を担当する。探索は最上位レイヤーから開始し、各レイヤーで最も近いノードを見つけながら下位レイヤーに移動する。
主要なパラメータは以下の2つである:
- M（接続数）: 各ノードが持つ最大エッジ数。大きいほど精度が向上するがメモリ消費が増加する。推奨値: 16〜64
- efConstruction（構築時探索幅）: インデックス構築時の探索候補数。大きいほどインデックス品質が向上するが構築時間が増加する。推奨値: 100〜200
- efSearch（検索時探索幅）: 検索時の探索候補数。大きいほど精度が向上するがレイテンシが増加する。推奨値: 50〜200
HNSWの最大の利点は、新しいベクトルの動的追加が可能なことである。RAGでは新しいドキュメントが継続的に追加されるため、この特性は非常に重要である。一方、メモリ消費量がベクトル数に比例して増大するため、数十億件規模では課題となる。
IVF（Inverted File Index）
IVF（転置ファイルインデックス）は、ベクトル空間をクラスタリングによって複数のパーティション（Voronoi セル）に分割し、検索時にはクエリに最も近いパーティションのみを探索することで検索範囲を削減するアルゴリズムである。
IVFの主要パラメータは以下の通り:
- nlist（パーティション数）: クラスタ数。sqrt(N)〜4*sqrt(N)が推奨される（Nはベクトル数）
- nprobe（探索パーティション数）: 検索時に探索するパーティション数。大きいほど精度が向上するが速度が低下する
IVF単体（IVF-Flat）では各パーティション内のベクトルをそのまま保持するため、メモリ効率はHNSWと同程度である。IVFの真価は、PQ（Product Quantization）との組み合わせ（IVF-PQ）で発揮される。
PQ（Product Quantization）
PQ（直積量子化）は、高次元ベクトルを複数のサブベクトルに分割し、各サブベクトルを事前学習したコードブックで近似表現することで、メモリ使用量を劇的に削減する圧縮手法である。
例えば、768次元のfloat32ベクトル（3,072バイト）を8つのサブベクトルに分割し、各サブベクトルを256個のセントロイドの1つに近似すると、1ベクトルあたりわずか8バイトで表現できる。圧縮率は約384倍である。
| 設定 | 元サイズ | PQサイズ | 圧縮率 | Recall@10低下 |
|---|---|---|---|---|
| 768d, M=8 | 3,072B | 8B | 384x | 5〜10% |
| 768d, M=16 | 3,072B | 16B | 192x | 2〜5% |
| 768d, M=32 | 3,072B | 32B | 96x | 1〜3% |
| 1536d, M=48 | 6,144B | 48B | 128x | 2〜5% |
PQは圧縮による精度低下が避けられないため、RAGの検索精度要件に応じたサブベクトル数（M）の選択が重要である。精度が最優先の場合はHNSWまたはIVF-Flatを、コスト効率が重要な場合はIVF-PQを選択する。
ベクトルデータベースの比較
RAGで使用される主要なベクトルデータベースを比較する。
| ベクトルDB | ライセンス | 主要アルゴリズム | スケーラビリティ | 特徴 |
|---|---|---|---|---|
| Qdrant | Apache-2.0 | HNSW | 分散クラスタ | Rustで高性能、フィルタリング高速 |
| Pinecone | プロプライエタリ | 独自 | マネージド | フルマネージド、運用負荷ゼロ |
| Weaviate | BSD-3 | HNSW | 分散クラスタ | GraphQL API、ハイブリッド検索内蔵 |
| Milvus | Apache-2.0 | IVF/HNSW/DiskANN | 分散クラスタ | 10億ベクトル級、GPU対応 |
| Chroma | Apache-2.0 | HNSW | シングルノード | 組み込み可能、開発用途 |
| pgvector | PostgreSQL | HNSW/IVFFlat | PostgreSQL依存 | 既存PostgreSQLに統合可能 |
選択基準は、データ規模（〜100万件ならpgvector、100万〜1億件ならQdrant/Weaviate、1億件以上ならMilvus/Pinecone）、運用体制（マネージドならPinecone、セルフホストならQdrant/Milvus）、メタデータフィルタリングの要件（Qdrantが最も柔軟）、既存インフラとの統合（PostgreSQL既存ならpgvector）によって決まる。
インデックスの最適化戦略
RAGシステムの本番運用では、以下の最適化戦略が重要である。
1. メタデータフィルタリングの活用: ベクトル検索の前にメタデータ（日時、カテゴリ、ソースなど）でフィルタリングすることで、検索空間を削減し精度とレイテンシを改善する。Qdrantの「payload index」やWeaviateの「where filter」が対応している。
2. マルチテナント設計: 複数のユーザーやプロジェクトが同一インデックスを共有する場合、テナントIDによるパーティショニングが必要である。Qdrantのcollection aliasやPineconeのnamespaceが利用できる。
3. インデックスの段階的構築: 大規模データの初期ロード時は、バッチ挿入後にインデックスを一括構築する方が、逐次挿入よりも高速かつ高品質なインデックスが得られる。
よくある質問（FAQ）
Q: pgvectorとQdrantのどちらを選ぶべきですか？ A: 既存のPostgreSQLインフラがあり、ベクトル数が100万件以下、メタデータフィルタリングがSQLで表現可能な場合はpgvectorが最適である。100万件以上のスケールや、複雑なフィルタリング条件（ネストされたJSON条件等）が必要な場合、または検索レイテンシの要件がシビアな場合はQdrantやWeaviateが適している。pgvectorはPostgreSQL 16以降でHNSWインデックスをサポートしており、性能が大幅に向上している。
Q: Embeddingモデルの次元数はどう選びますか？ A: 次元数が大きいほど情報量が増え精度が向上するが、ストレージコストとレイテンシも増加する。OpenAI text-embedding-3-largeは3072次元だが、Matryoshka Representation Learning（MRL）により任意の低次元（256, 512, 1024等）に切り詰めても高い精度を維持できる。コスト重視なら512〜1024次元、精度重視なら1536〜3072次元が推奨される。
Q: インデックスの再構築はどの頻度で行うべきですか？ A: HNSWは動的追加に対応しているため、通常は再構築不要である。ただし、大量のデータ削除や更新があった場合は、断片化によるパフォーマンス低下を防ぐために定期的な再構築（例: 週次）が推奨される。IVFベースのインデックスは、データ分布が大きく変化した場合にクラスタのセントロイドを再計算する必要がある。