演示顺利，真实通话出错，问题在哪一层？
您的语音智能体每次演示都顺利过关，一接真实电话却频频出错。哪一层出了问题、该先修什么，答案就在那些失败的通话里。
先说结论
语音智能体演示时表现良好，一到真实通话就出错，并不是它突然变差了。真实通话和演示经过的是同样的七层，从线路与音频、语音识别，到工具、转人工和结果统计。现在出问题的那一层，演示从来没有在真实条件下测过。
所以，别一上来就改提示词。把真实的失败通话拿出来，逐通按顺序走一遍各层，归到最先出问题的那一层。哪一层归到的通话最多，问题就出在哪一层，这也是您要先修的地方。只做这一处修改，再把同一批通话重跑一遍，前后对比。
本文针对已经上线的线路。如果还没上线，建议先看我们的指南：上线前如何测试语音 AI 智能体。
演示为什么能过关
演示是一场理想条件下的测试。打电话的人熟悉脚本，在安静的房间里吐字清楚，还会等智能体把话说完。测试数据也很干净：订单真实存在，时段正好空着。
真实的客户会插话。他们在车里或仓库里打电话，会用方言词和简称，还会顺带问一些流程没覆盖到的相关问题。有时接电话的也不是流程预想的那个人：会计替老板接了，家里人接了，或者电话转到了别的部门。
这些情况考验的是不同的层。演示做得好，只能说明输入干净时各层都撑得住，说明不了真实话务下哪一层最先出问题。
一通电话要经过的七层
每通电话都按同样的顺序经过同样的几层。前面的层出了问题，症状会出现在后面的层，所以只看症状，往往会找错地方。
- 线路与音频：电话接通，双向音频没有延迟或回声，通话正常结束。
- 语音识别：把客户说的话转成文字。
- 知识：智能体可以使用的信息，比如政策规定、产品细节和常见问题的答案。
- 决策：对话逻辑，也就是下一句说什么、问什么，什么时候确认，什么时候转人工，以及怎样结束通话。
- 工具与系统操作：在 CRM、预约系统或工单系统中查询和写入数据。
- 转人工：转接或回电，以及同事接手时拿到的上下文。
- 结果统计：系统记录的结果与实际发生的情况一致。
还有一道关口不属于 AI 层，那就是业务侧关口。有些通话败在业务侧：没有库存，没有空余时段，或者您自己系统里的数据已经过时。智能体该做的都做了，是业务这边兑现不了。这类通话要单独统计，交给负责该流程的人。
先看真实通话，而不是测试用例
取最近一段时间的全部真实通话，而不是测试用例表里的场景。然后剔除内部测试电话：同一个号码、同样照稿念的台词，隔几分钟就重复一遍。测试人员说话的方式，和真实客户不一样。
接着，抽样核对结果标签。如果把语音信箱算成了对话，或者把已完成的预约算成了失败，那么失败通话这批数据本身就是错的。结果统计是最后一层，却要最先核查。
最后，听录音。转写文本只能告诉您语音识别听到了什么，客户实际说了什么，只有录音能告诉您。
用诊断表，从症状定位到具体一层
一次只拿一通失败通话对照这张表，先找到证据，再把它归到某一层。
| 症状 | 可能的层 | 查什么 | 确认依据 |
|---|---|---|---|
| 外呼电话在头几秒就结束 | 线路与音频 | 从对方接起到智能体说出第一个字的时间 | 对方在一段静音后挂断，智能体还没开口。如果是开场白说到一半时挂断，指向决策层。 |
| 客户说完话后，长时间没有回应 | 线路与音频，或工具与系统操作 | 智能体每次回复前的停顿 | 每一轮都有停顿，指向线路。只有需要查询的那几轮才停顿，指向工具。 |
| 没人说话，智能体却话说一半就停下 | 线路与音频 | 每次中断，都对照录音 | 它被车流声、机器声或自己的回声打断。 |
| 客户不得不把话重复一遍 | 语音识别 | 客户第一次说时的转写文本，对照音频 | 录音里说得很清楚，转写文本却是错的或空的。 |
| 智能体回答了一个没人问过的问题 | 语音识别 | 识别出的文字，对照智能体刚问的问题 | 转写文本里有一句客户从没说过的话，智能体还回答了它。如果转写文本没错，指向决策层。 |
| 姓名、产品编码或地址识别有误 | 语音识别 | 同一批词在多通电话中的识别结果 | 不同客户说同一个词，识别出来都是同样的错误写法。 |
| 回答得很笃定，内容却是错的或已过时 | 知识 | 答案出自哪份资料，资料是什么时候的 | 智能体的资料本身有错或已过时。如果过时的是您自己系统里的数据，则归业务侧关口。 |
| 常见问题却回答“我没有这方面的信息” | 知识 | 智能体的资料里有没有这个话题 | 这个问题在真实通话中经常出现，资料里却没有。 |
| 客户已经说过的信息，智能体又问一遍 | 决策 | 客户作答的那一轮 | 转写文本没错，智能体下一轮却没有理会。 |
| 接电话的不是要找的人，脚本却照常往下走 | 决策 | 流程如何应对会计、家人或其他部门接听的情况 | 智能体不问该找谁，而是一直问这个人答不上来的问题。 |
| 智能体说已经预约好了，CRM 里却什么都没有 | 工具与系统操作 | 那一轮的工具日志：请求、响应、记录 ID | 返回的是报错，或者没有记录 ID，智能体照样告诉客户已经办好。如果根本没有发出请求，指向决策层。 |
| 转接之后，同事让客户从头再说一遍 | 转人工 | 转接那一刻，同事看到了什么 | 没有摘要，或者同事接起电话后摘要才到。 |
| 通话结尾，客户话没说完就被挂断 | 决策 | 谁挂断了电话，客户的最后一句话是什么 | 客户还没道别，智能体就挂断了。如果双方都没挂断，通话却断了，指向线路。 |
| 数据看板显示已解决，客户投诉却说没解决 | 结果统计 | 抽查标为已解决的通话，对照结果定义 | 这些通话并没有达到约定的结果，或者其实是语音信箱。 |
每通失败通话只计一次，记在首个断点
DRING 就是这样分析失败通话的。每通失败通话按顺序走过各层，只打一个标签：最先出问题的那一层，也就是它的首个断点。一句话听错，导致回复出错，接着预约失败，这算一次语音识别断点，不是三个问题。
每通电话只记一个值，各层的计数加起来，正好等于失败通话的总数。计数最大的那一层，就是修一处能挽回最多通话的地方。
另一种常见做法，是哪里出现症状，就在哪里打标签。按这种算法，下面示例中的 200 通失败通话一共打了 355 个标签。决策层拿到的标签最多，有 104 个，因为一句话听错，下一句回复通常也会跟着出错。可是首个断点在决策层的，只有 40 通。症状标签彼此重叠，总数和失败通话数对不上，还会让每一层看起来都很紧急。需要的话可以单独列出，但修复的先后要按首个断点来排。
本节的数字是为本文编写的示例，不是来自真实项目的数据。
| 最先出问题的层 | 失败通话（通） | 占比 |
|---|---|---|
| 语音识别 | 62 | 31% |
| 决策 | 40 | 20% |
| 工具与系统操作 | 24 | 12% |
| 业务侧，不是 AI 缺陷 | 22 | 11% |
| 线路与音频 | 18 | 9% |
| 知识 | 14 | 7% |
| 转人工 | 12 | 6% |
| 结果统计 | 8 | 4% |
| 合计 | 200 | 100% |
在这个示例中，应该先处理的是语音识别：200 通里有 62 通的首个断点在这一层。业务侧的 22 通不是 AI 缺陷。智能体再怎么改，也变不出空余时段，也修正不了您自己系统里过时的价目表。
语音识别出错，多半要在决策层修
首个断点说明的是通话在哪里偏离了方向，不一定是该在哪里修。在电话线路上，很多识别错误没法在语音识别层解决：音频经过压缩，叉车的声音可能比人声还大。即使识别出的文字有错，对话也不能跑偏，这部分工作要在决策层完成：
- 对不上的话，不接。识别出的文字和智能体刚问的问题对不上时，智能体不据此行动，也不另起话题，而是说明自己没听清，请对方再说一遍。
- 维护一张常见误识别清单。真实通话中经常识别错的词记进清单，遇到这些词，智能体提问确认，而不是靠猜。
- 用好系统数据。订单或记录已经查到时，智能体把内容复述一遍，再问“是这一个吗？”
- 热词表最后再加。把人名和产品术语做成热词表，是成本很低的识别设置，但要排在上面三步之后。
下面是为本文编写的示例，不是真实通话：同一句话听错了，两种处理方式。
| 说话方 | 说了什么 |
|---|---|
| 智能体 | “您的订单周四上午九点到十二点之间送到，这个时间您方便吗？” |
| 客户（正在开车） | “行，周四可以。能放快递柜吗？” |
| 语音识别听到的 | “行，周四可以。能把快递退了吗？” |
| 智能体（处理不当） | “好的，已经帮您把订单取消了。请问还有什么可以帮您？” |
| 智能体（处理得当） | “好的，那就定在周四。不好意思，后半句我没听清，您能再说一遍吗？” |
| 客户 | “我要是不在家，能放快递柜吗？” |
| 智能体 | “没问题。周四上午九点到十二点之间送到，您要是不在家，就给您放快递柜。” |
第一种回复因为一次识别错误，直接把订单取消了。第二种保留对得上的部分，没听清的再问一遍。想深入了解这一层，可以阅读语音 AI 如何纠正听错的内容。
工具与转人工，以日志为准
智能体说“您的预约已经办好了”，产生的只是一句话，不是一条预约。每个操作都要查工具日志：请求发出去了吗？返回了什么？有没有记录 ID？只有收到成功的响应，智能体才应该确认操作已完成。一通电话结束后应该留下什么，可以参考我们的 CRM 结果回写指南。
转人工出问题，同样悄无声息。电话转过去了，摘要却来晚了，或者根本没到。每次转接后，听一听最开始的几秒。如果同事还得问客户打来有什么事，这次转人工就是失败的。上下文应该包含哪些内容，请看如何设计转人工。
通话结尾，看有没有道别
很多流程设了计时器，时间一到就挂断，或者事情一办完就挂。在真实通话中，客户可能正在提问或道谢，话说到一半就被挂断了。智能体应该先听到客户道别，再挂断电话。
凡是由智能体挂断的通话，都看一下挂断前客户说的最后一句话：里面有没有道别？没有道别的通话所占的比例，就是您的提前挂断率，它归决策层。
一次只修一层
按首个断点统计的那张表，决定了修复的先后顺序：
- 选计数最大的 AI 层。业务侧关口交给对应流程的负责人。
- 针对这批通话，只改一处。如果是语音识别断点，这处修改通常要在决策层做，上文已经讲过。同时改两处，就分不清是哪一处起了作用。
- 把同一批失败通话重跑一遍。它们现在就是您的回归测试集：客户的台词不变，能做到的话，音频条件也保持一致。
- 对比修改前后的首个断点计数，而且要在同类话务上比：同一个外呼任务、同类名单或同样的呼入时段。换一批更好打的名单，什么改动看起来都有效。
有些通话不会消失，而是换个地方出问题。一通电话现在过了语音识别，可能会在后面的工具层断掉。这其实是进展：下一处该修的地方露出来了。Agent Factory 是 DRING 搭建、测试和改进智能体的方式，也遵循同样的规则：一次只改一处，测试通过后才发布。
DRING 能帮上什么
如果某个已上线的流程表现不佳，可以申请一次回电，专门聊聊它。提前准备一批失败通话样本，在公司规定允许的前提下附上录音，并写明每通电话本该达到的结果。我们的团队可以按本文的方法和您一起逐通梳理，看看每一通最先断在哪里。
涉及您自有系统的改动，单独评估范围。智能体能在 CRM 里执行哪些操作，取决于 CRM 的版本、权限，以及是否开放 API 访问。在 DRING 上，可以定义额外的分析字段，并通过 API、CRM、数据看板和报表返回。“最先出问题的层”就可以是其中一个字段。
DRING 搭建的每个智能体，在接第一通真实电话之前，都会跑 1,000 至 10,000 次专为您企业生成的模拟对话。模拟仍会有遗漏，真实通话会把它们暴露出来，所以上线后的优化要从真实客户的通话开始。