语音AI上线后才知道的静音问题

Voice AI 的演示听起来总是完美的，因为演示环境下的网络是完美的。一旦你把一个呼叫机器人部署到真实的 GSM 网络上，处理来自真实手机在真实信号条件下的真实呼叫，就会出现一整类在受控测试环境中从未出现过的故障类型，而这些故障实际上与 AI 的智能完全无关。

与模型无关的鸿沟

每个语音 AI 系统都假设存在一个合理连续的音频流。模型接收语音、处理语音、给出回应。这个假设在测试中站得住脚，因为连接稳定、环境可控。但一旦真实的 GSM 网络条件进入画面——丢包、短暂的连接不稳定、实时通话中后端查询比预期更慢、真实流量下偶尔卡顿的数据库查询——这个假设就崩溃了。

这些都不是传统意义上的 AI 问题。它们是基础设施的现实，而 AI 层仍然需要优雅地处理它们，因为在呼叫者看来，模型在思考和网络在卡顿之间没有任何区别。两者产生相同的体验——电话那头没有声音——而在人类眼中，电话里的沉默与文字聊天中的沉默有着截然不同的含义。文字对话中几秒钟的停顿不值一提。而同样的停顿在实时通话中让人感觉线路断了，而呼叫者对这种不确定性的反应是挂断电话、重复说话、或明显表现出沮丧，这些实际上都与最终答案是否正确无关。

把死寂变成听起来有意图的东西

解决办法不是让后端查询更快，尽管那也很重要。解决办法是接受某些延迟是不可避免的，需要用某些东西来填充，让呼叫者保持在对话中，而不是疑惑是否还有任何事情在发生。

系统 prompt 围绕显式的确认短语构建，这些短语在已知延迟条件下被触发——地理定位查询比预期多花了一点时间、数据库确认步骤运行稍慢。不是让模型在后端进程完成时简单沉默，而是指示它用语言来填补这个间隙，比如"Let me check that and confirm for you, one moment please"这样的表述，然后在结果返回后自然地给出结束的确认："appreciate your patience"，一旦信息准备好交付。

这听起来像是一个小的、几乎微不足道的添加。实际上，它改变了整个交互的感觉。一个在停顿中听到主动确认的呼叫者会把停顿解读为系统在工作。同样的停顿中什么都听不到的呼叫者会把它解读为系统故障。两者的底层延迟往往是相同的。只有呼叫者的解读变了，而正是这个解读决定了他们是平静地留在通话中，还是出于焦虑开始重复说话。

让这些 bridging phrases 的时机正确需要真正的迭代。太早，确认会在呼叫者甚至注意到间隙之前就触发，读起来显得奇怪的犹豫。太晚，呼叫者在安慰到来之前就已经开始担心了。指令集需要一个相当具体的阈值，与每个已知易延迟操作的实际预期持续时间相关联，而不是在所有地方应用一个单一的通用超时。

当转录本身反过来伤害你

一个独立且真正更难的问题出现在通话转录质量方面。实时 GSM 音频偶尔会产生部分乱码成碎片的转录文本，读起来像是完全不同的语言——有时是真实的外语干扰，有时只是转录层误读为属于另一种语言模型的语音噪音。一个把损坏的转录文本当作可靠输入的机器人会自信地把无意义的内容当作真实用户话语来处理，这会产生正是那种最快侵蚀呼叫者信任的不可预测、听起来错误的回应。

处理这个问题意味着在系统如何对待传入转录的方式中构建显式的低置信度检测，而不是假设每个转录都是同等可信的输入。当转录回来看起来是碎片化的、与通话的预期语言不一致、或者相对于会话上下文简直毫无意义时，指令集把这种情况当作请求澄清的信号，而不是尝试从损坏的输入中进行推理，简单到就像这样："I want to make sure I understood that correctly, could you repeat that for me"。这单一的 fallback 在保护通话质量方面比任何试图提高转录本身准确性的努力都更有效，因为它接受了某些转录失败就是会发生，并为这种现实构建了一条优雅的恢复路径，而不是假装输入层总是干净的。

不问呼叫者任何问题就解决地理定位

第三个反复出现的问题涉及地理定位——某些通话流程需要它来路由或个性化回应，但在相当多真实通话条件下直接获取是不可靠的。不是构建一个打断对话来显式询问呼叫者他们从哪里打来的流程——这会增加摩擦，在本来自然的通话中间感觉像一个奇怪的问题——更优雅的解决办法是利用呼叫者电话号码中已经存在的国际拨号前缀。几乎每个来电号码前面的国家代码本身就携带了足够的信号来推断一般位置背景，而不需要任何额外的问题或完全打断对话的流程。

这个修复是一个在这类工作中经常出现的模式的很好的例子——缺失数据问题的最佳解决方案往往不是直接要求用户提供缺失的数据，而是找到你已经可以访问的一条信息来替代它，而让呼叫者根本不会注意到最初存在过间隙。

让语音 AI 系统感觉可靠的一个有意义的部分与底层模型有多智能关系不大，而与系统如何优雅地处理真实电话网络的混乱、不可预测的条件关系更大——真实后端延迟时的死寂、损坏的转录、缺失的位置数据。这些都不是通过更智能的模型就能解决的。它们是通过把系统 prompt 视为不仅对一切正常工作时机器人说什么负责，而且对在其下层管道中某些东西不工作时的具体时刻它说什么和做什么负责来解决的。

有关具体客户部署和网络基础设施的详细信息，因此类工作的性质保密。乐意通过适当渠道与构建类似呼叫机器人系统的任何人讨论处理现实世界语音 AI 可靠性问题的一般方法。

Written by Mohammad Farhan Habib Faraz Senior Prompt Engineer and Prompt Team Lead at PowerinAI www.powerinai.com