第 2.1.2 节：把资料、检索、生成和引用连成 RAG 系统
RAG 系统只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明 RAG 系统的触发、处理、复核、记录和兜底步骤。
核心概念
下面几个概念都按“四层解释法”来讲：人话解释、项目位置、工程动作、面试说法。
RAG（检索增强生成）
人话解释：RAG（检索增强生成）就是用户提问后，系统先从企业资料里找相关内容，再让模型基于这些内容回答。它不是让模型“记住所有资料”，而是让模型在回答前拿到可控依据。
项目位置：在客服工作台里，RAG 位于“用户问题”和“模型回答”之间。用户问售后政策、产品说明、服务流程时，系统先检索知识库，再把命中的资料片段、来源、版本和权限信息交给模型生成回答。
工程动作：你要设计资料来源、解析清洗、分块、Embedding（嵌入向量）、索引、检索、重排序、权限过滤、引用展示、拒答策略、反馈闭环和日志审计。
面试说法：RAG 解决的是企业私有知识的依据、引用、更新和权限问题。它不是万能问答，也不能替代工具调用和人工审批。
知识库
人话解释：知识库不是“文件堆”。它是经过整理、发布、权限控制和可检索处理的企业资料集合。
项目位置：客服工作台里的知识库包含售后政策、产品说明书、客服话术、培训手册、FAQ（常见问题）、投诉处理规则和内部升级流程。不同资料面向不同角色，不是所有资料都能给外部客户看。
工程动作：你要给每份资料定义来源、负责人、版本、生效时间、适用范围、可见角色、审核状态、更新时间和失效规则。
面试说法：我不会把知识库理解成简单上传文件，而会把它设计成可治理资料资产。只有资料状态和权限清楚，RAG 结果才可验收。
检索
人话解释：检索就是从知识库里找出最可能回答用户问题的资料片段。
项目位置：用户问“保修期怎么算”，检索模块需要从售后政策、产品说明和保修条款里找出相关片段，而不是把整本文档都塞给模型。
工程动作：你要决定检索范围、关键词检索和向量检索是否结合、召回数量、相似度阈值、过滤条件、重排序规则和无命中处理。
面试说法：检索决定模型能看到什么材料。RAG 效果差时，不一定是模型差，也可能是资料分块、元数据、召回或重排序出了问题。
生成
人话解释：生成是模型根据用户问题和检索材料组织回答。它不是自由发挥，而是基于证据写出用户能理解的话。
项目位置：客服工作台的生成模块负责把检索片段变成客服答复，例如“根据 2026 年 5 月版售后政策，你的情况需要先提交照片材料，再由售后审核”。
工程动作：你要设计回答格式、引用格式、不能回答时的拒答模板、冲突资料处理方式和是否需要转人工的判断。
面试说法：RAG 的生成阶段要受引用和拒答约束。模型不能把资料里没有的内容包装成公司承诺。
引用
人话解释：引用就是告诉用户和质检人员，答案依据来自哪份资料、哪个版本、哪一段内容。
项目位置：客服工作台里，每个知识库回答都应该能展开查看引用来源。客服可以看到更完整的内部依据，外部客户只能看到允许展示的公开依据。
工程动作：你要设计引用字段、引用展示、引用权限、引用日志和引用缺失时的拒答规则。
面试说法：企业知识库没有引用就很难验收。引用让业务方能检查答案是否依据正确，也能在资料更新后追踪历史回答。
拒答
人话解释：拒答不是系统失败，而是系统知道自己没有足够依据、没有权限或不该自动处理。
项目位置：用户问“资料里没写，你猜我能不能退款”，RAG 系统应该拒绝猜测，并提示转人工或补充资料。
工程动作：你要定义无命中、低置信度、资料冲突、权限不足、资料过期、问题超范围时的输出方式。
面试说法：可交付的 RAG 必须能拒答。不能回答时给出清楚原因，比编造一个流畅答案更专业。
权限过滤
人话解释：权限过滤是确保用户只能检索到自己有权看的资料。
项目位置：外部客户可以看到公开售后政策，但不能看到内部投诉升级规则；一线客服可以看标准话术，但不一定能看管理层质检报告。
工程动作：你要在资料入库时写入可见角色、部门、租户、资料等级和生效范围，并在检索前或检索后强制过滤。
面试说法：RAG 的权限不能靠模型自觉。权限必须由系统字段和后端规则执行，否则会出现资料泄露。
本章在客服 Agent（智能体）工作台中的位置
客服 Agent（智能体）工作台可以拆成 7 层：
读图重点：先看问题分流，再沿 RAG 链路检查权限、证据和拒答；所有路径都进入日志，反馈再推动资料修正或重新索引。
读图顺序： 用户提出问题后，先识别用户身份和角色，再进入问题分流。通用解释走普通模型回答；企业资料问题走 RAG 检索链路；订单或工单状态走工具调用链路；高风险或争议转人工或审批。RAG 检索链路依次经过按角色和资料范围过滤、检索候选片段、重排序和置信度判断，再检查是否有足够依据：有依据就生成带引用回答，无依据就拒答或转人工。所有路径最终都要记录问答日志，进入反馈和质检复盘，并推动资料修正或重新索引。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 用户入口 | 客户、客服、运营在网页或内部系统里提问 | 识别问题类型和用户身份。 |
| 问题分流层 | 判断走普通回答、RAG、工具调用还是人工 | 本章核心边界。 |
| 知识治理层 | 管理资料上传、审核、版本、权限和发布 | 本章核心。 |
| 检索生成层 | 分块、向量化、检索、重排序、生成和引用 | 本章核心。 |
| 工具调用层 | 查订单、查工单、发起审批等业务动作 | 本章只讲边界，不展开工具细节。 |
| 人工协作层 | 转人工、客服确认、审批和质检复盘 | RAG 不能处理时的兜底。 |
| 日志审计层 | 记录问答、引用、拒答、权限和反馈 | 本章核心。 |
这一章主要讲第 2、3、4、7 层。第 1.6 章已经讲过工具调用与函数接口设计，所以这里要特别分清：RAG 回答资料问题，工具调用处理业务系统查询和动作。
一个好用的客服 Agent 不会把所有问题都送进 RAG。它会先分流：
| 问题类型 | 推荐路径 | 例子 |
|---|---|---|
| 通用解释，不代表公司承诺 | 普通模型回答 | “什么是退货？” |
| 企业资料、政策、产品说明、话术 | RAG | “你们 A 产品保修多久？” |
| 用户个人订单、物流、工单状态 | 工具调用 | “我的订单到哪了？” |
| 写入动作、审批、资金、争议 | 工具调用 + 人工 | “帮我退款。” |
| 资料缺失、权限不足、法律医疗等高风险判断 | 拒答或转人工 | “你猜我这种情况能赔多少？” |
这张分流表是本章最重要的工程判断之一。面试时，如果你只说“我们用 RAG 回答客服问题”，表达会很弱；如果你能说清“哪些问题不走 RAG”，才像真正做过项目。
系统流程图
下面是客服知识库 RAG 的推荐系统流程。
这张图里有 4 个关键点：
- 分流发生在检索之前。不是所有问题都进入 RAG。
- 权限过滤必须进入检索链路。不能先把不该看的资料给模型，再指望模型不说。
- RAG 必须能拒答。无依据、低置信度、资料冲突时不能硬答。
- 日志和反馈会反过来推动资料修正。知识库不是一次性建设，而是持续运营。
模块拆分
客服知识库 RAG 可以先拆成 8 个模块。
| 模块 | 负责什么 | 主要输出 |
|---|---|---|
| 资料接入模块 | 接收文档、网页、FAQ（常见问题）、手册和运营配置 | 原始资料记录。 |
| 资料治理模块 | 管理负责人、版本、审核、发布、失效和权限 | 可用资料清单。 |
| 解析清洗模块 | 提取正文、标题、表格、段落和附件信息 | 干净文本和结构化元数据。 |
| 分块索引模块 | 把资料切成知识片段并建立检索索引 | 可检索片段。 |
| 查询理解模块 | 判断问题类型、改写查询、识别用户角色 | 检索请求。 |
| 检索重排序模块 | 召回候选片段并排序过滤 | 候选依据列表。 |
| 生成引用模块 | 生成答案、引用来源、拒答或转人工建议 | 最终回答。 |
| 日志反馈模块 | 记录检索、引用、拒答、用户反馈和质检结果 | 可复盘记录。 |
不要一开始就把所有模块做复杂。作品集项目可以先实现最小闭环：资料接入、发布状态、分块索引、检索生成、引用展示和日志记录。真正进入企业项目时，再强化权限、审核、重排序、反馈闭环和运营看板。