选型看什么
向量库选型对比集中在四组维度：部署形态（嵌入库、单机服务还是分布式）、过滤与多租户能力、量化与内存策略、以及生态与运维成本。没有通用最优解——已有 PostgreSQL 的团队用扩展最省事，规模上亿则更看重分布式与磁盘索引，小规模离线任务用进程内库就够。
定位对照
| 系统 | 形态 | 突出能力 |
|---|---|---|
| FAISS | 进程内库 | 算法全面、GPU 加速 |
| pgvector | PostgreSQL 扩展 | 与 SQL 与事务同库，运维成熟 |
| Qdrant | 独立服务 | 过滤与量化丰富，部署简单 |
| Milvus | 分布式服务 | 规模上限高，组件齐全 |
| Chroma | 嵌入式或服务 | 上手快，原型友好 |
选型决策清单
选型决策清单
1. 现有数据栈已有 PostgreSQL？→ 先评估 pgvector
2. 单机内存装不下全部向量？→ 量化方案或分布式库
3. 强过滤/多租户刚需？→ 看过滤索引与隔离机制
4. 离线批处理为主？→ 库形态（FAISS）即可，无需服务化评估维度细化
- 过滤能力：是否支持向量与标量条件联合检索，过滤集很小时性能如何
- 写入与更新：单条与批量写入的吞吐，删除是否触发代价高昂的整理
- 一致性：写入后能否立刻查到，是否需要等待段加载
- 备份与迁移：向量与元数据能否整体导出，避免被单一实现锁定
- 运维依赖：是否引入额外组件，团队能否独立排障
落地注意事项
- 选型前先用真实数据做验证性测试，同一评测集上对比召回与高分位延迟
- 把过滤模式带进测试：只在无过滤条件下比性能会严重高估表现
- 预估三年的数据增长，避免半年后被迫迁移
- 确认权限模型：能否在检索语句里强制拼接租户条件
- 把向量库与业务库的关系想清楚，需要联表时同库扩展更省事
常见组合
| 场景 | 常见选择 | 理由 |
|---|---|---|
| 已有 PostgreSQL 的中小规模问答 | pgvector | 少一个组件，事务一致 |
| 独立知识库服务，千万级向量 | Milvus 或 Qdrant | 过滤与规模化能力更完整 |
| 线下批处理与实验 | FAISS | 无服务依赖，部署成本低 |
| 快速原型 | Chroma | 接口简洁，改造成本低 |
选型前先用真实数据做验证：同一评测集在候选系统上跑召回与高分位延迟，比看宣传页的峰值数据可靠得多。