Skip to main content

概述

聊天界面一直主导着我们与 AI 的交互方式,但多模态 AI 的最新突破正在开辟令人兴奋的新可能性。高质量的生成模型和富有表现力的文本转语音(TTS)系统现在使得构建感觉更像对话伙伴而非工具的代理成为可能。 语音代理就是其中一个例子。你无需依赖键盘和鼠标向代理输入内容,而是可以使用口语与之交互。这可以是一种更自然、更具吸引力的与 AI 交互的方式,并且在某些特定场景下尤其有用。

什么是语音代理?

语音代理是能够与用户进行自然口语对话的代理。这些代理结合了语音识别、自然语言处理、生成式 AI 和文本转语音技术,以创造无缝、自然的对话。 它们适用于多种用例,包括:
  • 客户支持
  • 个人助理
  • 免提界面
  • 辅导与培训

语音代理如何工作?

从高层次来看,每个语音代理都需要处理三个任务:
  1. 倾听 - 捕获音频并将其转录为文本
  2. 思考 - 解释意图、推理、规划
  3. 表达 - 生成音频并将其流式传输回用户
区别在于这些步骤如何排序和耦合。在实践中,生产环境中的代理遵循两种主要架构之一:

1. STT > Agent > TTS 架构(“三明治”架构)

三明治架构由三个不同的组件组成:语音转文本(STT)、基于文本的 LangChain 代理和文本转语音(TTS)。 优点:
  • 完全控制每个组件(可根据需要更换 STT/TTS 提供商)
  • 可访问现代文本模态模型的最新功能
  • 行为透明,组件之间界限清晰
缺点:
  • 需要编排多个服务
  • 管理管道的复杂性增加
  • 从语音到文本的转换会丢失信息(例如,语调、情感)

2. 语音到语音架构(S2S)

语音到语音使用多模态模型,该模型原生处理音频输入并生成音频输出。 优点:
  • 架构更简单,活动部件更少
  • 对于简单交互,通常延迟更低
  • 直接音频处理可捕捉语调和其他语音细微差别
缺点:
  • 模型选择有限,供应商锁定风险更大
  • 功能可能落后于文本模态模型
  • 音频处理方式的透明度较低
  • 可控性和定制选项减少
本指南演示了三明治架构,以平衡性能、可控性以及对现代模型功能的访问。通过某些 STT 和 TTS 提供商,三明治架构可以实现低于 700 毫秒的延迟,同时保持对模块化组件的控制。

演示应用概述

我们将逐步介绍如何使用三明治架构构建一个基于语音的代理。该代理将管理一家三明治店的订单。该应用将演示三明治架构的所有三个组件,使用 AssemblyAI 进行 STT,使用 Cartesia 进行 TTS(尽管可以为大多数提供商构建适配器)。 端到端的参考应用可在 voice-sandwich-demo 仓库中找到。我们将在本文中介绍该应用。 该演示使用 WebSockets 在浏览器和服务器之间进行实时双向通信。相同的架构可以适配其他传输方式,如电话系统(Twilio、Vonage)或 WebRTC 连接。

架构

该演示实现了一个流式管道,其中每个阶段异步处理数据: 客户端(浏览器)
  • 捕获麦克风音频并将其编码为 PCM
  • 与后端服务器建立 WebSocket 连接
  • 实时将音频块流式传输到服务器
  • 接收并播放合成的语音音频
服务器(Python)
  • 接受来自客户端的 WebSocket 连接
  • 编排三步管道:
    • 语音转文本(STT):将音频转发给 STT 提供商(例如 AssemblyAI),接收转录事件
    • 代理:使用 LangChain 代理处理转录文本,流式传输响应令牌
    • 文本转语音(TTS):将代理响应发送给 TTS 提供商(例如 Cartesia),接收音频块
  • 将合成的音频返回给客户端进行播放
该管道使用异步生成器在每个阶段启用流式传输。这允许下游组件在上游阶段完成之前开始处理,从而最小化端到端延迟。

设置

有关详细的安装说明和设置,请参阅仓库 README

1. 语音转文本

STT 阶段将传入的音频流转换为文本转录。该实现使用生产者-消费者模式来并发处理音频流和转录接收。

关键概念

生产者-消费者模式:音频块与接收转录事件并发发送到 STT 服务。这允许在所有音频到达之前就开始转录。 事件类型
  • stt_chunk:STT 服务处理音频时提供的部分转录
  • stt_output:触发代理处理的最终格式化转录
WebSocket 连接:维护与 AssemblyAI 实时 STT API 的持久连接,配置为 16kHz PCM 音频并自动进行轮次格式化。

实现

该应用实现了一个 AssemblyAI 客户端来管理 WebSocket 连接和消息解析。实现见下文;可以为其他 STT 提供商构建类似的适配器。

2. LangChain 代理

代理阶段通过 LangChain 代理处理文本转录,并流式传输响应令牌。在这种情况下,我们流式传输代理生成的所有文本内容块

关键概念

流式响应:代理使用 stream_mode="messages" 在生成响应令牌时立即发出,而不是等待完整响应。这使得 TTS 阶段可以立即开始合成。 对话记忆检查点使用唯一的线程 ID 维护跨轮次的对话状态。这允许代理引用对话中的先前交流。

实现

3. 文本转语音

TTS 阶段将代理响应文本合成为音频,并将其流式传输回客户端。与 STT 阶段类似,它使用生产者-消费者模式来处理并发的文本发送和音频接收。

关键概念

并发处理:该实现合并了两个异步流:
  • 上游处理:传递所有事件并将代理文本块发送给 TTS 提供商
  • 音频接收:从 TTS 提供商接收合成的音频块
流式 TTS:一些提供商(如 Cartesia)在收到文本后立即开始合成音频,从而允许在代理完成生成完整响应之前就开始音频播放。 事件透传:所有上游事件原样传递,允许客户端或其他观察者跟踪完整的管道状态。

实现

该应用实现了一个 Cartesia 客户端来管理 WebSocket 连接和音频流。实现见下文;可以为其他 TTS 提供商构建类似的适配器。

LangSmith

你使用 LangChain 构建的许多应用程序将包含多个步骤和多次 LLM 调用。随着这些应用程序变得越来越复杂,能够检查链或代理内部到底发生了什么变得至关重要。最好的方法是使用 LangSmith 在上面的链接注册后,请确保设置环境变量以开始记录跟踪:
或者,在 Python 中设置:

整合所有内容

完整的管道将三个阶段链接在一起:
我们使用 RunnableGenerators 来组合管道的每个步骤。这是 LangChain 内部用于管理跨组件流式传输的一种抽象。 每个阶段独立且并发地处理事件:音频转录在音频到达时立即开始,代理在转录文本可用时立即开始推理,语音合成在代理文本生成时立即开始。这种架构可以实现低于 700 毫秒的延迟,以支持自然对话。 有关使用 LangChain 构建代理的更多信息,请参阅代理指南