推出 Eleven v4认识 Eleven v4:迄今情感表现最丰富的模型。 Creator+ 套餐含 3 倍点数优惠,截止至 10 月 12 日

跳至内容

什么是对话式 AI 延迟,哪些因素会影响它?

发布时间
最近更新

收听收听本文

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

对话式 AI 的本质目标,是复现与人交谈的感觉,包括相同的 情感范围、音高和节奏。再加上从你停止说话到 AI 智能体开始回应之间符合“自然”感受的延迟,就得到了以真实人类沟通方式为基础的延迟目标。

希望大规模部署 对话式 AI 智能体的企业,若想实现这种自然体验,就需要尽可能降低延迟。本文将介绍什么是对话式 AI 延迟、整个流程中造成延迟的原因,以及降低延迟的整体思路。

摘要

  • 对话式 AI 延迟是指用户停止说话到听见智能体说出第一个词之间的端到端总延迟。
  • 延迟超过 700 ms 的智能体可能显得不自然;超过 1,200 ms 时,用户放弃率较高。
  • 延迟会在对话式 AI 流程的每个阶段不断累积。
  • ElevenAgents 通过单一统一架构处理完整流程,让企业更易使用低延迟对话式 AI。

什么是对话式 AI 延迟?

对话式 AI 延迟是指你说完话后,系统做出响应所需的总时间。对于现代 AI 模型,延迟以 ms 为单位衡量。实际上,总延迟由多个独立流程构成,每个流程都为端到端流程贡献一部分时间。

典型的对话式 AI 流程如下:

  1. 用户说话
  2. 音频由语音转文本模型转写
  3. 将转录文本传给 LLM 模型,由其生成回复
  4. 随后,LLM 的文本会通过 文本转语音 模型合成为音频
  5. 系统向用户播放音频

上述每个阶段都会为对话式 AI 系统增加延迟。因此,讨论延迟时需要厘清几个不同的缩写。

模型推理延迟

模型推理延迟是模型生成输出所花的时间,在内部测量且不包含外部因素。它用于衡量特定模型在典型输入下的运行速度。例如,Flash v2.5 的模型推理延迟约为 75 ms。了解这一点后,就能比较不同厂商模型的速度。

不过要注意,这并不是用户实际感受到的延迟。它仅指模型生成输出所花的总时间。

LLM 首个 token 时间

大语言模型(LLM)首个 token 时间(TTFT)是指大语言模型处理提示词并生成第一个可用输出 token 所需的总时间。

当 LLM 传来第一个 token 时,TTS 才会开始生成。因此,该指标衡量的是 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,并持续流式处理,确保轮次结束时输出立即就绪。

Conversational AI latency diagram showing ASR system: user input speech and processing latency by ElevenLabs.

轮次判断与端点检测

语音活动检测器(VAD)位于语音识别与语言模型之间,负责判断用户是否真的说完了。

为避免出错,VAD 会等待持续静音达到一定阈值后,才判定本轮结束。这段等待时间会在语言模型开始处理前增加延迟。虽然会多花一点时间,但也能避免用户还在说话时系统就开始回应。

从技术上讲,如果其他所有对话式 AI 组件的延迟都为零,轮次判断带来的延迟其实是好事。人类听到话后也会稍作停顿再回应,机器采用类似的停顿能让交互更真实。不过,由于对话式 AI 的其他组件已经会产生延迟,因此轮次判断的延迟越低越理想。

Turn taking diagram showing speech processing flow from Input Speech to LLM with latency and data flow paths.

语言模型处理

当 语音转文本(STT)引擎完成转录后,语言模型会生成回复。这里的延迟是开始生成 token 所需的时间,而非生成完整回复的时间。这些 token 一到达便会直接流入 TTS 阶段,因此最重要的是 TTFT。

除了模型选择,提示词长度和知识库规模也会影响这一阶段。LLM 需要考虑的上下文越多,耗时就越长。大规模设计这类系统时,应在实用的知识库与精简提示词之间取得平衡,以保持速度。

Diagram showing speech-to-text-to-speech process with latency and data flow.

语音合成

TTS 延迟是指从收到语言模型的第一个 token 到音频开始播放之间的时间。由于 token 的到达速度快于人类语音播放速度,合成模型无需等待完整回复。TTS 延迟严格来说就是生成首段音频所需的时间。

这一阶段曾是对话式 AI 延迟的最大单项来源,旧模型开始生成语音需要 2-3 秒。ElevenLabs 的 Flash v2.5 直接解决了这一问题,以约 75 ms 延迟实现语音合成,将这一瓶颈从数秒缩短到不足 1 秒。

Conversational AI latency flowchart showing speech processing: input speech to ASR, VAD, and LLM, then TTS for output speech.

网络延迟

数据从一个地点传到另一个地点总会增加延迟,地理距离只会进一步加剧网络往返延迟。

由于多个组件协同生成端到端回复,多次网络跳转会累积显著延迟。

Audio-processing workflow diagram showing latency and data flow by ElevenLabs.

函数调用

函数调用会在 LLM 阶段增加 API 往返时间。快速的内部查询可能只增加几十毫秒,而支付处理器或库存系统可能增加数秒。延迟完全取决于所调用的服务,因此这是最难直接优化的阶段。

最有效的模式是提示 LLM 在工具调用完成前先做出回应。例如“我来帮你查一下”这样的说法,能在外部调用完成期间让用户保持参与,而不是陷入沉默。工具在后台并行运行时,语音回复即可开始。

Conversational AI latency flowchart showing speech processing from input to output, highlighting ASR, VAD, TTS, and LLM stages.

如何降低对话式 AI 延迟

降低对话式 AI 延迟需要按影响程度处理流程中的每个阶段。单项改进确实能降低延迟,但要实现最大改善,仍需从整体上优化整个流程。

以下原则可从整体层面帮助降低对话式 AI 延迟:

  • TTS 模型选择:Flash v2.5 等速度优化型 TTS 模型,与 Eleven v3 等质量优化型模型采用不同架构。对于实时 语音智能体,正确选择是在满足延迟目标的前提下质量最高的模型,而这几乎总是速度优化型模型。
  • LLM 模型选择:较小、较快的 LLM 通常比大型模型具有更低的首个 token 时间。选择既满足任务质量要求又尽可能快的 LLM,与选择 TTS 模型同样重要。
  • 流式处理:流式 TTS 会在合成过程中分块返回音频,因此模型仍在生成其余内容时,用户已经能听到第一个词。此概念同样适用于 LLM 输出:语言模型生成后续句子时,便对第一句话开始 TTS 合成,可从流程中挽回部分延迟。
  • 系统提示词设计:可通过 精简系统提示词,将指令移入程序或工作流程,而非保留在每个决策步骤中。这样可减少模型每轮需要推理的上下文量。
  • 安全护栏:在流式模型中运行安全护栏,可在检查完成前开始播放输出,而无需等检查结束后再播放。
  • 模型共址:尽可能使用共址模型,例如 ElevenLabs Agents 技术栈,让各组件彼此靠近,避免在独立托管模型之间跳转而增加延迟。
  • 地理位置:让服务器更靠近用户可显著降低延迟,因为这会直接减少网络对端到端 TTFA 的影响。


除上述因素外,还可参考这份 延迟优化技术指南 了解更多详情。

通过 ElevenAgents 开始使用低延迟对话式 AI

构建和部署智能体时,对话式 AI 延迟是需要重点考虑的问题。ElevenAgents 已将延迟优化内置于流程中。从通过重叠技术争取时间,到降低各组件的模型推理延迟,ElevenAgents 可为企业构建低延迟对话式 AI 技术栈。

归根结底,目标是创造真实感。用户既要感受到与人交谈般的轻松,也要获得计算机程序带来的好处。通过缩短各个子流程,这已成为可能。

了解更多 ElevenAgents 信息,或 联系销售团队,立即开始。

对话式 AI 延迟常见问题

相关内容

用高质量 AI 音频创作