Voice Agent的Transcript可能全是错的：一条Pipeline为何让转录失真

在语音交互系统的评估体系里，Word Error Rate（WER）几乎是衡量转录质量的唯一标尺。行业默认的逻辑是：ASR识别准，Transcript就可靠。但Zian AI于9月发布的一份技术审计报告打破了这一假设——对Pipecat、LiveKit、ElevenLabs、AssemblyAI等主流Voice Agent工具的公开issue与changelog进行系统梳理后，共识别出11种Transcript与真实通话发生偏差的机制，其中10种与ASR无关。这意味着，当开发者发现转录结果与用户实际听到的内容不符时，问题很可能不在声学模型的字错误率，而在整条实时Pipeline的设计缺陷。

打断是Voice Agent Transcript失真最典型的触发场景。当用户在中途打断Agent输出时，系统面临的不是简单的语音识别问题，而是一道状态同步题：用户真正听到的是TTS已经播放的部分，但Transcript记录的很可能是LLM已经生成的完整文本。Pipecat的公开issue记录了具体案例：当TTS Provider未返回词级时间戳时，完整生成文本在合成阶段被直接提交进Transcript，即使后续音频实际上并未播放。提交者对179通电话的复查发现，有18通保存了不可能完整播出的最后一句回复。这个比例虽然不代表行业均值，但它证明了这一问题的真实存在。问题本质是：模型生成过与用户听见过，是两个需要独立追踪的状态。

打断场景下的幽灵台词

在文本交互中，模型输出与用户所见几乎同步。但在Voice Agent中，系统实际同时运行着三条时间线：文本时间线（LLM已生成的内容）、音频时间线（TTS实际合成和播放的内容）、记录时间线（Aggregator最终写入Transcript的事件）。正常通话时三者表面一致，所以Transcript常被当作Ground Truth。但当打断、重试、Tool Call、TTS故障或Session Close发生时，三条线的缝隙立刻暴露。ElevenLabs在iOS SDK v3.3.1中修复的一个典型问题就与此相关：Agent消息原本按event_id而非response_id对齐，在Tool Call前后存在多个response时，streaming text或correction可能被挂到错误的message上。这意味着Transcript偏差不仅有量的差异，还可能有质的错位——一句话生成了没播出来，或播出了没被写入，或被挂到了错误的对话轮次。

三条时间线的同时失配

从产业实践来看，Transcript偏差的真正危险在于它正在被大量下游系统当作可信基准。客服质检读取Transcript进行服务质量评估，Agent Eval依赖Transcript计算意图识别率和槽位填充率，会话总结直接从Transcript抽取关键信息，训练数据回流也可能直接从Transcript抽取样本。这形成了一个隐蔽的闭环：如果Transcript里包含用户没听见的Agent回复，质检会误判已提供了信息；如果Transcript遗漏了实际播出的内容，评测会误判为漏答。在Voice Agent评测越来越偏向任务完成率、意图准确率和自动Judge机制的当下，Transcript作为基础数据的可靠性直接决定了评估结论的有效性。更关键的是，OpenAI的Realtime API文档和LiveKit的设计都指向同一个事实：在实时语音场景中，Playback本身已经是Conversation State的一部分，系统必须根据真实播放位置截断对话历史，而不是按模型已生成的文本量来计算。

Pipeline失配的生产风险

面对这一挑战，技术审计报告给出的建议相当朴素：获取真实通话的双通道录音，逐句与Transcript做read-back检查，确认是否存在文字存在但无对应音频、音频存在但无文字、重复内容或说话人错位等问题，从最近20通电话开始积累数据。这套方法虽然原始，但揭示了当前Voice Agent可观测性（observability）体系中的一个显著空位——行业已建立对WER、TTFT、End-of-Turn、Interrupt Latency等指标的完整测试规范，却缺少对最终保存的Transcript与真实音频一致性的独立校验机制。如果Transcript要继续承担Eval、质检、训练数据和会话记忆的基础数据角色，它首先需要回答的不是识别准确率有多高，而是另一个更根本的问题：这里的每一句话，用户真正说过，或者真正听见过吗？这个看似简单的问题，或许是Voice Agent从Demo走向生产环境后，最值得关注的数据质量指标之一。