哪些问题该走 RAG，哪些该直接查工具或规则表？
简化版
按数据的性质分：RAG 适合相对静态的描述性知识，比如商品参数说明、FAQ、使用指南、制度条款，这类内容是非结构化文本，用户问法多样，需要语义检索加模型组织语言。实时且不能错的数据，比如价格、库存、订单状态、账户余额，必须由工具查真实来源，不能进知识库，更不能让模型凭记忆回答。规则明确、条目有限的内容，比如售后政策条款，可以直接查规则表匹配。而且确定性数据查到之后，不一定要再过一遍大模型：让模型「润色」只会增加编造风险和成本。最后还要想清楚分流由谁决定：调用方指定、规则判断，还是意图识别。
详细版
| 数据类型 | 例子 | 更新频率 | 能不能错 | 走哪条路 | 要不要调模型 |
|---|---|---|---|---|---|
| 描述性知识 | 商品参数说明、FAQ、使用指南 | 低 | 允许措辞差异 | RAG 检索 | 要，组织语言 |
| 实时业务数据 | 价格、库存、订单状态 | 高 | 不能错 | 工具查库 | 可以不调，直接拼字段 |
| 明确规则 | 退换货时限、质保条款 | 低 | 不能错 | 规则表匹配 | 可以不调 |
| 需要动作的请求 | 退款、改地址、建工单 | — | 不能错 | 工具执行 + 校验，或转人工 | 视情况 |
分流由谁决定：
调用方指定：页面或接口直接传问题类型 简单可靠，但依赖入口设计
规则判断： 关键词、正则、表单选项 可解释，覆盖面有限
意图识别： 分类模型或大模型判断类型 灵活，要处理误判和低置信
Agent 自选：把 RAG 和工具都交给模型按需调用 最灵活，要有调用上限和留痕完整版教学
一、为什么不能「什么都进知识库」
把价格、库存也写进知识库文档，看起来省事：一套 RAG 就能回答所有问题。问题在于：
10:00 商品 A 价格 5999，写进知识库，切片、向量化
14:00 运营改价为 5499
15:00 用户问「A 多少钱」→ 检索命中 10:00 的切片 → 回答「5999」知识库是离线加工的，从数据变化到切片、向量化完成有延迟；而价格、库存、订单状态是实时变化且不能出错的。报错一个价格就可能引发客诉甚至资损。这类数据必须每次都查真实来源。
反过来，把商品说明、FAQ 这类长文本放进数据库字段、用 SQL like 去查也不行：用户问法千变万化，关键词匹配几乎命中不了，这正是 RAG 的用武之地。
记忆钩子：会变、不能错的，查源头；变得慢、问法多的，走检索；条目少、规则硬的，查规则表。
二、确定性数据查到后，要不要再过模型
一个常见的设计是：工具查到订单状态后，再交给大模型「组织成自然语言」。这一步有代价：
| 做法 | 优点 | 代价 |
|---|---|---|
| 工具结果直接拼成文本返回 | 零编造风险、零模型成本、毫秒级 | 回答格式固定，不够口语化 |
| 工具结果交给模型组织 | 回答自然 | 多一次调用；模型可能改错数字、补充不存在的信息 |
对订单状态、价格库存这类问题，用户要的是准确的数字和状态，格式固定反而更清楚。只有当一个回答要综合多个来源（比如「这款笔记本适合编程吗、现在有货吗」同时涉及参数说明和库存）时，才值得把工具结果和检索资料一起交给模型。
三、规则表匹配：比 RAG 更硬的选择
售后政策这类内容有两个特点：条目有限（退货、换货、质保、物流几十条），而且每一条都是「必须这样执行」的规则。放进知识库走向量检索也可以，但有两个隐患：检索可能取到措辞相近但适用条件不同的条款；模型组织语言时可能改掉关键条件（「7 天」说成「一周内」还好，说成「15 天」就是事故）。
直接查规则表，按类型、名称、适用场景做关键词匹配，把命中的规则原文拼成回答，从根本上排除了编造的可能。代价是匹配不如语义检索灵活，所以要设计匹配不上时的兜底，比如返回最常用的几条规则，或者提示转人工。
四、同一句话，可能对应两种不同的问题
「售后怎么规定」在不同入口下含义不同：
在某商品详情页问 → 想知道「这个商品的售后说明写了什么」→ 该商品知识库里的售后说明
在客服中心问 → 想知道「平台的售后规则是怎么定的」 → 平台规则表所以分流不只看问题文本，还要看问题从哪里来、当前上下文是什么。入口本身就是很强的分流信号：详情页天然限定在某个商品，订单页天然带着订单号。
五、分流由谁决定
四种方式的对比：
| 方式 | 实现 | 优点 | 风险 |
|---|---|---|---|
| 调用方指定 | 页面或接口传问题类型 | 简单、零误判 | 入口多了要各自维护，用户在错的入口问就答偏 |
| 规则判断 | 关键词、正则 | 可解释、快 | 覆盖不全，问法一变就漏 |
| 意图识别 | 分类模型或大模型判类型 | 灵活 | 误判后走错数据源，要有低置信兜底 |
| Agent 自选 | 模型在工具和检索之间按需调用 | 能处理混合问题 | 步数不可控，要有调用上限和过程留痕 |
实际系统常常组合使用：入口能确定的先由入口确定，剩下的用意图识别，识别不准的交给 Agent 或转人工。自动路由的设计和评测，见「RAG Query Router 适合解决什么问题？」。
六、模型负责说，系统负责做
还有一类请求不是「查」而是「做」：退款、改地址、建工单。这类请求既不能交给 RAG（知识库里只有流程说明，没有执行能力），也不能让模型在回答里「声称已办理」。要么由工具在代码层面真正执行并校验权限和参数，要么由页面入口交给人工处理。一个只做知识问答的客服窗口，最重要的边界就是不假装自己办了事。
七、怎么验证分流设计是否合理
分流设计好不好，要看线上数据：
统计每类问题的量、平均耗时、模型调用次数
抽查回答：确定性数据有没有被模型改错，描述性问题有没有答空
统计兜底比例：规则匹配不上的比例、意图识别低置信的比例、转人工的比例例如一周 1000 次问答里，价格库存类 300 次都没调模型、耗时毫秒级，商品知识类 500 次各调一次模型，售后规则类 200 次里有 20 次匹配不上走了兜底——这 20 次就是补规则或补知识的线索。
八、常见误区与追问
- 误区：所有问题都走 RAG 最统一。 价格库存订单这类实时数据进知识库会过期，必须查真实来源。
- 误区：工具查到数据后一定要交给模型润色。 确定性数据直接返回更准、更快、更省，模型润色可能改错数字。
- 误区：规则类内容放进知识库就行。 条目有限、必须严格执行的规则，查规则表拼原文更可靠。
- 误区：分流只看问题文本。 问题来自哪个入口、当前上下文是什么，同样是关键信号。
- 误区：模型可以在回答里告诉用户「已为您办理」。 真实业务动作只能由工具执行或转人工，模型只负责说明。
- 追问：一个问题同时涉及说明和库存怎么办？ 分别查知识库和工具，再把两部分结果一起交给模型组织回答。
- 追问：规则匹配不上怎么办？ 设计兜底，比如返回最常用的几条规则或提示转人工，并统计兜底比例作为补规则的依据。
九、加强记忆
按数据性质分流：描述性知识变得慢、问法多，走 RAG；价格库存订单会变、不能错，用工具查源头；售后条款条目少、规则硬，查规则表拼原文。确定性数据查到后不一定再过模型，直接返回零编造风险。同一句话在不同入口含义不同，入口本身就是分流信号。分流可以由调用方指定、规则判断、意图识别或 Agent 自选，常组合使用并设兜底。退款建单这类动作由工具执行或转人工，模型只负责说。上线后按各类问题的量、耗时和兜底比例检验分流设计。
项目实战落地
项目里怎么做的
《AI Agent电商平台导购与运营增长系统》的 POST /shoppingQa/ask 按 questionType 分到四条链路：
| 类型 | 数据源 | 调大模型 |
|---|---|---|
PRODUCT 商品知识 | 商品知识切片向量检索，按 0.5 阈值过滤后交给模型作答 | 是 |
PRICE_STOCK 价格库存 | 价格、库存、优惠三个工具，读 product 表后拼接字段 | 否 |
ORDER 订单状态 | 订单工具查 shop_order，字段按行列出 | 否 |
AFTER_SALE 售后咨询 | after_sale_rule 表关键词匹配，取前三条规则拼成回答 | 否 |
每条问答把回答、依据（evidence_content）和链路轨迹（tool_trace）一起存进 shopping_qa。问题类型由调用方传入：前台商品详情页固定传 PRODUCT，后台由管理员在下拉里选，系统本身不做意图识别。
《AI智能客服与工单处理系统》则把边界划在「查」与「做」之间：AI 客服只做知识问答，不查订单、不建工单，回答不了的问题由每条回答下方固定的人工工单入口承接。
为什么这样取舍
- 三类确定性问题不调模型：这些数据本身就是准确的，让模型再组织一遍只会增加编造风险和 token 成本。
- 类型由调用方传入：先把分流边界做清楚，自动路由需要在分发前再加一步意图识别，这是明确的下一步改进方向。
面试官还会追问
- 在前台商品详情页问「售后和保修怎么规定」，走的是哪条链路？和后台选「售后咨询」答的是一回事吗？
- 售后咨询一条规则都没匹配上时，系统怎么回答？
学完《AI Agent电商平台导购与运营增长系统》，上面这些追问你都会迎刃而解。