RAG 全流程

一句话理解：RAG（检索增强生成）就是先从企业知识里找出与问题相关的片段，放进上下文，再让模型基于这些片段回答；它分为离线“建索引”和在线“查与答”两条流水线。

模型不知道你们公司的退款政策，不知道上个月刚更新的换货标准，也不知道企业版和个人版的发票流程有什么差别。让 Agent 用上企业自己的知识，最常见的做法就是 RAG。

很多团队的 RAG 项目会经历同一条曲线：Demo 阶段效果惊艳，上线后用户开始反馈“答非所问”“引用了过期规则”“明明文档里有却说找不到”。团队的第一反应通常是换一个更强的模型，但问题往往出在检索链路的某一环。这一课先把整条流水线画清楚，后面几课再逐环深入。

两条流水线

下面这张全景图把离线与在线两条流水线，以及贯穿其中的支撑能力画在一起：

每一环都会影响最终答案，也都可能成为故障点。下表列出每一环的职责、常见问题，以及在本模块哪一课深入：

环节	做什么	常见问题	详见
解析	从 PDF、Word、网页中提取文字与表格	表格被拆成乱序文字；扫描件提取不到文字	本课
切块	把长文档切成适合检索的片段	条款被从中间切断；片段丢失“这是哪份文档”的背景	切块与元数据
元数据	给片段标注来源、版本、权限、生效日期	没有版本信息，新旧规则一起被召回	切块与元数据
向量化	把文本转成表示语义的向量	对订单号、错误码等精确字符串不敏感	Embedding 与语义搜索
检索	找出与问题最相关的候选片段	只用向量检索，漏掉关键词精确匹配的结果	混合检索与重排序
重排序	对候选片段精细打分，只保留最相关的几段	不做重排，把 20 个半相关片段全塞进去	混合检索与重排序
组装上下文	决定片段的顺序、格式与标注	片段没有来源标签，模型无法引用	上下文五问
生成与引用	基于片段回答并标注出处	片段里没有答案时仍然编造	引用与可追溯
保鲜与权限	文档更新后同步索引；只检索用户有权看的内容	删除的文档仍被召回；越权看到其他区域的客户合同价	知识保鲜与权限

解析 这一环值得单独强调，因为它最容易被低估。企业文档里大量关键信息在表格中：价格表、时效表、退款标准。如果解析工具把一张“版本 × 席位数 × 价格”的表格拆成一串没有结构的数字，后面的检索和生成再好也救不回来。上线前一定要抽查解析结果，尤其是表格、多栏排版和扫描件。

一个完整的例子

用户（华东区售后客服）问：“订单已经开了发票，还能退款吗？”

1. 理解与改写：
   原问题 → “已开具发票 订单 退款 处理方式”
   附加过滤：业务线=售后；区域 ∈ {全国, 华东}；状态=生效中；用户权限=华东客服

2. 检索：
   关键词检索命中 “发票 作废” 的 12 个片段
   向量检索命中语义相近的 20 个片段
   合并去重后得到 26 个候选

3. 重排序：
   精排后保留 3 段：
   ①《退款政策》v3 第 4.2 条（生效中）
   ②《发票管理规范》第 7 条
   ③ FAQ：“开票之后还能不能退款”

4. 组装上下文：按相关度排列，每段带上文档名、条款号、版本、生效日期

5. 生成：
   “已开具发票的订单，需要先完成发票作废，再发起退款【退款政策 v3 §4.2】；
    发票已交付给客户的，须由客户确认作废后才能重新开具【发票管理规范 §7】。”

6. 校验：程序检查每条引用都能在对应片段中找到原文

注意第 1 步的过滤条件：“生效中”和“用户权限”不是让模型判断的，而是在检索时由程序直接过滤。 这比检索完再让模型“注意不要用过期规则”可靠得多。

什么时候不该用 RAG

RAG 不是让 Agent 获取信息的唯一方式。以下三种情况，要先考虑别的方案。

1. 数据是结构化的、实时的业务数据。 “订单 ORD-1024 现在是什么状态”“这个月华东区有多少笔退款失败”，答案在业务系统的数据库里，应该通过工具调用 API 或受控查询获取，而不是把订单数据导出成文本再做向量检索。RAG 适合 非结构化的、相对稳定的知识：规则、制度、手册、FAQ、历史案例。数据该用工具还是知识库，参见 LLM 与确定性程序的分工。

2. 知识总量很小。 如果全部相关文档加起来只有几万 Token，直接放进上下文（配合提示缓存）可能比搭建检索系统更简单、更准确。Anthropic 在 2024 年介绍 Contextual Retrieval 的文章中就给过类似建议：知识库小于约 20 万 Token 时，可以考虑直接整体放入提示。不过也要记住上下文腐化的问题，文档越多，这种做法越需要用评测验证。

3. 问题需要多步探索。 “对比近三个月三次退款政策修订的差异，并判断哪些历史订单受影响”，一次检索很难拿全信息。这类问题更适合让 Agent 把检索当作工具反复使用，参见 Agentic RAG 与联网搜索。

“答不准”时先定位是哪一环

RAG 最重要的排查习惯，是把问题拆成 检索问题 还是 生成问题：

这个拆分决定了修复方向，也是 RAG 效果评估 一课中指标设计的基础。

常见误区

• “RAG 效果不好就换更强的模型。” 如果正确片段根本没被检索到，任何模型都答不对。先看检索结果。
• “把所有数据都放进向量库。” 实时业务数据应该通过工具查询。向量库里的订单状态一定是过期的。
• “文档导进去就完事了。” 解析质量、切块方式、元数据、更新机制，决定了知识库上线三个月之后是否还可用。

产品经理检查清单

• 用户的问题中，哪些依赖非结构化知识（适合 RAG），哪些依赖实时业务数据（适合工具）？
• 知识源有哪些？总量多大？谁负责维护？多久更新一次？
• 表格、扫描件、图片中的信息是否能被正确解析？抽查过吗？
• 版本、生效状态、区域、权限，是在检索时由程序过滤，还是指望模型判断？
• 检索不到依据时，Agent 的预期行为是什么？
• 出现“答不准”时，能否在日志中看到检索到的具体片段？

练习

用 20 份 PDF 搭建公司知识库 Agent（贯穿项目 02）之前，先完成一份设计草图：

1. 列出这 20 份文档的类型（制度、手册、FAQ、表格为主的文档……），标注哪些含有关键表格。
2. 按本课的两条流水线，为每一环写一句你的方案（例如“切块：按标题层级切，表格整体保留”）。
3. 写出 5 个用户可能问的问题，判断每个问题应该走 RAG、工具查询还是两者结合。
4. 挑一份含表格的 PDF，用任意解析工具提取文字，检查表格是否还能读懂。

延伸阅读

• Anthropic：Introducing Contextual Retrieval
• Claude 文档：Embeddings

下一步

下一课「Embedding 与语义搜索（直觉版）」会解释流水线中最“神奇”的一环：为什么意思相近但字面不同的文本能被找到，以及它在哪些地方会失灵。