语音 AI 追求极致低延迟其实是个陷阱，如何平衡响应速度与对话自然度

在开发语音 AI Agent 时，很多工程师最执着的指标就是端到端延迟（Latency）。大家习惯性地认为，响应速度越快，用户体验就越好。但我在构建一个基于 Pipecat、LiveKit、Deepgram 和 Cartesia 组合的销售培训平台时，发现了一个非常反直觉的结论：如果响应速度过快，反而会放大端点检测（Endpointing）的错误，让 AI 变成一个没礼貌的“插话王”。

这种情况在实际生产环境中非常典型。当时我将系统的 p95 延迟压到了 880ms 左右，从技术指标上看，这已经达到了极其流畅的标准。但实测结果却很糟糕：只要用户在说话过程中稍微停顿 0.5 秒思考，AI 就会立刻判定用户已经说完了，然后迅速抢话。

这种现象揭示了一个核心矛盾：速度并不是免费的，它实际上放大了端点检测的容错成本。如果 pipeline 稍微慢一点，这种由于停顿导致的误判反而会被自然掩盖——因为当 AI 准备好说话时，用户可能已经继续说话了，此时触发打断机制（Barge-in）能够实现无缝衔接，用户感知不到 AI 曾经想插话。而当响应速度快到极致时，AI 的抢话行为会变得极其突兀。

为了解决这个“抢话”问题，我在生产环境进行了 A/B 测试，通过调整端点检测参数来增加 AI 的“聆听耐心”。具体操作是将 Eager end-of-turn 从 on (0.35) 改为 off，并将 VOICE_EOT_THRESHOLD 从 0.5 提高到 0.7，同时将 VOICE_EOT_TIMEOUT_MS 从 700ms 延长到了 1200ms。

调整后的结果非常明显，AI 不再频繁地打断用户。虽然整体响应时间往后推了大约半秒，但从用户心理感知来看，这不再被定义为“延迟”，而像是一个自然的对话停顿。这给了我一个深刻的实战经验：在优化语音 Agent 时，必须将“处理延迟”与“聆听耐心”这两个概念完全分开看待。处理延迟（即从确认用户说话结束到首字节音频发出）确实需要严格控制在 1 秒以内，但“聆听耐心”（等待用户说完的缓冲时间）应该是故意设计的交互逻辑，而不应该被算在延迟预算里。

另外，在衡量延迟指标时，很多团队容易掉进 p50（中位数）的陷阱。p50 在做 Demo 演示时非常好看，但在生产环境中几乎没有参考价值。真正决定用户是否觉得对话“卡顿”或“诡异”的决定性指标是 p95，因为长尾延迟才是导致用户体验崩塌的元凶。

如果你既想保持端点检测的稳定性，又想降低体感延迟，可以尝试优化首包发送逻辑。不需要等待 LLM 生成整个句子，只要缓冲区积累了 4-8 个 token，就立即将其发送给 TTS 引擎。

用伪代码逻辑来表达就是：

if current_tokens >= 4 and not first_chunk_sent:
    send_to_tts(buffer)
    first_chunk_sent = True

这种分块（chunking）处理方式能有效降低首字节响应时间，从而在不牺牲端点检测稳定性的前提下，提升整体的流畅感。