RAG 比較のためのベクトルストア
RAG スタックに適したベクター DB を選択しましょう
適切な ベクトルストア を選択することは、RAG アプリケーションのパフォーマンス、コスト、スケーラビビリティを決定づけます。この包括的な比較では、2024-2025 年における最も人気のあるオプションを取り上げています。

アーキテクチャから本番環境に至るまで、RAG システムの構築に関する完全なガイドについては、Retrieval-Augmented Generation (RAG) チュートリアル を参照してください。
ベクトルストアとは何か、そしてなぜ RAG が必要なのか
ベクトルストアは、高次元の埋め込みベクトルを保存およびクエリするために設計された専門データベースです。 Retrieval Augmented Generation (RAG) システムにおいて、ベクトルストアは知識のバックボーンとして機能し、文脈的に適切なドキュメントの取得を可能にする意味的類似度検索を実現します。
RAG パイプラインを構築する際、ドキュメントは OpenAI の text-embedding-3-small や、BGE、E5 などのオープンソースの代替モデルなどによって埋め込み(濃密な数値ベクトル)に変換されます。最先端の多言語パフォーマンスについては、Qwen3 埋め込みおよびリランカーモデル が、ローカル展開における Ollama との優れた統合を提供します。多言語およびマルチモーダルアプリケーションでは、クロスモーダル埋め込み を使用することで、異なるデータタイプ(テキスト、画像、音声)を統一された表現空間に統合できます。これらの埋め込みは意味的な意味を捉えるため、正確なキーワード一致ではなく、意味に基づいてドキュメントを検出できます。
ベクトルストアは以下の処理を担います:
- 保存: 数百万から数十億のベクトルの保存
- 索引付け: 高速な近似最近傍 (ANN) 検索のための索引付け
- フィルタリング: メタデータによる検索範囲の絞り込み
- CRUD 操作: 知識ベースの維持管理
関連するドキュメントを取得した後、埋め込みモデルによるリランキング を行うことで、より高度な類似度測定を使用して候補を再スコアリングし、取得の品質をさらに向上させることができます。
簡易比較表
| ベクトルストア | タイプ | 最適用途 | ホスティング | ライセンス |
|---|---|---|---|---|
| Pinecone | 管理型 | 本番環境、ゼロオペレーション | クラウドのみ | 専有 |
| Chroma | 埋め込み/サーバー | プロトタイピング、シンプルさ | セルフホスト | Apache 2.0 |
| Weaviate | サーバー | ハイブリッド検索、GraphQL | セルフホスト/クラウド | BSD-3 |
| Milvus | サーバー | スケール、エンタープライズ | セルフホスト/クラウド | Apache 2.0 |
| Qdrant | サーバー | 豊富なフィルタリング、Rust のパフォーマンス | セルフホスト/クラウド | Apache 2.0 |
| FAISS | ライブラリ | 埋め込み、研究 | メモリ内 | MIT |
| pgvector | 拡張機能 | PostgreSQL 統合 | セルフホスト | PostgreSQL |
詳細なベクトルストアの解説
Pinecone — 管理型のリーダー
Pinecone は、機械学習アプリケーションのために特別に設計された、完全に管理されたベクトルデータベースです。
from pinecone import Pinecone
pc = Pinecone(api_key="YOUR_API_KEY")
index = pc.Index("my-rag-index")
# ベクトルのアップサート
index.upsert(vectors=[
{"id": "doc1", "values": embedding, "metadata": {"source": "wiki"}}
])
# メタデータフィルタリング付きのクエリ
results = index.query(
vector=query_embedding,
top_k=5,
filter={"source": {"$eq": "wiki"}}
)
メリット:
- インフラ管理がゼロ
- 優れたドキュメントと SDK サポート
- クエリ課金制のサーバーレスティア
- 高速なクエリレイテンシ(P99 で約 50ms)
デメリット:
- クラウド専用(セルフホスティング不可)
- 使用量に応じてコストが変動 -ベンダーロックインの懸念
最適用途: 本番投入の速度と運用の単純さを優先するチーム向け。
Chroma — 開発者のファボリット
Chroma は、「AI ネイティブなオープンソース埋め込みデータベース」として位置づけられています。そのシンプルさと、LangChain や LlamaIndex とのシームレスな統合が愛されています。
import chromadb
client = chromadb.Client()
collection = client.create_collection("my-docs")
# 自動埋め込み機能付きのドキュメント追加
collection.add(
documents=["Doc content here", "Another doc"],
metadatas=[{"source": "pdf"}, {"source": "web"}],
ids=["doc1", "doc2"]
)
# クエリ
results = collection.query(
query_texts=["semantic search query"],
n_results=5
)
メリット:
- 非常にシンプルな API
- 埋め込み機能の標準搭載
- 埋め込み(メモリ内)またはクライアントサーバーモードで動作
- 一等級の LangChain/LlamaIndex 統合
デメリット:
- 非常に大きなデータセットのスケーラビリティに限界
- エンタープライズ機能が少ない
- 埋め込みモードでの永続化が複雑な場合がある
最適用途: プロトタイピング、小〜中規模プロジェクト、Python 優先のチーム向け。
Weaviate — ハイブリッド検索のチャンピオン
Weaviate は、ベクトル検索にキーワード(BM25)検索を組み合わせ、GraphQL API を提供します。ハイブリッド検索で取得品質が向上するシナリオに優れています。
import weaviate
client = weaviate.Client("http://localhost:8080")
# ベクトライザー付きスキーマの作成
client.schema.create_class({
"class": "Document",
"vectorizer": "text2vec-openai",
"properties": [{"name": "content", "dataType": ["text"]}]
})
# ハイブリッド検索(ベクトル + キーワード)
result = client.query.get("Document", ["content"]) \
.with_hybrid(query="RAG architecture", alpha=0.5) \
.with_limit(5) \
.do()
メリット:
- ネイティブなハイブリッド検索(alpha パラメータでベクトル/キーワードのバランス調整)
- 埋め込みモジュールの標準搭載
- GraphQL クエリ言語
- マルチテナンシー対応
デメリット:
- 運用の複雑さが高い
- 学習曲線が急
- リソース集約型
最適用途: ハイブリッド検索と GraphQL API が必要となる本番アプリケーション向け。
Milvus — エンタープライズ規模
Milvus は、数十億規模のベクトル類似度検索のために設計されています。大規模なスケーリングを必要とするエンタープライズ展開の定番選択です。
from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
connections.connect("default", host="localhost", port="19530")
# スキーマの定義
fields = [
FieldSchema(name="id", dtype=DataType.INT64, is_primary=True),
FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536)
]
schema = CollectionSchema(fields)
collection = Collection("documents", schema)
# 挿入と検索
collection.insert([[1, 2, 3], [embedding1, embedding2, embedding3]])
collection.search(
data=[query_embedding],
anns_field="embedding",
param={"metric_type": "COSINE", "params": {"nprobe": 10}},
limit=5
)
メリット:
- 数十億ベクトル規模での実績
- 複数の索引タイプ(IVF、HNSW、DiskANN)
- GPU アクセラレーション対応
- 活発なエンタープライズコミュニティ(Zilliz Cloud)
デメリット:
- 展開が複雑(etcd、MinIO の必要)
- 小規模プロジェクトには過剰
- 運用オーバーヘッドが高い
最適用途: 大規模なエンタープライズ展開と、DevOps 能力を持つチーム向け。
Qdrant — パフォーマンスとフィルタリングの融合
Qdrant は Rust で書かれており、優れたパフォーマンスと豊富なメタデータフィルタリング機能を誇ります。本番 RAG において人気が高まっています。
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
client = QdrantClient("localhost", port=6333)
# コレクションの作成
client.create_collection(
collection_name="documents",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE)
)
# 豊富なペイロード付きアップサート
client.upsert(
collection_name="documents",
points=[
PointStruct(id=1, vector=embedding, payload={"category": "tech", "date": "2024-01"})
]
)
# 複雑なフィルタリング付き検索
client.search(
collection_name="documents",
query_vector=query_embedding,
query_filter={"must": [{"key": "category", "match": {"value": "tech"}}]},
limit=5
)
メリット:
- 優れたクエリパフォーマンス(Rust 製)
- ネストされた条件を含む豊富なフィルタリング
- メモリ効率のための量子化
- 機能とシンプルさのバランスが良好
デメリット:
- Pinecone/Weaviate に比べるとエコシステムが小さい
- クラウドサービスは比較的新しい
最適用途: 複雑なフィルタリング要件と高いパフォーマンスを必要とするチーム向け。
FAISS — 研究用の馬力
FAISS (Facebook AI Similarity Search) はデータベースではなくライブラリです。多くのベクトル DB がこれに基づいて構築されています。
import faiss
import numpy as np
# 索引の作成
dimension = 1536
index = faiss.IndexFlatIP(dimension) # 内積類似度
# ベクトルの追加
vectors = np.array(embeddings).astype('float32')
index.add(vectors)
# 検索
D, I = index.search(query_embedding.reshape(1, -1), k=5)
メリット:
- メモリ内検索が爆速
- 複数の索引タイプ(Flat、IVF、HNSW、PQ)
- GPU サポート
- ネットワークオーバーヘッドなし
デメリット:
- 永続化なし(手動で保存/ロードが必要)
- メタデータフィルタリングなし
- CRUD 操作なし(更新には索引再構築が必要)
- シングルノードのみ
最適用途: 研究、プロトタイピング、ベクトルがメモリに収まるシナリオ向け。
pgvector — PostgreSQL ネイティブ
pgvector は PostgreSQL にベクトル類似度検索を追加します。既存の Postgres インフラストラクチャをベクトルに使用できます。
PostgreSQL などの従来のデータベースをベクトル検索に使用できますか? はい、pgvector によってこれが可能かつ実用的になっています。
-- 拡張機能の有効化
CREATE EXTENSION vector;
-- ベクトル列を持つテーブルの作成
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
content TEXT,
embedding vector(1536)
);
-- HNSW 索引の作成
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
-- 類似度検索
SELECT id, content, embedding <=> '[0.1, 0.2, ...]' AS distance
FROM documents
WHERE category = 'tech'
ORDER BY distance
LIMIT 5;
メリット:
- 既存の PostgreSQL スキル/インフラの活用
- ベクトルとの ACID トランザクション
- リレーショナルクエリとベクトル検索の組み合わせ
- 新しいデータベースの運用不要
デメリット:
- 専門 DB と比較してパフォーマンス上限がある
- PostgreSQL エコシステムに限定
- 索引構築が遅い場合がある
最適用途: すでに PostgreSQL を使用しており、新しいインフラなしでベクトルを導入したいチーム向け。
適切なベクトルストアの選択
意思決定フレームワーク
以下の質問から始めてください:
-
規模感はいかですか?
- 10 万ベクトル未満 → Chroma, pgvector, FAISS
- 10 万〜1000 万ベクトル → Qdrant, Weaviate, Pinecone
- 1000 万ベクトル超 → Milvus, Pinecone, Qdrant
-
セルフホストか管理型か?
- 管理型 → Pinecone, Zilliz (Milvus), Weaviate Cloud
- セルフホスト → Qdrant, Milvus, Chroma, Weaviate
-
ハイブリッド検索が必要ですか?
- はい → Weaviate, Elasticsearch
- いいえ → どのオプションも使用可能
-
フィルタリングの複雑さはいかですか?
- シンプル → Chroma, Pinecone
- 複雑なネストフィルタ → Qdrant, Weaviate
-
FAISS と専用ベクトルデータベースの違いは何ですか? 永続化、分散検索、本番機能が必要な場合はデータベースを選択してください。FAISS は、埋め込み研究シナリオに最適です。
一般的な RAG アーキテクチャパターン
本番システムでは、高度な RAG 変種 について検討してください。LongRAG(拡張コンテキスト用)、Self-RAG(自己反射機能付き)、GraphRAG(知識グラフを使用したより洗練された取得戦略)などです。
パターン 1: Chroma を使ったシンプルな RAG
ドキュメント → 埋め込み → Chroma → LangChain → LLM
MVP と内部ツールに最適。
パターン 2: Qdrant を使った本番 RAG
ドキュメント → 埋め込み → Qdrant (セルフホスト)
↓
FastAPI → LLM
コスト意識のある本番展開に最適。
パターン 3: Pinecone を使ったエンタープライズ RAG
ドキュメント → 埋め込み → Pinecone (管理型)
↓
アプリ → LLM
コストよりも信頼性を優先するチーム向け。
RAG パイプラインに LLM を統合する際、構造化出力技術 を使用すると、Ollama と Qwen3 を活用して言語モデルからの一貫性のあるパース可能なレスポンスを確保でき、取得した情報の抽出と処理が容易になります。
パフォーマンスベンチマーク
実際のパフォーマンスは、データセット、クエリ、ハードウェアによって異なります。一般的な観察結果は以下の通りです:
| 操作 | FAISS | Qdrant | Milvus | Pinecone | Chroma |
|---|---|---|---|---|---|
| 100 万ベクトルの挿入 | 30 秒 | 2 分 | 3 分 | 5 分 | 4 分 |
| クエリレイテンシ (P50) | 1ms | 5ms | 10ms | 30ms | 15ms |
| クエリレイテンシ (P99) | 5ms | 20ms | 40ms | 80ms | 50ms |
| メモリ/100 万ベクトル | 6GB | 8GB | 10GB | N/A | 8GB |
注: Pinecone のレイテンシにはネットワークオーバーヘッドが含まれます。他はローカルです。
マイグレーションの考慮事項
RAG プロジェクトにおいて、Chroma と Weaviate のどちらを選ぶべきですか? マイグレーションパスも考慮してください:
- Chroma → 本番環境: 埋め込みをエクスポートし、Qdrant/Pinecone に再インポート
- pgvector → 専門 DB: COPY を使用してエクスポート、変換、ロード
- FAISS → データベース: 索引を保存し、ベクトルをターゲット DB にロード
ほとんどのフレームワーク(LangChain、LlamaIndex)はベクトルストアを抽象化しており、アプリケーションレイヤーでのマイグレーションを容易にしています。
コスト比較
管理型オプション(月額、100 万ベクトル、1 日 1 万クエリ):
- Pinecone Serverless: 約$50-100
- Pinecone Standard: 約$70-150
- Weaviate Cloud: 約$25-100
- Zilliz Cloud: 約$50-200
セルフホスト(インフラコスト):
- 小型 VM (4GB RAM): 月額$20-40
- 中型 VM (16GB RAM): 月額$80-150
- Kubernetes クラスター: 月額$200+
有用なリンク
- Pinecone ドキュメント
- Chroma GitHub
- Weaviate ドキュメント
- Milvus ドキュメント
- Qdrant ドキュメント
- FAISS Wiki
- pgvector GitHub
- LangChain ベクトルストア
- LlamaIndex ベクトルストアガイド
- LLMs with Structured Output: Ollama, Qwen3 & Python or Go
- Advanced RAG: LongRAG, Self-RAG and GraphRAG Explained
- Reranking with embedding models
- Qwen3 Embedding & Reranker Models on Ollama: State-of-the-Art Performance
- Cross-Modal Embeddings: Bridging AI Modalities