RAG：让 Agent 学会“先查资料，再回答”

一、RAG 就是给 AI 一本可以随时翻的资料书

RAG，全名叫 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。

用一句人话讲：

RAG 就是让 AI 在回答问题之前，先去指定资料库里查相关内容，再根据查到的资料回答。

如果不加 RAG，AI 就像一个闭卷考试的学生，只能靠自己脑子里的知识回答。问题是，AI 的知识有截止时间，也不知道你公司昨天刚发布的新制度，更不知道你内部文档里的业务规则。

加了 RAG 之后，AI 就变成了开卷考试的学生：

先看题目
↓
去资料库查相关内容
↓
找到可能有用的资料
↓
筛掉不相关内容
↓
结合资料生成答案

所以，RAG 的核心不是“让模型变聪明”，而是：

让模型回答时有依据。

这也是为什么企业知识库问答、智能客服、文档助手、代码助手、法律检索系统，都会用到 RAG。

二、为什么需要 RAG：AI 不是不知道，就是容易编

想象你参加一场考试，题目是：

请说明公司昨天刚发布的报销政策有哪些变化。

如果你没有拿到最新制度，只能凭记忆回答，那你大概率会乱猜。你可能会说“差旅报销标准提高了，审批流程简化了”，听起来很像真的，但可能完全不对。

这就是 AI 常见的“幻觉”：它会生成一个语言上很流畅、逻辑上看似合理，但事实并不可靠的答案。

比如用户问：

我们公司的年假政策是什么？

没有 RAG 的 AI 可能会泛泛而谈：

一般公司会根据工龄提供 5 到 15 天年假。

加了 RAG 的 AI 应该先查内部制度文档，然后回答：

根据《员工休假制度 2026 版》，入职满 1 年不满 10 年的员工，每年享有 5 天年假；满 10 年不满 20 年的员工，每年享有 10 天年假。

前者是在“猜常识”，后者是在“查依据”。这就是 RAG 最朴素、也最重要的价值。

三、RAG 到底在做什么：四个关键动作

RAG 听起来像一个复杂技术，但拆开看，其实就是四步。

一个基础提示词可以这样写：

你是一个企业知识库助手。
 
请只根据下面提供的资料回答用户问题。
如果资料中没有答案，请明确说“当前资料中没有找到相关信息”，不要编造。
 
要求：
1. 回答要简洁清楚；
2. 重要结论要说明依据来自哪段资料；
3. 如果资料之间有冲突，请指出冲突；
4. 不要使用资料之外的知识进行补充。
 
用户问题：
{{question}}
 
检索资料：
{{retrieved_context}}
 
请输出答案：

这段提示词的核心是：限制模型的发挥空间，让它围绕资料作答。

四、用一张图看懂 RAG 的总流程

一个标准 RAG 系统通常分成两条线：离线处理和在线回答。

• 离线处理：提前整理文档、切块、入库；
• 在线回答：用户提问后，检索、筛选、生成答案。

也就是说，RAG 不是单纯“问模型一个问题”，它更像一条小型流水线。

五、嵌入、向量数据库和分块：先把资料变得可检索

很多小白第一次接触 RAG，会卡在两个词上：嵌入和向量数据库。

不用先学复杂数学，可以先用一张“含义地图”理解：意思相近的句子，在地图上离得更近。比如“如何申请年假”和“员工怎么请年休假”，词不完全一样，但含义很近。

“嵌入”做的事，就是把一段文字转换成机器能比较相似度的数字坐标；“向量数据库”做的事，就是在大量坐标里快速找到离用户问题最近的片段。

但 RAG 的效果，往往不是败在向量数据库，而是败在分块。

如果把 300 页产品手册整本塞给模型，成本高、速度慢，还很难定位答案来源。如果机械地每 500 字切一段，又可能把完整语义切碎。

比如原文是：

员工入职满一年后，可以申请年假。试用期员工原则上不享受年假，但特殊情况可由直属主管审批。

如果刚好切成：

片段 1：员工入职满一年后，可以申请年假。试用期员工原则上
片段 2：不享受年假，但特殊情况可由直属主管审批。

模型拿到任何一个片段，都会很别扭。

更实用的分块方式是：

其中最值得新手掌握的是“父子分块”：

检索时，用小块定位；
回答时，给模型看大块上下文。

例如小块是“试用期员工原则上不享受年假”，父块则包含整个“第三章 年假政策”。这样既能精准命中问题，又不会让答案丢掉上下文。

还有一种常见增强，是给片段补一句“它来自哪里”。比如：

本片段来自 Acme 公司 2026 年第三季度财报，讨论第三季度营收表现。
营收同比增长 3%，主要受新产品推动。

不要让一个片段孤零零地入库。来源、标题、版本、更新时间，都是后面回答能不能可信的基础。

六、检索方式：不要只迷信向量搜索

很多人以为 RAG 就等于向量搜索，这是一个常见误区。

向量搜索擅长找“意思相近”的内容。比如用户问“怎么取消订单”，文档写的是“订单提交后，用户可在发货前申请撤销”，虽然“取消”和“撤销”不是同一个词，但语义接近，向量搜索通常能找出来。

但它不擅长处理没有明显语义的精确匹配：

ISSUE-1247
SKU-89A72
合同编号 HT-2026-0518
员工编号 E102938

这些编号没有复杂语义，不能指望向量搜索理解它们。

生产环境更推荐混合搜索：

一句话原则：

语义问题靠向量，精确编号靠关键词，生产系统两者都要。

第一次检索通常会返回一批候选内容，比如 Top 20。但这 20 个片段里，可能只有 3 个真正有用。重排器的角色不是“从全世界找资料”，而是“在候选资料里挑最有用的”。

一个常见流程是：

先检索 Top 30
↓
重排器筛到 Top 5
↓
把 Top 5 交给大模型

七、不要塞太多资料：上下文越长不一定越好

很多新手会想：

既然不知道哪个片段有用，那我把 Top 50 都塞给模型，总会有答案吧？

这很危险。

资料塞太多，会让成本变高、响应变慢，也会让模型更容易漏看关键内容。有一个很经典的现象叫 “Lost in the Middle”，可以理解为：模型看长上下文时，开头和结尾更容易被注意到，中间内容更容易被忽略。

所以不要固定每次都塞 Top 10 或 Top 20，可以按问题类型动态决定。

例如“公司年假有几天”，通常 3 到 5 个片段就够。但如果用户问“请比较新版报销制度和旧版报销制度的差异”，就可能需要更多片段，因为它涉及多个版本、多个条款。

关键原则是：

给模型足够回答的信息，不要把资料库直接倒进去。

八、RAG 还需要吗：长上下文不是万能解法

现在很多模型的上下文窗口越来越大，能一次读很长的内容。于是有人会问：既然模型能读很长文档了，还需要 RAG 吗？

答案是：有些场景不需要，有些场景非常需要。

一句话判断：

资料少、问题简单，用长上下文；
资料多、更新快、要引用、要权限，用 RAG。

九、Agentic RAG：从“查一次”变成“边查边想”

普通 RAG 的流程通常是：

用户提问
↓
检索一次
↓
生成答案

这适合简单问题。但有些问题不是查一次就能回答的。

例如：

请比较我们产品和竞品 A 在价格、功能、适用客户、售后政策上的差异，并给出销售建议。

这个问题至少包含几个子问题：我们的价格是多少、竞品价格是多少、双方功能差异是什么、售后政策怎么比、不同客户该怎么推荐。

这时候就需要 Agentic RAG。

Agentic RAG 更像一个研究助理，会先拆问题，再分头查资料，必要时还会调用工具。

它比普通 RAG 更强，但也更贵、更慢。所以不要滥用。单点事实问题，用普通 RAG 就够；多文档综合、多版本对比、需要计算、需要判断资料新旧和冲突时，再考虑 Agentic RAG。

十、完整案例：做一个企业制度问答助手

下面用一个“企业制度问答助手”把 RAG 串起来。

目标是：

员工可以向 AI 提问公司制度问题，AI 根据内部文档回答，并给出依据。

员工可能会问：

试用期员工可以休年假吗？
出差住宿标准是多少？
发票抬头写错了怎么办？
加班调休有效期是多久？

这些问题看似简单，但答案分散在员工手册、休假制度、差旅报销制度、财务发票规范、考勤管理办法里。如果让 AI 直接回答，很容易编。

文档入库可以这样做：

收集制度文档
↓
清洗无关内容
↓
按标题和语义分块
↓
给片段补充来源信息
↓
生成嵌入向量
↓
存入向量数据库和关键词索引

片段入库时，建议保留元数据：

{
  "chunk_id": "leave-policy-003",
  "title": "试用期员工休假规定",
  "source": "员工休假制度 2026 版",
  "department": "人力资源部",
  "updated_at": "2026-03-01",
  "content": "试用期员工原则上不享受年假，特殊情况需由直属主管和人力资源部审批。"
}

用户提问后的流程：

一个理想输出应该长这样：

试用期员工原则上不可以休年假。
 
依据《员工休假制度 2026 版》，试用期员工原则上不享受年假。如果存在特殊情况，需要由直属主管和人力资源部审批。

这个答案的优点是：先给结论，不绕弯子，有制度依据，没有自由发挥，用户也知道下一步该找谁审批。

如果找不到答案，不要硬答。正确做法是：

当前资料中没有找到关于“试用期员工是否可以提前折算年假”的明确规定。建议咨询人力资源部确认。

这比编一个答案安全得多。

十一、让 RAG 真正可用的设计原则

RAG 做到能 demo 不难，做到生产可用，关键在这些地方：

上线前至少准备一批测试问题：

常见问题
边界问题
找不到答案的问题
跨文档问题
版本冲突问题
关键词编号问题

并观察：是否找到了正确片段，是否引用了正确来源，是否编造了不存在的内容，是否在资料不足时拒绝猜测，是否漏掉了更新版本。

一个实用原则是：

先治理知识库，再优化模型。

十二、和上一篇、相关模式的关系

RAG 不是孤立能力，它通常和其他 Agent 设计模式配合使用。

上一篇讲的人机协同，解决的是：AI 遇到高风险决策时，什么时候让人介入。RAG 解决的是：AI 回答问题或做判断前，如何先查到可靠资料。

例如，一个报销审核 Agent：

先用 RAG 查询公司报销制度；
再根据制度判断是否符合规则；
如果金额过高或规则不明确，再进入人工审批。

也就是说：

RAG 负责查依据；
人机协同负责管风险。

它和记忆管理也不一样。记忆保存的是用户、任务或长期交互中的信息；RAG 检索的是外部知识库。

记忆：这个用户以前说过什么。
RAG：资料库里规定了什么。

RAG 本质上也可以看成一种工具使用。Agent 不知道答案时，可以调用检索工具：

search_knowledge_base(question)

如果是 Agentic RAG，它还可能继续查数据库、查网页、调用计算器、查询业务系统。

所以，RAG 是 Agent 从“只会聊天”走向“会查资料、会用依据回答”的关键能力。

总结

在设计 RAG 系统时，可以用下面这份清单自查：

1. 文档是否清洗干净？
2. 是否保留了来源、标题、版本、更新时间？
3. 分块是否保留完整语义？
4. 是否支持向量搜索和关键词搜索？
5. 是否有元数据过滤和权限过滤？
6. 是否使用重排器筛选候选内容？
7. 是否控制传给模型的片段数量？
8. 是否要求模型只基于资料回答？
9. 是否有“资料不足”的兜底回答？
10. 是否能输出引用来源？
11. 是否处理新旧版本冲突？
12. 是否有测试集评估检索和回答效果？

这份清单的核心是：

不要只追求“能答”，而要追求“答得有依据、可追溯、可维护”。

RAG 不是让 AI 背下更多知识，而是让 AI 在回答前先查可靠资料，并把答案建立在可追溯的依据上。