AWS · ML 博客

大规模评估你的Amazon Nova Sonic语音代理,无需麦克风

Evaluate your Amazon Nova Sonic voice agent at scale, no microphone required

二〇二六年六月八日 · 英文原文

Amazon AGI团队与AWS专家联合推出Nova Sonic Test Harness开源框架,用于自动化测试Amazon Nova Sonic语音代理。该框架通过JSON定义测试场景,使用LLM-as-judge技术评估目标达成、响应准确性、工具使用等6项指标,支持文本/Polly TTS/脚本化/数据集驱动四种输入模式。工具可并行运行数百个场景,检测音频与文本输出不一致的幻觉问题,处理8分钟会话超时与双向流式传输。

语音代理正在改变企业与客户的互动方式,通过自然的口语对话处理预约预订、订单查询、账户管理等事务。但随着这些代理能力不断增强,一个根本性的挑战随之而来:如何测试它们?与可以编写输入脚本并断言输出的文本聊天机器人不同,语音代理的运行范式截然不同。它们双向传输音频流,响应具有非确定性,在多轮对话中保持上下文,并实时使用工具。目前大多数团队测试的唯一方法是让人实际与系统对话并听取返回结果。这既缓慢、不一致,也无法扩展。这种测试缺口给构建语音应用的团队带来了两个关键问题:迭代系统提示和工具配置极其缓慢。每次调整提示或修改工具定义以提高准确性时,都需要手动重新测试数十个对话场景,以判断效果是变好还是变差。没有自动化反馈,提示工程就变成了猜测。缺乏可靠的语音代理质量评估框架。在部署变更前无法运行回归测试套件。无法衡量代理在数百个场景中是否正确处理边缘情况。无法捕捉细微的回归问题,比如代理突然忘记确认预订,直到真实用户遇到问题。如果你有3个用户角色下的50个对话场景,就需要进行150次手动测试,每次测试需要几分钟的实时交互。每次修改提示后都这样操作,你将在质量保证上耗费数天时间。在这篇文章中,我们将向你介绍 Nova Sonic Test Harness,这是一个我们为解决这两个问题而构建的开源框架。它既可作为快速迭代工具,用于调整系统提示和工具配置(运行对话、查看结果、调整、重复),也可作为全面评估框架,用于大规模验证语音代理质量。它能自动与 Amazon Nova Sonic 完成多轮对话,使用 LLM-as-judge 技术进行评估,甚至能检测模型音频输出与文本输出不匹配的情况(音频幻觉)。无需麦克风。

为什么语音到语音测试与众不同

如果你之前测试过基于文本的大语言模型(LLM),可能会想为什么不能直接沿用那些工具。以下是语音代理测试本质上更困难的原因:

测试工具处理了所有这些挑战。让我们看看它是如何工作的。

测试工具的工作原理

在高层面上,该工具做四件事:配置一个测试场景,与 Nova Sonic 运行一次完整对话,评估结果,并生成报告。整个流程无人值守运行。你在一个 JSON 文件中定义场景,然后回来查看结果。

图1:架构概览。测试工具协调用户模拟器、Nova Sonic 和 LLM 评判器,跨越 AWS 服务。

让我们逐一了解每个阶段。

定义测试场景

每个测试都从一个 JSON 配置文件开始。可以将其视为描述一个对话场景:Nova Sonic 扮演什么角色,调用者是谁,有哪些工具可用,以及“成功”的标准是什么?这是一个真实示例,测试一个预约预订代理:

{
  "test_name": "healthcare_appointment_booking",
  "sonic_system_prompt": "你是史密斯医生办公室的接待员...",
  "sonic_voice_id": "tiffany",
  "sonic_tool_config": {
    "tools": [{"toolSpec": {"name": "checkAvailability", "..."}}]
  },
  "user_model_id": "claude-haiku",
  "user_system_prompt": "你是一个打电话预约的病人...",
  "max_turns": 8,
  "auto_evaluate": true,
  "evaluation_criteria": {
    "user_goal": "预约下周二的门诊",
    "evaluation_aspects": ["目标达成", "响应准确性", "工具使用", "对话流畅度"],
    "rubrics": {
      "目标达成": [
        "代理是否确认了具体的日期和时间?",
        "代理是否收集了患者姓名?"
      ]
    }
  }
}

关键洞察在于,你定义的是目标和评估标准,而不是预期输出。由于 Nova Sonic 每次响应都不同,我们根据评分标准进行评估,而不是检查精确字符串。一个模型注册表(models.yaml)将像 claude-haiku 这样的短别名映射到完整的 Amazon Bedrock 模型 ID,这样当模型版本变化时配置不会失效。

运行对话

有了配置文件后,工具会自动运行对话。以下是每一轮发生的情况:

图2:从配置到结果的四阶段测试流程。

图3:单轮对话内的数据流。

  1. 用户模拟器生成消息。 一个 LLM(例如,Amazon Bedrock 上的 Claude Haiku)读取到目前为止的对话,并决定调用者接下来会说什么。它保持角色设定。如果角色是“不耐烦的客户”,它就会表现得急躁。
  2. 消息发送给 Nova Sonic。 可以是文本(快速,适用于大多数测试),也可以是使用 Amazon Polly 合成的音频(用于测试完整的语音识别流程)。
  3. Nova Sonic 流式返回其响应。 文本、音频以及可能的工具调用会异步到达。工具使用响应式流实时处理所有这些数据。
  4. 工具检测到本轮对话结束。 Nova Sonic 分两个阶段生成文本(推测性,然后是最终版)。当所有推测性块都最终确定后,本轮对话完成。这比等待静默或使用超时更可靠。
  5. 工具调用在流中处理。 如果 Nova Sonic 请求调用一个工具(比如检查预约可用性),注册的处理程序会运行并返回结果,而不会中断连接。
  6. 所有内容都被记录。 最终文本、音频 WAV 文件、工具调用和时序元数据都被保存下来。然后循环重复。

如何处理长对话?

Nova Sonic 连接大约在8分钟后超时。SessionContinuationManager 透明地处理这个问题:它监控连接时长,在超时前(默认:6分钟)创建一个新会话,并将对话历史重放到新会话中。你的测试场景无需了解这一点。它只是正常工作。

评估质量

对话结束后,工具将完整的转录文本传递给一个独立的 LLM 评判器(例如,Claude Opus)。评判器对测试设置一无所知。它只看到对话和评估标准。这可以防止偏见。

图4:LLM 评判器使用 YES/NO 评分标准独立评估每个指标。

评判器评估六个内置指标,分为三个层级:

指标 层级 检查内容
目标达成 关键 对话是否完成了用户想要的事情?
响应准确性 关键 事实、数字和陈述是否正确?
工具使用 重要 是否使用正确的参数调用了正确的工具?
对话流畅度 重要 听起来是否像自然对话?
系统提示合规性 重要 代理是否保持角色设定?
语音格式 建议 响应在口头朗读时听起来是否自然?

层级系统决定了通过/失败逻辑:两个关键指标都必须通过才能获得整体 PASS。重要指标计入通过率分数。建议指标会被报告,但不影响判定结果。

每个指标通过多个评分标准问题进行评估,这些问题得到严格的 YES/NO 答案。一个指标只有在其所有评分标准问题都通过时才通过。这意味着当某件事失败时,你确切知道是哪个问题失败了,并且可以阅读评判器的推理来理解原因。

你还可以为你的领域定义自定义评分标准问题。对于医疗保健代理,你可以添加:“代理在预订前是否验证了保险信息?”对于银行代理:“代理在执行转账前是否确认了转账金额?”

查看结果

根据你的工作流程,结果有多种格式:

捕捉音频幻觉

语音到语音模型同时生成文本和音频输出。大多数情况下它们是一致的。但偶尔,Nova Sonic 可能写的是一个内容,说的却是另一个。想象一下,一个语音代理在音频中告诉客户他们的订单“下周一”到达,而文本流显示“下周二”。如果你只检查文本日志,你永远不会发现这个问题。

  1. 将每轮对话的音频上传到 Amazon Simple Storage Service (Amazon S3)。
  2. 使用 Amazon Transcribe 转录音频(实际说了什么)。
  3. 使用 LLM 将转录结果与文本输出进行比较。
  4. 对每个差异进行分类:填充词、措辞变体或事实错误。

每轮对话都会得到一个判定结果:

这对于传达具体事实的语音代理最为重要:预约时间、价格、电话号码、药物名称、确认码。其中任何一个出现幻觉都可能直接伤害用户。

大规模测试

测试一个场景对开发很有用。但为了在部署前获得信心,你必须测试数十个场景,涉及不同的角色、边缘情况和对话路径,并且必须重复运行以考虑非确定性。

图5:批量执行并行运行测试会话,并生成聚合质量报告。

批量运行器使这变得实用:

# 并行运行12个医疗保健场景
python -m cli.main --scenarios-dir scenarios/healthcare --parallel 4

# 重复运行同一场景10次以测量方差
python -m cli.main --config configs/order_status.json --repeat 10 --parallel 5

# 运行包含100个条目的评估数据集
python -m cli.main --dataset datasets/healthcare_eval.jsonl --parallel 8

该工具附带即用型场景包:12个医疗保健场景(预约预订、保险理赔、转诊),8个银行场景(转账、余额查询、争议),以及5个客户服务变体(愤怒、冷静、困惑的调用者,具有不同的订单状态)。

批量运行后,仪表板显示所有场景的通过率、每个指标的细分、共失败相关性(哪些指标倾向于一起失败),以及运行之间的并排比较。你可以确切看到提示更改后哪些方面得到了改进或出现了退化。

选择合适的输入模式

不同的测试需求需要不同的方法。该工具支持四种输入模式:

模式 工作原理 何时使用
文本(默认) LLM 生成的消息作为文本事件发送 日常测试、提示迭代、工具验证
Amazon Polly TTS 使用 Amazon Polly 将用户文本合成为音频 测试完整的自动语音识别(ASR)流程、生产环境真实条件
脚本化 预定义消息,不涉及 LLM 回归测试、运行间精确可重复性
数据集驱动 从 JSONL 或 Hugging Face 加载场景 基准评估、大规模测试套件

文本模式最快,支持最高的并行度。当你特别需要测试 Nova Sonic 如何处理真实音频输入(包括潜在的 ASR 误解)时,使用 Amazon Polly 模式。对于需要每次输入都相同的回归测试,使用脚本化模式。

入门指南

有关完整的设置说明、先决条件和配置详情,请参阅 GitHub 仓库。你将在五分钟内运行你的第一个自动化对话。

使用的 AWS 服务

服务 在工具中的功能 必需?
Amazon Bedrock 托管 Nova Sonic、用户模拟器 LLM 和评判器 LLM
Amazon Polly 将用户文本转换为语音用于音频输入测试 可选
Amazon S3 临时存储音频文件用于转录 可选
Amazon Transcribe 将音频转换为文本用于幻觉检测 可选

清理

Amazon Bedrock 模型调用按使用量付费,无闲置费用。如果你使用了可选服务,请删除为音频评估创建的任何 Amazon S3 存储桶(内部对象会自动清理,但存储桶本身会保留)。如果需要,可以从 AWS Management Console 中移除 Amazon Transcribe 任务。

结论

在这个工具出现之前,测试 Nova Sonic 语音代理意味着两件事之一:让人与它对话(缓慢、不一致、无法扩展),或者不测试它(有风险,尤其是在迭代提示或部署到新场景时)。Nova Sonic Test Harness 为你提供了第三种选择:自动化、可重复、可扩展的测试,覆盖完整的对话生命周期,从第一轮到评估再到幻觉检测。它处理了困难的部分(双向流式传输、会话超时、非确定性评估),这样你就可以专注于构建更好的语音体验。

关键要点

立即克隆仓库并运行你的第一个测试。随着你的 Nova Sonic 应用不断增长,测试也会随之增长。

关于作者

Osman Ipek Osman 是亚马逊 AGI 团队的应用 AI 架构师,专注于 Nova 基础模型。他通过实用的 AI 实施策略指导团队加速开发,专长涵盖语音 AI、代理系统、模型评估和 MLOps。

Lana Zhang Lana 是 AWS 全球专家组织中的生成式 AI 高级专家解决方案架构师。她专攻 AI/ML,重点关注 AI 语音助手和多模态理解等用例。她与媒体与娱乐、游戏、体育、广告、金融服务和医疗保健等不同行业的客户紧密合作,帮助他们通过 AI 转变业务解决方案。

译自 AWS · ML 博客 · 录于 二〇二六年六月八日