常见向量数据库有哪些，如何根据项目需求选型？

核心回答

常见方案包括 Milvus、Qdrant、Chroma 等专用向量数据库，PostgreSQL 的 pgvector 扩展，以及 Elasticsearch、OpenSearch、Redis 等系统提供的向量检索能力。FAISS 也常用于向量检索，但它主要是相似搜索与聚类算法库，不能直接等同于提供完整数据管理、权限和服务接口的数据库。

选型先看需求，再筛选候选方案：

1. 查询怎么做：只查相似向量，还是要同时满足租户、时间、文档版本等过滤条件，结合关键词与重排。
2. 数据怎样变化：向量数量、维度、增长速度、更新删除频率，以及写入后多久必须可查、旧内容多久必须不可见。
3. 质量与性能目标：在目标召回率下能否满足并发、尾部延迟、内存和费用预算。
4. 交付与运维条件：现有数据库和搜索体系能否复用，是否需要分片、高可用、备份恢复、访问控制，团队能承担多少维护工作。

已有 PostgreSQL、需要向量与业务字段一起管理时，可以先评估 pgvector；已有 ES、又重视全文搜索和向量组合时，可以先评估现有搜索系统。专用数据库则作为独立检索服务的候选。最终用相同数据和查询条件验证，而不是规定“超过多少条就必须换某个产品”。

先分清算法库、扩展与数据库服务

FAISS 主要围绕向量索引提供构建、搜索和调参能力，适合嵌入应用、离线处理或自建检索服务。它可以保存和读取索引，也有按向量 ID 限定搜索范围的机制；因此不能简单说它“没有持久化、不能过滤”。但文档与元数据如何关联、数据同步、访问控制、服务并发和故障恢复，仍要由应用或外围系统组织。

pgvector 是 PostgreSQL 扩展，把向量与普通业务字段放在同一数据体系中，能够利用 PostgreSQL 的事务、关联查询和恢复等能力。它有精确检索，也支持 HNSW、IVFFlat 等近似索引。已有 PG 时，这种方式可能减少额外服务和双写链路，但仍需验证索引、过滤、资源竞争与容量，不能只因复用方便就认定一定合适。

Elasticsearch、OpenSearch 等搜索系统的向量能力，适合放在已有全文检索、文档字段和搜索运维体系里一起评估。向量检索、关键词搜索与元数据条件的组合方式，需要结合具体产品版本和查询结构核对。

Milvus、Qdrant 等专用数据库及云托管服务，则把向量检索作为主要能力提供。是否支持项目所需的过滤、索引、更新、扩展和隔离，仍要逐项核对部署形态与版本。自建意味着承担集群、备份和升级工作；托管减少部分运维投入，同时需要评估费用、服务限制和数据迁移。

这些类别有交集，不是能力高低的固定排名。小项目也可能需要严格隔离和持续更新，大数据量的离线任务也可能适合算法库。

把业务条件带进检索测试

以企业知识库为例，查询除了语义相近，还可能要求“当前租户、有效版本、用户有权阅读”。这些条件决定了可接受的结果集合，不能等模型拿到内容后才补做权限判断。

还要区分过滤语义与底层执行方式。有的查询在近似搜索过程中限定范围，有的先取近邻候选再过滤。假设全局取回的候选大多不属于当前租户，过滤后只剩少量结果，即使授权范围内仍有相关资料，也可能没有返回足够候选。

pgvector 的近似索引就需要注意这种过滤行为；当前文档提供迭代扫描等方式继续寻找匹配结果，也可以结合过滤字段索引、部分索引或分区评估。ES 的 kNN 查询则明确区分专门的预过滤参数与其他位置的后过滤条件。两者都说明：同样写了一个过滤条件，查询结构和执行策略仍可能影响召回与延迟，不能把某种行为推给所有向量库。

若需要产品编号、错误码等精确匹配，还应测试关键词与向量的组合，而不只看纯语义检索。重新排序可以改善候选顺序，却补不回根本没有召回的证据。

更新、删除和一致性同样决定能否落地

文档更新通常涉及正文、分块、向量和元数据。应维护稳定的文档或片段标识及版本，明确新增片段怎样入库、旧片段怎样失效。业务源更新成功，不等于检索索引已经更新；接口返回成功后，还要按产品约定验证可查询状态。

选型时可以用几类具体操作检查：刚写入的文档何时能搜到，修改后是否仍出现旧内容，删除后是否还会被召回，权限变更能否及时生效，以及批量更新期间查询是否稳定。缓存也要纳入，否则索引删了，应用仍可能返回旧结果。

有些系统可以在同一数据库内管理业务字段和向量，另一些系统需要同步任务或消息管道。前者要关注同库查询与业务负载的资源竞争；后者要关注失败重试、重复写入和跨系统一致性。采用哪一种，应看项目允许的延迟、故障处理方式与维护成本。

用同条件测试比较，而不是套产品规模表

先固定 Embedding 模型、向量维度、距离度量、分块与数据快照，再为各方案选择满足目标的索引和参数。测试查询应包含正常语义问题、精确编号、严格过滤、无答案，以及更新删除后的请求。

比较时同时记录：近邻召回、业务证据覆盖、P95/P99 延迟、目标并发下的吞吐、索引构建时间、写入更新代价、内存磁盘和总费用。ANN 相对精确近邻的召回率与业务所需证据是否找到是两项指标：前者检查索引近似造成的损失，后者还受 Embedding、分块和检索策略影响。向量距离排得准，也不保证资料能回答业务问题。

容量也不只由条数决定。例如 100 万条、768 维、每维 4 字节的原始向量，约占 1,000,000 × 768 × 4 = 3.072 GB，这里使用十进制 GB。索引、元数据、原文、副本和更新中的临时空间还需另算。这只是容量计算示例，不是任何产品的内存或性能基准。

如果已有方案在质量和预算内达标，继续复用往往能减少系统复杂度；只有出现明确瓶颈，再根据测量结果决定调参、调整索引或引入专用服务。

追问：做 RAG 一定要向量数据库吗？

不一定。RAG 的关键是取得可用外部证据，可以通过关键词、SQL、已有搜索系统或外部 API 检索。需要语义近邻搜索时，也可以先用精确扫描建立质量基线；是否需要 ANN 或独立向量服务，取决于数据形态与目标负载。不能把“使用了向量数据库”当成 RAG 效果好的证明。

对应教程

参考资料