什么是对话式 AI 延迟,哪些因素会影响它?
- 发布时间
- 最近更新
对于 对话式 AI,延迟决定了应用是优秀还是卓越。
对话式 AI 的本质是追求更高目标:它力求复现与真人交谈的体验,模拟相同的情感范围、音高和节奏。再加上从你说完到 AI 智能体开始回应之间符合“自然”感受的延迟,就得到了基于人类实际沟通方式的延迟目标。
想大规模部署 对话式 AI 智能体的企业,若想实现这种自然体验,就需要尽可能降低延迟。本文将介绍什么是对话式 AI 延迟、整个流程中导致延迟的因素,以及降低延迟的高层方法。
摘要
- 对话式 AI 延迟,是指用户停止说话到听到智能体说出第一个字之间的端到端总延迟。
- 延迟超过 700 ms 的智能体可能显得不自然;超过 1,200 ms 时,用户放弃率较高。
- 延迟会在对话式 AI 流程的每个阶段累积。
- ElevenAgents 通过单一统一架构处理完整流程,让企业也能轻松使用低延迟对话式 AI。
什么是对话式 AI 延迟?
对话式 AI 延迟是指系统在你说话后作出回应所需的总时间。对于现代 AI 模型,延迟以 ms 衡量。实际上,总延迟由多个独立流程构成,每个流程都是端到端链路的一部分。
典型的对话式 AI 流程如下:
- 用户说话
- 语音由语音转文本模型转写
- 将转写文本传给 LLM 模型,生成回复
- 随后,LLM 的文本通过 文本转语音 模型合成为音频
- 向用户播放音频
这些阶段都会为对话式 AI 系统增加延迟。因此,讨论延迟时需要区分几个不同的缩写。
模型推理延迟
模型推理延迟是模型生成输出所花费的时间,在内部测量,不包含任何外部因素。它用于衡量特定模型在典型输入下的运行速度。例如,Flash v2.5 的模型推理延迟约为 75 ms。借此可比较不同厂商模型的速度。
不过要注意,这并不是用户实际感受到的延迟。它只针对模型生成输出所花的总时间。
LLM 首 token 时间
大语言模型(LLM)的首 token 时间(TTFT),是 LLM 处理提示词并生成首个可用输出 token 所需的总时间。
TTS 会在从 LLM 收到首个 token 时开始生成,因此它衡量的是 LLM 开始触发 TTS 模型运行所需的时间。对于大多数端到端对话式 AI 系统,LLM TTFT 是总延迟的重要组成部分。
TTS 首音频时间(TTFA)
TTS 首音频时间(TTFA)衡量从首次发出 TTS 请求到第一个音频块实际离开模型的时间。它描述的是专属于 TTS 引擎的模型推理延迟。
端到端首音频时间(TTFA)
端到端 TTFA 就是对话式 AI 的总延迟。它涵盖流程中的所有部分,包括语音识别、LLM TTFT、TTS、TTFA,以及各步骤之间的所有网络传输。整体讨论对话式 AI 延迟时,这才是用户实际感受到的指标。
用户说话后,要等到端到端 TTFA 完成,才能听到智能体的回应。这是一个整体指标,改善流程中任何一部分都能让它变得更好。
为什么对话式 AI 延迟很重要
当用户与 AI 智能体交谈时,延迟会直接影响他们对这段体验的评价。低延迟可缩短等待回复的时间,让对话感觉自然,也让智能体显得更可靠。
高延迟的智能体会显得生硬、能力不足,即使回复质量相同也是如此。对企业而言,哪怕仅相差几百 ms,也会让人觉得无比漫长,使 客户支持智能体 显得笨拙且低效。
以下场景说明了对话式 AI 延迟为何如此重要:
- 低于 500 ms:对话智能体反应迅速、流畅。用户可能察觉不到自己说完和首次收到回复之间的延迟,对话得以顺畅进行。
- 500 ms 至 1000 ms:用户说完到收到回复之间的等待开始变得明显。时间只是略长,却可能让用户提前调整行为,例如重复表达,或停下来确认智能体是否真的理解了。
- 超过 1000 ms: 延迟开始让人感觉缓慢,停顿会让部分用户觉得 AI 智能体跟不上对话节奏。转写记录中可能偶尔出现打断,或要求与人工客服交谈。在某些情况下,用户会放弃通话。
这些阈值都会转化为实际业务结果。
在延迟较低的一端,客户服务智能体可自然处理咨询,帮助用户无需额外协助便解决问题。这能减轻人工客服压力,并保持较高的客户满意度。在延迟较高的一端,犹豫过久的智能体则会让客户感到沮丧。
我们在另一篇文章中定义了 语音智能体延迟预算基准,展示 P50 和 P95 值下的良好延迟表现。
对话式 AI 延迟由什么导致?
对话式 AI 延迟概括了多个流程,每个环节都会影响整体延迟。因此,实现低延迟的瓶颈更是系统层面的问题,并非仅靠选择更好的模型就能解决。毕竟,流程中有多个模型协同工作。
我们为开发者撰写了一份深入的 语音智能体延迟优化 技术指南,可用于优化端到端首音频时间(TTFA)的每个阶段。
除核心流程外,电话系统和函数调用等因素也会增加延迟,尽管它们并不属于模型基础设施内部。
以下概述影响对话式 AI 延迟的所有因素。
自动语音识别
语音识别的延迟并不是生成转写文本所需的时间。用户说话时,转写流程会在后台运行,因此说话结束时,文本基本已经准备就绪。
这里的延迟实际上是从语音结束到转写文本完成并传递至下一阶段之间的间隔。Scribe v2 Realtime 将这一间隔缩短至约 150 ms,通过持续流式传输,让输出在轮次结束时立即就绪。

轮次切换与端点检测
语音活动检测器(VAD)位于语音识别和语言模型之间,负责判断用户是否真的说完了。
为避免出错,VAD 会在判定该轮对话结束前,等待持续静默达到一定阈值。这段等待会在语言模型处理文字前增加延迟。虽然会多花一点时间,但也能避免用户仍在说话时系统就开始回应。
从技术上说,如果其他对话式 AI 组件的延迟均为零,那么轮次切换造成的延迟反而是好事。人类在回应话语前也会稍作停顿,机器采用类似停顿会让交互更真实。不过,其他对话式 AI 组件本身已会产生延迟,因此延迟越低越理想。

语言模型处理
从 语音转文本(STT)引擎获得转写文本后,语言模型会生成回复。这里的延迟是开始生成 token 所需的时间,而非生成完整回复的时间。这些 token 一到达就直接流入 TTS 阶段,因此最重要的是 TTFT。
除了模型选择,提示词长度和知识库规模也会影响这一阶段。LLM 需要考虑的上下文越多,耗时越长。大规模设计此类系统时,需要在实用的知识库与精简提示词之间取得平衡,以保持速度。

语音合成
TTS 延迟是从收到语言模型的首批 token 到音频开始播放之间的时间。由于 token 的到达速度快于人类语音播放速度,合成模型无需等待完整回复。TTS 延迟严格来说就是首个音频块的生成时间。
过去,这一阶段是对话式 AI 延迟最大的单一来源,旧模型开始生成语音需要 2-3 秒。ElevenLabs 的 Flash v2.5 直接解决了这一问题,以约 75 ms 延迟实现语音合成,将这个瓶颈从数秒缩短至不足 1 秒。

网络延迟
将数据从一个地点传输到另一个地点总会增加延迟,而地理距离只会加剧网络往返延迟。
由于多个组件需要协同生成端到端回复,多次网络跳转会累积显著延迟。

函数调用
函数调用会在 LLM 阶段增加 API 往返请求。快速的内部查询会增加几十毫秒,而支付处理器或库存系统可能增加数秒。延迟完全取决于所调用的服务,因此这是最难直接优化的阶段。
最有效的方法是让 LLM 在工具调用完成前先作出回应。例如,“我来帮你查一下”这类话可以在等待外部调用完成时维持用户参与度,而不是留下沉默。工具并行运行时,语音回复即可开始。

如何降低对话式 AI 延迟
降低对话式 AI 延迟,需要按影响程度处理流程的每个阶段。单项改进确实能减少延迟,但要取得最大效果,仍需从整体优化整个流程。
以下原则可从高层面帮助你降低对话式 AI 延迟:
- TTS 模型选择:针对速度优化的 TTS 模型(如 Flash v2.5)与针对质量优化的 Eleven v3 等模型采用不同架构。对于实时 语音智能体,正确选择是在满足延迟目标的前提下质量最高的模型,而这几乎总是针对速度优化的模型。
- LLM 模型选择:更小、更快的 LLM 通常比大型 LLM 具有更低的首 token 时间。选择既能满足任务质量标准、又最快的 LLM,与选择 TTS 模型同样重要。
- 流式传输: 流式 TTS 会在合成过程中分块返回音频,因此模型还在生成剩余内容时,用户已经能听到第一个字。这一概念同样适用于 LLM 输出:语言模型生成后续内容时,基于第一句话启动 TTS 合成,可从流程中节省延迟。
- 系统提示词 设计:可通过 精简系统提示词,将指令放入程序或 workflow,而非保留为每个决策步骤的一部分。这样可减少模型在每轮中需要推理的上下文。
- 护栏机制:在流式模型中运行护栏机制,可让输出在护栏检查完成前开始播放,而不必等检查结束后才播放。
- 模型共置:尽可能使用共置模型,例如 ElevenLabs Agents 技术栈,让各组件保持接近,避免在独立托管模型之间跳转而增加延迟。
- 地理位置:让服务器靠近用户可显著降低延迟,因为这能直接减少网络对端到端 TTFA 的影响。
除上述因素外,还可参考这份 延迟优化技术指南,了解更多详情。
通过 ElevenAgents 开始使用低延迟对话式 AI
构建和部署智能体时,对话式 AI 延迟是一个重要考量。ElevenAgents 将延迟优化融入整个流程。从通过重叠技术节省时间,到降低各组件的模型推理延迟,ElevenAgents 可为企业构建低延迟对话式 AI 技术栈。
归根结底,目标是营造真实感。用户既要感受到与真人交谈的轻松,也要获得计算机程序的优势。通过缩短各个子流程,如今这已成为可能。
了解更多 ElevenAgents 信息,或 联系销售团队,立即开始。
.webp&w=3840&q=80)
.webp&w=3840&q=80)


