
为自家文档打造高效语音智能体
- 分类
- 产品
- 日期
大多数应用对延迟要求不高,但对话式 AI 对延迟的要求决定了应用的优劣。
对话式 AI 的目标是让交流体验像真人对话一样自然,同时在智能上超越人类。要实现这一点,应用必须避免长时间的静默,否则就会失去真实感。
对话式 AI 的延迟挑战还在于其流程分散。它由多个前沿环节组成,每一步都会叠加延迟。
作为一家生成式语音公司,我们长期研究如何降低对话式 AI 的延迟。现在,希望分享我们的经验,帮助有兴趣开发对话式 AI 应用的用户。
每个对话式 AI 应用至少包含 4 个步骤:语音转文本、轮流控制、文本处理(如 LLM)、以及 文本转语音。这些步骤虽然可并行执行,但每一步都会带来一定延迟。
对话式 AI 的延迟计算方式很独特。许多流程的延迟通常由某个瓶颈决定,比如网站访问数据库时,网络延迟占主导。但对话式 AI 的各环节延迟差异不大,每一部分的延迟都不可忽视,因此总延迟是各环节之和。
系统的“耳朵”
自动语音识别(ASR,也叫语音转文本 STT)是将语音音频转为文本的过程。
ASR 的延迟并不是生成文本的总时长,因为语音转文本会在用户说话时后台运行。实际延迟是从说话结束到文本生成完成的时间。
.webp&w=3840&q=95)
因此,无论说话时间长短,ASR 延迟可能相近。不同 ASR 实现的延迟也不同(有些情况下模型嵌入浏览器中,如 Chrome/Chromium,几乎没有网络延迟)。开源模型 Whisper 会增加 300ms 以上延迟,我们的自研实现延迟低于 100ms。
系统的“本能”
轮流控制 / 打断检测(TTI)用于判断用户是否说完。底层模型叫做语音活动检测器(VAD)。
轮流控制涉及复杂规则。短暂的语气词(如“嗯”)不应触发轮换,否则对话会变得断断续续。模型需要判断用户是否真的想引起注意,以及是否表达完毕。
优秀的 VAD 不会一检测到静音就切换轮次。词与词之间也有停顿,模型需确保用户确实说完。为此,需要检测静音阈值(或更准确地说,无语音)。这个过程会带来延迟,影响整体体验。
.webp&w=3840&q=95)
理论上,如果其他对话式 AI 环节延迟为 0,TTI 的延迟反而有助于模拟人类对话,因为人类也会停顿。但由于其他环节本身已有延迟,TTI 延迟应尽量减少。
系统的大脑
接下来,系统需要生成回复。现在通常用大型语言模型(LLM),如 GPT-4 或 Gemini Flash 1.5。
选择不同语言模型对延迟影响很大。Gemini Flash 1.5 等模型非常快,输出低于 350ms。更强大的模型如 GPT-4、Claude 处理复杂问题时延迟可达 700-1000ms。选择合适的模型通常是优化对话式 AI 延迟最直接的方法。
不过,LLM 的延迟指的是开始生成 token 的时间。这些 token 可立即传递给后续 文本转语音 流程。由于文本转语音受语速限制,LLM 输出速度远快于语音生成,因此最关键的是首 token 延迟(即首字节时间)。
.webp&w=3840&q=95)
除了模型选择,LLM 延迟还受提示词长度和知识库大小影响。内容越多,延迟越长。因此需要在上下文丰富和模型负担之间找到平衡。
系统的“嘴巴”
对话式 AI 的最后一步是 文本转语音(TTS)。TTS 的延迟是收到文本 token 后开始发声的时间。因为后续 token 生成速度快于人类语速,所以 TTS 延迟只看首字节时间。
.webp&w=3840&q=95)
过去,文本转语音速度较慢,生成语音需 2-3 秒。但现在像我们的 Turbo 引擎只需 300ms,新一代 Flash TTS 引擎更快。Flash 模型时延仅 75ms,端到端首字节音频延迟可达 135ms,行业领先(必须小小自豪一下)。
除了四大环节,还有一些因素会影响对话式 AI 的总延迟。
数据在不同地点传输总会有延迟。对于部分对话式 AI 应用,ASR、TTI、LLM 和 TTS 最好部署在同一区域,这样主要的网络延迟只来自用户与系统之间的传输。我们自有 TTS 和内部转写方案,可以减少两次服务器调用,从而降低延迟。
.webp&w=3840&q=95)
许多对话式 AI 应用需要调用函数(即对接工具和服务)。比如让 AI 查询天气。这会在文本处理阶段增加额外的 API 调用,根据需求可能带来更多延迟。
比如语音点餐时,可能需要多次 API 调用,有些环节(如信用卡处理)延迟较高。
.webp&w=3840&q=95)
不过,对话式 AI 系统可以通过让 LLM 在函数调用完成前先回复用户(如“我帮你查一下天气”)来减少等待时间,让对话不中断,更贴近真实交流。
.webp&w=3840&q=95)
这种异步模式通常通过 webhook 实现,避免长时间请求。
另一个常见功能是 对话式 AI 平台 支持用户电话接入(或代表用户拨打电话)。电话接入会带来额外延迟,且受地域影响较大。
.webp&w=3840&q=95)
同一区域内电话接入会增加约 200ms 延迟。跨洲通话(如亚洲到美国)延迟可达 500ms。如果用户号码与所在区域不一致,还会增加跳转延迟。
希望这次对对话式 AI 智能体 的全流程解析对你有帮助。总的来说,应用应将延迟控制在 1 秒以内,通常选对 LLM 就能实现。同时,复杂流程运行时应及时与用户互动,避免长时间静默。
最终目标是让用户像与真人交流一样自然,同时享受计算机程序带来的便利。通过优化各环节,这已成为可能。
在 ElevenLabs,我们正用自研的 STT 和 AI 语音智能体 系统优化对话式 TTS 模型的每一个环节。逐步优化流程,实现流畅对话体验。全局协同让我们在每个环节都能减少哪怕 1ms 的延迟。