この記事で分かること／分からないこと
- 分かること: ベクトル検索の速さが、どのパラメータと引き換えに決まるか(公式ドキュメントで確認できた範囲)
- 分かること: データ量と応答速度の関係について、公式ドキュメントが何と言っているか
- 分からないこと: 各サービスの具体的な応答時間(本稿はミリ秒の数値を一切書いていない。自社で測っておらず、公式の数値も条件が揃わないため転記していない)
- 分からないこと: 自社の要件でどの設定が最適か(データ分布と許容できる再現率で変わる)
編集部の自社RAG基盤は、実行時に触るのが確定配信用の索引だけで、ベクトル検索を実行時に行わない構成である(出所: /home/sol/convai-platform/docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。応答速度の考え方はRAGのレイテンシをどこで測るかで扱っており、本稿はベクトルDBを使う場合に限った整理である。ベクトルDBの応答時間について自社の実測は持っていない。
速さは再現率との交換で決まる
pgvectorのREADMEは、HNSW索引のクエリ時パラメータ ef_search(既定値40)と、IVFFlat索引の probes(既定値1)について、いずれも高くすると再現率が上がり、低くすると速くなる、というトレードオフを明記している。IVFFlatの probes については、リスト数の平方根あたりから始めるのがよい、という目安も示されている(出所: https://raw.githubusercontent.com/pgvector/pgvector/master/README.md 、確認日2026-09-06)。
つまり「速いベクトルDB」という言い方は、どの再現率での速さかを言わなければ意味を持たない。同じサービス、同じデータでも、パラメータを下げれば速くなり、その分だけ取りこぼしが増える。レイテンシ要件を決めるときは、許容できる再現率を同時に決める必要がある。
データ量は、速さより「載るか」に効く
Weaviateの資源計画のドキュメントは、メモリがサポートできるデータセットの最大サイズを決めるが、メモリはクエリ速度に直接は影響しない、と述べている。データセットのサイズと現在のクエリ負荷には相関がない、とも書かれている(出所: https://weaviate.io/developers/weaviate/concepts/resources 、確認日2026-09-06)。
これは、レイテンシ要件を考えるときに「データが増えたら遅くなる」を前提にしなくてよい、という意味ではない。索引がメモリに載っている限りは速さが保たれるが、載らなくなった時点で性質が変わる、と読むべきである。この境目は規模で何が変わるかで扱った。
絞り込みは速さを別の形で削る
メタデータで絞り込むと、速さそのものより「返ってくる件数」が先に減る。pgvectorのREADMEは、ef_search の上限に対して絞り込み条件で結果がさらに減りうること、対策として iterative index scans を有効にすると必要に応じて索引を追加で走査することを述べている(出所: 同上)。追加で走査する分、時間はかかる。
Qdrantの索引のドキュメントは、ペイロード索引が絞り込みを速くすると述べている(出所: https://qdrant.tech/documentation/concepts/indexing/ 、確認日2026-09-06)。絞り込みが多い用途では、ベクトル索引だけでなくメタデータ側の索引の有無が応答時間に効く。詳細はメタデータ絞り込みが要るかで扱った。
レイテンシ要件から選ぶときの順序
公式ドキュメントで確認できた性質を並べると、順序はこうなる。
まず、許容できる再現率を決める。これを決めずに応答時間の目標だけ置くと、パラメータを下げて目標を達成し、取りこぼしに後で気づくことになる。次に、索引がメモリに載る規模かを確認する。載るなら速さはパラメータで調整でき、載らないなら別の話になる。最後に、絞り込みの頻度を見る。絞り込みが多いなら、メタデータ側の索引を持てるか、探す範囲を先に狭める仕組みがあるかが効く。テナント単位の仕切りはマルチテナントの分け方で扱った。
本稿がミリ秒の数値を書いていないのは、自社で測っていないことと、公式が示す数値も測定条件(次元数・件数・ハードウェア・パラメータ)が揃わないと比較にならないためである。応答時間は自社のデータと設定で測るしかない。
よくある質問
Q1. どのベクトルDBが一番速いのか
問いの立て方を変える必要がある。pgvectorのREADMEが明記するように、速さは ef_search や probes といったパラメータで再現率と交換されるため、どの再現率での速さかを言わなければ比較にならない。本稿はサービス間の速度比較を行っていない。
Q2. データが増えると遅くなるのか
Weaviateの資源計画のドキュメントは、メモリがデータセットの最大サイズを決めるが、クエリ速度には直接影響しないと述べている。索引がメモリに載っている限りは速さが保たれ、載らなくなった時点で性質が変わる、と読むのが妥当である。
Q3. 絞り込みを入れると遅くなるのか
先に起きるのは「返ってくる件数が減る」症状である。pgvectorは絞り込み条件で結果が減りうるとし、iterative index scans で追加走査する対策を挙げている。追加走査の分だけ時間は増える。Qdrantはペイロード索引で絞り込みを速くする方式を取っている。
Q4. 自社の応答時間はどのくらいか
編集部の自社RAG基盤は実行時にベクトル検索を行わない構成のため、ベクトルDBの応答時間について自社の実測は持っていない。本稿でミリ秒の数値を書いていないのはそのためである。
レイテンシ要件は、再現率と一緒に決めないと後で崩れる。自社の要件でどう設定すべきか相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシをどこで測るか
- 関連記事: 規模で何が変わるか
- 関連記事: 更新頻度で変わる選択
- 関連記事: そもそもベクトルDBが要らない場合