跳到内容

如何优化对话式 AI 的延迟?

延迟是区分优秀与卓越对话式 AI 应用的关键

Diagram of a speech processing system showing data flow from user input to output speech, including components like telephone network, ASR, VAD, LLM, TTS, and latency indicators.

大多数应用对延迟要求不高,但对话式 AI 对延迟的要求决定了应用的优劣。

对话式 AI 的目标是让交流体验像真人对话一样自然,同时在智能上超越人类。要实现这一点,应用必须避免长时间的静默,否则就会失去真实感。

对话式 AI 的延迟挑战还在于其流程分散。它由多个前沿环节组成,每一步都会叠加延迟。

作为一家生成式语音公司,我们长期研究如何降低对话式 AI 的延迟。现在,希望分享我们的经验,帮助有兴趣开发对话式 AI 应用的用户。

四大核心环节

每个对话式 AI 应用至少包含 4 个步骤:语音转文本、轮流控制、文本处理(如 LLM)、以及 文本转语音。这些步骤虽然可并行执行,但每一步都会带来一定延迟。

对话式 AI 的延迟计算方式很独特。许多流程的延迟通常由某个瓶颈决定,比如网站访问数据库时,网络延迟占主导。但对话式 AI 的各环节延迟差异不大,每一部分的延迟都不可忽视,因此总延迟是各环节之和。

自动语音识别

系统的“耳朵”

自动语音识别(ASR,也叫语音转文本 STT)是将语音音频转为文本的过程。

ASR 的延迟并不是生成文本的总时长,因为语音转文本会在用户说话时后台运行。实际延迟是从说话结束到文本生成完成的时间。

Flowchart showing user input speech processed by ASR system.

因此,无论说话时间长短,ASR 延迟可能相近。不同 ASR 实现的延迟也不同(有些情况下模型嵌入浏览器中,如 Chrome/Chromium,几乎没有网络延迟)。开源模型 Whisper 会增加 300ms 以上延迟,我们的自研实现延迟低于 100ms。

轮流控制 / 打断检测

系统的“本能”

轮流控制 / 打断检测(TTI)用于判断用户是否说完。底层模型叫做语音活动检测器(VAD)。

轮流控制涉及复杂规则。短暂的语气词(如“嗯”)不应触发轮换,否则对话会变得断断续续。模型需要判断用户是否真的想引起注意,以及是否表达完毕。

优秀的 VAD 不会一检测到静音就切换轮次。词与词之间也有停顿,模型需确保用户确实说完。为此,需要检测静音阈值(或更准确地说,无语音)。这个过程会带来延迟,影响整体体验。

Flowchart showing the process of speech recognition and language modeling, with steps including input speech, ASR, VAD, and LLM.

理论上,如果其他对话式 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 延迟(即首字节时间)。

Flowchart of speech processing system showing input speech, ASR, VAD, LLM, and TTS components with data flow and latency indicated.

除了模型选择,LLM 延迟还受提示词长度和知识库大小影响。内容越多,延迟越长。因此需要在上下文丰富和模型负担之间找到平衡。

文本转语音

系统的“嘴巴”

对话式 AI 的最后一步是 文本转语音(TTS)。TTS 的延迟是收到文本 token 后开始发声的时间。因为后续 token 生成速度快于人类语速,所以 TTS 延迟只看首字节时间。

Diagram of a speech processing system showing input speech, ASR, VAD, LLM, TTS, and output speech with data flow and latency indicators.

过去,文本转语音速度较慢,生成语音需 2-3 秒。但现在像我们的 Turbo 引擎只需 300ms,新一代 Flash TTS 引擎更快。Flash 模型时延仅 75ms,端到端首字节音频延迟可达 135ms,行业领先(必须小小自豪一下)。

其他影响因素

除了四大环节,还有一些因素会影响对话式 AI 的总延迟。

网络延迟

数据在不同地点传输总会有延迟。对于部分对话式 AI 应用,ASR、TTI、LLM 和 TTS 最好部署在同一区域,这样主要的网络延迟只来自用户与系统之间的传输。我们自有 TTS 和内部转写方案,可以减少两次服务器调用,从而降低延迟。

Diagram of a speech processing system showing input speech, ASR, VAD, LLM, TTS, and output speech with latency and network latency indicators.

函数调用

许多对话式 AI 应用需要调用函数(即对接工具和服务)。比如让 AI 查询天气。这会在文本处理阶段增加额外的 API 调用,根据需求可能带来更多延迟。

比如语音点餐时,可能需要多次 API 调用,有些环节(如信用卡处理)延迟较高。

Diagram of a speech processing system showing input speech, ASR, VAD, LLM/function calling, TTS, and output speech with data flow and latency indicated.

不过,对话式 AI 系统可以通过让 LLM 在函数调用完成前先回复用户(如“我帮你查一下天气”)来减少等待时间,让对话不中断,更贴近真实交流。

Flowchart of a speech synthesis system showing user input, system processing, and output speech, with components like ASR, VAD, TTS, and LLM.

这种异步模式通常通过 webhook 实现,避免长时间请求。

电话接入

另一个常见功能是 对话式 AI 平台 支持用户电话接入(或代表用户拨打电话)。电话接入会带来额外延迟,且受地域影响较大。

Diagram of a speech processing system showing data flow and latency between components.

同一区域内电话接入会增加约 200ms 延迟。跨洲通话(如亚洲到美国)延迟可达 500ms。如果用户号码与所在区域不一致,还会增加跳转延迟。

结语

希望这次对对话式 AI 智能体 的全流程解析对你有帮助。总的来说,应用应将延迟控制在 1 秒以内,通常选对 LLM 就能实现。同时,复杂流程运行时应及时与用户互动,避免长时间静默。

最终目标是让用户像与真人交流一样自然,同时享受计算机程序带来的便利。通过优化各环节,这已成为可能。

在 ElevenLabs,我们正用自研的 STT 和 AI 语音智能体 系统优化对话式 TTS 模型的每一个环节。逐步优化流程,实现流畅对话体验。全局协同让我们在每个环节都能减少哪怕 1ms 的延迟。

查看更多 ElevenLabs 团队的文章

用高质量 AI 音频创作