Agent 中的 RAG 和向量：让 AI 真正用好你的知识库

当我们第一次接触 Agent，常会遇到两个词：RAG 和向量。它们听起来像是底层工程术语，却直接决定了一个 Agent 能不能回答“公司内部问题”、能不能使用最新资料，以及回答是否可靠。

这篇文章不从复杂公式出发，而是用一条完整链路说明：向量是什么、RAG 怎么工作，以及 Agent 如何把它们组合成一个能查资料、会思考、能行动的系统。

一、为什么单靠大模型还不够？

大模型擅长理解语言和组织表达，但它有三个天然限制：

• 训练数据不一定包含你的私有资料；
• 知识存在更新延迟，无法自动知道最新制度和数据；
• 面对细节问题时，可能生成听起来合理但并不准确的内容。

例如，用户问：“今年公司的差旅报销标准是什么？”模型可能知道一般性的报销规则，却不知道你们公司今年刚发布的制度。要解决这个问题，Agent 需要在回答前先查找真实资料，这就是 RAG 的价值。

二、RAG：先检索，再生成

RAG 是 Retrieval-Augmented Generation 的缩写，中文通常译为“检索增强生成”。它的核心思想很简单：

先从知识库中找到相关内容，再让大模型依据这些内容回答问题。

一次典型的 RAG 请求大致经过以下步骤：

1. 用户提出问题；
2. 系统将问题转换为检索请求；
3. 从知识库召回若干相关片段；
4. 将片段和用户问题一起交给大模型；
5. 模型整理信息并生成最终答案。

因此，RAG 不是另一个模型，而是一套“检索 + 生成”的工作流程。它可以接入产品文档、项目资料、客服知识库、数据库，甚至实时 API。

三、向量：把“意思”变成可比较的数字

计算机无法直接比较两句话的语义，但可以比较数字。Embedding 模型会把一段文字转换成一串数字，这串数字就是向量：

1“如何申请年假”       → [0.12, -0.38, 0.74, ...]2“年假申请流程是什么” → [0.10, -0.35, 0.71, ...]

虽然两句话用词不同，但意思接近，所以它们的向量通常也更接近。系统可以使用余弦相似度等方法，找出与问题语义最相关的文本。

这里要注意：向量不是文字的“编码翻译”，也不是越长越好。它是一种用于表达语义特征的数学表示，最终效果取决于 Embedding 模型、文本切分方式和检索策略。

四、从文档到答案：一条完整链路

一个可用的知识库通常要先做“入库”，再做“查询”。

1. 入库阶段

先读取 PDF、网页、Markdown 或数据库内容，然后按标题、段落和长度切成多个文本片段。每个片段生成一个向量，并连同原文、标题、来源、更新时间等元数据一起保存。

切分不能太粗，也不能太碎。片段过大，检索结果会混入无关内容；片段过小，又可能丢失上下文。实践中通常会保留少量重叠文本，并优先按自然段和标题切分。

2. 查询阶段

用户提问后，系统先为问题生成向量，再在向量数据库中搜索相似片段。为了提高准确率，生产系统往往会加入关键词检索、分类筛选和重排序：

1问题 → 向量召回 + 关键词召回 → 过滤权限 → 重排序 → 提供给模型

最后，Agent 把这些片段放入上下文，并要求模型只依据可信资料回答；如果资料不足，则明确说明“无法从现有知识库确认”。

五、Agent 在其中扮演什么角色？

RAG 解决的是“如何找到资料”，Agent 解决的是“什么时候找、找什么、找到后做什么”。

一个成熟的 Agent 可能会先判断：

• 这是闲聊问题，直接回答即可；
• 这是知识库问题，需要检索；
• 这是实时数据问题，需要调用 API；
• 这是复杂任务，需要多轮检索、计算或执行工具。

例如，用户说“帮我比较两份产品方案，并给出推荐”，Agent 可以先分别检索两份方案，再调用计算工具整理成本，最后生成带依据的对比结论。此时，RAG 是 Agent 的知识工具，向量是其中的一种检索基础设施。

六、向量数据库应该怎么选？

向量数据库负责保存向量，并进行相似度搜索。常见选择包括 Milvus、pgvector、Pinecone、Weaviate 和 Chroma。

选型时不必只看品牌，可以从以下几个问题出发：

• 数据规模是几万条，还是上亿条？
• 是否已经使用 PostgreSQL？
• 是否需要私有化部署？
• 是否要求严格的租户隔离和权限过滤？
• 是否需要同时支持关键词和向量混合检索？

小型项目可以从 Chroma 或 pgvector 开始；已有 PostgreSQL 的团队通常会优先考虑 pgvector；更大规模或更复杂的检索场景，再评估专用向量数据库。

七、常见误区：有了向量，不代表 RAG 就可靠

误区一：把整篇文档直接存成一个向量

整篇文档往往主题太多，检索时难以精准命中。合理切分和元数据设计，通常比单纯更换数据库更重要。

误区二：只做向量搜索

型号、订单号、代码和专有名词可能需要精确匹配。向量检索与关键词检索结合，效果通常更稳定。

误区三：检索到了就一定答对

召回内容可能过时、重复或权限不符。系统需要做来源展示、时间过滤、权限校验和答案评估。

误区四：把所有问题都交给 RAG

天气、库存、订单状态等实时信息，更适合调用 API；数学计算更适合使用计算工具。Agent 应该根据问题选择合适的工具。

八、一个实用的落地方案

如果你准备为自己的 Agent 接入知识库，可以按这个顺序推进：

1. 先选一个明确场景，例如“产品文档问答”；
2. 清理文档，补充标题、版本、来源和更新时间；
3. 设计合理的切分规则并生成 Embedding；
4. 使用向量数据库完成基础召回；
5. 加入关键词检索、权限过滤和重排序；
6. 在提示词中要求模型引用来源、拒绝无依据猜测；
7. 用真实问题集评估召回率、答案准确率和响应速度。

不要一开始就追求复杂架构。先让“能找到正确片段”这件事稳定下来，再逐步加入 Agent 的规划、工具调用和多轮推理能力。

可以把三者记成一句话：

向量负责理解相似语义，RAG 负责把相关资料带给模型，Agent 负责决定何时检索、如何使用资料并完成任务。

当大模型连接上可靠的知识库和工具，它就不再只是一个会聊天的模型，而会成为能够基于事实工作的智能助手。理解 RAG 和向量，是搭建这类 Agent 的第一步，也是从“演示效果”走向“真正可用”的关键一步。