森林教练 · 企业 AI 案例

淘宝售后用 AI，先证明“更快”不等于“解决得更好”

5940 名客服、4 周随机现场实验，测出生成式 AI 的真实收益与边界

如果一个客服团队把平均处理时长降下来了，你会认为售后服务变好了吗？

我不会急着下结论。

因为客服工作其实有两条线：一条是让客户更快被理解、更快收到回复；另一条是把订单问题真正处理完，让客户不必因为同一件事再次回来。

前一条，几秒钟就能看见变化。后一条，往往要等几天，甚至等到客户再次联系、投诉升级，才知道答案到底有没有用。

淘宝售后这场实验值得看的地方，不是它用了什么“大模型”，而是它做了两件很克制的事：把生成式 AI 放在一线客服旁边，而不是直接替代客服；再用随机分组，把“更快”和“解决得更好”分开测。

这才是一个企业 AI 案例真正应该回答的问题：工具接上以后，业务到底改变了哪一段？

淘宝售后原本已经有一套标准流程。

客户先与数字客服交互，系统读取订单历史，并从预设动作中给出建议。如果问题没有解决，客户再进入人工客服。人工客服的工作台里，也有客户信息、订单历史、过往互动记录，以及可以检索标准回复和 SOP 的回复库。

但售后场景有一个现实难题：客服通常要同时处理多个对话。面对退换货、退款、维修、物流等订单问题，客服需要先看懂客户到底遇到了什么，再查订单、判断规则、组织回复，最后提出下一步处理方案。

真正容易卡住的，往往不是“有没有一句话可以回复”，而是最开始的几秒钟：问题是什么？这笔订单现在处于什么状态？接下来能做什么？

2023 年，Alibaba 开发了一个生成式 AI 助手，接入淘宝售后客服工作流。论文披露，这个助手结合了 Qwen 大语言模型和针对淘宝客服场景微调的机器学习算法，使用服务聊天、订单详情和客户信息，主要做两件事：

注意，它只在对话开头阶段提供文本建议，而且建议只对客服可见。

客服可以一键发送，也可以复制后修改，还可以完全忽略，自己重新组织回复。AI 没有直接对客户承诺退款，也没有绕过客服去修改订单。

这一步很关键。

它把 AI 的职责限定为“帮助理解和组织”，把最终发送、判断和责任仍然留在人手里。模型不是售后规则的拥有者，只是进入一线工作流的一层辅助能力。

2024 年 1 月 23 日到 2 月 19 日，淘宝进行了一次为期 4 周的随机 A/B 实验。

参与者是 5940 名入职未满一年的淘宝官方客服，不是店铺自己的商家客服。2895 名客服被随机分到处理组，获得 AI 助手访问权限；3045 名客服进入对照组，继续使用原有客服工具。随机分组按照客服 ID 进行。

这批客服在实验期间处理了约 256 万次聊天，收到约 39 万条客户评分，实验样本约占当时淘宝官方客服的 15.6%。研究还保留了前面 4 周的处理前观察窗口，用来比较两组在接入 AI 前后的变化。

实验结束后，论文时间线显示，助手于 2024 年 2 月 20 日向所有客服上线。但这不等于论文已经证明它在长期、所有复杂售后场景里都持续有效。实验能够回答的是：在这段时间、这类客服和这个工作流里，获得 AI 访问权限后，指标发生了什么变化。

这就是随机实验的价值。

— 随机实验分组结构

它不是先挑几个表现好的客服做展示，而是保留一组仍按旧流程工作的对照组，让“用了 AI”和“没有用 AI”的差别尽量可以比较。

论文先估计的是 ITT，也就是“被分配到 AI 访问权限”之后，处理组整体平均发生了什么。

结果是：

从这些指标看，AI 确实帮助客服更快识别问题、缩短对话，也让客户对当下的服务体验评价更好。

但真正值得停下来看的，是最后一个结果：

论文把它作为更接近客观解决结果的指标。客户觉得这次沟通更顺、更清楚，不代表订单背后的问题已经彻底处理完。

换句话说，AI 改善了“服务是怎么被体验的”，却没有在平均意义上证明“问题解决结果变好了”。

这两个结果并不矛盾。

客服可以更快地识别问题，更有条理地解释规则，也可以让客户少上传几张证明图片、少写几段补充说明；但如果退款、换货、物流或其他业务动作本身没有真正完成，客户仍然可能回来。

所以，企业做客服 AI 时，至少要同时看两套指标：

一套是处理速度和即时体验，另一套是一次解决、重复联系、投诉复发和后续工单结果。

只看第一套，容易把“回复得更快”误认为“事情办得更好”。

处理组拥有访问权限，并不代表每个客服都会使用 AI 建议。

有人直接发送，有人会复制后修改，有人看一眼就不用。于是论文又把随机分组作为工具变量，估计实际使用 AI 的局部平均处理效应，也就是 LATE。

在这个局部估计里，AI 使用率从 0 提高到 1，对应的结果更大：

这里要特别注意：LATE 不是“所有客服只要用了 AI，就一定得到这组收益”。它描述的是那些因为随机获得访问权而改变使用行为的那部分客服的局部效果，不能直接写成全体客服的平均提升。

— ITT 与 LATE 结果对照

这也是为什么我不建议企业只拿一个“AI 使用率”去做成绩单。使用率上升，可能带来收益，也可能把不适合使用的场景一起推给 AI。你还要知道谁在用、用在什么问题上、用了以后哪些结果变好或变坏。

平均数还会掩盖另一件事：不同水平的客服，得到的不是同一种结果。

论文按处理前客户评分把客服分成五个绩效分位。低绩效客服从 AI 中获得的收益更大，尤其是在客户评价和聊天时长上，表现差距因此缩小。

这很容易理解：一个经验不足的客服，原来需要花更多时间查规则、组织语言，AI 提供的诊断和解决方案建议，恰好补上了这部分经验缺口。

但处在最高绩效分位的客服，主观服务质量和客观服务质量都出现了下降的估计。

论文给出的过程证据与一个解释一致：在同时处理多个聊天的环境里，AI 让部分高绩效客服增加了离开当前对话的时间，后续回复变慢，客户即时再次联系的情况也增加，原本连续的服务节奏被打断。

这不是在说“AI 一定会伤害高手”，也不是说论文已经完全识别了唯一的中介机制。它提醒管理者的是：

给新客服的辅助建议，可能是在补能力；给一个已经形成稳定工作流的高手，可能变成新的界面切换和注意力成本。

如果企业只看全员平均处理时长，很可能看不见这类损失。

如果把淘宝案例压缩成企业能拿走的最小方法单元，我会拆成六步。

1. 先定义“解决”，再定义“提速”

在接入模型之前，先写清楚什么叫问题解决。

售后至少可以同时定义：问题识别时间、整段处理时长、一次解决率、三日内同一问题再次联系、投诉升级率和最终工单是否关闭。

如果你只定义“回复更快”，模型很容易把团队带向更快地产出回复，而不是更完整地完成业务动作。

2. 从一个小决策点开始，不要一上来做全自动客服

先挑一个高频、规则相对稳定的问题类型，让 AI 只做问题诊断和下一步建议。

建议只对员工可见，员工可以采纳、修改、拒绝。退款、赔付、隐私请求、重大投诉和超权限动作，保留人工审批和升级出口。

3. 把业务上下文和权限一起接入

最小数据集不只是聊天文本，还要包括订单 ID、问题类型、订单状态、历史处置、允许执行的动作、对应 SOP 和证据链接。

数据能不能查到，和客服有没有权限执行，是两件事。AI 可以建议“下一步是什么”，但不能因为建议生成得很像，就自动获得修改订单的权力。

4. 保留一组对照，不要只做上线前后对比

淘宝实验给出的可复制结构是：

小企业不一定需要 5940 名客服，但可以先选一类售后问题和一批客服，按员工随机分组，连续跑 4 周，同时保留旧流程组。

5. 平均数之外，必须做分层验收

至少按客服熟练度、入职时长、并发聊天数量、问题类型和 AI 采纳率分层看结果。

如果低绩效员工变快了，但高绩效员工的客户评价下降；如果平均满意度上升，但三日复联和投诉复发不变，就不能只宣布“项目成功”，而要调整推送时机、适用人群和工作台交互。

6. 把每次建议和结果写回工作流

每条建议都记录：模型给了什么、客服是否采纳、改了什么、最后发了什么、客户是否再次联系、工单最终怎么结束。

— 企业复制闭环

这样沉淀下来的不是一个聊天窗口，而是一套可复盘的客服 Skill：

这才有可能从一次 AI 试点，变成组织能力。

这个案例给我的最大启发，不是“客服也可以接大模型”，而是企业终于开始把 AI 当成一个可以被验证的业务干预。

它改变了客服的工作界面，也改变了问题识别和回复组织的方式；但它没有自动证明订单问题被更好地解决，更没有证明所有客服、所有问题和所有阶段都适合使用同一种 AI。

所以，企业接入 AI 之前，我会先问四个问题：

先把问题定义清楚，再把数据、权限、人工确认和复盘接起来。AI 负责提效，人负责判断和结果。