向量数据库到底解决什么问题？它不是 RAG 的全部

在很多 RAG 项目里，向量数据库是最容易被提前神化的部分。

很多人刚开始做知识库问答时，会先问：

用 Milvus 还是 Qdrant？
用 FAISS 够不够？
pgvector 能不能上生产？
向量数据库是不是 RAG 的核心？

这些问题都很正常。

因为 RAG 的基本流程里确实有一个关键动作：把用户问题转换成向量，然后从大量文档向量里找到相似内容。

这个动作需要存储向量、建立索引、执行相似度检索。

向量数据库就是为这类场景服务的基础设施。

但这里有一个很重要的前提：

向量数据库很重要，但它不是 RAG 的全部。

它解决的是“向量怎么存、怎么查、怎么过滤、怎么管理”的问题，不会自动解决文档切分、Embedding 选型、检索质量、Prompt 约束、答案幻觉、权限控制和效果评测。

如果把 RAG 简化成“接一个向量数据库”，系统很容易停留在 Demo。

这篇文章就围绕一个问题展开：

向量数据库在 RAG 里到底解决什么问题，又解决不了什么问题？

向量数据库在 RAG 链路里的位置

先看一个基础 RAG 流程。

文档入库阶段：

原始文档
  ↓
文档解析
  ↓
文档切分
  ↓
Embedding 向量化
  ↓
写入向量数据库

用户查询阶段：

用户问题
  ↓
问题 Embedding
  ↓
向量数据库检索
  ↓
召回相关 Chunk
  ↓
构造 Prompt
  ↓
大模型生成答案

从这个链路可以看出，向量数据库处在 Embedding 之后、Generator 之前。

它不负责解析文档，也不负责生成答案。

它的主要任务是：

• 存储文档片段的向量。
• 根据问题向量查找相似向量。
• 返回对应的文档片段和元数据。
• 支持索引构建、更新和删除。
• 在一定条件下支持 metadata 过滤。

也就是说，向量数据库是 RAG 的检索基础设施。

它不是“大脑”，也不是“知识本身”，更不是“答案生成器”。

如果前面的文档切分很差，向量数据库只能存储很差的 Chunk。

如果 Embedding 模型不适合业务，向量数据库只能基于不合适的向量做相似度搜索。

如果后面的 Prompt 没有约束模型，向量数据库召回正确内容后，模型仍然可能自由发挥。

所以它很重要，但它只是链路中的一环。

它首先解决的是向量存储

Embedding 模型会把文本转换成向量。

比如一个 Chunk 可能被转换成 768 维、1024 维或更高维度的数组。

如果知识库只有几十个 Chunk，直接放在内存里也能检索。

但真实系统里，Chunk 数量可能很快变多。

比如：

• 一份员工手册切出几百个 Chunk。
• 一套产品文档切出几千个 Chunk。
• 多个项目资料切出几万个 Chunk。
• 企业级知识库可能达到几十万、几百万个 Chunk。

这些向量需要被稳定存储起来。

向量数据库要解决的第一个问题就是：

如何存储大量高维向量，并且能在查询时快速读取和检索。

这不只是把数组写到文件里那么简单。

还要考虑：

• 向量数据如何持久化。
• 索引如何保存。
• 数据如何分区。
• 服务重启后如何恢复。
• 新文档如何增量写入。
• 旧文档如何删除或更新。
• 大规模数据下如何保证查询性能。

如果只是 Demo，这些问题可以先不复杂化。

但一旦进入真实业务，向量存储就会变成基础能力。

第二个问题：相似度检索

向量数据库最核心的能力是相似度检索。

用户问题会被 Embedding 模型转换成一个 Query 向量。

系统需要在数据库中找到和这个 Query 向量最接近的若干文档向量。

这就是常见的 TopK 检索。

比如：

用户问题：试用期员工能不能申请年假？

系统生成问题向量后，向量数据库可能返回：

Top1：员工手册 > 请假制度 > 年假规则
Top2：员工手册 > 入职管理 > 试用期说明
Top3：考勤制度 > 请假审批流程

这些结果会被作为候选上下文交给大模型。

相似度检索通常会用到一些距离或相似度计算方式，比如：

• Cosine similarity。
• Dot product。
• Euclidean distance。

不同模型、不同向量归一化方式、不同数据库实现，对相似度计算会有不同要求。

但对业务开发者来说，更重要的是理解这个事实：

向量数据库返回的是“向量上相似的内容”，不一定是“真正能回答问题的内容”。

比如用户问：

生产环境数据库备份策略是什么？

向量数据库可能召回：

• 生产环境数据库备份策略。
• 开发环境数据库初始化说明。
• 数据库权限申请流程。
• 数据库巡检记录。

这些内容在语义上都和“数据库”有关，但不一定都能回答“备份策略”。

所以向量检索只是召回候选内容，不能保证结果就是最终答案依据。

后面通常还需要 Rerank、过滤、Prompt 约束和答案验证。

第三个问题：索引加速

如果向量数量很少，系统可以直接暴力计算相似度。

比如只有 1000 个 Chunk，每次查询把 Query 向量和所有文档向量算一遍，也许还能接受。

但当向量数量达到几十万、几百万时，暴力搜索成本就会很高。

这时需要索引。

向量索引的目标是让相似度检索更快。

常见索引类型包括：

• Flat。
• IVF。
• HNSW。
• PQ。

不同索引方式在速度、召回率、内存占用、构建成本之间有不同取舍。

比如：

Flat 搜索更接近精确搜索，但数据量大时速度可能慢。

HNSW 查询速度快，召回效果通常不错，但内存占用较高。

IVF 适合较大规模数据，但参数设置会影响召回率。

PQ 可以压缩向量，降低存储和内存成本，但可能损失精度。

普通业务开发不一定需要一开始就深入这些算法细节。

但至少要知道：

向量数据库不是简单地把向量存起来，它还要通过索引结构在性能和召回质量之间做平衡。

如果索引参数不合适，可能出现：

• 查询速度慢。
• 正确结果召回不到。
• 内存占用过高。
• 构建索引时间太长。
• 新增数据后索引更新不及时。

所以进入生产环境后，向量索引不是一次配置完就结束，而是需要结合数据规模和查询效果持续调优。

第四个问题：metadata 管理和过滤

在 RAG 系统里，光有向量是不够的。

每个向量背后都应该关联一批元数据。

比如：

chunk_id
document_id
document_title
section_path
source_url
created_at
updated_at
version
department
tenant_id
permission_group

这些 metadata 非常重要。

因为真实知识库检索经常不是“从所有文档里找最相似内容”这么简单。

用户可能只能访问某个部门的文档。

某个客户只能看到自己的项目资料。

某个制度已经过期，不应该再被召回。

某类问题只应该在产品文档里检索，而不是在项目记录里检索。

这时就需要 metadata filter。

比如：

tenant_id = 当前租户
permission_group in 当前用户权限组
document_status = active
version = latest

如果没有 metadata，向量数据库只能做语义相似度检索，很难处理权限、版本、租户、时间范围这些业务边界。

很多 RAG 系统不好用，不是因为向量检索本身差，而是因为没有把 metadata 设计好。

尤其是企业场景，metadata 不是附加字段，而是系统可用性的关键。

向量数据库解决不了文档质量问题

现在说它解决不了什么。

第一个解决不了的是文档质量。

如果原始文档混乱、重复、过期、格式丢失，向量数据库不会自动修复。

比如：

• PDF 解析时表格错位。
• Word 文档标题层级丢失。
• Excel 表头和数据行脱离。
• 旧版本制度没有标记废弃。
• 多份文档内容互相冲突。
• 文档里有大量无意义页眉页脚。

这些问题如果不在文档处理阶段解决，向量数据库只会把它们一起存进去。

后面用户提问时，系统可能召回脏数据、旧数据或不完整数据。

所以 RAG 的第一层质量不是向量数据库决定的，而是知识数据本身决定的。

向量数据库可以高效检索，但不能保证被检索的内容一定正确。

向量数据库解决不了切分问题

第二个解决不了的是文档切分。

如果 Chunk 切得太碎，向量数据库会存一堆缺少上下文的片段。

如果 Chunk 切得太大，向量数据库会存一堆主题混杂的大段文本。

比如用户问：

客户现场交付期间能远程办公吗？

如果文档切分把规则拆成：

涉及客户现场交付期间。

而没有保留前一句：

以下情况不允许远程办公：

那么即使向量数据库召回了这个片段，模型也无法判断是允许还是不允许。

所以向量数据库只能检索已有 Chunk，不能替你判断 Chunk 是否合理。

Chunk 的设计仍然要在文档处理阶段解决。

向量数据库解决不了语义误召回

第三个解决不了的是所有语义误召回。

向量检索擅长找语义相似内容。

但在很多业务场景里，“相似”不等于“正确”。

比如：

合同审批流程
采购审批流程
报销审批流程
项目立项审批流程

这些内容都很相似，都可能包含“提交申请、负责人审批、财务复核、归档”等词。

向量数据库可能把它们都召回来。

但用户问的是合同审批，就不应该拿采购审批来回答。

再比如：

ERR_1024
ERR_1025
ERR_1042

这些错误码在向量语义上可能差异不大，但业务含义完全不同。

单纯向量检索可能会误召回。

这时需要：

• 关键词检索。
• 精确匹配。
• metadata 过滤。
• Hybrid Search。
• Rerank。
• 业务规则约束。

向量数据库可以提供基础检索能力，但不能完全替代检索策略设计。

向量数据库解决不了答案幻觉

第四个解决不了的是模型幻觉。

即使向量数据库召回了正确内容，大模型仍然可能在生成阶段自由发挥。

比如资料里只写：

员工年休假按入职月份折算。

模型可能补充：

试用期员工一般不能申请年假。

如果这个结论不是资料中明确写的，就可能造成错误。

所以 RAG 不是只要检索正确就万事大吉。

还需要 Prompt 约束模型：

• 只能基于检索资料回答。
• 资料不足时说明无法确定。
• 给出引用来源。
• 区分原文依据和推断内容。
• 不要补充资料外结论。

向量数据库负责把资料找出来，但不能保证模型一定按资料回答。

答案生成仍然需要单独设计。

常见工具怎么理解？

很多人选型时会看到一些常见工具，比如 FAISS、Milvus、Qdrant、pgvector。

这里不做工具排行榜，只讲大致定位。

FAISS 更像是一个高性能向量检索库。

它适合本地实验、离线检索、单机高性能搜索等场景。优点是成熟、高效，缺点是它本身不是完整数据库，很多服务化、权限、元数据管理、集群能力需要自己补。

Milvus 是专门面向向量检索的数据库系统。

它更适合较大规模向量数据和生产服务化场景，支持多种索引和分布式能力。相应地，部署和运维复杂度也会更高。

Qdrant 也是专门的向量数据库。

它对服务化、API、过滤能力和工程接入比较友好，适合需要较好 metadata filter 和应用集成体验的场景。

pgvector 是 PostgreSQL 的向量扩展。

它适合已经大量使用 PostgreSQL 的团队，把结构化数据、metadata 和向量放在同一个数据库里管理。对于中小规模 RAG 系统，它会很方便；但大规模高并发向量检索时，需要认真评估性能和索引方案。

这些工具没有绝对优劣，关键看场景。

不要为了“看起来专业”而过早引入复杂系统。

也不要在数据规模和并发已经上来后，还用临时 Demo 方案硬撑。

什么时候不需要专门的向量数据库？

不是所有 RAG 项目一开始都需要专门的向量数据库。

如果你的知识库规模很小，比如只有几百到几千个 Chunk，访问量也不高，那么用轻量方案就可以先跑起来。

比如：

• 本地 FAISS 索引。
• SQLite 加本地向量索引。
• PostgreSQL + pgvector。
• 内存检索加文件持久化。

这类方案的优势是简单、成本低、容易调试。

早期更重要的是验证：

• 文档切分是否合理。
• Embedding 是否能召回正确内容。
• Prompt 是否能约束答案。
• 用户问题是否真的适合 RAG。

如果这些基础问题都没验证清楚，直接上复杂向量数据库并不会让系统自动变好。

复杂基础设施会带来额外运维成本。

所以小规模阶段可以先轻量化。

等到数据规模、并发、权限、租户、更新频率真正上来后，再升级更完整的向量数据库方案。

什么时候需要专门的向量数据库？

当系统进入生产阶段，专门的向量数据库价值会更明显。

常见信号包括：

• Chunk 数量达到几十万或更多。
• 查询并发明显增加。
• 需要稳定低延迟检索。
• 文档持续增量更新。
• 需要复杂 metadata filter。
• 需要多租户隔离。
• 需要权限过滤。
• 需要删除和重建索引。
• 需要监控、备份和运维能力。

这时，一个成熟的向量数据库可以减少很多自研成本。

尤其是企业级 RAG，向量数据库不只是检索组件，还会承载很多数据管理职责。

比如：

• 一个租户的数据不能召回到另一个租户。
• 一个部门的私有文档不能被其他部门用户检索。
• 旧版本文档要下线。
• 删除文档后对应向量也要删除。
• 更新文档后要重新生成向量。
• 查询日志需要能回溯。

这些问题都比 Demo 里的“TopK 查相似文本”复杂得多。

企业场景要特别关注什么？

企业级 RAG 里，向量数据库选型不能只看查询速度。

还要关注几个实际问题。

第一，权限过滤。

检索阶段必须考虑用户权限。否则模型可能看到用户本不该看到的资料。

第二，多租户隔离。

不同客户、部门、项目的数据是否物理隔离或逻辑隔离，需要提前设计。

第三，版本管理。

同一份文档多个版本并存时，默认应该检索最新版本，旧版本要有明确状态。

第四，删除机制。

文档删除后，向量、metadata、缓存、引用关系都要同步处理。

第五，增量更新。

知识库不是一次性构建，后续会不断新增、修改和下线文档。

第六，可观测性。

每次检索返回了哪些 Chunk、分数是多少、过滤条件是什么，都应该能记录。

第七，成本。

向量维度、索引类型、数据规模、查询并发都会影响存储和计算成本。

这些能力决定了向量数据库能不能支撑长期运行，而不只是能不能跑通 Demo。

一个实用的选型检查清单

实际选型时，可以用下面这份清单。

第一，数据规模有多大？

几千个 Chunk、几十万个 Chunk、几百万个 Chunk，对方案要求完全不同。

第二，查询并发有多高？

内部低频使用和面向用户的高并发服务，不是同一类问题。

第三，是否需要 metadata filter？

如果需要按租户、部门、权限、版本、时间过滤，就要重点看过滤能力。

第四，是否需要频繁更新？

如果文档经常新增、修改、删除，要评估增量写入和索引更新能力。

第五，团队是否有运维能力？

复杂系统能力强，但也需要部署、监控、备份和故障处理。

第六，是否和现有技术栈匹配？

如果团队已经深度使用 PostgreSQL，pgvector 可能是很自然的起点。

如果团队需要大规模向量检索服务，专门向量数据库可能更合适。

第七，是否方便排查问题？

能不能看到命中的 Chunk、相似度分数、过滤条件、索引状态。

第八，迁移成本是否可控？

未来如果更换 Embedding 模型、重建索引、迁移数据，是否有清晰方案。

这份清单比单纯比较工具名字更有价值。

总结

向量数据库是 RAG 系统里的重要基础设施。

它主要解决向量存储、相似度检索、索引加速、metadata 管理和过滤等问题。

但它不是 RAG 的全部。

它解决不了文档质量问题，解决不了不合理的 Chunk，解决不了所有误召回，也解决不了大模型生成阶段的幻觉。

一个可用的 RAG 系统，需要文档处理、Embedding、向量数据库、检索策略、Rerank、Prompt、权限控制、评测和可观测性共同配合。

所以不要神化向量数据库。

也不要忽视它。

在小规模阶段，可以用轻量方案先验证闭环。

在生产阶段，则要认真考虑数据规模、过滤能力、更新机制、权限隔离、成本和运维。

真正成熟的 RAG，不是因为接了某个向量数据库才可靠，而是因为整条检索和生成链路都被认真设计过。

下一篇文章，可以继续讨论检索质量怎么提升。

因为只靠向量检索并不总是够用，很多真实问题需要关键词检索、Hybrid Search 和更完整的召回策略。