在很多 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如果需要按租户、部门、权限、版本、时间过滤就要重点看过滤能力。第四是否需要频繁更新如果文档经常新增、修改、删除要评估增量写入和索引更新能力。第五团队是否有运维能力复杂系统能力强但也需要部署、监控、备份和故障处理。第六是否和现有技术栈匹配如果团队已经深度使用 PostgreSQLpgvector 可能是很自然的起点。如果团队需要大规模向量检索服务专门向量数据库可能更合适。第七是否方便排查问题能不能看到命中的 Chunk、相似度分数、过滤条件、索引状态。第八迁移成本是否可控未来如果更换 Embedding 模型、重建索引、迁移数据是否有清晰方案。这份清单比单纯比较工具名字更有价值。总结向量数据库是 RAG 系统里的重要基础设施。它主要解决向量存储、相似度检索、索引加速、metadata 管理和过滤等问题。但它不是 RAG 的全部。它解决不了文档质量问题解决不了不合理的 Chunk解决不了所有误召回也解决不了大模型生成阶段的幻觉。一个可用的 RAG 系统需要文档处理、Embedding、向量数据库、检索策略、Rerank、Prompt、权限控制、评测和可观测性共同配合。所以不要神化向量数据库。也不要忽视它。在小规模阶段可以用轻量方案先验证闭环。在生产阶段则要认真考虑数据规模、过滤能力、更新机制、权限隔离、成本和运维。真正成熟的 RAG不是因为接了某个向量数据库才可靠而是因为整条检索和生成链路都被认真设计过。下一篇文章可以继续讨论检索质量怎么提升。因为只靠向量检索并不总是够用很多真实问题需要关键词检索、Hybrid Search 和更完整的召回策略。