第 2.1.1 节：先判断哪些问题应该交给 RAG
进入实现之前，先围绕“先判断哪些问题应该交给 RAG”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出问题应该交给 RAG 的适用场景、不适用场景、前置条件和进入工程实现的判断标准。
本章要解决什么问题
进入第 2 卷后，很多读者会自然把注意力放到 RAG（检索增强生成）上。它是 AI Agent（人工智能体）岗位、企业项目和作品集里最常见的能力之一。只要客户说“我们有很多资料，能不能做一个 AI（人工智能）知识库”，大概率就会有人想到 RAG。
但真实项目里，RAG 最容易被误解。很多新手会把它理解成“把文档扔进向量数据库，然后让模型回答”。这个理解太粗糙。向量数据库只是系统组件，不是完整 RAG 系统。文档上传成功也不等于知识库可用。模型能说出一段流畅回答，也不等于答案可信、可追溯、可验收。
本章要解决的问题是：如何给 RAG划边界，并把它放进一个真实客服 Agent 系统里。
我们的贯穿项目仍然是：企业客服知识库与工单 Agent 工作台。在这个工作台里，用户可能会问：
- “这个产品支持 7 天无理由退货吗？”
- “我的订单为什么还没发货？”
- “你们最新的质保政策是什么？”
- “帮我申请退款。”
- “我对客服处理结果不满意，帮我投诉。”
这些问题看起来都像客服问答，但它们的处理方式完全不同。有的问题可以由普通模型根据常识解释；有的问题必须检索企业最新资料；有的问题要调用订单、物流、工单等业务工具；有的问题必须转人工。
RAG 在这里解决的不是“让模型变成万能知识库”，而是解决企业问答里的 4 个核心问题：
- 企业资料依据：答案必须基于公司认可的制度、产品文档、售后政策、培训手册和 FAQ（常见问题）。
- 引用来源：回答要能说明“依据来自哪份资料、哪个版本、哪一段内容”。
- 资料更新：企业资料会变化，知识库要能重新解析、索引和生效。
- 权限边界：不同用户、部门、角色不能看到同一批资料。
这一章帮助你建立工程判断：什么时候让模型直接回答，什么时候走 RAG，什么时候调用工具，什么时候转人工。只有先把边界讲清楚，后面分块、Embedding（嵌入向量）、索引、重排序、权限和可观测性才有意义。
学习目标
学完本章后，读者应该能做到：
- 用人话解释 RAG 是什么，而不是只背“检索增强生成”这个词。
- 判断一个客服问题应该由普通模型回答、RAG、工具调用还是人工处理。
- 画出企业客服知识库 RAG 的最小系统流程图。
- 说明 RAG 为什么重点解决依据、引用、更新和权限问题。
- 设计客服知识库的资料来源、模块拆分、字段契约和状态流转。
- 说明检索、重排序、生成、引用、拒答之间的关系。
- 设计权限过滤、资料状态、问答日志和引用日志。
- 写出 RAG 项目的失败兜底方案。
- 说明哪些场景不适合使用 RAG。
- 把本章能力连接到作品集项目和面试表达。
贯穿业务场景
我们要做的系统是“企业客服知识库与工单 Agent 工作台”。它面向客服团队、售后团队、运营人员和内部管理员。
这个工作台至少有 4 类用户：
| 用户角色 | 典型需求 | 系统应该提供什么 |
|---|---|---|
| 外部客户 | 查询产品、售后、物流和投诉入口 | 可理解、可追溯、不会泄露内部资料的回答。 |
| 一线客服 | 快速查政策、查订单、生成回复建议 | 最新知识库、业务工具和工单协作。 |
| 运营管理员 | 上传资料、维护版本、查看命中情况 | 资料治理、发布流程和效果看板。 |
| 质检负责人 | 复盘错误回答和客服处理质量 | 引用记录、问答日志、拒答原因和人工接管记录。 |
在这个场景里，知识库不是一个“聊天文件夹”。它是客服系统的一部分，必须和用户身份、资料版本、权限、工单流程、日志审计连接起来。
来看几类真实问题：
| 用户问题 | 推荐处理方式 | 为什么 |
|---|---|---|
| “你们客服工作时间是几点？” | RAG 或固定配置回答 | 答案来自企业公开资料，必须跟当前政策一致。 |
| “这个产品适合新手吗？” | RAG + 模型总结 | 需要参考产品说明书和适用人群资料。 |
| “什么是 7 天无理由退货？” | 普通模型可解释概念，但企业承诺要用 RAG | 通用概念和企业政策不能混在一起。 |
| “我的订单什么时候发货？” | 工具调用 | 需要查询订单系统，不是知识库问题。 |
| “帮我申请退款。” | 工具调用 + 人工审批 | 涉及业务状态改变和资金风险。 |
| “你们公司内部投诉升级规则是什么？” | 视权限决定是否 RAG | 内部资料不能对外部客户直接开放。 |
| “资料里没写，但你觉得我能不能退？” | 拒答或转人工 | 不能让模型代替公司做承诺。 |
这张表的重点是：RAG 不是所有问题的默认答案。 它只适合回答“需要从企业资料中找依据，并基于依据生成说明”的问题。只要问题涉及实时业务数据、写入动作、资金风险、合规判断或资料外推，就必须引入工具、规则或人工。
新手为什么会卡住
新手做 RAG 项目，经常不是卡在某个模型参数，而是卡在边界不清。常见误解有 7 个。
| 误解 | 问题在哪里 | 正确理解 |
|---|---|---|
| RAG 就是向量数据库 | 向量库只负责存和查，不负责资料治理、权限、引用和拒答 | RAG 是资料进入、检索、生成、引用、日志和反馈的完整链路。 |
| 文档传上去就能答 | 文档可能过期、重复、冲突、权限不明 | 上传只是第一步，还要解析、分块、审核、发布和索引。 |
| 检索到资料就一定能回答 | 命中的片段可能不完整、不相关或互相冲突 | 需要重排序、阈值、引用规则和拒答策略。 |
| 模型可以自己判断资料是否可信 | 模型不知道企业内部版本规则 | 资料状态、版本和有效期必须由系统字段控制。 |
| 答案流畅就代表正确 | 模型可能把片段拼错、扩写过度或编造承诺 | 必须用引用、日志、验收问题集来检查。 |
| 权限可以靠 Prompt（提示词）提醒 | Prompt 不能替代后端权限 | 权限过滤必须发生在检索和生成链路中。 |
| RAG 可以替代客服 | 复杂争议、审批、投诉和资金动作需要人工 | RAG 是辅助依据，不是最终业务责任人。 |
这些误解背后有一个共同点：把 RAG 当成“模型效果问题”，而不是“企业知识工程问题”。本章会反复强调：RAG 的价值来自可控资料、可见引用、可更新索引、可审计权限，而不只是回答看起来聪明。