向量数据库是什么？为什么 RAG 和 Agent 都需要它

为什么需要向量数据库

你在做 RAG（检索增强生成）的时候，需要从一堆文档里找到和用户问题"最相关"的几段内容。这个"最相关"不是关键词匹配——用户问"怎么报销差旅费"，文档里写的是"出差费用报销流程"，关键词对不上，但语义上是相关的。

传统数据库做不了这种"按语义相似度查找"的事情。你需要先把文本转成向量（一组数字，代表文本的语义），然后在这个向量空间里找距离最近的。向量数据库就是专门干这个的。

和传统数据库的核心区别

简单说：传统数据库回答"是不是"，向量数据库回答"像不像"。

向量数据库在 RAG 中的角色

整个 RAG 流程里，向量数据库是存储和检索环节：

• 写入：把文档切成小段，每段通过 Embedding 模型转成向量，存进向量数据库
• 查询：用户提问时，把问题也转成向量，在数据库里找最相似的几个段落
• 返回：把找到的段落交给大模型，模型基于这些内容生成回答

想了解更多 RAG 的细节，可以看 RAG 是什么。

主流产品怎么选

我的建议：如果你是第一次接触，从 Chroma 开始。它是一个 Python 库，不需要单独安装服务，pip install chromadb 就能用。等你跑通了流程、确认需要生产级方案，再考虑 Milvus 或 Pinecone。

什么时候不需要向量数据库

这是很多人忽略的问题。不是所有 RAG 场景都需要向量数据库：

• 文档量很小（几十篇以内）：直接把所有文档塞进 prompt 的上下文窗口就行，检索反而多余
• 查询是精确匹配：按日期、按 ID、按状态查数据，用传统数据库
• 已经有搜索引擎：如果你的文档在 Elasticsearch 里，用它的语义搜索功能也行，不一定非要换向量数据库

从业者提醒

向量数据库不是 RAG 的全部。很多人觉得"用了向量数据库就等于做了 RAG"，实际上 Embedding 模型的选择、文档切分策略、检索结果的质量，每一个环节都影响最终效果。向量数据库只是其中一环。 冷启动问题。向量数据库里的数据需要预先写入。如果你的知识库经常变化，要有一个可靠的数据更新管道，不然检索到的可能是过时的内容。 混合检索经常更好。纯向量检索有时候会漏掉关键词精确匹配能命中的结果。很多生产系统用"向量检索 + 关键词检索"混合方案，效果比单一方式好。 监控很重要。上线后要关注检索质量——用户问的问题有没有命中正确的文档段落。如果检索质量不行，模型再好也生成不出好答案。

下一步

• 想了解文本怎么转成向量？看 Embedding 是什么
• 想了解 RAG 的完整流程？看 RAG 是什么
• 想动手试？从 Dify 教程 开始，它内置了向量数据库配置