第4章 — 適切なベクトルデータベースの選定
LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第4回です。RAGシステムでもっとも速く育ち、規模では最大のコストを背負い、もっとも強くチームを縛る部分 — 技術的に選ばれ、運用的に決められる。
この章がなぜあるのか
ベクトルデータベースは検索システムの保存層で、その選択は多軸の判断です — 性能、データレジデンシー、チームの運用形態、システムの寿命全体での総コスト。誤った選択は数年単位で縛ります。10億の埋め込みを別システムに引っ越すのは、どのチームも軽くは引き受けません。技術比較は有用ですが、選択はたいてい比較では見えない3軸で決まります — データを置いていい場所、チームが運用できるもの、寿命全体のコスト。
4.1 アーキテクチャ — 専用設計か、拡張か
最初の判断は、しばしば名付けられないままに行われます — ベクトルワークロード向けに専用設計された新システムを導入するか、すでに運用しているシステムを拡張するか。専用設計 のDB — Pinecone、Qdrant、Milvus、Weaviate、Vespa — はインデックスを核に外向きに設計されています。クエリプランナ、ストレージ配置、レプリケーション、API、すべて高次元ベクトル上の近似最近傍クエリのために組まれている。性能の天井は高く、特にフィルタ+ベクトルのハイブリッドクエリで効きます。代わりに、運用する別システムが1つ増えます。
拡張 型 — pgvector、Elasticsearch dense_vector、MongoDB Atlas Vector Search、Redis with RediSearch — はチームがすでに動かしているDBにベクトル検索を加えます。新しい認証、バックアップ手順、オンコール、パッチサイクルは要りません。性能の天井はホスト側のアーキテクチャで決まり、たいていは数千万ベクトル帯までのアプリケーションが必要とするラインを十分超えます。決定は純粋な性能問題ではほとんどなく、運用予算をどこに使うかの問題に近い — Postgresを1つ動かしているチームは2つ目を動かしたくありませんし、10のデータサービスを動かしているチームは11個目に抵抗を覚えません。
4.2 マネージドの主役 — Pinecone と Vertex
Pinecone はマネージドなベクトルDBの代表格です。運用のシンプルさ、安定したレイテンシ、成熟したSDK、ストレージと計算を分離し実使用に応じて課金するサーバーレス層を備えます。新規展開の既定値として安全で、ワークロードが予約容量で得をする場合だけ別の選択を考えればよい。代価は、プロプライエタリなマネージドが背負うアーキテクチャ的なロックインです — 埋め込み自体は原理上ポータブルですが、エクスポートして再インデックスするコストは無視できません。Vertex AI Vector Search は Google の選択肢で、Google 自身の大規模類似検索を支える ScaNN ライブラリの上に立っています。スケール上限が高く、GCP の他要素(埋め込みモデル、IAM、Cloud Monitoring)との統合が強く、その代わり単一クラウドへの戦略的なコミットを要求します。Azure AI Search は Microsoft 環境でこのポジションを占めます。プラットフォーム純正の3者の選択は、たいてい既存のクラウドコミットメントに従うのが合理で、スケールとレジデンシーの確認が済んでいれば妥当です。
4.3 オープンソース — Qdrant、Milvus、Weaviate
OSS の枠は、自分でインフラを制御したいチーム — コスト、レジデンシー、戦略 — で、分散システムを運用する力があるところ向けです。Qdrant はもっとも小さく集中型: Rust 製、単一バイナリで動き、低レイテンシのベクトル検索を、強いフィルタリングと量子化のサポートとともに提供します。数分で動かせる手触りで、運用フットプリントを最小にしたいときの選択肢。Milvus は最大でエンタープライズ寄り — クラウドネイティブな構成で計算・ストレージ・メタデータが分離し、この枠でいちばん高いスケール上限(数十億ベクトル、GPU加速、階層ストレージ)を持つ。運用の複雑さも相応で、Zilliz Cloud がそれを和らげます。Weaviate はこの2者の中間で、Qdrant より機能が多く、Milvus より複雑でない。埋め込み、再ランキング、マルチテナンシーの組み込みモジュールがあり、検索インデックスというより検索プラットフォームです。3者とも中核は Apache ライセンスで、有料のマネージドが上に乗っています。ベンチマークは互いに小さな定数倍の中に収まり、決定は「適合」であって生の性能ではありません。
4.4 組み込みと Postgres — Chroma と pgvector
本物の RAG 展開のほとんどは、毎秒数十クエリを、数十万のベクトルに対して処理しています — 毎秒百万を数十億に対して、ではありません。このワークロードに正しい道具は、アプリケーションプロセスの中か、その隣で動きます。Chroma は組み込みの選択肢 — 既定でインプロセス、ローカルディスクに永続化、最小ケースでは設定不要。プロトタイプ、自分のデータと一緒に出荷するツール、1台に収まる本番展開に向きます。pgvector は Postgres にベクトル型、距離演算子、HNSW/IVFFlat インデックスを加えます。十分プロビジョニングされたホスト上で約1,000万ベクトルまでのコーパスなら、pgvector は信頼できる本番選択で、すでに Postgres を運用しているチームには運用上もっとも簡単です。ベクトル検索は、既存の ORM が理解するテーブル上の SQL クエリになり、構造化メタデータとのジョインは第一級です。これらの選択肢の隠れた美徳は、考えを変えるコストを下げてくれること — 分散システムへの移行は、もし起きるとしても、境界が見えています。
4.5 レジデンシー、運用、コスト — 実際に決める3軸
運用上の3軸は名付ける価値があります。本番の判断は実際にここで決まるからです。データレジデンシー は、どんな技術比較よりも前に候補リストを絞ります。EU の個人データ保護、金融業の規制、ソブリンクラウドへのコミット — これらは交渉できません。どのベンダーに対してもまず訊くべき問いは、どのリージョンをサポートし、データ取り扱いについてどんな契約上の約束があるか、です。一つ注意点: 埋め込みは派生データですが、ほとんどの規制枠組みでは引き続き個人データとされます。反転や類似検索で元を取り戻せるからです。原文書はカバーしているが埋め込みについては曖昧、という契約は不十分です。
運用形態 はチーム側の容量です。エンジニア3人で1アプリ運用しているチームは、運用面積をいちばん増やさない選択肢を選ぶべきです — pgvector、マネージドの Pinecone か Qdrant Cloud、組み込みの Chroma。30人のチームなら、コストと機能のために OSS 分散システムの複雑さを吸収できます。間違いは、実際の運用容量とミスマッチなシステムを選ぶことです。総コスト はシステムの寿命全体での — プロビジョニング、監視、バックアップ、リストア訓練、容量計画、アップグレード作業、オンコール時間の按分 — を含みます。誠実な構図は、3つのシナリオ — 現在、10倍、100倍 — でのコストを訊ねること。始点と同じくらい、傾きが重要です。
第4章を踏まえて
ベクトルDBは、保存層が何を保てるか、どれだけ速くクエリできるか、どのフィルタ・メタデータパターンが使えるかを決めます。これらの性質だけで検索品質が決まるわけではありません — その上に何を組めるかが決まる。組まれるのは検索パイプラインで、ここで利得が積み重なります — 密ベクトル + BM25 のハイブリッド、異種検索器をまたぐ Reciprocal Rank Fusion、クロスエンコーダによる再ランキング、そしてユーザーの問い方と文書の答え方を橋渡しするクエリ理解。
次回 — 第5章: 検索パイプラインの設計。 密ベクトル検索とキーワード検索が Reciprocal Rank Fusion で結合する仕組み、残りの品質ギャップの大半を埋めるクロスエンコーダ再ランキングの工程、そして残りを担うクエリ理解の層。
