我们的语音代理p99为280ms，竞争对手为450ms，但用户却觉得我们的更慢。我们测量了原因。

上个季度将语音代理部署到生产环境。仪表盘显示我们比所有列出的竞争对手都快。p99端到端延迟为280ms。最大竞争对手为450ms。我们确实更快。用户研究小组却反馈我们的代理感觉更慢。在5点李克特量表上相差8个百分点，具有统计显著性。经过两周调查，我们发现用户小组衡量的是打断时间，而非延迟。打断时间是指用户开始插话到代理停止说话之间的时间。端到端时钟衡量代理的响应时间。打断时钟衡量的是用户想要控制对话时的实际等待时间。两者数值不同。我们的端到端延迟是280ms，打断时间为380ms，竞争对手只有60ms。我们的测量方法：1. 从之前的支持通话中提取500次打断尝试的合成语料库，将每个样本输入代理副本，测量从第一个音节到代理停止的时间。2. 生产流水线中的OTel跨度：一个跨度标记VAD触发，另一个标记TTS中断，两者相减。两种方法：合成语料用于A/B测试，生产数据用于实际分布。我们的打断响应率在100ms阈值为41%，250ms时达到89%，但250ms对于响应感来说太慢了。修复措施有三项：1. 将音频缓冲区页面锁定在内存中。使用libc::mlock锁定缓冲区。当模型权重活跃时，音频页面偶尔会换页到交换空间，导致检测延迟150ms。锁定后，VAD在25ms内捕捉到语音。2. VAD阈值调整。默认值为0.6，测试范围0.4到0.65，0.5最佳。检测提前4%，误报仅增加1.2%。3. TTS中断路径。我们的TTS以200ms块流式传输。当VAD触发时，音频队列仍会播放400ms的缓冲块。我们将块大小降至30ms，并在VAD触发时立即清空队列。网络开销增加，但值得。四周的工作后，100ms阈值下的打断响应率从41%提升至89%。p99延迟实际上略有上升（280ms到305ms），因为TTS块变小了。仪表盘数据变差了，但用户表示我们的代理现在比竞争对手（450ms）感觉更快。关键的心态转变是：语音代理延迟是仪表盘数字，而打断响应率是用户数字。一旦同时测量两者，仪表盘就成为调试工具，用户指标成为产品KPI。好奇其他团队是如何分别测量用户实际体验与仪表盘报告数据的。