LLM Wiki / RAG
向量数据库选型：不要只看 QPS 和价格
从检索能力、过滤、多租户、混合检索、运维、成本和生态角度选择 Milvus、Qdrant、Weaviate、Pinecone、pgvector、Elastic 等方案。
向量数据库选型很容易被简化成性能对比：谁 QPS 高、谁延迟低、谁更便宜。但在企业 RAG 里，更关键的问题通常是过滤、多租户、混合检索、增量更新、权限裁剪、备份恢复和生态集成。
选型观点
向量库不是独立存在的数据库，而是 RAG 检索链路的一部分。它必须和全文检索、权限系统、数据管道、评测平台一起考虑。
选型维度
| 维度 | 要问的问题 |
|---|---|
| 检索能力 | 支持 HNSW、IVF、PQ、量化、多向量、稀疏向量吗？ |
| 过滤能力 | metadata filter 在高基数、多条件、权限过滤下性能如何？ |
| 混合检索 | 是否原生支持 BM25 + vector，还是需要外部搜索引擎配合？ |
| 多租户 | namespace、collection、tenant 隔离怎么做？ |
| 更新删除 | 文档更新、权限变更、删除是否容易传播到索引？ |
| 运维 | 备份、扩容、监控、升级、灾备是否成熟？ |
| 成本 | 内存、磁盘、计算、托管费用、重建成本如何？ |
| 生态 | LangChain、LlamaIndex、OpenTelemetry、云服务集成是否顺畅？ |
常见方案定位
| 方案 | 适合场景 | 注意点 |
|---|---|---|
| pgvector | 小中规模、已有 PostgreSQL、权限和业务数据强绑定 | 大规模 ANN、复杂混合检索和横向扩展要谨慎。 |
| Milvus / Zilliz | 大规模向量检索、分布式部署、索引类型丰富 | 运维复杂度高于轻量方案。 |
| Qdrant | payload filter、API 友好、RAG 工程落地快 | 极大规模和复杂企业搜索需压测。 |
| Weaviate | schema、hybrid search、generative search 生态完整 | 需要评估数据模型和部署模式是否匹配。 |
| Pinecone | 托管服务、快速上线、运维负担低 | 成本、供应商锁定和数据治理要评估。 |
| Elastic / OpenSearch | 已有搜索体系、BM25、过滤、运维成熟 | 向量能力和专用向量库相比需要具体压测。 |
架构组合方式
小团队可以从 pgvector 或托管向量库开始，降低运维成本。已有搜索基础设施的团队，应优先评估 Elastic、OpenSearch 或 Azure AI Search 的混合检索能力。向量规模很大、检索延迟要求高、索引类型复杂时，再考虑专用向量数据库。
Metadata Filter 是核心能力
企业知识库几乎一定需要过滤：租户、部门、权限组、文档类型、时间范围、产品线、语言、版本。过滤条件越复杂，越不能只看裸向量查询性能。
需要压测的问题：
- 过滤是在 ANN 前、ANN 中还是 ANN 后执行？
- 高基数字段，比如 user_id、tenant_id，性能是否稳定？
- 多条件过滤和向量召回同时存在时，Recall 会不会下降？
- 权限变更后索引多久生效？
压测清单
| 测试 | 目的 |
|---|---|
| Top-K 延迟 | 看 P50/P95/P99，而不是平均值。 |
| Recall 曲线 | 不同索引参数下质量是否可接受。 |
| 过滤压测 | 多租户、ACL、时间范围组合过滤。 |
| 写入压力 | 批量导入、增量更新、删除。 |
| 重建成本 | 换 embedding 模型或 schema 后重建多久。 |
| 故障恢复 | 节点故障、备份恢复、版本升级。 |
推荐决策路径
- 数据量小、团队熟 PostgreSQL：先用 pgvector。
- 已经有 Elastic/OpenSearch：先验证混合检索方案。
- 需要快速上线且不想运维：评估 Pinecone、Zilliz Cloud 等托管方案。
- 需要可控部署和较强过滤能力：评估 Qdrant、Weaviate、Milvus。
- 多租户和权限复杂：把 filter 性能和权限更新作为第一优先级压测。
向量数据库选型没有通用最优。最好的选择是和你的数据规模、权限模型、搜索需求、运维能力和成本边界匹配。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。