语音代理的最佳STT API？我会先测试延迟再测试准确性
摘要
作者认为，对于实时语音代理，STT延迟和实时行为比原始转录准确性更为关键，并提出了不同的评估记分卡。
我曾以为“语音代理的最佳STT”问题意味着：哪个STT的转录准确性最高？现在我不这么认为了。对于实时代理，即使转录技术上是准确的，但如果来得太晚或不断变化，依然会破坏通话。用户并不关心你的WER有多好。他们感受到的是：“为什么机器人停顿了？”“为什么它在我还没说完就回答了？”“为什么它没注意到我纠正的数字？”“为什么它打断我说话？”因此，我现在的测试不再是“哪个STT最准确？”，而是：代理的其余部分能否安全地以足够快的速度使用文本？我尝试使用LiveKit + Langfuse的设置来记录每一个回合：用户开始说话 → 第一个转录片段 → 可用的转录 → LLM开始回复 → 工具调用 → 语音开始 → 用户打断 → 代理闭嘴。Smallest AI Pulse在我的候选名单上有一个特定原因：我不想把它当作文件转录工具来评估。我想看它是否像一个实时监听层一样为语音代理工作。对于这个用例，我的记分卡将是：第一个可用文本、最终转录延迟、部分重写混乱、端点检测、打断行为、电话音频、名字/数字/日期、95百分位的回合延迟。准确性当然仍然重要。但对于语音代理，延迟决定了整个过程是感觉生动还是虚假。还有别人也是这样衡量STT的吗？
相似文章
为服务型企业运行生产级语音代理6个月：延迟计算远比演示所暗示的复杂。
在为服务型企业运行语音AI代理6个月后，作者揭示了现实世界中的延迟是双峰的（中位数约800ms，p95约2.4s），而p95决定了用户的感知。诸如VAD误触发、长提示词下函数调用退化、以及TTS质量等问题比LLM的选择更重要，而多语言支持则增加了显著的成本。
你的语音助手响应慢可能不是因为大语言模型。
一位开发者驳斥了常见的观点，即LLM延迟是语音助手响应慢的主要原因，并解释说，延迟往往源于更早的阶段，如音频捕获、语音活动检测（VAD）和语音转文字（STT）。他建议记录特定的延迟指标，并测试不同的STT/TTS提供商和编排框架来诊断问题。
@svpino：我为两家不同的公司构建了两个语音管道。它们看起来都是这样的：音频 → STT → 清理转录 → ……
Santiago 指出了传统 STT 管道在丢失语调和情感方面的局限性，然后介绍了 Modulate 公司的 Velma，这是一个原生语音 AI 模型，通过分析原始音频来捕捉意图、情感及其他声学信号，通过 API 获取，其成本比基于 LLM 的方法便宜 10 倍。
我们的语音代理p99为280ms，竞争对手为450ms，但用户却觉得我们的更慢。我们测量了原因。
一个语音代理团队发现，尽管端到端延迟更低（280ms对比竞争对手的450ms），但由于糟糕的打断响应时间（380ms对比60ms），用户感知更慢。他们确定了三项修复措施——内存锁定、VAD阈值调整和更小的TTS块——将100ms阈值下的打断率从41%提升至89%，让用户感觉更快。
在构建 AI 辅导系统时，延迟比模型选择更重要
一位从业者认为，在 AI 辅导系统中，语音启动延迟才是关键因素，而非模型的选择。他建议将语音启动延迟控制在 1 秒以内，并强调流式 TTS 是优化效果最显著的手段。文章梳理了从 ASR 到 TTS 再到虚拟形象同步的完整处理链路，并指出延迟叠加最严重的环节。