上线了一款面向金融科技的印地语-英语语音代理：所有踩过的坑以及真正有效的修复

写这篇文章是因为半年前我开始构建这个项目时，网上几乎找不到关于印度语言语音代理的有用内容。一切都是以美国为中心的。所以这是真正的事后复盘。背景：一个金融科技的语音代理，处理付款提醒、KYC 跟进、基本账户查询。使用印地语-英语混合，因为我们的用户真实说话就是这样。不是大都市英语，也不是纯印地语，而是真正的混合。我以为最难的部分：LLM 理解 Hinglish 的意图。真正难的部分：让代理以听起来不破碎的方式回话。出问题的环节，大致按带来的痛苦程度排序：1. 数字、数字、数字。这是金融科技，所以每一次通话都要回读一个金额、一个日期、一个账户参考号、一个 OTP 样式的号码。早期，代理会在一个印地语句子中间冒出一整段刺耳的纯英语说“aapka due amount hai one thousand four hundred ninety nine rupees”，或者更糟，把参考号读成一个巨大的单个数，而不是逐位读出。仅这一点就让我们的第一次试点彻底失败。用户觉得困惑并且有点不可信，这在金融科技中是致命的。2. 语言切换时的卡顿。很多 TTS 在印地语↔英语边界会明显停顿或改变口音。在涉及用户金钱的通话中，任何怪异之处都会被理解为“这是一个骗人的机器人”，人们就会挂断。3. 延迟，但具体是通话窗口负载下的延迟。我们把外呼提醒分批放在人们真正接听的时间段。每个提供商的单次通话延迟看起来都很好。但当我们达到真实并发时，一家提供商的延迟开始飙到 800 毫秒以上，通话感觉像死了一样。要在你自己的真实并发下测量，演示数字是骗人的。4. 合规性，显然。金融科技。与印度央行（RBI）相关的严密审查、数据驻留问题、企业合作伙伴的 SOC 2 要求。几个本来不错的选项直接被淘汰了。真正解决问题的是什么？老实说，是换了一个将印度语码混合和数字规范化当作一等公民而不是事后才考虑的 TTS，并且通过真实的电话线路在真实并发下测试一切，而不是在浏览器标签页里测试。当数字回读变得干净的那一刻（“aapka payment 15 tarikh tak, 2,340 rupees, reference number 4 8 2 9 1”），试点的数据完全改变了。信任度上升，通话完成率上升。我不想把这变成广告，如果大家愿意，我很乐意在评论区分享细节。但元教训是：对于印度语音代理，停止评估“哪个声音最好听”，开始评估“它能否通过电话线路、在规模化场景下，正确说出一个印地语-英语句子中的金额、日期和参考号”。这才是真正的工作。有任何问题尽管问我，我花了太长时间才弄明白，我宁愿你们跳过这些痛苦。