ベクトルDBの選択はRAGの品質を左右する
RAG（Retrieval-Augmented Generation）パイプラインにおいて、ベクトルデータベースの選択は検索品質に直結する。同じembeddingモデル、同じLLMを使っても、ベクトルDBのインデックスアルゴリズム、フィルタリング性能、スケーリング特性の違いにより、最終的な回答品質が10-20%変動する。
KGAでは5つのベクトルDBを実際のプロジェクトに導入した経験がある。マーケティング資料の比較記事ではなく、本番環境でのリアルな評価をまとめる。
テスト条件
比較は以下の条件で統一した。データ: 100万件の日本語テキストチャンク（平均300トークン）。Embedding: OpenAI text-embedding-3-small（1536次元）。クエリ: 1,000件の検索クエリ（実ユーザーの質問から抽出）。環境: AWS東京リージョン。メトリクス: Recall@10（上位10件に正解が含まれる率）、P99レイテンシ、月額コスト。
Pinecone: マネージドの安心感
Pineconeは最も成熟したマネージドベクトルDBだ。サーバーレスプラン（2024年導入）により、従来のPodベースと比較して大幅にコストダウンした。
性能: Recall@10は94.2%。P99レイテンシは28ms。100万ベクトルの1クエリあたり平均レイテンシは12ms。メタデータフィルタリング（日付範囲、カテゴリ等）を追加してもレイテンシの増加は2-3ms程度。
コスト: サーバーレスプラン、100万ベクトル、月間500万クエリで約$70/月。Podベース（s1.x1）だと$70/月（常時起動）。サーバーレスはクエリ数に応じた従量課金なので、アクセスパターンによって最適解が変わる。
長所: 完全マネージドで運用負荷ゼロ。APIが直感的で学習コストが低い。Namespace機能でテナント分離が容易。短所: データの所在地が米国リージョン中心（東京リージョンは2025年時点で未提供）。ベンダーロックインのリスク。カスタマイズの自由度が低い。
Qdrant: 高性能オープンソース
Qdrantは Rust製のオープンソースベクトルDBで、KGAが最も多くのプロジェクトで採用しているものだ。セルフホストとQdrant Cloud（マネージド）の両方が利用可能。
性能: Recall@10は95.1%。P99レイテンシは15ms。HNSW + Product Quantization（PQ）の組み合わせで、メモリ効率と検索精度のバランスが優秀。特にスカラー量子化（Scalar Quantization）を有効にすると、メモリ使用量が75%削減されつつ、Recall低下は1%以内に抑えられる。
コスト: セルフホスト（AWS c7g.xlarge）で月額$130。Qdrant Cloud（1GBストレージ）で月額$25。
長所: 高い検索精度。Payload（メタデータ）のインデックスが強力で、複雑なフィルタリングクエリでも性能劣化が少ない。Rust製で安定性が高く、KGAの半年間の運用でダウンタイムはゼロ。gRPC APIの性能が優秀。短所: 分散クラスタリングの設定がやや複雑。ドキュメントは充実しているが、コミュニティの規模はPineconeやWeaviateに劣る。
Weaviate: マルチモーダルの強み
WeaviateはオープンソースのベクトルDBで、モジュールシステムによるマルチモーダル対応が特徴だ。テキストだけでなく、画像、音声、動画のembeddingをネイティブにサポート。
性能: Recall@10は93.8%。P99レイテンシは22ms。HNSWベースのインデックスで、100万ベクトル規模では安定した性能。ただしフィルタリングクエリでのレイテンシ増加がQdrantより大きい（+8-12ms）。
コスト: セルフホスト（AWS m7i.xlarge）で月額$160。Weaviate Cloud（Sandbox）は無料だが、本番用は問い合わせベース。
長所: GraphQLベースのクエリ言語が表現力豊か。マルチモーダル対応でテキスト+画像の統合検索が可能。Hybrid Search（ベクトル検索 + BM25キーワード検索）がビルトインで、実装コストが低い。短所: メモリ消費が大きい。100万ベクトル（1536次元）で約8GBのメモリが必要で、Qdrantの約1.5倍。Java/Go混合のアーキテクチャで、デバッグが複雑な場合がある。
Milvus: 大規模対応の本命
Milvusは中国のZilliz社が開発するオープンソースベクトルDBで、分散アーキテクチャによる大規模データ対応が強み。数十億ベクトルのスケールで運用実績がある。
性能: Recall@10は94.5%。P99レイテンシは35ms。100万ベクトルの規模ではQdrantやPineconeにレイテンシで劣るが、1,000万ベクトル以上のスケールでは分散アーキテクチャの優位性が出る。
コスト: セルフホスト（MinIO + etcd + Milvus、最小構成）でAWS月額$250。Zilliz Cloud（マネージド）は$95/月〜。
長所: GPUインデックス（IVF_PQ_GPU）でビルド・検索を高速化。分散アーキテクチャ（Proxy + Data Node + Query Node + Index Node）で、各コンポーネントを独立にスケーリング可能。数十億ベクトルの実績。短所: アーキテクチャが複雑で、セルフホストの運用負荷が高い。MinIO、etcd、Pulsarなどの依存コンポーネントが多く、障害点が増える。100万ベクトル以下の小規模用途にはオーバースペック。
Chroma: プロトタイプに最適
ChromaはPython-nativeの軽量ベクトルDBで、LangChainやLlamaIndexとの統合が簡単だ。pip install chromadbだけで開始できる。
性能: Recall@10は91.5%。P99レイテンシは45ms。ブルートフォース検索（小規模）とHNSW（大規模）の自動切り替え。100万ベクトルでも動作するが、パフォーマンスは他の専用DBに劣る。
コスト: セルフホストなら実質無料（アプリケーションと同一プロセスで動作可能）。Chroma Cloudは2025年時点でベータ。
長所: セットアップが最も簡単。Pythonの辞書感覚でベクトルを追加・検索できる。プロトタイプの速度が圧倒的に速い。embeddingの自動生成機能あり。短所: 本番環境での運用実績が少ない。分散対応が未成熟。大規模データでの性能が他に劣る。永続化の信頼性にも懸念。
KGAの推奨
プロトタイプ・小規模: Chroma（手軽さ優先）。中規模本番（〜500万ベクトル）: Qdrant（性能・安定性・コストのバランス最良）。大規模本番（1,000万ベクトル〜）: Milvus（分散スケーリング）。マネージド優先: Pinecone（運用負荷ゼロ）。マルチモーダル: Weaviate（画像+テキスト統合検索）。
KGAの標準選択はQdrantだ。性能、安定性、コストのすべてでバランスが良く、セルフホストの運用負荷も許容範囲。日本語テキストのRAG用途で最も信頼できる選択肢だと実感している。ただしプロジェクトの規模やチームのスキルセットに応じて柔軟に選択することが重要であり、一つのDBに固執する必要はない。重要なのはembeddingの品質とチャンク戦略であり、ベクトルDBはその基盤に過ぎないことを忘れてはならない。