为服务型企业运行生产级语音代理6个月：延迟计算远比演示所暗示的复杂。

过去6个月，我们一直在为餐厅和沙龙构建语音AI。想分享一些技术现实，与大家展示的“800ms延迟”演示不同。没人谈论的是：延迟是双峰的，而不是平均的。演示展示的是中位数延迟，而真实用户流失取决于p95。我们的中位数约800ms，p95为2.4秒。正是这个p95决定了代理听起来像人类还是有问题。它来自罕见的边缘情况：模型因格式错误的函数调用输出而重试、工具执行缓慢（通过慢速第三方API查询日历）、VAD在背景噪声下误触发。中断处理比对话本身更容易出问题。用户不断地打断代理。简单的VAD会把每次咳嗽或背景噪音都当作打断。我们最终采用了三层系统：VAD信号 + 语义检查（用户说的实际上是继续吗？）+ 声学能量阈值。但仍有约5%的错误率。函数调用的可靠性随提示词长度增加而下降。系统提示词低于1500个token时，函数调用准确率为96%；超过3000个token时，同一模型下降至84%。当你在一个提示词中塞入个性、业务规则和少量示例时，没人告诉你这些。TTS的选择比LLM的选择更影响感知质量。用户抱怨机器语音的次数比抱怨错误答案多10倍。将LLM从GPT-4换成Claude或Gemini，业务指标只变化了2%。而将TTS从通用换成ElevenLabs Flash，预约转化率提升了14%。多语言是万物的附加税。我们支持50多种语言。每种语言都需要：单独的TTS语音调优、单独的VAD校准（某些语言有更多齿擦音，会干扰VAD）、提示词中单独的少量示例。仅因为这些校准，俄语每次通话的成本比英语高出约40%。还有其他人运行生产级语音代理吗？好奇你们的p95是多少，以及如何处理多语言成本激增的问题。