クイックリファレンス

ベクトルデータベースと検索アーキテクチャ早見表:基礎概念・インデックス・量子化・製品選定

ベクトルデータベースと意味検索(セマンティック検索)の高密度リファレンス:距離尺度、ANNインデックス(HNSW/IVF/DiskANN/ScaNN)、量子化メモリ試算、インラインフィルタリング、RRFハイブリッド検索、専用DB・拡張機能・クラウドマネージドサービスの階層別比較を網羅。

· 公開日

**ベクトルデータベース(Vector Database)**は、高次元の密/疎埋め込みベクトル(Embedding)とメタデータを格納し、近似最近傍探索(ANN)インデックスによってミリ秒単位の類似検索を実現する、RAG・意味検索・AIエージェント記憶層の基盤ストレージです。

ワークロード / 制約条件 推奨カテゴリ 代表的な製品 選定理由
既存の PostgreSQL 基盤・約1,000万件以下 RDB ベクトル拡張 pgvector (+ halfvec / HNSW) ACID トランザクション、SQL JOIN、既存運用をそのまま活用でき新規基盤が不要
全文検索 BM25 + ベクトルハイブリッド 検索エンジン拡張 Elasticsearch / OpenSearch / Vespa 成熟した転置インデックスと多段階ハイブリッドランキング生態系
高QPS本番サービス・高度なフィルタリング 専用分散ベクトルDB Qdrant / Milvus / Weaviate 専用ストレージエンジン、高速ペイロードフィルタ、水平スケーリングに強い
ローカル開発・エッジ・データレイク直接参照 組み込み / 列指向DB LanceDB / Chroma / FAISS インプロセス実行、Apache Arrow / Parquet とのゼロコピー連携
大規模コールド/ウォームデータの超低コスト保存 オブジェクトストレージネイティブ SaaS Turbopuffer S3/GCS を正本としローカル NVMe/RAM キャッシュで低コストを実現
運用レス・パブリッククラウドとの深い統合 フルマネージドクラウド Pinecone / Vertex AI Vector Search / Azure AI Search サーバーレス自動拡張とクラウド IAM・監視のシームレスな統合

🔗 関連早見表: LLM & AIエージェント技術概念早見表 · 現代AI中核アルゴリズム早見表 · PostgreSQL コマンド早見表 · Redis コマンド早見表 · MongoDB コマンド早見表


1. コア概念と距離尺度

1.1 基本用語集

用語 定義 エンジニアリング上の注目点
Embedding(埋め込みベクトル) テキスト・画像・音声などの意味を固定長の浮動小数点配列へ変換した表現 代表次元数:384 / 768 / 1024 / 1536 / 3072。次元数に比例してメモリと計算量が増加
ANN(近似最近傍探索) わずかな再現率(例: 95%–99%)を譲る代わりに検索速度を100〜1000倍高速化する手法 遅延と精度のトレードオフの核(全件厳密走査の k-NN と対比)
Metadata Filtering スカラー属性(テナント、日時、権限、カテゴリ)でベクトル検索対象を絞り込む処理 Pre-filtering / Single-stage(Inline) / Post-filtering の区別が重要
Hybrid Search(ハイブリッド検索) 密ベクトル(意味類似)と疎ベクトル / BM25(厳密なキーワード一致)の融合 型番・エラーコード・略語など純粋な意味検索の取りこぼしを補完
Sparse Vector(疎ベクトル) 大部分の要素が 0 である高次元表現(SPLADE、BM25 の重みなど) 非ゼロ要素のインデックスと重みのみを保存し、密検索と組み合わせて利用

1.2 3大距離・類似度尺度

Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v)     = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v)     = √( ∑ᵢ (uᵢ − vᵢ)² )
尺度 意味 数学的等価関係 主な適用シーン
コサイン類似度 (Cosine) ベクトルの向き(角度)のみを比較し長さを無視(−1〜1、距離は 1 - cos) L₂正規化済みベクトルでは内積と順位が完全一致 テキスト意味検索、RAG、文埋め込み(デフォルト推奨)
内積 (Inner Product / IP) 角度と長さの両方を反映。計算コストが最小 正規化済みベクトルなら Cosine の代わりに IP を使い除算・平方根を省略可能 推薦システム、正規化済み Embedding(OpenAI 等)
ユークリッド距離 (L₂) 空間上の直線距離(小さいほど近い) 単位ベクトルでは L₂² = 2 − 2 · cos(u, v) 画像・顔特徴比較、座標クラスタリング、長さ情報が必要な特徴

2. ANN インデックスアルゴリズムと量子化圧縮

2.1 ベクトルインデックス比較

インデックス種別 仕組み メモリ消費 速度と再現率 規模と代表的な実装
Flat(厳密走査) 全ベクトルとの距離を総当たり計算 中(生/量子化ベクトルのみ) 再現率100%。約10万件超で遅延が急増 10万件未満の小規模データ、再現率ベンチマーク基準
IVF-Flat(転置ファイル) K-Means で nlist 個のバケットに分割し近傍 nprobe 個を走査 低(グラフ構造の追加負荷なし) nprobe で調整可能、再現率は中〜高 メモリ制約のある100万〜1,000万件規模(FAISS / Milvus / pgvector)
IVF-PQ(IVF + 積量子化) バケット分割+部分空間コードブック圧縮 極低(1/16〜1/64 に圧縮) 超高速だが1段階目の再現率は低下、再ランキング併用が定石 1億件超のオンメモリ検索(FAISS / Milvus / LanceDB)
HNSW(階層的探索グラフ) 多層スキップリスト状の近傍グラフ(上層で粗探索、下層で精密探索) 高(ベクトル+グラフ隣接表を RAM/mmap 常駐) ミリ秒遅延 + 95%–99% 高再現率、商用標準 100万〜1億件超のリアルタイム検索(Qdrant / Milvus / Weaviate / pgvector)
DiskANN(Vamana グラフ) SSD 最適化グラフ:圧縮ベクトルを RAM、本体グラフと元ベクトルを NVMe に配置 低(メモリ使用量を5〜10分の1に削減) 単一ノードで1億件超をミリ秒応答(高速 NVMe IOPS に依存) メモリ予算が厳しい1億〜10億件規模(Milvus / LanceDB / Azure)
ScaNN 異方性ベクトル量子化 + 木構造パーティショニング 低〜中 内積検索において同遅延帯で極めて高い再現率 Google 系の大規模推薦・検索(Vertex AI Vector Search / OSS)

HNSW 主要チューニングパラメータ:

  • M(ノードあたりの最大双方向リンク数、目安 16–64):大きいほど高次元データの再現率が向上するがメモリと構築時間が増大。
  • efConstruction(構築時の探索候補リスト長、目安 100–400):構築時間のみに影響し、大きくするとグラフ品質が向上。
  • efSearch(検索時の動的探索幅、top_k 以上が必須):クエリ単位で動的変更可能な唯一のパラメータ。増やすと再現率が上がり QPS が下がる。

2.2 ベクトル量子化(Quantization)とメモリ試算

1,000万件 × 1536次元ベクトル(FP32 生データ)の基準試算:

生ベクトル容量 ≈ N × D × 4 Bytes   (HNSW グラフ構造に約 1.2×〜1.5× の追加メモリが必要)
量子化方式 1次元あたりビット幅 圧縮率 1,000万 × 1536次元容量 精度トレードオフと用途
FP32(非圧縮) 32-bit (4 B) 1× ~57.2 GB 基準精度。全量 RAM 常駐コストが高い
FP16 / BF16(半精度) 16-bit (2 B) 2× ~28.6 GB 精度劣化がほぼ無く(pgvector halfvec 等)、費用対効果が極めて高い
SQ8(スカラー量子化 Int8) 8-bit (1 B) 4× ~14.3 GB 再現率 97%以上を維持しやすく、本番環境の標準圧縮
PQ(積量子化) サブ空間/コードブック依存 16×–64× ~1–4 GB 学習が必要。多段抽出+元ベクトル再計算(Rescore)と併用
BQ(バイナリ量子化 1-bit) 1-bit 32× ~1.79 GB ハミング距離で超高速粗抽出。3×–5× オーバーサンプリング+Rescore 推奨(1024次元以上で有効)

3. 主流ベクトルDB・検索エンジン階層別比較

3.1 専用ネイティブベクトルデータベース

製品 ライセンス / 提供形態 実装言語とストレージ設計 インデックスと特徴 適した用途
Qdrant Apache 2.0 / Self-hosted & Cloud Rust;オンメモリ / mmap / ディスク量子化 HNSW + SQ8/BQ、疎ベクトル対応、高速ペイロードフィルタ 高QPS独立サービス、マルチテナント、複雑な属性絞り込み
Milvus Apache 2.0 / 分散型 & Zilliz Cloud Go 制御層 + C++ 実行層;コンピュート・ストレージ分離 IVF, HNSW, DiskANN, GPU CAGRA、マルチテナント分割 10億件級の大規模・高スループット基盤
Weaviate BSD-3-Clause(一部企業向け機能は商用) Go;内蔵オブジェクトストレージ + 転置インデックス HNSW + 動的/PQ/BQ量子化、GraphQL/REST、モジュール式ベクトル化 ベクトル化パイプライン一体型の RAG 構築
Chroma Apache 2.0 / 組み込み & Client-Server Python / Rust コア;SQLite + ローカル/分散 HNSW、シンプルな API、LangChain / LlamaIndex と密連携 プロトタイピング、中小規模 Python RAG
LanceDB Apache 2.0 / 組み込み & Enterprise Rust;Lance 列指向フォーマット & Apache Arrow IVF-PQ, HNSW, DiskANN、ゼロコピー I/O、マルチモーダルネイティブ ローカル組み込み、サーバーレス S3 直読み、マルチモーダル基盤
Pinecone プロプライエタリ Serverless SaaS マネージド分散エンジン(Pod から Serverless へ進化) コンピュート・ストレージ分離、疎密ハイブリッド、Namespace 分離 運用レスを最優先するクラウド本番システム
Turbopuffer プロプライエタリ SaaS / BYOC Rust;オブジェクトストレージ(S3/GCS)正本 + NVMe/RAM キャッシュ ランダム I/O の多いグラフ索引を避けたセントロイド索引(SPFresh 系)、全文 + ベクトル コールド/ウォーム偏在の大規模データ(コード索引等)の超低コスト運用

3.2 純粋ベクトル検索ライブラリ(DB ではない)

製品 ライセンス 機能範囲と境界 適用シーン
FAISS (Meta) MIT C++ / Python 類似検索ライブラリ(メタデータ永続化・分散トランザクション・認証サーバーなし);CPU SIMD / マルチ GPU 対応 オフライン一括計算、アルゴリズム検証、独自エンジンへの組み込みコア

3.3 既存データベース・検索エンジンのベクトル拡張

製品 基盤 ベクトル機能 長所と制約
pgvector PostgreSQL 拡張(Supabase 等を含む) vector / halfvec / sparsevec / bit 型;HNSW & IVFFlat 長所:ACID・SQL JOIN・追加運用ゼロ;制約:数千万件超で書込増幅とメモリ負荷増
Elasticsearch / OpenSearch Lucene 転置索引 + HNSW Dense Vector + BM25 ネイティブハイブリッド、RRF、ネスト絞り込み 長所:検索チームの既存技術資産を再利用;制約:JVM ヒープ外メモリとマージ負荷が大きい
Redis (Query Engine) インメモリ KV ストア Flat / HNSW インデックス、サブミリ秒応答、リアルタイム更新 長所:セマンティックキャッシュや特徴量ストアに最適;制約:大規模時のメモリコスト高
MongoDB Atlas Search ドキュメントDB(Atlas / Local CLI) Lucene ベース HNSW、BSON ドキュメントと同一基盤で検索 長所:ドキュメントとベクトルの二重書き込み同期が不要;制約:Atlas 環境への依存
SingleStore 分散 HTAP SQL DB SQL + ネイティブベクトル演算(内積/L₂)、列指向+行指向混在 リアルタイム SQL 分析とトランザクションを両立する企業システム
Vespa Apache 2.0 大規模サービング基盤 HNSW + 厳密/近似ハイブリッド、多段階 ML ランキング(Tensor/XGBoost/ONNX) 超大規模検索・推薦プラットフォーム(学習・運用コストは高め)

3.4 パブリッククラウドフルマネージドサービス

サービス名 クラウド コア技術と特徴
Vertex AI Vector Search(旧 Matching Engine) Google Cloud (GCP) Google ScaNN ベース、10億件級のストリーミング更新と疎密ハイブリッドに対応
Amazon OpenSearch Serverless / Aurora pgvector AWS サーバーレス検索クラスタと RDB ベクトル拡張、Amazon Bedrock ナレッジベース連携
Azure AI Search Microsoft Azure Semantic Ranker、統合ベクトル化パイプライン、エンタープライズ RBAC 文書権限制御

4. フィルタリング戦略とハイブリッド検索

4.1 メタデータフィルタリング実行方式

戦略 実行順序 弱点とエンジニアリング対策
Pre-filtering(事前フィルタ) スカラー索引で対象 ID ビットマップを作成し、その範囲でベクトル検索 一致率 1% 未満の厳しい条件ではグラフが分断され再現率低下;対策:閾値で厳密走査へ自動フォールバック
Post-filtering(事後フィルタ) 全体から Top-K を取得後、条件に合わない結果を除外 返却件数が K 未満(最悪 0 件)になる;対策:単独利用は避け、大幅なオーバーサンプリングが必須
Single-stage / Inline(統合フィルタ) HNSW グラフ探索の各ステップでビットマップをリアルタイム照合 現在の主流(Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan)で精度と速度を両立

4.2 逆順位融合(RRF: Reciprocal Rank Fusion)

密ベクトル検索と BM25 全文検索ではスコア尺度が異なるため、RRF で順位ベースに統合します:

RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d))     (経験的平滑定数 k = 60)

5. 本番スニペット早見表

5.1 pgvector テーブル設計・HNSW・反復スキャン(SQL)

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    tenant_id INT NOT NULL,
    content TEXT NOT NULL,
    embedding halfvec(1536),          -- float16 でメモリを50%削減
    fts tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);

CREATE INDEX idx_docs_emb_hnsw ON documents
    USING hnsw (embedding halfvec_cosine_ops)
    WITH (m = 16, ef_construction = 128);

CREATE INDEX idx_docs_fts ON documents USING gin (fts);

SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;

SELECT id, content, 1 - (embedding <=> $1::halfvec) AS cosine_sim
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::halfvec
LIMIT 10;

pgvector 距離演算子: <-> ユークリッド距離 (L₂) · <=> コサイン距離 (1 - cos) · <#> 負の内積 · <+> マンハッタン距離 (L₁)。

5.2 Qdrant バイナリ量子化と Payload フィルタリング(Python)

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="knowledge_base",
    vectors_config=models.VectorParams(
        size=1536,
        distance=models.Distance.COSINE,
        on_disk=True,
    ),
    quantization_config=models.BinaryQuantization(
        binary=models.BinaryQuantizationConfig(always_ram=True)
    ),
)

client.create_payload_index(
    collection_name="knowledge_base",
    field_name="tenant_id",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

hits = client.query_points(
    collection_name="knowledge_base",
    query=[0.012, -0.045, ...],
    query_filter=models.Filter(
        must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="org_a"))]
    ),
    search_params=models.SearchParams(
        quantization=models.QuantizationSearchParams(rescore=True, oversampling=3.0)
    ),
    limit=10,
).points

関連テーマ