Agent 开发常用的向量数据库：从原型验证到生产选型

开发 AI Agent 时，我们经常会遇到一个问题：模型能理解问题，却不一定掌握回答问题所需的知识。

这些知识可能藏在产品文档、业务数据库、历史对话和工具执行记录中。向量数据库的作用，就是帮助 Agent 从这些资料里找到与当前任务相关的内容。

本文介绍 Agent 开发中常见的向量数据库，以及它们各自适合的使用场景。

一、Agent 为什么需要向量数据库？

传统数据库擅长精确查询，例如根据订单号找到订单，或者筛选某个时间段的交易记录。

但用户的问题往往没有明确的查询条件。例如：

“上次那个连接超时的问题，最后是怎么解决的？”

相关记录可能写的是“数据库连接池耗尽”，并没有出现“连接超时”这几个字。仅靠关键词匹配，容易漏掉这些内容。

向量检索的基本做法，是使用 Embedding 模型将文本转换成数值向量，再根据向量之间的距离或相似度寻找相关内容。

一个典型的 Agent 知识检索流程如下：

文档 / 历史记录
      ↓
清洗与分块
      ↓
Embedding 模型
      ↓
向量数据库

用户问题
   ↓
生成查询向量
   ↓
检索相关片段，并按权限等条件过滤
   ↓
可选：使用 Reranker 重排序
   ↓
Agent 结合检索结果组织回答

在 Agent 系统中，向量数据库主要用于三类任务：

• 知识检索：查找企业文档、产品手册、代码说明等资料，为 RAG 提供上下文。
• 长期记忆召回：寻找与当前任务相关的历史对话、用户偏好和任务经验。
• 工具与案例检索：从大量工具描述、处理案例或操作流程中筛选候选项。

不过，向量数据库只是记忆系统的一个组成部分。记忆是否可信、是否过期、是否允许跨用户访问，都需要应用层明确管理。

二、选型前，先关注这几个能力

选型不能只看“检索速度快不快”。对 Agent 来说，以下能力往往更影响实际效果。

1. 元数据过滤

实际检索通常需要附加业务条件：

{
  "tenant_id": "tenant_demo",
  "document_type": "manual",
  "status": "published"
}

数据库需要在满足这些条件的数据中寻找相关内容。

尤其在多租户场景下，权限条件必须由服务端可靠注入，不能依赖模型自行生成。选择时还应关注过滤条件如何参与检索，以及过滤后的召回效果。

2. 混合检索

向量检索擅长理解语义，关键词检索擅长匹配精确信息。

例如：

• “如何恢复误删除的数据”适合语义检索。
• ERR_CONNECTION_RESET、产品型号和 API 名称通常需要精确匹配。

因此，生产系统常采用混合检索：结合向量与关键词检索，再融合或重排结果。

3. 数据更新与删除

Agent 的知识库会持续变化。除了新增数据，还需要处理文档更新、重复导入、权限调整和历史内容删除。

要关注的不只是“有没有删除接口”，还包括更新何时对查询可见、如何同步原始数据，以及备份中的数据如何处理。

4. 运维与现有架构

如果团队已经熟悉 PostgreSQL 或 Elasticsearch，复用现有系统可能比引入新数据库更合适。

选型成本应包括：

数据库费用、基础设施费用、维护成本，以及数据同步和故障排查成本。

三、常见向量数据库与适用场景

1. PostgreSQL + pgvector：让业务数据与向量一起查询

pgvector 是 PostgreSQL 的向量扩展，支持存储向量和执行相似度检索。

它的主要优势是可以把向量检索与关系查询结合起来。例如，先通过业务字段、关联关系和权限条件限定数据，再执行相似度搜索。

适合：

• 已经使用 PostgreSQL 的业务系统。
• 文档、用户、权限等数据存在较多关联关系的应用。
• 希望减少数据库种类、统一备份与运维的团队。

需要注意：

向量查询仍然需要索引设计、SQL 优化和容量规划。数据规模、过滤条件和并发负载变化后，应使用真实数据评估检索效果与延迟。

2. Qdrant：专注向量检索，适合自建检索服务

Qdrant 是专门面向向量检索的数据库，提供向量搜索、元数据过滤，以及稀疏与稠密向量相关能力。

它的检索接口比较直接，适合将知识检索作为一个独立服务接入 Agent。

适合：

• 希望自建专用向量数据库。
• 检索经常需要按租户、文档类型等字段过滤。
• 希望从单机部署逐步扩展的应用。

需要注意：

需要设计集合、载荷索引、分片和备份策略。支持过滤并不意味着任意过滤条件都能保持相同的查询性能。

3. Milvus：面向较大规模向量检索

Milvus 是开源向量数据库，提供多种向量索引和分布式部署能力，也有托管服务生态。

它适合将向量检索作为独立基础设施建设的团队，例如集中承载多个知识库或多模态检索业务。

适合：

• 数据量较大、检索负载持续增长的系统。
• 文本、图像等多模态向量检索。
• 有基础设施团队支持的组织。

需要注意：

不同部署形态的维护成本差异明显。评估时应同时考虑索引构建、数据导入、资源使用和故障恢复，不能只比较查询耗时。

4. Pinecone：减少基础设施维护的托管方案

Pinecone 是托管向量数据库服务，适合希望通过 API 快速接入检索能力的团队。

它的核心价值是减少数据库部署和维护工作，让开发者更多关注数据处理、检索流程和 Agent 本身。

适合：

• 小团队快速上线。
• 不希望维护数据库集群的项目。
• 接受云托管模式的应用。

需要注意：

应根据实际服务方案核对区域、数据驻留、限额和计费方式。成本评估需要同时考虑存储、读写请求及业务增长后的访问模式。

5. Weaviate：对象化数据与混合检索

Weaviate 是开源向量数据库，围绕数据对象、属性和向量组织检索，也提供关键词与向量结合的混合检索能力。

它还提供与向量化、生成模型相关的集成，适合希望在统一检索平台中组织知识对象的应用。

适合：

• 文档对象具有明确属性结构的知识库。
• 需要结合关键词和语义搜索的产品。
• 希望使用较完整检索集成能力的团队。

需要注意：

应提前明确数据结构、模型调用位置和多租户组织方式。集成能力能够减少开发工作，也会增加需要理解和配置的系统行为。

6. Chroma：适合原型开发与本地验证

Chroma 是 AI 应用开发中常见的数据检索工具，提供本地持久化和服务化使用方式。

它的上手成本较低，适合快速验证“文档分块、Embedding、检索、生成”这一整条流程。

适合：

• RAG 教程和概念验证。
• 本地 Agent、个人知识库。
• 需要快速迭代的实验项目。

需要注意：

原型运行顺利，不代表部署后自然满足并发、权限和高可用要求。进入生产前，应针对实际部署方式验证这些能力。

7. Elasticsearch：已有搜索系统的自然延伸

Elasticsearch 本身是搜索与分析引擎，也支持向量检索。

它的优势在于成熟的全文检索、过滤和聚合能力。对于文档搜索类 Agent，可以在现有搜索架构中加入语义检索。

适合：

• 已经使用 Elasticsearch 的团队。
• 对关键词、字段过滤和聚合要求较高的应用。
• 希望把传统搜索与语义搜索结合的知识库。

需要注意：

向量索引会增加资源消耗，需要重新评估容量。混合检索效果也依赖分词、召回策略和结果融合方式。

8. Redis：适合结合实时数据与向量搜索

Redis 的相关搜索能力支持向量检索，可与实时数据访问结合使用。

适合：

• 已有 Redis 技术栈。
• 对低延迟有明确要求的在线检索。
• 需要结合短期状态或实时数据的场景。

需要注意：

使用前应确认所选产品和部署版本包含所需搜索能力。容量规划也要考虑内存、索引结构、持久化方式和成本。

四、FAISS 算向量数据库吗？

FAISS 经常出现在向量检索选型中，但更准确地说，它是一个向量相似度搜索库。

它适合本地索引、算法实验，以及定制化检索系统。完整应用通常还需要另外实现：

• 文档和元数据存储。
• 权限过滤。
• 数据更新与版本管理。
• 服务接口、并发控制和备份恢复。

因此，比较 FAISS 与向量数据库时，需要把这些配套开发成本一起计算。

五、如何根据项目情况做选择？

下面的表格可以作为初步筛选依据：

这些只是候选方向。最终选择应通过真实业务数据测试，重点观察：

1. 召回质量：正确资料能否进入候选结果。
2. 过滤正确性：租户、权限和状态条件是否始终生效。
3. 查询延迟：关注高并发下的 P95、P99，而不仅是平均值。
4. 更新时效：新增、修改和删除何时能够反映到查询结果中。
5. 总体成本：包括资源、服务费用和维护投入。

六、数据库之外，更影响效果的几个细节

向量数据库选对了，Agent 的回答也未必准确。检索效果还依赖整条数据链路。

首先，分块方式需要保留语义上下文。如果把操作步骤、标题和限制条件切散，即使检索命中，也可能无法支持完整回答。

其次，Embedding 模型要适合业务内容。中文文档、代码、表格和专业术语的表现可能不同，应使用实际问题验证。更换模型后，通常需要重新生成文档向量。

再次，保留来源和版本信息。检索结果应携带文档地址、章节、更新时间等信息，便于 Agent 引用，也方便排查错误答案。

最后，允许检索没有答案。相似度高不等于事实可靠。当资料不足或内容相互冲突时，Agent 应明确说明依据不足，而不是强行生成结论。

对多数项目来说，可以先根据现有技术栈选出两三个候选方案，再用一组真实问题比较检索质量、延迟和成本。向量数据库负责找到候选资料，可靠的 Agent 则需要把数据处理、权限控制、检索评估和回答依据一起做好。