如何利用 Amazon Nova 2 Sonic 构建自然低延迟语音助手 | 人工智能
如何利用 Amazon Nova 2 Sonic 构建自然低延迟语音助手 | 人工智能
Loka 通过使用 Amazon Nova 2 Sonic 构建对话式 AI 助手，彻底改变了客户语音交互体验，让客户在自然、响应迅速的服务中保持参与。他们基于 AWS 的解决方案在 Big Bench Audio 上实现了极高的语音推理准确率，同时相比传统语音 AI 流水线大幅降低了成本并缩短了响应时间。在本文中，我们将展示 Loka 用来解决常见痛点所采用的架构与方法：那些机械、缓慢的语音助手导致客户挂断电话，损害品牌声誉并推高支持成本。
传统语音助手为何不足
传统语音助手遵循一个三步流程，这从根本上带来了问题。首先，通过语音转文本（Speech-to-Text）系统将语音转换为文本。接着，通过大语言模型（LLM，Large Language Model）处理该文本。最后，使用文本转语音（Text-to-Speech）技术将文本响应转换回语音。此流水线在每个步骤都会引入叠加延迟。结果往往是在听到响应前出现 3 到 5 秒的停顿。这种延迟破坏了自然对话的感觉。打断或纠正助手变得笨拙且令人沮丧。
考虑一个汽车经销商的真实场景。客户打电话说：“我想看你广告里那款 SUV，但不是混动版。我只能在下午 5 点后过来。”助手需要同时解析多条信息。它必须理解意图、否定和日程约束。传统系统在处理这种复杂性时很吃力，因为在转换过程中丢失了关键信息。当语音变成文本时，语调、犹豫和紧迫感都消失了。经销商场景让这些局限尤为突出。客户打电话时期望得到即时、有用的回复。在销售对话中，五秒钟的停顿仿佛永恒。更糟的是，如果助手理解错误需要澄清，延迟会叠加。对话变得冗长而非有用。
除了技术上的延迟，还有经济问题。服务数千个地点需要严格控制成本。传统实时语音系统在规模扩大时可能变得成本过高，尤其是在处理连续音频流时。糟糕的体验和高成本限制了语音 AI 的采用。企业需要一个更好的解决方案。
原生语音到语音模型
AI 的最新进展开启了一种根本不同的方法。开发者现在可以直接将音频流发送到语音到语音模型，这些模型将理解、推理和生成为统一的系统。通过端到端处理音频，这些模型捕获了传统纯文本流水线会遗漏的语调、情感和微妙线索。
为了验证这种方法，严格的测试至关重要。我们使用了 Big Bench Audio 这一衡量语音输入推理能力的基准。Amazon Nova 2 Sonic 在语音推理得分上达到了 87.0。这超过了 Gemini 2.5 Flash Native Audio (Live API) 的 71.0 和 GPT Realtime 的 83.0。这些得分证实了原生音频处理并不会为了速度而牺牲智能。该模型能够处理真实经销商场景中复杂的多部分请求。
图 1 – 语音推理得分对比 – Big Bench Audio
仅凭推理能力对于生产系统来说还不够。延迟决定了对话是感觉自然还是机械。Nova 2 Sonic 的首帧音频响应时间（Time to First Audio）为 1.39 秒。这种响应时间允许自然的“打断插入”（barge-in）行为。当用户打断对话时，语音助手能够自然回应。这种体验符合人类对话模式。
图 2 – 首帧音频响应时间对比 – Big Bench Audio
成本效率也得到了提升。Nova 2 Sonic 的输入音频成本约为每小时 0.27 美元（基于发布时的定价）。这低于同类实时模型和传统方法。
图 3 – 每小时音频成本对比 – Big Bench Audio
为了在延迟和成本之外衡量质量，我们需要一套结构化的评估体系。我们构建了一个自动化流水线，使用 LLM（大语言模型）作为评判员。每个对话在五个维度上按 1-5 分进行评分。回复恰当性衡量回复是否相关且上下文正确。意图理解评估智能体是否把握了用户的深层目标。完整性追踪是否提供了所需的信息或操作。对话自然度衡量对话流畅度、轮流发言、语气和拟人化程度。
将 Amazon Nova Sonic 与 Amazon Nova 2 Sonic 进行比较，能看出明显的进步。回复恰当性从 2.5 提高到 2.9。意图理解从 2.9 提升到 3.0。最显著的是，完整性从 1.8 跃升至 2.5。这意味着智能体完成复杂任务的能力大幅提升。对话自然度从 2.5 提高到 2.8。总体评分从 2.4 提升到 2.7。这些改进直接转化为经销商处更好的客户成果。
| 指标（1-5 分制） | Nova Sonic（基准） | Nova 2 Sonic | 变化 |
|---|---|---|---|
| 回复恰当性 | 2.5 | 2.9 | +0.4 |
| 意图理解 | 2.9 | 3.0 | +0.1 |
| 完整性 | 1.8 | 2.5 | +0.7 |
| 对话自然度 | 2.5 | 2.8 | +0.3 |
| 总体评判得分 | 2.4 | 2.7 | +0.3 |
表 1 – 五个维度上的语音到语音模型指标对比
工程化构建对话式 AI 智能体
有了强大的基础模型，下一个挑战是优化。我们将提示词视为代码，根据测量的性能进行迭代。基准的 Nova 2 Sonic 配置总体评分为 2.7。经过第一次提示词优化后，评分上升到 3.1。第二次迭代达到了 5.0 分制下的 3.8 分。这一改进源于更好的轮流发言纪律和重复控制。智能体学会了何时说话、何时倾听以及何时提出澄清性问题。
| 配置 | 回复恰当性 | 意图理解 | 完整性 | 错误恢复 | 对话自然度 | 总体评判得分 |
|---|---|---|---|---|---|---|
| Amazon Nova 2 Sonic（基准） | 2.9 | 3.0 | 2.5 | 2.6 | 2.8 | 2.7 |
| Amazon Nova 2 Sonic（提示词 v1） | 3.2 | 3.3 | 3.0 | 2.8 | 3.9 | 3.1 |
| Amazon Nova 2 Sonic（提示词 v2） | 3.7 | 3.9 | 3.9 | 3.8 | 4.1 | 3.8 |
表 2 – 提示词增强后五个维度上的语音到语音模型指标对比
团队通过多种方式改进了基准提示词，将其演化为两个提示词模板。他们将硬编码的经销商详情替换为模板化变量，例如 {assistant_name} 和 {dealership_address}。这一改动使得提示词可以在任何经销商处复用。
团队将格式从编号列表改为在清晰标注的标题下使用项目符号。像“工具使用规则”、“错误恢复”和“对话结束”这样的标题为模型提供了更清晰的行为边界。这种结构减少了不同主题之间的指令混淆。
团队在提示词中加入了具体的行为示例。这些示例精确展示了如何在不重复呼叫者话语的情况下表示确认。他们还引入了一个回复前检查清单，促使模型在每次回复前进行自我审核。
Amazon Bedrock Prompt Management 自然而然地成为了整个生命周期的管理平台。它允许团队使用唯一的 Amazon Resource Name (ARN) 存储每个模板版本。他们可以将变更从草稿提升到生产环境，而无需改动应用程序代码。
当新经销商上线时，其特定变量会在运行期间通过 Amazon Bedrock API 注入。这意味着同一个核心提示词服务于每个客户，同时保持完全可定制。
团队添加了 AWS Identity and Access Management (AWS IAM) 访问控制，以限制谁可以编写、批准或部署提示词变更。这为此前非正式的编辑流程带来了适当的治理层。
这种方法将提示词工程从一次性任务转变为可重复、可审计的工作流。随着经销商数量和使用场景的增长，该工作流能够随之扩展。
真实世界测试需要模拟实际经销商通话中的边缘场景。我们测试了愤怒的客户、忙碌的家长、话多的客户、困惑的客户以及年长来电者等场景。
忙碌家长场景在五个维度上均获得了 5.0 分。智能体完美地处理了打断、背景噪音和时间压力。愤怒客户场景总体评分为 4.5 分。智能体保持了冷静、同理心，并专注于解决方案。困惑客户场景同样获得了 4.5 分。智能体耐心地澄清问题，同时不显得居高临下。
| 聊天示例 | 响应适当性 | 意图理解 | 完整性 | 错误恢复 | 对话自然度 | 总体评分 |
|---|---|---|---|---|---|---|
| 愤怒客户 | 4.5 | 4.5 | 4.0 | 4.5 | 4.5 | 4.5 |
| 忙碌家长客户 | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 |
| 话多客户 | 3.5 | 3.0 | 2.5 | 2.0 | 4.0 | 3.0 |
| 困惑客户 | 4.5 | 4.5 | 4.5 | 5.0 | 4.5 | 4.5 |
| 老年客户 | 3.5 | 3.0 | 2.5 | 2.0 | 4.0 | 3.0 |
| 平均 | 4.2 | 4.0 | 3.7 | 3.7 | 4.4 | 4.0 |
表3 – 基于客户角色的语音到语音模型评估
两个场景揭示了尚存的改进空间。话多客户和老年客户案例的整体评分均为3.0。当用户提供冗长、绕弯的输入时，语音助手在理解结构上遇到困难。在这些情况下，完整性评分降至2.5。错误恢复降至2.0。这些结果明确了未来提示工程（prompt engineering）的改进方向。尽管如此，边缘案例的平均评分仍为4.0，表明该模型具有强大的实际部署能力。
构建正确的架构对于生产部署至关重要。我们设计了一个无服务器、事件驱动的系统，使用 LiveKit 作为传输层。LiveKit 抽象了 WebRTC（适用于 Web 客户端）和 会话初始协议（SIP）（适用于电话通话）的复杂性。这使得工程团队能够完全专注于代理逻辑。
图4 – 对话式 AI 助手 – 解决方案架构
语音助手通过基于 Python 函数的工具与经销商运营系统集成，这些工具代表了助手在对话过程中可以执行的操作。常用工具包括库存搜索、预约预订和客户数据查询。这些工具充当 Amazon Nova 2 Sonic 和后台服务之间的集成层。模型决定何时使用某个工具，Python 函数执行相应的 GraphQL 查询或变更操作，并将结构化数据返回给代理。
AWS Fargate 提供了计算层。我们将 LiveKit Agents 容器化并部署在 Amazon Elastic Container Service（Amazon ECS）上。这使得代理工作节点与媒体服务器能够独立扩展。在经销商高峰时段，资源可以动态优化。Amazon Relational Database Service（Amazon RDS） 被用作持久化关系型存储，用于存储结构化应用数据，包括经销商配置、对话历史和客户记录。
实时语音助手无法容忍数据库延迟。Amazon ElastiCache 用于处理房间管理和跨分布式任务的临时会话协调。Amazon Bedrock 提供了对 Nova 2 Sonic 模型的直接访问。
浏览器客户端通过 WebRTC（Web 实时通信）连接，这是一个用于点对点音频、视频和数据传输的开源框架。传统电话通话通过 SIP 中继进入，经由网络负载均衡器（Network Load Balancer）路由，从而为媒体数据包提供 TCP/UDP 吞吐量。
可观测性来自 Langfuse，它自托管在 AWS 上。Langfuse 追踪了每一个代理决策和工具调用。这些数据被反馈到评估管道中，用于持续改进。
演示
以下视频展示了该功能。
对话式 AI 的新标准
从基于文本的聊天机器人到实时语音助手的转变，不仅仅是界面的改变。它需要完全不同的基础设施和思维方式。Nova 2 Sonic 同时满足了三个关键的工程需求。首先，它提供了高推理能力，无需中间文本转换。其次，它实现了低延迟，使得自然的类人打断成为可能。第三，它具备生产可行性，并且对于数千个地点具有成本效益。
对于汽车经销商来说，这项技术已经在生产中推动收入增长。客户在打电话时能立即得到有用的回复。复杂请求可以在一次对话中顺利处理。预约能够正确安排，无需令人沮丧的来回沟通。
其影响远不止于汽车销售。需要实时、智能语音交互的行业都能从中受益。想象一个旅行代理，通过自然对话帮助你规划整个假期。设想一个教育辅导，适应你的说话风格和学习节奏。考虑医疗调度系统处理复杂的保险和可用性问题。
语音到语音AI（Speech-to-speech AI）已达到生产就绪状态。开始在您自己的AWS环境中试验Nova 2 Sonic。构建原型，测试边缘情况，并探索您的业务中可能的应用。
本文是AWS与Loka之间的合作成果，Loka专注于构建生产就绪的AI解决方案。Loka的团队已经解决了围绕架构、评估和优化的难题。他们在汽车经销商的体验直接适用于其他行业。
语音到语音AI仍处于早期阶段。最好的应用尚未被发明。您的行业知识结合这项技术可以创造出突破性的解决方案。现在就开始。