零售电商的 AI 客服：为什么"接通率"是个错误的指标
大部分零售电商上 AI 客服，最后都在同一个地方翻车：
机器人接了 80% 的会话，投诉率却上去了。
原因不复杂：接通率衡量的是"机器人拦住了多少人"，不是"多少人的问题被解决了"。 一个把所有人都拦住、然后车轱辘话说三轮的机器人，接通率非常好看。
这篇讲清楚该量什么、怎么分场景、以及一条几乎所有人都跳过的红线。
---
该量的四个指标
把接通率从考核里拿掉，换成这四个：
| 指标 | 定义 | 为什么它比接通率重要 |
|---|---|---|
| 一次解决率 | 用户问完就走、没再问同一件事、没转人工 | 这才是"解决了" |
| 转人工顺畅度 | 从用户表达不满到接上人工的轮次和秒数 | 拦得越久，投诉越狠 |
| 上下文保留率 | 转人工后，客服看不看得到前面的对话 | 让用户重说一遍是最大的怒点 |
| 错误答案率 | 抽查中给出错误信息的比例 | 一条错误的退货政策，成本远大于省下的人力 |
其中第二项最反直觉：很多系统被设计成"尽量不转人工"，因为那样"成本低"。但用户已经想找人的时候还被拦着，是零售场景里最强的差评触发点——省下的那几分钟人力，换来一条差评和一次退货，账是亏的。
建议的硬门槛：用户明确表达要人工时，3 轮以内、30 秒以内接上。做不到就不要上。
---
分场景：哪些该给机器人，哪些不该
不要笼统地说"客服机器人"。零售电商的会话至少分四类，处理方式完全不同。
一、订单状态类（最适合）
"我的货到哪了""什么时候发""能不能改地址"。
为什么适合：答案是确定的、来自系统的、实时的。这类根本不需要生成式模型——查询接口 + 模板回复就够了，又快又不会错。
常见错误：用大模型去答一个查数据库就能答的问题。慢、贵、还可能编。
二、商品与政策类（适合，但要治理）
"这个尺码怎么选""能不能七天无理由""开发票要多久"。
为什么要治理：这类答案来自商品详情和平台政策文档，而这些文档经常过期、经常有例外、经常各说各的。
必须做的三件事：
- 每条政策标注生效时间和适用范围（哪些品类、哪些渠道、哪些活动期间除外）
- 活动期间的临时规则单独标记，活动结束自动失效
- 涉及金额、天数、比例的答案，必须与原文做程序化比对
为什么第三条特别重要："7 天无理由"被说成"15 天"，用户会照着做，然后产生一次必然的纠纷。这类错误语义完全通顺，人工抽查很难发现。
三、售后与纠纷类（谨慎）
"东西坏了""发错了""我要退款"。
这一类的正确做法是：识别 + 分流 + 收集信息，不做判定。
- 可以做：确认订单、引导上传照片、说明流程、给出预计时长
- 不该做：判定责任、承诺赔付、给出最终处理结论
理由：判定和承诺一旦说出口就有效力。系统说"这个我们会全额退"，用户就会当真——而它可能根本不了解这个订单的具体情况。
四、情绪与投诉类（立即转人工）
用户已经在生气了。
这一类没有"先试试能不能自己解决"的空间。识别到强烈负面情绪，立刻转人工，并把完整上下文带过去。
识别不准怎么办：宁可误转。误转一个不生气的用户，成本是几分钟人力；漏转一个生气的用户，成本是一条差评加一次退货。
---
一条几乎所有人都跳过的红线
在境内面向公众提供生成式人工智能服务，适用《生成式人工智能服务管理暂行办法》。零售电商的客服机器人是直接面向消费者的，这一点和企业内部工具有本质区别。
要注意的三件事：
1. 面向公众提供服务与内部使用，要求不同——涉及备案、内容标识等一系列问题
2. 生成内容的标识要求——需要确认在你的场景下是否适用、怎么落地
3. 消费者权益相关的表述必须准确——退换货政策、保修承诺这类内容说错了，产生的是实际的法律后果
这些必须由企业自身的合规部门确认适用情况。本文只提示其存在，不构成合规意见。
实践中的建议：把"涉及承诺、赔付、权益的表述"整理成一张受控话术表，系统只能从表里选，不能自由生成。这一条能挡掉这类风险里的绝大部分。
---
知识治理：零售场景的特殊难点
零售电商的资料有两个别的行业没有的麻烦：
一、SKU 数量大，且频繁变动。
商品上下架、价格调整、库存变化——用固定周期同步一定会失准。这类数据应该实时查系统，而不是进知识库。
判据很简单：会变的查接口，不变的进知识库。把商品价格放进向量库，是零售场景最典型的错误。
二、活动规则叠加。
大促期间，平台规则、店铺活动、优惠券、满减，多层叠加还互相排斥。
处理方式：活动规则单独一个库，带明确的生效和失效时间，活动结束自动移出检索范围。不要指望人工记得去删。
---
怎么验收
口径沿用开源评测框架 RAGAS（docs.ragas.io），另加零售特有的两项：
| 指标 | 建议门槛 |
|---|---|
| 答案忠实度（每句话能对应到原文） | 不低于 95% |
| 数值类准确率（金额/天数/比例） | 100%，程序化比对 |
| 转人工响应（明确要求后） | 3 轮 / 30 秒以内 |
| 上下文传递完整性 | 100% |
| 情绪识别转人工准确率 | 宁可误转，漏转率接近 0 |
数值类那一项没有及格线的说法——它靠的不是模型准确率，是输出侧的程序化比对。做不到就不要让系统回答涉及数字的问题。
测试集建议规模：从真实会话记录里抽 200–300 条，覆盖四类场景，其中至少 50 条是边界情况（活动期、多单合并、跨店、退款中途改主意）。边界情况才是真正暴露问题的地方。
---
一个务实的上线顺序
1. 只做订单状态类，纯接口查询，跑 2–4 周
2. 加商品与政策类，但先做资料治理，且数值必须程序化校验
3. 加售后信息收集（只收集不判定），观察转人工顺畅度
4. 情绪识别转人工从一开始就要有，不是最后加
不要一次全上。四类场景的失败方式完全不同，混在一起上线，出了问题定位不了是哪一类的问题。
---
相关阅读
- 企业知识库怎么做，才不会变成资料坟场
- 企业 AI 的数据治理：治什么、治到什么程度、谁来治
- 企业 AI 项目怎么验收：七层验收标准与证据要求
- 企业第一次做 AI，怎样选对项目并设计可退出的试点
---
*本文说明的是方法与判断标准，不代表任何未公开项目的实施细节。文中引用的开源评测框架与公开规范，出处已在正文标明，读者可自行核验。合规适用情况请由企业自身合规部门确认，本文不构成合规意见。*