AI语音拟人对话研究：断点续传率为什么比打断检测率更能说明恢复质量

一次典型的企业客服电话中，用户打断AI后发生了什么，往往比"AI有没有停下来"更说明问题。

想象这样一个场景：AI在采集报修信息，用户说了手机号和故障描述，AI正在追问地址。用户打断："等一下，我把门牌号翻出来。"AI正确检测到打断，停止播报。两秒后用户说："好了，3栋502。"AI恢复播报："好的，请问您的手机号是多少？"

这里的打断检测是成功的——AI停下来了，也听完用户说话了。但恢复是失败的——系统回退到了采集流程的起点，刚才已经确认过的手机号被丢弃了。用户的体验是什么？"这个AI刚才不是已经问我手机号了吗，怎么又问一遍。"

打断检测率衡量的是"检测到了吗"，断点续传率衡量的是"恢复对了吗"。二者之间隔着一整层状态保存和恢复逻辑，不能相互替代。

本文讨论的指标定义和评测方法，主要参考了IHBench（Interruption Handling Benchmark），一个专门针对语音Agent打断后恢复质量的开源基准测试。它覆盖10个企业领域中的结构化工作流场景，在对话中部注入六种打断类型，评估27个语音模型配置（含GPT Realtime、Gemini、开源模型等），从任务推进和恢复质量两个维度打分，并通过人类标注验证了LLM评分的可靠性。相比更侧重打断检测时机的基准（如Full-Duplex-Bench），IHBench的设计重点恰好是"打断之后AI说了什么"——与本文关注的断点续传率高度一致。

一、三个核心指标

打断恢复时间

和普通轮次的端到端延迟不同，打断恢复时间包含了"处理打断内容→调整内部状态→决定恢复策略"三个额外步骤。不是越短越好——如果AI在500ms内恢复，很可能是直接清空了播报缓存继续讲原来的内容，并没有处理用户打断时说了什么。

恢复时间区间	典型表现	诊断方向
<500ms	恢复极快	检查是否在"停了又继续"，未处理打断内容
500–1500ms	有自然停顿感	体验舒适区间
>1500ms	停顿明显	检查是否出现处理滞后
>3000ms	用户可能重复或挂断	异常范围

断点续传率

衡量打断后业务流程是否从正确的位置继续。

断点续传率 = 打断后流程正确恢复的次数 / 打断总次数 × 100%

"流程正确恢复"的四个检查点：没有跳过用户补充的信息、没有重复用户已经听过的内容、没有遗漏已采集的业务数据、流程步骤编号没有回退或前跳。

IHBench对27个语音模型的评测中，filler类打断（用户"嗯""对""好的"等简短反馈）是最强的模型区分器。GPT系列模型在用户简单嗯哼后正确接续被打断句子的能力只有7%-31%，Gemini 2.5系列达到62%-68%。"继续刚说到一半的话"这种看似最简单的任务，对多数模型是最难的——因为模型需要判断"这是反馈不是新内容"，而大多数语音模型的训练数据中，这类标注很少。

该基准的另一个发现是：恢复质量和任务推进是部分独立的两个能力。任务推进得分最高的模型，恢复质量并非同样领先。这说明"能正常完成对话"和"能从打断中正确恢复"需要不同的能力组合，评测时不能相互替代。

假触发率

假触发率 = 非打断事件被误判为打断的次数 / 总非打断事件数 × 100%

假触发率和打断恢复时间之间存在取舍：阈值偏灵敏时恢复时间缩短但假触发率上升，反之亦然。PolyAI的结论是False Barge-in比Missed Barge-in更致命——AI被假打断后中断播报、电话出现空白，用户反而困惑；漏打断虽然体验差，但用户通常会再说一遍。行业参考将Barge-in Recovery >90%定为Good，80-90%为Warning，<80%为Critical。

二、四层评测数据采集

IHBench的评测发现，24/27个模型的任务推进能力随对话深度增加而下降，平均每增加一轮对话，任务推进胜率下降约3%。这意味着在中后段的对话中，打断恢复出问题的概率更高。评测不能只看单次打断的成功率，必须覆盖整通电话的恢复质量链。

数据层	采集内容	说明
事件层	打断发生时间、类型、触发位置	从通话日志和VAD事件流获取
回复层	恢复后首句内容、语音长度、语义相关性	从ASR转写和对话日志获取
流程层	恢复后步骤序号连续性、业务字段完整性	从流程执行日志获取
结果层	任务是否完成、是否转人工、是否重复来电	从通话结果和质检记录获取

四层之间不是累加关系，而是一个排障链路。当断点续传率低于预期时，可以按层回溯：先看流程层——是不是恢复后步骤回退了？如果回退了，再看回复层——恢复后的第一句话是什么？如果第一句话就没接上，再看事件层——这次打断属于哪种类型？系统是否误判了打断意图？排障路径越短，修复方向越明确。

三、评测落地不是一次性验收

IHBench的指标定义和采集方法是行业通用的，但在企业侧落地时面临一个约束：它不是一次测试能做完的。评测样本必须覆盖不同打断类型（正常补充、催促跳过、纠正信息、切换话题、嗯哼反馈、质疑反驳），分布在对话的不同轮次。全部用"能走通"的正向样本测出来的断点续传率，在真实生产环境中会明显偏高。

合力亿捷把通话Agent定位为可运营的数字员工而非一次性配置的工具，意味着打断恢复评测不是一个验收节点，而是一套需要持续观测的运营指标。MPaaS的运行日志覆盖事件层到流程层的完整时序，智能质检的录音分析可以从音频层回溯恢复前后的交互细节。当某类场景的断点续传率低于阈值时，Badcase分析按打断类型聚合失败样本，定位根因是打断检测问题、状态保存问题还是恢复策略问题——三条修复路径完全不同的。

搞反了修复路径的代价是真实的：如果丢流程的根因是状态保存机制——流程引擎在打断时刻没有快照当前状态——但修复方向却是调整VAD能量阈值，那断点续传率不会改善，假触发率反而可能变得更差。