具备前沿智能的实时语音代理 — Bohan Li, EliseAI

中文العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00我叫波（Bo）。我今天在这里为大家介绍前沿智能实时语音代理。
00:00:18实际上我们要探讨的是，我们公司 Elise AI
00:00:22是如何架构我们的语音代理框架，以实现具备我们所需的前沿智能水平的实时语音的。
00:00:28所以在开始之前，我想先类比一下，为什么我们决定采用级联语音代理，
00:00:36特别是在将其与我之前从事的自动驾驶汽车进行对比时。
00:00:42在我看来，如果我们从感知、规划和控制的角度来剖析，
00:00:48级联语音代理就非常好理解了。
00:00:53对于自动驾驶汽车来说，感知就是边界框、摄像头和激光雷达；
00:00:59而对于语音来说，它就是转写，
00:01:05基本上就是将现实世界中的这些信号有效地转化为
00:01:09语言模型或你所使用的任何“大脑”能够处理的数据元素。
00:01:17第二个是规划堆栈，这相当直观。
00:01:23在这里，语言模型将接收来自感知阶段的输出，并生成你希望
00:01:29输出并反馈回真实世界的输出。最后是控制层，
00:01:36在自动驾驶中，你需要获取规划器输出的轨迹，并将其转化为实际的控制指令来驾驶汽车。
00:01:43在这里，我们是将文本转化为音频，用来表达我们的语音代理的想法。
00:01:50是的，接下来我将深入探讨其中的每一个元素，我们在每一个领域都做了一些有趣的小技巧，
00:02:00深入探讨其中的每一个要素。我们在这些领域的每一个地方都采用了一些有趣的小技巧，
00:02:08在不牺牲智能性的前提下，提升语音智能体的运行速度。
00:02:13我们提出了这样一个概念，叫做流式推测转写器（streaming speculative transcriber），
00:02:19实际上就是将一个快速流式转写器（如 Flux）叠加在
00:02:24Scribe v2 或精确批处理转写器（它能吸收更多上下文）的顶部或下方。
00:02:33它稍微慢一些，但会给你提供更准确的检测结果。
00:02:39现在我们来过一遍具体场景，在这个场景中，代理刚问完，比如提供
00:02:44“你能写下你的姓名和出生日期吗？”，然后用户会这样说，我们来看看时间上的表现。
00:02:49在时间上会是这样的。首先我们会得到初步的检测结果。我们会从流式传输层
00:02:57获取它。精准层即纠错层不会被触发，因为文本是相同的。
00:03:05我们会得到更多流式文本检测结果，在这种情况下，修正层实际上被取消了，
00:03:11因为我们有了更新的文本，所以更多的上下文、更多的音频会覆盖旧的准确文本。
00:03:21这里就是第一次修正介入的地方。因为 Scribe v2 层理解了
00:03:27问题的上下文，所以它能够理解这里讨论的是名字和出生日期。
00:03:34接着还有几次检测，这些只是标点符号，我们不在乎。
00:03:37最后，我们将这段文本释放给代理。
00:03:44接下来转向语言模型层。在这里，既然我们使用的是这种缓慢但
00:03:52聪明的 LLM，我们真的很想减少往返次数，而导致我们进行大量推理的原因就是工具调用。
00:03:58摆脱这种情况的一种方法是让后台代理为你进行工具调用，
00:04:05并把工具结果推回给主代理的上下文中，让它以为是自己发起了工具调用，但实际上并没有。
00:04:13所以回想一下之前的检测。将会发生的是，每一次检测都会触发代理的早期生成，
00:04:26但我们不会真正将其输出，直到我们确认用户已经说完话为止。
00:04:38用户说“好的”。智能体大概知道用户还想说别的。
00:04:45我们这里的后台工具调用，将帮助我们从用户检测中提取姓名和出生日期
00:04:51此时并没有触发，所以没有什么进展。下一个即时检测进来了，显示依然不是名字。
00:05:02我们的代理顺着这个思路继续进行下去。
00:05:06现在返回了更多上下文。代理觉得这里应该有个名字了。
00:05:11它会要求拼写出来，因为它可能觉得这里有一些转写错误。
00:05:16依然没有名字或出生日期。然后最后，大家记住，这是我们转写器
00:05:22（来自 Scribe v2）的修正后的最终即时检测。
00:05:27这里，我们之前在没有任何工具调用的情况下仓促生成的代理响应将被取消，
00:05:34因为后台代理终于能够找到它所寻找的姓名和出生日期了。
00:05:38因此它将重新触发，现在代理确实拥有了它所需的上下文。
00:05:45你看，这里的工具调用包含了一些智能处理。
00:05:49我们将纠正姓名的错误转写，在这里进行一些语音匹配。
00:05:53进行一些类似语音匹配的操作。
00:05:57一旦我们理解这是用户话语的结束，我们就会将其输出。所以相当标准。
00:06:02我们就会将其输出。所以相当标准。
00:06:06好的，接下来的这一层是文本转语音（TTS）。对于 TTS 来说，目标是
00:06:12获取代理所说的话，而代理会以流式方式输出这些内容。
00:06:16因此我们需要尽快生成音频。理想情况下，你可以在代理甚至还未完成生成全部文本之前，
00:06:24在智能体甚至还没生成完整文本之前，你就可以播放音频。
00:06:31所以这有点像是隐藏了完成生成的延迟。所以我接下来要播放流式
00:06:39它以“U”开头。其实在我深入讲解之前，我们要在这里介绍一个新概念，叫做前缀缓存（prefix cache）。
00:06:46前缀缓存会检查代理流，看看我们是否已经为该单词序列生成过音频，
00:06:52这些音频来自先前的生成，或者可能是本次通话中相同的生成。
00:07:02这些音频来自先前的生成，或者可能是本次通话中相同的生成。
00:07:10所以它看到了单词“U”。对于这个前缀缓存，我们不想对每个单词都立即命中，
00:07:17我们要再等几个单词。所以在三个单词之后，前缀缓存迎来了第一次命中。
00:07:24右边这里是我们的标准 TTS 提供商，Cartesia 是一个支持 WebSocket 的 TTS 引擎。
00:07:31右边这里是我们的标准语音合成提供商，你知道，Cartesia 是一个支持 WebSocket 的语音合成引擎。
00:07:36所以我们通过缓存传输代理的内容，同时也通过 WebSocket 传输。
00:07:45更多 token 进来，更多缓存，更多发送到 WebSocket。这里没什么好说的。
00:07:51好的，现在我们遇到了第一个独特的情况，即我们发现了一个实际上导致缓存未命中的 token。
00:07:59如果我们缓存先前的生成，这是合乎情理的。“You said your name is”是非常常见的内容，
00:08:05是一个很常见的情况，但一旦我们加上名字，突然间就会导致缓存未命中。
00:08:12此时我们实际上要输出缓存的音频。所以你刚才说名字是...
00:08:19因此，“You said your name is”将在其余流式文本返回时被发出。此时用户听到了代理的声音。
00:08:25用户并不清楚发生了什么，对他们来说只觉得响应速度非常快。
00:08:32现在剩余的文本流过。此时我们已经从缓存中输出了。
00:08:38缓存已经完成了它的工作。其余部分我们可以丢给 Cartesia。这里有一个小技巧，
00:08:46Cartesia 已经看到了截至目前的整个转录文本。对 Cartesia 来说，它并不知道前缀缓存的存在。
00:08:56它只会生成带有标准自然语调的完整句子。
00:09:01但我们所做的是，当生成结果返回时，既然我们已经在这里播放了音频，
00:09:08我们实际上可以抑制来自 Cartesia 的这部分音频，只播放剩下的部分。
00:09:13所以用户可能会有一点点小 hiccups（卡顿）。我稍后会播放一些音频，你会发现你可能根本察觉不到。
00:09:21实际上，我们截取这部分内容，并在这段音频播放完毕后直接将其输出。
00:09:28所以对用户来说一切都是无缝衔接的。
00:09:35是的，我想现在这里有太多的技术细节了，最好的方法就是直接播放一段通话并亲眼见证。
00:09:43所以我录制了一通电话，让我们听听发生了什么。
00:09:53这里我们将与你们通话。这是 Bo，妇产科，Elise 在说话。
00:09:59您好，我觉得我可能怀孕了，我想预约做个超声波检查来确认一下。
00:10:03真是个好消息。请提供你的姓名和出生日期？
00:10:08好的，我是 Elise trial。出生日期是 2303。
00:10:15谢谢你。你是我们这里的新患者吗？
00:10:24是的。欢迎来到 Bo 妇产科。我可以给你发一个链接用来上传你的保险信息吗？
00:10:34可以。好的。已发送。收到后请告诉我。
00:10:48我已收到你的保险信息。我这里最早的预约是星期四，
00:10:537月2日上午10点。其实，等一下，让我查一下我的日历。
00:11:01好的，请便。下周有什么时间吗？
00:11:09下周的话，我可以提供由北区诊所的艾弗里·斯通医生（Dr. Avery Stone）在周二
00:11:147月7日下午2点或3点做的超声波检查。这两个时间哪个适合你？
00:11:20行，下午2点可以。太好了。你的预约已完成。我们期待到时见到你。
00:11:29谢谢。再见。好的，差不多就是这样。
00:11:35是的，你可以看到我们的——所有这些流式传输，你知道，有很多事情
00:11:43都在后台发生。是的，这正是让语音代理变得如此有趣的地方。
00:11:48并且可以在 harness（框架）中付出很多努力，真正做到
00:11:55自然的对话，这正是我们所追求的。
00:11:59好的。嗯。所以，我想最后简单地聊一下有关 Elyse 的事情。
00:12:04我认为 Elise 的总部在纽约，我们正在努力将我们在湾区的业务扩展开来。
00:12:09我觉得这可能是一种与人们在旧金山想到 AI 初创公司时
00:12:15所联想到的不同的公司风格，
00:12:23我们的重点其实就是真正去帮助人们，在他们需要的地方提供帮助
00:12:31比如生活最关键的领域。我们从事住房、医疗保健行业，并且做得很好，
00:12:37这里有一个加入我们团队的链接，并且我们
00:12:45会在 Twitter 上发布很多内容，所以你也可以关注我们的账号 @Elyse.ai。就这样。
00:12:57所以，我们将在 Twitter 上发布更多内容，并且我们将在 Twitter 上发布更多内容。

핵심 요약

Elise AI通过流式投机转写、后台工具调用和前缀缓存等架构设计，实现了兼具前沿智能与超低延迟的实时语音代理。

하이라이트

  • Elise AI采用级联式语音代理架构，将语音任务划分为感知、规划和控制三个核心层。

  • 流式投机转写器结合了快速流式转写层Flux和高精度批量转写层Scribe v2，平衡了实时响应与转写准确率。

  • 后台代理在用户说话时提前执行工具调用，避免了主语言模型的频繁往返推理延迟。

  • 前缀缓存机制比对代理流，复用先前生成的音频序列，缩短文本到语音的生成时间。

  • Cartesia文本到语音引擎通过WebSocket支持流式音频输出，并配合音频抑制技术隐藏缓存切换带来的延迟。

타임라인

级联式语音代理架构与对齐

  • 语音代理架构借鉴自动驾驶的感知、规划和控制三个分层设计。
  • 感知层负责将现实世界的语音信号转录为语言模型可处理的数据元素。
  • 规划层利用语言模型接收感知层的输出并生成业务逻辑结果。
  • 控制层将文本转换为音频以表达语音代理的思考和回复。

演讲者通过对比自动驾驶系统的设计逻辑，阐述了语音代理中各层级的功能划分。通过对感知、规划和控制层的优化，系统能够在不牺牲智能水平的前提下提升处理速度。

流式投机转写层设计

  • 系统采用流式投机转写器，在快速流式转写层下方叠加高精度批量转写层。
  • Flux提供快速的初步文本检测，而Scribe v2利用上下文提供更高准确率的矫正。
  • 当接收到新的音频上下文时，早期的准确率矫正层会自动取消以保持实时性。

转写层通过分层策略兼顾了速度与精度。快速层负责捕捉基础语音，而较慢但更聪明的Scribe v2层则在后台纠正错别字并结合上下文理解诸如姓名和出生日期等关键信息。

后台工具调用与推理优化

  • 后台代理替代主智能体进行工具调用，将结果直接推入主代理的上下文中。
  • 系统在用户完整发言前进行早期代理生成，但在确认发言结束前不实际输出。
  • 后台代理成功检索到名称和出生日期后，会取消未调用工具的早期生成并重新触发。

为了减少慢速智能大语言模型的往返推理次数，系统将工具调用剥离到后台代理中执行。这种机制允许主代理在不知道实际进行了工具调用的情况下获取所需上下文，同时支持同音纠错等智能对齐。

前缀缓存与文本到语音加速

  • 前缀缓存机制检查代理文本流，复用之前生成过的音频序列。
  • 当遇到缓存未命中的新词时，系统立即输出已缓存的音频以隐藏延迟。
  • Cartesia文本到语音引擎生成完整句子的自然韵律，系统通过音频抑制技术无缝衔接前后音频。

文本到语音阶段利用前缀缓存来避免重复渲染常用短语。即使遇到新词导致缓存失效，系统也能无缝衔接预先缓存的音频与实时生成的语音，使终端用户感受到极快的响应速度。

医疗预约通话演示与公司概况

  • 实际录制的医疗预约通话演示展示了语音代理在真实场景中的低延迟交互。
  • EliseAI总部位于纽约并正向旧金山湾区扩展，专注于医疗和住房等关键领域的AI应用。

通过真实的妇产科预约电话录音，直观展示了前述的流式传输和后台处理效果。最后介绍了公司的核心业务领域及招聘方向。

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기