开始做 RAG 项目时，很多人第一个问题就是“用哪个向量数据库”。市场上的选择非常多，宣传口径也各不相同。实际上，对于大多数中小规模项目，向量数据库并不是决定成败的关键，选一个团队能运维好、满足过滤和权限需求的方案，比追求极致性能更重要。

向量数据库做什么

向量数据库负责存储文本、图片等内容的向量表示，并根据查询向量快速找出最相似的若干条记录。为了在海量数据中实现毫秒级检索，它们通常使用近似最近邻（ANN）索引，例如基于图结构的 HNSW 或基于聚类的 IVF 等算法，用少量精度损失换取大幅速度提升。

除了相似度检索，一个可用于生产的系统还需要支持元数据过滤、增删改、持久化、备份和权限控制。

主要方案类型

专用向量数据库

专门为向量检索设计的数据库，通常提供完善的索引类型、分布式扩展和管理工具，适合数据规模大、检索性能要求高的场景。有开源自部署和托管云服务两种形态。

传统数据库的向量扩展

在关系型数据库或文档数据库中加入向量字段和索引能力，例如 PostgreSQL 的向量扩展。最大优势是数据与业务表在一起，可以直接用 SQL 做关联查询和权限过滤，团队无需学习和运维新系统。对于百万级以内的数据量，通常完全够用。

搜索引擎

主流搜索引擎普遍支持向量检索，天然具备成熟的关键词检索能力，非常适合需要混合检索的场景。如果团队已经在使用搜索引擎，增加向量能力的成本很低。

嵌入式向量库

以库的形式集成在应用进程中，无需单独部署服务，适合原型验证、本地应用和数据量较小的场景。

选型清单

1. 数据规模与增长

几万到几十万条向量，几乎所有方案都能轻松应对；上亿条向量才需要认真考虑分布式架构和索引调优。不要为想象中的规模过早引入复杂系统。

2. 元数据过滤

企业知识库几乎都需要按部门、文档类型、时间、权限过滤。要确认方案支持高效的“先过滤再检索”或“检索时过滤”，并测试过滤条件很严格时召回率是否明显下降。

3. 混合检索

是否原生支持关键词与向量的混合检索和结果融合，还是需要自己拼接。

4. 更新频率

文档频繁更新时，要关注增删改的性能，以及索引重建对在线服务的影响。

5. 运维能力

团队是否有能力维护一个新的数据库系统？备份、监控、扩容、版本升级都需要投入。托管服务能降低运维负担，但要考虑成本和数据存放位置等合规要求。

6. 成本

向量占用的内存往往比想象中大。高维向量、大量数据、HNSW 索引都会推高内存需求。部分方案支持向量量化压缩，可以显著降低存储成本。

7. 生态集成

是否与你使用的开发框架、编程语言和云平台有良好集成。

一个务实的建议路径

  1. 原型阶段：用嵌入式库或现有数据库的向量扩展，快速验证 RAG 效果；
  2. 上线初期：如果数据量在百万级以内且已有 PostgreSQL 或搜索引擎，优先在现有系统上扩展；
  3. 规模增长后：当性能、并发或数据量确实成为瓶颈，再迁移到专用向量数据库。

需要注意，迁移的主要成本往往不在数据库本身，而在重新计算向量。更换 Embedding 模型同样需要重建全部索引，选型时要提前规划。

小结

向量数据库选型的关键不是跑分，而是匹配：数据规模、过滤需求、混合检索、运维能力和成本。对大多数团队来说，先用熟悉的工具跑通完整链路，把精力放在文档切分和检索评测上，收益远大于纠结数据库品牌。