我的语音助手本来很智能,直到一个电话号码被转录错误。
摘要
本文认为,语音助手的语音转文字(STT)应该根据实体准确性(例如电话号码、日期)来评估,而不是一般的词错误率,因为遗漏关键字段可能会破坏工作流程。文章提到使用HubSpot字段进行测试,并指出Smallest AI Pulse是一个有趣的工具,可以实时捕获工作流关键实体。
这个代理听起来不错。自然的声音。良好的提示。不错的交接逻辑。CRM更新成功了。日历集成也成功了。然后它把一个电话号码听错了,整个东西就变得没用了。这时我意识到,语音代理的语音转文字(STT)不应该像普通转录那样评判。转录可能“大部分正确”,但仍然无法完成工作流程。对于语音代理来说,这些词比其他词更重要:电话号码、预约时间、日期、姓名、电子邮件地址、价格、地址、订单ID、“不要”、“不”、“实际上”、“等等”、“不,我是说……”。这些是改变行动的词。我现在正在用HubSpot字段测试这一点,而不是仅仅转录准确性。示例记分卡:电话号码字段匹配了吗?预约日期匹配了吗?代理捕捉到更正了吗?它要求确认了吗?CRM仅在确认后更新了吗?转录保留了否定词吗?Smallest AI Pulse对我来说很有趣,因为我评估的不是“它能否写出漂亮的转录?”而是评估一个实时的STT层是否能在通话进行中捕获工作流关键实体。对于AI语音代理,我认为实体准确性应该有自己的基准。不是WER。不是感觉。系统是否捕获了重要的字段?
相似文章
语音代理的最佳STT API?我会先测试延迟再测试准确性
作者认为,对于实时语音代理,STT延迟和实时行为比原始转录准确性更为关键,并提出了不同的评估记分卡。
我分析了10000通语音AI电话,其中40%存在类似问题
对10,000通语音AI电话的分析揭示了关键失败点:STT错误率、前8秒混乱、中断处理、长时间静默、工具调用延迟、LLM故障以及转接失败——为代理构建者提供了实用见解。
你在生产环境的语音智能体中使用什么 STT API?最先出问题的是什么?
一位开发者询问人们在生产环境的语音智能体中使用哪些 STT API,比较了 Deepgram、AssemblyAI 和 Smallest AI Pulse,并指出了常见的故障点,如端点检测、延迟和打断。
在选择STT API之前,先对真正会影响用户的转录错误进行优先级排序。
一份关于评估语音转文本API的指南,通过根据转录错误对用户的实际影响进行排序,而不是仅看原始准确率指标。
@svpino:为什么这么多AI电话智能体在你打断它们之前听起来很聪明?即使这些智能体给出合理……
Deepgram发布了Flux TTS,一种流式、对话原生的文本转语音模型,能跨对话轮次保留语气、节奏和上下文,处理打断,并实现低至80ms的延迟,让语音AI感觉更自然。