代码语言

知识点思维导图

36 个知识节点

参考资料

项目实战（01） - 项目：AI 客服助手

读完后，你应能完成以下任务：

绘制“项目实战（01） - 项目：AI 客服助手 / 三条路径，一个路由”的关键对象与数据流，解释“RAG 没命中，不能拒答了事。”，并用源码位置、日志或 Trace 标注证据。

为“项目实战（01） - 项目：AI 客服助手 / 意图识别可以三路融合”设计正常与异常输入，验证“客服场景里只靠关键词容易误判，只靠模型又不稳定。”，输出首个偏差位置与回归测试结果。

实现“项目实战（01） - 项目：AI 客服助手 / RAG 这条路：命中就答，没命中交棒”的最小代码或配置，检验“return None 这一行是 RAG 和客服流程的接缝。”，输出命令、结果与 Diff，并说明不适用边界。

一、AI 客服助手的真实应用场景

电商客服后台，一天的提问长这样：

"退货之后多久退款？" —— 查制度就能答。
"帮我查下我那个 C1001 的订单到哪了？" —— 得查真实订单库，制度里没有。
"你们支持货到付款吗？" —— 知识库压根没收录，answer 不了。

一个只会聊天的机器人，第一条能蒙对，第二条会编一个假物流单号，第三条会一本正经地胡说。客服场景对"胡说"零容忍——答错退款时效要赔钱，编造订单状态要投诉。

所以客服助手的第一能力不是"会聊"，是分诊：先判断这句话该走哪条路，再决定调谁。这一篇就是把 43 的 RAG 和 28 的工具调用接起来，让一个助手同时具备这三条路径。

二、三条路径，一个路由

客服助手的骨架是一个 route，把用户问题分到三条路径之一：

用户问题
   │
   ├─ 问制度/政策/物流规则 ──→ RAG 检索知识库 ──→ 命中？答 + 引用
   │                                          └─ 没命中 → 转路径 C
   ├─ 要真实数据（查订单）  ──→ 工具调用 lookup_orders ──→ 四层校验后查库
   │
   └─ 要落地动作（转人工）  ──→ 工具调用 create_ticket ──→ 写操作，卡确认

注意两个"没命中"的去向不一样：

RAG 没命中，不能拒答了事。客服拒答等于把用户晾在那。要兜底转人工建工单，让真人接手。
工具没权限/没确认，必须拦。这是安全边界，宁可不办也不能越权办。

这就是客服项目比纯 RAG、纯工具调用都更完整的地方：它要同时处理"答不了怎么办"和"不该办怎么拦"两类边界。

三、意图识别可以三路融合

客服场景里只靠关键词容易误判，只靠模型又不稳定。更稳的做法是三路融合：

路径	适合判断什么
规则/关键词	订单号、工单号、退款、投诉等强特征
embedding 相似度	和历史问题、FAQ 意图相近的问法
LLM 分类	长句、多意图、需要澄清的问题

三路结果不一致时，不要硬走某条路。可以降级为澄清问题，或交给人工。上线后用 LLM-as-Judge 抽样评估路由准确率和回答满意度。

四、RAG 这条路：命中就答，没命中交棒

RAG 部分和 43 一样：切 chunk、打分检索、命中才答。区别在返回值——客服里 RAG 没命中不直接拒答，而是返回 None，把决策权交回路由：

return None 这一行是 RAG 和客服流程的接缝。RAG 只对"知识库里有没有"负责，"没有了怎么办"是客服流程的事。

五、工具这条路：四层校验一字不改

查订单、建工单走的就是 28 那套 execute_tool：白名单 → 权限 → 参数 → 写操作确认。客服场景把它用得更实：

工具	类型	权限	要确认吗
`lookup_orders` 查订单	读	`read:orders`	否
`create_ticket` 建工单	写	`write:tickets`	是

demo 场景 2 和 3 是同一句"查 C1001 订单"，有权限成功、没权限被拦——权限永远是后端的事，不是模型的事。场景 4 的"转人工"是写操作，没确认就只能停在"待确认"，不会自己把工单建了。

六、工程上真正会踩的坑

路由把"查订单"误判成 RAG：用户说"我的订单退款政策是啥"，里面既有"订单"又是问政策。光靠关键词会冲突。真实项目靠模型意图识别，且要给路由加优先级和澄清追问，别让一句话同时触发两条路径。
RAG 没命中就硬拒答：客服拒答是事故。一定要有转人工/建工单的兜底，把用户接住。
转人工的工单标题用了整句脏文本：用户骂骂咧咧一长串，直接塞进工单标题既难看又可能带敏感词。要截断 + 脱敏，正文另存。
三条路径的日志混在一起：出问题分不清是检索错了还是工具调错了。trace 要标清楚这次走了哪条路径、命中了什么、调了什么工具、结果如何。

七、一句话面试答法

客服助手怎么决定是查知识库还是调工具？ 我在前面加了一层意图路由：问制度政策走 RAG，要真实数据或要落地动作走工具调用。两条路的边界处理不同——RAG 没检索到不直接拒答，而是兜底转人工建工单把用户接住；工具调用则走白名单、权限、参数、写操作确认四层校验，没权限宁可不办也不越权。每条路径都有独立 trace，坏 case 能直接定位是路由错、检索错还是工具错。

八、动手实践：44 AI 客服助手

把 RAG（知识库问答） 和 工具调用 接成一个客服闭环：能答的查知识库，要数据的查订单，答不了的自动转人工建工单。复用了 43（检索拒答）和 28（工具四层校验）的核心思路。

8.1 在线运行

零依赖，纯标准库。

8.2 预期输出

=== 场景 1：问售后政策（走 RAG，命中知识库）===
用户：退货之后多久退款？
  路由 → 知识库检索
  回答：退款将在退货签收后 3 个工作日内原路返回。（依据：售后政策）
  引用：after-sale.md

=== 场景 2：查订单（走工具，命中订单）===
用户：帮我查下客户 C1001 的订单
  路由 → 工具：lookup_orders({"customer_id": "C1001"})
  执行成功：{"customer_id": "C1001", "orders": [...]}

=== 场景 3：查订单（无权限，被后端拦）===
  拦截：缺少权限：read:orders

=== 场景 4：要求转人工（写操作，待确认）===
  待人工确认（写操作）：{"title": "我要投诉，请转人工"}

=== 场景 5：问知识库没有的问题（兜底转人工建工单）===
  知识库无相关资料 → 转人工，自动建工单
  已建工单：{"id": "T-1001", ...}

最值得看的是路由：同一个助手，5 句话走了三条不同路径。客服项目的核心就是这个「分诊」能力，而不是单一的聊天。

8.3 代码对应文章的哪些点

概念	在 main.py 哪里
意图路由（查知识 / 查数据 / 建工单）	`route`
知识库检索 + 拒答	`rag_answer`（命中返回，未命中返回 None）
工具四层校验	`execute_tool`
答不了自动转人工兜底	`handle` 的路径 C

8.4 动手改

把 route 换成真实模型的 function-calling 决策，规则逻辑全部下线。
加一个 check_logistics 查物流工具，体会「加能力只加 schema + 执行分支」。
把场景 4 的 confirmed 改成 True，看写操作确认后如何落单。

8.5 可运行源码：项目：AI 客服助手

main.py

九、总结

三条路径，一个路由：RAG 没命中，不能拒答了事。
RAG 这条路：命中就答，没命中交棒：return None 这一行是 RAG 和客服流程的接缝。
工具这条路：四层校验一字不改：查订单、建工单走的就是 28 那套 execute_tool：白名单 → 权限 → 参数 → 写操作确认。
工程上真正会踩的坑：路由把"查订单"误判成 RAG：用户说"我的订单退款政策是啥"，里面既有"订单"又是问政策。
一句话面试答法：两条路的边界处理不同——RAG 没检索到不直接拒答，而是兜底转人工建工单把用户接住；