向量数据库选型专题

概览

向量数据库是 RAG 系统中负责存储和检索 Embedding 向量的基础组件。它决定了知识片段能否被快速召回，也影响权限过滤、增量更新、混合检索和运维复杂度。

企业选型时不要只问“哪个向量库性能最好”，而要先明确文档规模、更新频率、过滤条件、部署方式和团队运维能力。

官方可确认的信息

Milvus、Qdrant、Weaviate 等项目资料都把向量检索、向量索引、相似度搜索、元数据过滤作为核心能力。NVIDIA RAG 官方资料也把检索与生成视为 RAG 链路中的关键阶段。

这些信息可以确认：向量数据库不是 RAG 的全部，但它是 RAG 检索层的关键基础设施之一。

选型时先看 6 个维度

1. 数据规模

小型知识库和千万级向量库不是同一类问题。规模越大，索引构建、查询延迟、分片、备份和恢复越重要。

2. 元数据过滤

企业 RAG 通常需要按部门、用户、文档类型、权限、时间和业务线过滤。如果过滤能力弱，检索结果会产生安全和准确性问题。

3. 混合检索

很多中文企业知识库不能只依赖向量相似度。关键词检索、BM25、向量检索和重排组合，通常比单一路线更稳。

4. 更新频率

如果文档频繁更新，就要关注增量写入、删除、重建索引和版本隔离。

5. 部署形态

需要判断是本地单机、私有化集群、托管服务，还是随应用内嵌。部署形态会直接影响成本、维护和数据边界。

6. 运维能力

向量库上线后需要监控、备份、扩容、版本升级和故障恢复。没有运维能力时，不宜一开始选择过重的架构。

向量数据库是否需要 GPU

多数企业 RAG 的在线检索瓶颈不一定在 GPU。Embedding 生成、Reranker 和 LLM 生成更常使用 GPU；向量检索本身是否需要 GPU，要看索引规模、召回延迟、并发和具体产品能力。

因此，向量库选型应先按数据规模和检索需求判断，而不是默认“有 AI 就要 GPU”。

工程估算说明

以下不是官方固定规格，而是 RAG 项目选型口径：

• 先估算 chunk 数，而不是只看原始文档数量；
• 先确认权限过滤和元数据字段，再选向量库；
• 先做真实查询集评估召回率，再谈性能压测；
• 对生产系统，要验证增量更新、删除、备份恢复和索引重建时间；
• 中文知识库建议同时评估关键词检索、向量检索和 reranker。

后续可补充

• 补充 Milvus / Qdrant / Weaviate / pgvector 对比表
• 补充小型、中型、大型知识库的部署建议
• 补充中文 RAG 混合检索评估方法