评估语音智能体：话轮交替、工具调用与富有表现力的语音

三类决策，三项测量

我们分别衡量这三种能力。一个助手可以等你说完话，但仍然选择错误的工具。它也可以在遗漏了你要求的感情或风格的情况下清晰地说话。

我们在 Apple M5 Pro 上使用 48 GiB 的内存运行了本地模型。对于云服务，我们测试了结果中列出的模型版本和设置。

每个部分解释了我们使用了多少录音、测试了哪些语言以及任何仍在检查中的结果。这些细节有助于您比较分数。

TurnBench：停顿何时意味着话轮结束

TurnBench 区分说话者结束话轮和话轮内的停顿，也区分打断与“嗯哼”之类的简短附和声。下面的表格主要评估话轮结束检测。

我们使用了 TurnBench 的公开开发录音及其自己的评分代码。该表显示了每个模型的运行规模。官方排行榜使用独立的测试集。

召回率是模型检测到的真实轮次结束的比例。FPR (误报率)是在一个轮次内被错误地视为说话者结束的标记停顿的比例。

我们的排行榜按 Youden’s J（J = 召回率 − FPR）排序，显示为 J ×100；数值越高越好。官方测试排行榜按召回率对模型进行排名，将 FPR 高于 15% 的模型排在达到该限制的模型之后。

VAP 在我们的五段对话比较中具有最高的 Youden’s J：88.2% 的召回率和 7.4% 的 FPR。Mimi 的误报更少，为 2.0%，但捕获的轮次结束更少，并且决策时间更长。

VAP (语音活动投射) 监听两个说话者在单独的音频通道上的声音，并预测他们即将发生的语音活动。它利用最近的对话来估计当前说话者是否会继续发言或将发言权移交给对方。 关于 VAP 的研究 表明它学会了利用语音中的线索，例如音高和节奏。

我们运行的版本是在来自 otoSpeech 的 104 小时对话音频上进一步训练的。我们的理解是，这种训练及其对两个说话者的视角有助于解释我们在比较中取得的优异结果。

我们还在两段开发对话上测试了可下载的 p99 CoreML 模型和两个 VAP 导出版本：包含 148 个轮次结束点和 94 个轮内停顿，使用的是固定的决策策略。p99 检测到 134 个结束点，有 15 个误报；两个 VAP 导出版本分别检测到 124 个，各有 2 个误报。每个导出版本都做出了与其原始检查点相同的事件决策。 验证协议 会记录输入和阈值。VAP 行保留了更大的五个对话运行结果。

p99 CoreML 和 VAP CoreML 模型具有 speech-swift API。 VAP ONNX 通过 C++ 和 Android 运行时运行。 集成指南 涵盖了下载和音频输入。您的应用程序设置响应策略。

SLURP：根据语音指令选择行动

SLURP 包含带有标注动作和参数值的口述 home-assistant 请求。在我们的路由测试中，每条录音都附带了十个候选动作和一个无动作选项。

我们的 1,000 条记录的设置包括 810 个有正确可用动作的请求和 190 个没有该动作的请求。我们期望在后 190 个请求上不采取任何动作。这检查了模型是否会在其动作不可用时拒绝请求。

大多数系统使用 1,000 条记录，包括近距离交谈和远场音频。远麦克风准确率衡量的是在请求工具可用时，从更远距离录制的记录上的正确选择。尽管缺少工具仍呼叫 计算了即使标注的工具不存在，系统仍然返回动作的请求。它汇集了近距离交谈和远场记录，并且不测量来自背景语音或静音的激活。表格显示了确切的计数。

本地 Parakeet → Gemma 4 E2B 流水线达到了 75.2% 的远麦克风准确率，接近 Nova 的 75.9%，落后于 GPT Audio 的 83.0%。但在正确工具不可用的 190 个请求中，Gemma 仍然选择了动作 88 次：其误激活率为 46.3%。一个例子是“删除项目”：当列表移除不可用时，它选择了日历移除。它还拒绝了 88 个正确工具可用但选择错误工具的请求，并在另外 69 个请求中选错了工具。

Jev 和 GLiNER 在 423 个支持的远场麦克风请求中，在 311 个请求上选择了正确的工具，准确率为 73.5%。当缺少正确工具时，它们的行为会发生变化：Jev 在 190 个请求中有 22 个（11.6%）仍然选择了一个动作，而 GLiNER 则在 74 个（39.0%）请求中这样做。例如，GLiNER 将降低说话人音量的请求解释为调暗灯光，因为缺少音量工具。这些示例选择了与请求不一致的动作。更广泛的工具描述也可能重叠：一个食谱请求可能会被发送到通用的烹饪工具。我们的计数遵循标注的意图，因此不能证明每个替代方案在语义上都是不合理的。

Nova 在匹配工具和所有必需的参数值方面得分最高：45.4%，或 810 个支持请求中的 368 个。它在 643 个请求中选择了正确的工具，但在其中 275 个请求的参数未能匹配。在 147 个案例中，值与参考值不同；另外有 128 个案例遗漏了至少一个参数，有时还伴有值差异。

最常见的值不匹配是时间，出现在 34 个此类案例中。我们还看到了缺失的日期和命名错误的字段。对于包含“本周”的闹钟请求，Nova 返回了时间但遗漏了日期。一些失败是措辞差异：在严格的文本比较下，“lasagna”与参考值的“lasagne”不匹配。该分数计算了这两种类型的不匹配。

InstructTTSEval：表达方式也会出错

对于 InstructTTSEval，我们保持口述脚本固定，并使用三种类型的指令生成单独的片段：

• APS (Acoustic-Parameter Specification) 提供详细的语音设置，例如音高、语速、音量和声纹质地。例如：“低音调、慢语速、柔和的音量和略带气音的声音。”
• DSD (Descriptive-Style Directive) 用自然语言描述表现方式，使某些语音特征保持开放。例如：“用温暖而令人安心的语气说话。”
• RP (Role-Play) 提供一个角色或情境，并要求模型推断出应如何发音。例如：“你是一位安慰焦虑病人的医生。”

每种类型的百分比显示了生成的语音遵循该指令的频率。

较大的队列包含 25 条英语和 25 条中文源文本，每种类型进行三次检查：每个系统 150 个片段。Nova 覆盖了 25 条英语文本，共 75 次检查。总体得分是总通过次数除以总检查次数；在任务规模相等的情况下，它是 APS、DSD 和 RP 的平均值。保存的 Gemini Pro 评估模型提供风格裁决，而转录检查单独检查口述词语。

Original recordings 是基准测试的人工源音频。我们使用与进行 150 次检查的指令和评估模型相同的指令对它们进行评分，为合成语音提供参考点。其 73.3% 的得分意味着评估模型接受了 150 个指令检查中的 110 个。

在匹配的 150 个检查队列中，FireRedTTS3-Instruct 得分为 65.3%，MOSS-VoiceGenerator 得分为 56.0%。Google 的 TTS 运行得分为 67.3%。在 75 个英语检查中，FireRed 得分 72.0%，MOSS 得分 52.0%，Google 得分 72.0%。VoxCPM2 的 BF16 运行仍为 59.3%；其角色扮演结果 46.0% 低于其语音描述和指导结果。较大的 Qwen CustomVoice 检查点得分为 52.7%，而较小的实验输入运行得分为 48.0%。仅凭模型大小并不能决定分数。

我们的 ElevenLabs 指令到标签的转换降低了请求的歌唱和一些情感变化。CosyVoice3 在 50 个 APS 剪辑中有 48 个未能通过词内容检查；其生成设置还遗漏了官方实现中存在的参考条件化。这些问题仍然需要修正输入验证。Fish 的修正运行和几行其他记录包含的评估模型回复声称音频不可用；我们保留了这些裁决，并将受影响的行标记为临时。这些是针对我们的移植版本、输入适配器和评估模型的结果，而不是发现上游模型在每个实现中都有相同限制。

人类原始录音的失败主要集中在角色扮演：50 项检查中有 29 项未通过，相比之下 APS 为八项、DSD 为三项。真实录音可以符合详细的声音描述，却未必符合指定角色；评估模型也可能出错。参考行帮助我们解读指令遵循得分，并不是对人类语音质量的评价。

按描述设计声音可作为合成后端

Qwen 的 VoiceDesign 检查点根据书面描述生成声音。CustomVoice 则将指导应用于选定的预设音色。检查点和控制通道都很重要：名为“instruction”的字段并不能赋予模型它从未训练过的能力。

我们在相同的五个英语和五个中文源上测试了 Qwen3-TTS 1.7B VoiceDesign 和 Breeze TTS 2，每个模型进行 30 个检查。四个校准检查不在其分数内。我们保留了所有输出，包括每个模型的单次口语标记。

VoiceDesign 通过了 23/30 项检查，Breeze 通过了 20/30 项。三类任务共用十段原始录音，因此这只是开发阶段的初步筛查。配对差值为 10 个百分点，但按原始录音分组计算的区间很宽，且包含零。评估模型的设置也与较大样本组不同，因此该试验并不能证明 VoiceDesign 优于 Google 的 67.3% 结果。

FireRedTTS3-Instruct 和 MOSS-VoiceGenerator 现在在上面的表格中各有 150 个风格检查。单独的内容检查发现 FireRed 剪辑有 0/150 个词错误，MOSS 剪辑有 12/150 个词错误（高于 30%）。它们用于短脚本的运行时样本仍保留在 Space 中。在温暖的英文脚本上，FireRed 的第一个可用 PCM 大约是 4.50 s，MOSS 是 0.47 s；FireRed 返回完整的波形，而 MOSS 进行流式传输。这些时间数据不能确立指令质量或匹配的质量-速度排名。现有模型的延迟和内存认证仍不确定。

话轮交替研究已超越结束点检测

研究快照：2026 年 10 月 30 日。包含更早基线之外新提交的 官方 TurnBench 保留测试集。p99 的 系统概述描述了 6.1 百万个学习参数、额外的分类头以及使用两个音频通道的轮次策略。其 Apache 2.0 下载包含 5.3 百万参数的单声道模型。我们的轮次管理表包含了该可下载的检查点。

LiveKit 的 eot-bench 用 14 种语言的真实人机对话对其进行了补充。它扫描了端点检测策略，并在固定的误截止预算下比较了延迟，包括完整的权衡曲线。这对多语言产品是一个有用的后续步骤，因为在英语中有效的阈值不一定适用于其他语言。

MultiPartyTurnBench 本月提交，将楼层控制扩展到 2 到 5 个说话人。其作者报告了强大的轮次进入性能，以及接近随机选择性打断的处理能力，针对评估的智能体。它生成的对话提供了受控测试，需要与真实音频检查相结合。会议和共享房间需要的不仅仅是扩展一个双说话人端点规则。

Full-Duplex-Bench v3 将真实的流利度差的语音与链式工具调用配对，暴露了自我修正和多步骤失败。本月提交的 DuplexAct 评估交互动作以及智能体是否能跟进。我们认为这些是用于检测到事件和完成有用的交互之间的差距的互补测试。我们在本文中尚未运行这些新的基准测试。

私有语音合成、定向配音与英语声音选择

Soniqo 的 私有运行时和设备端 SDK 为您自己的环境中的语音应用提供了构建模块。我们与构建表达性合成和情感导向配音流程的团队合作：保留预期的词语，选择一种声音，提供一个表现要求，然后在上下文中审查结果。

您可以将语音设计后端插入到合成阶段，同时保持轮次策略和工具执行的分离。对于叙述场景，应用程序可以指定平静的安慰或日益增长的紧迫感，而不是推断一种情绪并在没有导演控制的情况下改变表现力。配音工作流程还需要时序、说话人连续性和听觉审查；上述三个基准测试并未认证完整的整个工作流程。

Kokoro 系列目录中包含 美式和英式预设语音。风格感知的后端增加了自然语言语音描述。预设选择、语音设计和克隆是不同的控制项，支持情况因模型而异。请求的地域口音需要由熟悉该方言的听众进行评估；转录准确性和说话人相似度不能证明真实性。

如果本地后端和模型资产已配置，合成可以在部署环境中进行。确切的部署和模型选择取决于目标硬件和模型的条款。仅用于研究的基准数据和受限的模型权重不构成全面的商业许可。

这些测量能支持哪些选择

• 根据其操作点选择轮次策略。 在我们的开发切片中，VAP 和 Mimi 提供了不同的召回率、误报率和延迟权衡。目前已保留的研究已经超越了最初的基线。
• 计算完整的工具请求次数。 在我们的十动作设置中，Nova 在 643 个支持的请求上选择了正确的工具；另外 368 个也具有匹配的参数。错误的值和缺失的字段构成了差距。
• 按指令类型测试交付方式。 在几次运行中，角色扮演是一个较弱的领域。VoiceDesign 的试点项目需要进行更大规模的匹配比较，而不是声称有新的总体获胜者。

我们接下来有用的测量是：一个包含匹配判定的更大 VoiceDesign 队列、在固定截止率下的多语言端点检测，以及将纠正传递到最终工具调用的交互测试。人类对口音、自然度和性能连续性的审查应与生产语音工作的自动得分并列。

阅读 实时结果和协议，探索 speech-swift，或讨论 私有部署。上表保留了链接快照中的运行规模和设置。