智能客服系统里，RAG、工具调用和人工转接应该怎么配合？

知识点详解：一次售后对话会经过三种不同的边界

公开规则：RAG 回答“通常怎么办”

“七天无理由怎么计算”是在问政策。RAG 可以从经过管理的售后规则中检索生效版本，回答起算时间、排除商品和申请条件，并把来源展示出来。若各渠道政策不同，还要先明确购买渠道；如果资料冲突，先说冲突，不要替业务部门拍板。

这时不一定要查询用户订单。公开政策答复的任务边界是解释规则，不是判断某一单是否符合。把这一步做好，系统就能先解决大量低风险、可标准化的问题。

订单查询：工具回答“这笔订单现在怎样”

用户说“我的订单能退吗”，问题就变了。需要先识别并验证用户身份，再查询订单、签收时间、商品类别和售后状态。查询工具要由应用携带已认证的用户身份，后端按订单归属做授权，而不是把用户在聊天里输入的订单号直接当访问凭证。

模型可以整理工具返回的信息，向用户解释“政策要求是什么、当前订单满足了哪些条件”。但最终是否有退货资格，最好由确定性的业务规则或售后服务给出。知识库可能说明一般条件，不能替代实时订单事实；订单接口的返回也不能被模型自行改写成另一个金额或日期。

退款执行：从回答变成业务动作

“帮我退款”是写操作，风险比问政策高得多。系统要确认用户要退哪笔订单、退款金额和去向是否由业务系统核算，是否需要人工审核或二次确认；然后才由有权限的后端服务执行。执行结果要有业务单号，重试要避免重复退款。

如果订单工具超时，系统应停在“无法核实”。它可以告诉用户当前状态、安排重试或创建人工工单，但不能为了让对话显得顺畅而承诺退款成功。模型提出操作意图，与后端真正完成退款，是两个需要分开记录的事件。

人工转接：交接的是事实，不是整段聊天的噪声

有些问题靠补问就能解决，例如用户没提供购买渠道；有些必须转人工，例如工具持续失败、例外政策缺少决策规则，或者用户对已给结论提出正式投诉。

转接包可以包含：用户已授权的身份与订单标识、已查到的政策版本、工具调用结果、系统没有核实的部分、用户诉求，以及已经做过的操作。**推测和已核实事实要分开标注。**这样人工接手时知道下一步该查什么，也不会把 AI 的一句“可能可以退”误当成业务承诺。

面试官继续追问

用户提供订单号，就能直接查询吗？

不能。订单号不是身份凭证。查询工具必须核对登录身份和订单归属；涉及他人订单时，模型也不能从历史聊天里“借用”权限。

RAG 与订单系统说法冲突，信谁？

先看冲突的是什么。政策版本和适用范围由权威政策源确认；订单状态由订单系统确认；退款资格由业务规则决定。不要简单说“实时系统永远优先”或“知识库永远优先”，因为两者回答的不是同一个事实。

什么情况下不应自动退款，而应转人工？

规则不覆盖的例外、金额异常、身份或订单归属不清、工具结果矛盾、用户明确要求投诉升级，都适合交给人工。已有明确规则和确认流程的正常退款，则不必为了“稳妥”全部转人工。

面试速记卡

• RAG：解释当前适用的公开政策，不能证明个人订单状态。
• 读工具：带已认证身份查询订单，后端核对归属。
• 写工具：退款由业务规则、权限与确认控制，模型不能直接拍板。
• 失败兜底：工具超时就说明无法核实，不猜资格、不伪称操作成功。
• 人工转接：交接已核实事实、未解决问题和已做操作，不传递模型猜测。