波仔
🐦 第13章 实战案例：智能客服
📄 一句话概括

一个节点干四件事：按关键词查、命中了就把 hits 加一、查不到就写进 miss 表、把答案交给下游。 三种查法一种比一种宽：精确查问法、按关键词模糊查、问法和关键词一起模糊查。 客服里最常用的是第二种。 查不到不是异常，是正常分支。它要有自己的去处——转人工，并且记下来。

📝 本章和前面几章的关系

这一节只讲一个节点，可它是整条链里唯一同时读写外部数据的地方。 本沙箱没有飞书，这一节用真 sqlite 开库、真建表、真跑 UPDATE，字段名和 SQL 与飞书那边一一对应。 注意：飞书多维表格的接口是 HTTP 的，不是 SQL。 所以本节把 SQL 当「语义说明」看，节点里真正填的是「表 ID + 字段名 + 筛选条件」。

一、节点做四件事

步 动作 失败会怎样
1 按关键词查 faq 表 查不到，走第 3 步
2 命中就 UPDATE hits = hits + 1 只影响报表，不影响答复
3 没命中就 INSERT 进 miss 表 少一条原料，不影响本轮
4 把 answer 交给下游输出节点 必须成功，否则这轮空转

第 2、3 步失败了不影响这一轮答复，所以很多人干脆不写。写了才知道哪条该改。 第 4 步是唯一不能失败的。它一失败，用户等半天什么也没收到——这种时候要有个兜底话术，别让链空转。 四步的顺序不能换：先加 hits 再判断要不要写 miss，会把「命中过」的问题也记成没答上来。

二、三种查法，一种比一种宽

查法 写法 什么时候用
精确查问法 question = 用户原话 几乎不用，用户不会照标准问法说
按关键词模糊查 keywords LIKE %词% 最常用
问法和关键词一起模糊查 两个字段 OR 补漏，容易查宽

第二种是主力：用户说「能退款吗」，标准问法是「支持退货吗」，但关键词里有「退款」，就接上了。 第三种要小心。 查宽了会把不相关的条目捞出来——「洗」一个字的模糊查，可能把「洗碗机」和「洗面奶」都捞出来。 所以第三种只用来补漏：主查走关键词，漏了再用问法捞一遍，两次结果取先命中的。

三、hits 加一，是给谁看的

第 2 条「支持退货吗」被问了一次，hits 从 0 变 1。运营每周看一次这张表，按 hits 排个序。 排在前面的，答案要写得更细。 排到最后一次没被问的，两种可能：要么没问题， 要么问法没人看得懂——后者更常见。 这一列不能只增不减。上线三个月后，前十条可能全是已经改过产品的旧问题，那就该下线而不是继续加。

四、查不到：写进 miss 表

搜「内部价」，零条。这时候链不能报错，得走第三条路——转人工，同时把这句话写进 miss 表。 miss 表只要三列：id、问题原文、创建日期。 不要在这一步做归类，归类是人的活（第 13.10 节讲为什么）。 运营每天看一次 miss 表，答得上的补进 faq，答不上的转产品页或干脆不回。

这张表就是 FAQ 自动更新的原料。 没人记，那批问题会一直被转人工，永远不变。

五、飞书节点这边怎么填

节点类型选「多维表格」，操作选「查询记录」，表 ID 从第 13.4 节的 URL 里取， 筛选条件写「keywords 包含关键词」，返回条数填 1，输出 answer 和 id 两个变量。 后面再接一个「更新记录」节点：记录 id 接上一步的 id，hits 填上一步的 hits 加一。 飞书这边没有 SQL，筛选条件就是界面上那几个下拉框。上面这段是它们的语义，不是代码。

「返回条数：1」这一项很关键。返回十条，下游不知道该用哪条的答案； 返回一条，虽然可能漏，但链路清楚。 要更稳的话，查询返回三条，再插一个节点按命中词数挑一条。 这一章没做，因为五条 FAQ 用不上——五条的时候，挑错和漏掉是同一个结果。

六、动手 Demo：读写一张在线表

用真 sqlite 建一张五条记录的 faq 表，跑三种查法，再看 hits 怎么加、miss 怎么写。 字段名和飞书那边一一对应，SQL 只是它们的语义说明。

con = Q.db(DB, [u'''CREATE TABLE faq (id INTEGER PRIMARY KEY, question TEXT,
                  answer TEXT, keywords TEXT, hits INTEGER DEFAULT 0)'''],
           [(u'INSERT INTO faq VALUES (?,?,?,?,?)', FAQ)])

Q.q(con, u'UPDATE faq SET hits = hits + 1 WHERE id = ?', (2,))

实跑输出：

--------------------------------------------------------------------
读写一张在线表
--------------------------------------------------------------------


  ① 五条常见问题
  --------------------------------------------------------------------

| id | 标准问法 | 关键词 | 答案 | 命中 |
|---:|---|---|---|---:|
| 1 | 能保温多久 | 保温,多久,时长 | 装满热水能保温 12 小时，采用 316 … | 0 |
| 2 | 支持退货吗 | 退货,退款,七天 | 支持七天无理由退货，十五天内质量问题可换新。 | 0 |
| 3 | 杯盖能洗吗 | 杯盖,清洗,洗 | 杯盖可以拆开清洗，不建议放进洗碗机。 | 0 |
| 4 | 多久能到 | 发货,物流,几天 | 发货后三到五天送到，偏远地区五到七天。 | 0 |
| 5 | 有优惠吗 | 优惠,折扣,会员 | 会员九五折，生日当月再减二十元。 | 0 |


  ② 三种查法，一种比一种宽
  --------------------------------------------------------------------
  精确查「支持退货吗」：1 条
  按关键词查「退货」：1 条，第 2 条
  模糊查「洗」：1 条
  客服里最常用的是第二种：用户不会照标准问法说话，但会说出关键词。

  ③ 命中一次就加一
  --------------------------------------------------------------------
  第 2 条被问了一次：支持退货吗，命中 1 次
  这一列是给运营看的：哪些问题问得多，就说明哪些答案要写得更细。
  它也顺便告诉你哪些问题问得少——可能就是没人看得懂，得改问法。

  ④ 查不到怎么办
  --------------------------------------------------------------------
  搜「内部价」：0 条。查不到就要走第三条路——转人工，并且把这个问题记下来。
  记下来之后，miss 表里有 1 条。运营每天看一次，答得上的就补进 faq 表。
  ! 这张 miss 表就是「FAQ 自动更新」的原料。 没人记，那些问题就永远答不上来。

①五条常见问题：关键词那一列是接口语用的，hits 一开始都是 0。 ②三种查法：精确查 1 条、按关键词查 1 条、模糊查 1 条。 ③hits 加一之后，第 2 条从 0 变 1，这是给运营看的报表。 ④搜「内部价」零条，写进 miss 表——这张表是 FAQ 自动更新的原料。 ⑤第四节那句提醒：这一步不要做归类，归类是人的活。

30 秒实验

  1. 把三种查法各跑一遍，看第三种会不会捞出不相关的条目。捞出来了，就砍掉它。
  2. 给 hits 加一个时间列，看这周新增多少。只有累计值看不出趋势。
  3. 在 miss 表里攒够二十条再看，看能不能归成三到五类。归得出来，说明该补的是那几类。

常见误区

  1. 「查不到就报错，让人工处理。」报错会中断整轮对话，用户连转人工的提示都收不到。
  2. 「hits 只增不减。」上线三个月后前十条可能全是旧问题，该下线而不是继续加。
  3. 「miss 表里顺手归个类。」归类是人的活。机器归的类，运营看不懂也不敢用。
自测三问（点开对答案） 1. 这个节点按什么顺序做四件事？ —— 先查、命中就加 hits、没命中写 miss、最后把答案交给下游。顺序换了会记错。 2. 三种查法里最常用的是哪种？ —— 按关键词模糊查。用户不会照标准问法说话，但会说出关键词。 3. 查不到的时候该做什么？ —— 不报错，转人工，并把问题写进 miss 表。它不影响本轮答复，但是下一版的原料。

查到了答案，还得拼成一句人话。下一节讲输出节点——用户看到的就是它拼出来的那段。

相关笔记