我们的语音智能体正确填写了 CRM 中的所有字段,但没有一笔付款成功。
摘要
一个团队发现,他们的语音智能体一直在自信地向 CRM 字段填入错误的值(听错的账号、凭空编造的姓名),导致付款失败。他们描述了通过添加验证层来解决这一问题的变通方法,同时质疑为什么不在语音模型内部直接进行实体提取。
我们的语音智能体在打催收电话时,几乎所有内容的置信度都超过了90%,但后来运营团队有人随机抽了一批CRM记录,听了实际的录音,结果糟糕透了。智能体记录账号时弄错了一位数字,置信度却依然很高,因为模型对自己听到的内容很有信心,只不过它听错了。比如客户说“十五二十”,意思是1520,模型却把它记成了两个独立字段。客户报姓名时,模型就挑一个发音相近的常见名字,因为它不确定的时候就是这么干的:选概率最高的词,而不是正确的词。而且下游没有任何环节能发现问题,因为CRM里的记录看起来没毛病。三天后付款失败了,因为账号不对,但没人追查到智能体头上,而我们居然还在庆祝字段填写率,明明一半字段都是错的,笑死。现在我们在智能体和CRM之间加了一层校验:IFSC代码用正则表达式匹配,账号检查长度和校验和,姓名的字符级置信度低于阈值就暂缓录入,另外,任何校验不通过的内容都会在来电者还在线时转交人工处理,而不是等三天后付款失败才发现。不过,这样每个字段会多花大约一秒,而在催收电话里,对方本来就已经很恼火了,这一秒可不是无关紧要的。我们现在可能也只能发现70%的错误记录,因为有些错误值的格式是有效的,只是碰巧属于别人,这种情况什么校验都查不出来。我们是在给一个本该在模型层面解决的问题打补丁,而不是从根源上修好它。gnani和另外几家直接在语音技术栈内部做实体提取,而不是先转写再校验,这样就能绕过这一整摊麻烦,但我也不知道有谁在这么做??
相似文章
我的语音助手本来很智能,直到一个电话号码被转录错误。
本文认为,语音助手的语音转文字(STT)应该根据实体准确性(例如电话号码、日期)来评估,而不是一般的词错误率,因为遗漏关键字段可能会破坏工作流程。文章提到使用HubSpot字段进行测试,并指出Smallest AI Pulse是一个有趣的工具,可以实时捕获工作流关键实体。
一旦我们进行真实通话测试,两个 AI 语音智能体在合规方面就彻底失灵了
一位从业者称,两个 AI 语音智能体在演示中表现合格,却在真实的金融服务通话中出了问题——一个编造了一项费用,另一个在被打断时跳过了必须告知的事项。经受住考验的智能体采用了锁定且必须执行的工作流程步骤;这篇帖子询问其他人如何在上线前测试此类合规问题。
我们的语音智能体编造了一个送货日期,然后连续三个回合都坚持这个说法。
一位从业者描述了他们的 AI 语音智能体如何凭空编造了一个交付日期,并在自身输出不断累积到上下文中时,在多轮对话里愈发坚持这一说法;还介绍了如何通过将工具返回的事实与智能体自身的发言分开,比提示模型将自己的回答视为暂定结论更可靠地解决了这一问题。
上线了一款面向金融科技的印地语-英语语音代理:所有踩过的坑以及真正有效的修复
一位开发者分享了为金融科技构建印地语-英语语音代理的事后复盘,重点介绍了数字回读、语码混合TTS、负载下的延迟和合规性等挑战。关键的修复是选择对印度语码混合有一流支持的TTS,并在真实并发条件下进行测试。
扩展语音代理在各个层面都会在不同位置出现问题——这里有一个通常首先限制你的因素
本文探讨了扩展语音代理时面临的挑战,指出问题会出现在不同层面,并找出了通常最先限制性能的瓶颈。