已经有 PostgreSQL 时，什么情况下 pgvector 足够，什么情况下应该上专用向量库？

数据量中等、需要事务/SQL、过滤简单、团队熟悉 PostgreSQL 时 pgvector 足够；数据量大、过滤复杂、需要混合检索或水平扩展时考虑专用向量库。

为什么带过滤条件的向量查询要单独压测？

过滤会改变候选集和索引使用方式，可能显著增加延迟；真实业务几乎都有租户/权限/时间过滤。

只比较 QPS 的选型测试有什么问题？

高 QPS 可能以低召回为代价；必须同时看 recall@k、nDCG、p95 延迟、索引构建和资源占用。

系统学习 AI 学习路径：从 GPU 运行时到推理、微调与 RAG 评估

vector-db-selection

向量数据库选型：按规模、过滤、混合检索、运维和成本做决定

补充说明

向量数据库没有绝对最优，只有匹配场景。选型先看五个问题：数据规模和增长、是否需要元数据过滤、是否需要 BM25+向量的混合检索、延迟/QPS 要求、团队是否愿意运维分布式系统。常见路线包括专用向量库（Qdrant、Milvus、Weaviate、Chroma）、搜索引擎（OpenSearch/Elasticsearch）、关系库扩展（pgvector）和嵌入式索引（FAISS）。

专用向量库通常在召回性能、过滤和水平扩展上更强；pgvector 胜在事务、SQL 和已有 PostgreSQL 运维体系；OpenSearch 适合已有全文检索和日志平台；Chroma 适合原型和轻量应用；FAISS 是库不是服务，需要自己封装持久化、并发和过滤。

常用示例

选型检查清单：
1. 向量数量与维度：100 万 × 1024 维 ≈ 4GB 原始向量，加索引/副本会更高
2. 过滤条件：租户、时间、权限、标签，过滤能否走索引
3. 检索模式：纯向量、BM25、混合、多向量、稀疏向量
4. 延迟目标：p95 < 50ms 还是 < 500ms
5. 写入与更新：批量导入、增量更新、删除、重建索引
6. 运维：备份、恢复、扩缩容、监控、升级
7. 多租户：逻辑隔离还是物理隔离

# 用同一批查询对比召回和延迟，而不是只看 QPS
# 记录 recall@10、nDCG@10、p50/p95 延迟、索引构建时间、磁盘/内存占用
# 分别测试：无过滤、租户过滤、时间范围过滤、混合检索

# pgvector 示例：如果已有 PostgreSQL，先用 SQL 验证需求
# CREATE EXTENSION vector;
# CREATE TABLE docs (id bigserial, tenant_id int, embedding vector(1024), content text);
# CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
# SELECT id, content FROM docs
# WHERE tenant_id = 42
# ORDER BY embedding <=> %s LIMIT 10;

易错点与排错

只 benchmark QPS：不看 recall@k 的 QPS 没有意义；先保证召回，再比吞吐和延迟。
忽略过滤性能：带租户/权限过滤的查询可能比纯向量慢一个数量级；用真实过滤条件压测。
低估索引内存：HNSW 等索引常驻内存，向量原始大小只是下限；按索引类型和副本数估算容量。
把 Chroma/FAISS 直接上生产：原型工具缺少多租户、备份、扩缩容和权限；生产要评估运维能力。
忽略更新/删除：频繁更新会导致索引膨胀或重建；确认删除语义、compaction 和重建窗口。
多租户只做逻辑过滤：过滤条件写错就可能跨租户泄漏；高风险场景用物理隔离或独立 collection。
混合检索权重未调：BM25 和向量分数尺度不同，直接相加会被某一侧支配；用 RRF 或归一化后调权重。
迁移成本被低估：不同库的过滤语法、索引参数和 API 不通用；先做 PoC，保留导出/重建方案。

参考链接

读完自测

合上页面，先回答，再展开对照。

已经有 PostgreSQL 时，什么情况下 pgvector 足够，什么情况下应该上专用向量库？
为什么带过滤条件的向量查询要单独压测？
只比较 QPS 的选型测试有什么问题？

答案

数据量中等、需要事务/SQL、过滤简单、团队熟悉 PostgreSQL 时 pgvector 足够；数据量大、过滤复杂、需要混合检索或水平扩展时考虑专用向量库。
过滤会改变候选集和索引使用方式，可能显著增加延迟；真实业务几乎都有租户/权限/时间过滤。
高 QPS 可能以低召回为代价；必须同时看 recall@k、nDCG、p95 延迟、索引构建和资源占用。