上一篇介绍 Structured Output 时，我们解决了一个问题：模型生成的结果，怎样可靠地交给程序处理。 但真正开发 Agent 时，还会遇到另一个更基础的问题：
模型怎样获得自己原本并不知道的知识？
例如，企业内部有产品文档、制度、合同、项目资料和会议纪要，这些内容并不存在于通用大模型的训练数据中；即使是公开信息，也可能已经发生变化。
如果用户问： “公司目前北京地区的差旅住宿标准是多少？” 模型仅依靠自身知识，很可能不知道答案，甚至根据常见经验生成一个看起来合理但实际错误的数字。更合理的做法是：先从企业知识库中找到最新的差旅制度，再让模型基于这些资料回答。 这就是 RAG（Retrieval-Augmented Generation，检索增强生成） 。但进入 Agentic AI 之后，还需要进一步理解：
RAG 并不等于 Agent，知识库问答系统也不等于 Agent。
RAG 是 Agent 获取外部知识的一种能力，而 Agent 还需要决定什么时候检索、检索什么、是否继续检索，以及获取知识以后下一步应该做什么。
一、RAG 到底解决什么问题
大模型虽然掌握大量通用知识，但天然存在几个限制：
- 不掌握企业私有数据；
- 训练数据存在时间边界；
- 很难保证具体事实始终准确；
- 不适合把大量企业资料永久放进 Prompt。
一个最直接的办法，是把所有资料都放进上下文：System Prompt + 用户问题 + 企业制度 + 产品资料 + 历史文档。但随着资料越来越多，很快就会遇到上下文窗口、Token 成本和无关信息干扰等问题。RAG 的核心思路不是：把所有知识交给模型。 而是：
先找到与当前问题最相关的少量知识，再把它们放进本轮上下文。
因此，最基本的 RAG 流程可以表示为：
用户问题
↓
检索相关知识
↓
得到少量证据
↓
加入模型上下文
↓
LLM 基于证据生成答案
例如用户询问： “北京员工出差酒店标准是多少”？ 系统不需要把几十份公司制度全部交给模型，而只需要检索出《2026 年差旅管理办法》中与北京住宿标准相关的几个段落。这就是 RAG 最核心的价值：
让模型按需获得知识，而不是要求模型记住所有知识。
二、一个完整的 RAG，不只是“向量数据库 + 大模型”
很多入门资料会把 RAG 简化为：文档 → 向量数据库 → LLM，这种理解没有错，但对于生产系统来说还远远不够。一个比较完整的 RAG 通常包含两条链路。
真正影响 RAG 效果的，往往并不是最后一步调用哪个大模型，而是前面的知识处理和检索链路。
三、RAG 的第一步，其实是把文档处理好
假设知识库中有一份 200 页的《员工管理制度》。不能简单把整份 PDF 转成一个向量，因为用户询问某一个具体问题时，绝大多数内容都是无关的。通常需要先把文档拆成多个 Chunk：
员工管理制度
├─ 第一章 总则
├─ 第二章 考勤
│ ├─ 工作时间
│ ├─ 请假制度
│ └─ 加班管理
└─ 第三章 差旅
├─ 交通标准
├─ 酒店标准
└─ 报销流程
这里就会遇到一个典型问题：Chunk 应该切多大？ 如果切得太大，一个 Chunk 中可能同时包含大量无关内容，降低检索准确率；如果切得太碎，又可能把一句完整规则的适用条件和具体标准分开。因此，RAG 的文档切分正在从早期的：固定字符数切分；逐渐发展到：按段落、标题、语义和文档结构进行切分。 对于合同、制度、技术文档、表格等复杂文件，还要尽量保留：标题层级、表格结构、页码、章节和来源信息。 否则即使后续 Embedding 和模型能力再强，进入知识库的数据本身已经被破坏，最终效果仍然不会理想。
四、Embedding：让“意思相近”也能够被找到
Embedding 可以把文本转换成一组高维向量。例如： “员工去北京出差，住宿最多可以报销多少？” 可能被转换成：
[0.142, -0.287, 0.613, ...]
知识库中的每个 Chunk 也会生成对应向量查询时，通过计算 Query Vector 与文档向量之间的距离，就可以找到语义最相近的内容。因此，即使制度中写的是： “北京地区住宿费标准上限为……”
而用户问的是： “去北京住酒店最多能报多少？” 。两句话的字面并不完全相同，仍然可能通过语义向量被匹配到一起。这就是向量检索相对于传统关键词匹配的主要优势：
它不仅寻找相同的词，还可以寻找相近的意思。
五、为什么只有向量检索还不够
向量搜索擅长语义匹配，但对编号、产品型号、人名和精确术语并不一定最稳定。例如用户搜索：
“BM-2026-0148 合同审批记录” ，这里最重要的信息实际上是：BM-2026-0148。传统关键词搜索反而更容易准确命中。因此，生产级 RAG 越来越常见的方式是：Hybrid Search——混合检索。同时运行：
┌─ 向量检索
用户 Query ──┤
└─ 关键词 / BM25 检索
↓
结果融合
两种检索方式分别解决不同问题：向量检索：意思像不像？关键词检索：字面是不是它？ 再配合 Metadata Filter，可以进一步限制：可以进一步限制文档类型、创建时间、部门、作者、项目、权限范围等。因此现代 RAG 的检索通常已经不再只是：Vector Search；而更接近：Vector Search + Keyword Search + Metadata Filter
六、Rerank：检索之后为什么还要再排一次
第一次检索的目标通常是：尽量不要漏掉相关内容。 因此系统可能先召回 20～50 个 Chunk。但如果把几十个 Chunk 全部放入 LLM 上下文，不仅 Token 消耗高，也可能因为无关信息过多降低最终回答质量。因此通常会增加 Rerank：
Query
↓
Retriever
↓
Top 30
↓
Reranker
↓
Top 5
↓
LLM
可以简单理解为：Retriever 更关注“召回来”。Reranker 更关注“排得准”。 Rerank 会重新判断 Query 与每一个候选 Chunk 之间的相关性，然后只把最有价值的几个证据交给模型。因此，生产 RAG 的典型链路往往是：
Retrieve → Merge → Rerank → Context → Generate
而不是简单的：
Query → VectorDB → LLM
七、引用和证据，比“回答得像真的”更重要
假设用户问： “北京出差酒店标准是多少？” ，系统回答： “600 元 / 晚。” 对于普通聊天来说，这似乎已经完成了任务。但企业知识系统更应该继续告诉用户：
答案：600 元 / 晚
来源：
《2026 年差旅管理办法》
第三章第 12 条
第 8 页
因此知识库中的 Chunk 不应该只有正文内容，还应该保留：
documentId
documentName
page
section
chunkId
score
最终返回：答案 + Citation。尤其在合同、制度、法律、财务、研发规范等场景中，用户往往更关心：
这个结论到底从哪里来的？
因此，RAG 的目标不是单纯让模型“回答得更像真的”，而应该让答案拥有可以追溯的证据链。
八、多轮对话为什么需要 Query Rewrite
RAG 进入聊天和 Agent 后，还会遇到多轮对话的问题。例如第一轮用户问： “公司的差旅标准是什么？” ；第二轮继续问： “那北京呢？” 如果直接把： “那北京呢？” 拿去搜索知识库，检索系统很难知道用户究竟想查什么。因此需要 Query Rewrite，把当前问题结合历史对话改写为：
“公司当前北京地区的差旅住宿标准是什么？”
然后再进行知识检索。完整过程就变成：
Conversation History + Current Query
↓
Query Rewrite
↓
Standalone Query
↓
Retrieval
这一步的价值主要是解决：指代、省略和上下文依赖。 在实际企业问答系统中，Query Rewrite 往往会显著影响多轮 RAG 的稳定性。
九、传统 RAG 为什么会继续演进到 Agentic RAG
传统 RAG 通常是一条固定流水线：Query → Retrieve → Rerank → Generate。无论问题简单还是复杂，都执行一次检索，然后生成答案。对于简单知识问答，这种方式已经足够。但如果用户提出：
“比较 2025 年和 2026 年的销售政策变化，并分析哪些调整会影响渠道合作伙伴。”
一次检索往往很难拿到完整证据。系统可能需要分别查询：
2025 年销售政策
然后：
2026 年销售政策
接着发现渠道返点相关信息不足，还需要继续检索：
2026 年渠道返点政策
最后再将多轮结果进行综合。这时执行流程已经从：一次检索变成：分析 → 检索 → 判断 → 再检索 → 综合。 这就是 Agentic RAG 开始发挥作用的地方。
十、Agentic RAG：让 Agent 决定“怎么查”
Agentic RAG 可以把传统固定检索流程升级为动态决策过程典型执行方式是：
用户问题
↓
Agent 分析问题
↓
判断是否需要检索
↓
生成 / 改写 Query
↓
执行检索
↓
Rerank
↓
判断证据是否充分
如果证据不足：分析缺失信息 → 生成新 Query → 再次检索如果证据充分：基于证据推理 → 生成答案。
传统 RAG 与 Agentic RAG 对比
二者最重要的区别不是使用了不同的向量数据库，而是：
传统 RAG 的检索流程由程序提前决定，Agentic RAG 的检索过程可以根据任务动态调整。
十一、并不是所有问题都需要 Agentic RAG
Agentic RAG 看起来比传统 RAG 更“智能”，但并不意味着所有知识问答都应该升级。例如用户问： “公司年假是多少天？” 一次普通 RAG 检索就可以完成：Query → Retrieve → Answer。如果强行加入规划、反思、多轮检索，反而会增加：
- 调用次数；
- Token 消耗；
- 延迟；
- 不确定性。
因此更合理的架构是：
简单问题
→ Traditional RAG
复杂问题
→ Agentic RAG
例如：单一制度查询。 适合传统 RAG。而：多文档对比、跨来源验证、复杂条件组合、多跳推理， 更适合 Agentic RAG。这仍然符合本系列一直强调的原则：
能用确定性流程解决的问题，不必全部交给 Agent 自主判断。
十二、RAG 也正在从向量检索继续扩展
传统 RAG 最适合回答：
“哪个文档片段与这个问题最相关？”
但有些问题真正关注的是：实体之间的关系。 例如：
A 公司与 B 公司参与过哪些共同项目，这些项目分别由谁负责？
这类问题往往需要跨多个文档建立：公司 → 项目 → 人员 → 合同之间的关系。于是出现了 GraphRAG：
文档
↓
抽取实体 / 属性 / 关系
↓
构建知识图谱
↓
图关系检索 + 语义检索
↓
多跳推理
因此目前 RAG 已经逐渐从最初的：Chunk + Embedding + VectorDB，扩展为：
Naive RAG
↓
Hybrid RAG
↓
Rerank RAG
↓
GraphRAG
↓
Agentic RAG
这些方式并不是简单的版本替代，而是针对不同问题复杂度增加新的检索和推理能力。
十三、一个更完整的 Agentic RAG 实例
假设用户告诉一个合同分析 Agent：
“分析这批供应商合同，找出付款、违约和解除条款中与公司最新采购制度冲突的内容，并给出修改建议。”
这里已经同时使用了前几篇介绍的能力：
- Context Engineering： 负责管理本轮模型应该看到什么。
- Function Calling： 负责调用合同解析、文件读取等程序能力。
- Structured Output： 负责把风险项输出成程序可以处理的数据。
- RAG： 负责获取企业制度知识。
- Agent： 负责把这些能力组合起来完成整个任务。
这也是为什么进入 Agentic AI 后，单独理解某一个技术还不够，更重要的是理解这些能力如何在 Agent Loop 中协同。
十四、RAG、Memory 和 Tool 到底有什么区别
这是 Agent 开发中最容易混淆的几个概念。
| 能力 | 主要解决的问题 | 典型内容 |
|---|---|---|
| RAG | 去哪里找外部知识 | 文档、制度、合同、知识库 |
| Memory | 以前发生过什么 | 用户偏好、历史任务、长期信息 |
| Tool | 如何获取实时数据或执行操作 | API、数据库、搜索、文件系统 |
| Context | 本轮模型实际看到什么 | Prompt、RAG、Memory、Tool Result |
| Agent | 下一步应该做什么 | 判断、规划、选择能力 |
例如用户说：
“按照公司差旅制度，帮我规划下周去上海的行程，我还是喜欢以前住过的安静型酒店。”
系统可能这样处理：
公司差旅标准 → RAG
喜欢安静型酒店 → Memory
查询实时酒店价格 → Tool
创建预订 → Tool
是否需要检索、什么时候调用工具 → Agent
因此可以用一句话区分：
RAG 提供知识，Memory 提供历史，Tool 提供行动能力，而 Agent 决定如何使用它们。
十五、为什么“知识库问答系统”不能直接等同于 Agent
现在不少 AI 系统的流程实际上是：
上传 PDF
↓
建立向量库
↓
用户提问
↓
RAG
↓
LLM 回答
如果流程始终是预先固定的：
每次问题都必须检索，然后生成答案。
它更准确的定位仍然是：RAG Knowledge Assistant——知识库问答助手。
真正进入 Agent 之后，系统需要能够根据目标动态决定：
用户目标
↓
Agent
├─ 不需要知识 → 直接处理
├─ 需要企业知识 → RAG
├─ 需要历史信息 → Memory
├─ 需要实时数据 → Tool
├─ 证据不足 → 再次 RAG
├─ 需要业务操作 → Function Calling
└─ 完成任务 → Structured Output
因此：
RAG 是 Agent 可以使用的一种能力，而不是 Agent 本身。
这也是本篇最重要的概念边界。
十六、生产级 RAG 真正应该关注什么
真正建设企业 RAG 系统时，与“选择哪个向量数据库”相比，还有几个问题更值得关注。
1. 知识质量
如果知识库中存在：过期制度、重复文档、错误版本和相互冲突的内容，再好的检索算法，也只能更加准确地找到错误知识。因此需要建立：版本、有效期、来源和知识治理机制。
2. 权限过滤
用户只能检索自己有权限访问的文档。权限控制应该发生在：检索阶段。而不是：先把所有文档检索出来并送入 LLM，再决定哪些答案不能显示。 否则可能已经产生数据泄漏。
3. 可观测性
至少应该记录：
Original Query
Rewritten Query
Retriever
Top-K
Rerank Score
最终证据
引用来源
Token
Latency
当用户说： “这个答案不对”。 系统才能判断到底是：文档没有入库、Chunk 切错、没有召回、Rerank 排错，还是模型最终推理出了问题。
4. 无证据时不要强行回答
如果知识库没有足够证据，更合理的结果应该是：
当前知识库没有找到足够信息。
而不是要求模型利用常识补全一个答案。RAG 的目标之一，本身就是减少模型脱离证据自由生成带来的幻觉风险。
十七、本篇小结
RAG 最核心的思想其实非常简单：
不要要求模型记住所有知识，而是在需要时，把正确的知识找到并加入当前上下文。
真正需要记住的是：
RAG ≠ Knowledge Base ≠ Agent。
知识库负责保存知识；
RAG负责找到知识；
Memory负责保存历史；
Tool负责获取实时数据和执行操作；
而 Agent 才负责根据目标决定：
什么时候需要知识、应该去哪里找、要找几次，以及找到以后下一步应该做什么。
到这里，第 6～9 篇介绍的几项基础能力已经逐渐连接起来：
Context Engineering
如何给模型准备正确的上下文
Function Calling
如何让模型调用程序能力
Structured Output
如何让模型把结果可靠交给程序
RAG
如何让模型获得外部知识
上一篇回顾：
【第二部分：大模型应用开发基础】8.Structured Output——让模型输出可被程序可靠处理的数据Structu - 掘金
下一篇将真正进入 Agent 开发：
不使用框架，手写一个最小 Agent
到那时我们会把模型、上下文、Tool、RAG 和执行循环组合起来，也会看到一个重要事实：
Agent Framework 并没有创造一种神秘的新能力，它真正做的，是把这些已经存在的基础组件组织成一个可以持续运行的 Agent Runtime。
