Hume 音频判定 API：语音 agent 缺的是一层可审计的判断

语音 agent 真正的缺口不在听得清不清，而在于它从不把「我认为刚刚发生了什么」写成任何可被读取的东西。Hume 在 2026 年 11 月 2 日发布的 Audio Decision API 把这层判断压成一次调用：音频、一句自然语言问题、一组候选答案进去，候选答案上的概率或时间片段出来，没有转写，也没有解释。这个接口形态在工程上站得住，但它买到的不是「更准」，而是「可回放、可单测、可复核」；它的可靠性上限由概率怎么定义、问题怎么发、字段怎么评测决定，不由模型大小决定。

一次调用把音频换成字段，而不是换成一段转写

这层接口的契约只有三样东西：提交一段音频、写一句自然语言问题、给出候选答案，一次调用换回候选上的概率分布。官方文档把请求限制得很死：一个请求 1 到 25 个问题，其中 noul、choice、score 合计不超过 20 个，span 不超过 5 个；问题 ID 由调用方自选，答案按同一个 ID 回填；音频 5 秒到 5 分钟，模型按 16 kHz 单声道听。四种原语的返回形态各不相同：noul 只给一个 0 到 1 的份额，连 confidence 字段都没有；choice 给被选中项、confidence 和按选项名索引的 probabilities；score 给概率加权均值、confidence、按层级索引的 probabilities 与 legend；span 给起止毫秒与概率，不给份额。choice 与 score 的 probabilities 各自相加为 1，而 score 的层级索引从 0 起，与量表上印的文字编号不同，读均值必须经 legend 换算。

四种提问形态分别对应四类问题，官方各自给了原文示例：noul 问「Does the customer sound frustrated?」，choice 问「Which best describes the agent's tone?」，score 问「How patient does the agent sound?」，span 问「Where does someone laugh, sigh or gasp?」。可问的维度列了十类，从语音与语种、说话人与声音、情绪与表达，到声学环境、非语音事件、对话动态、通信质量、意图与结果、社会与行为信号、时间与上下文信号。接口本身不返回任何文本：文档原话是「Each answer is numbers, not text」，并补上一句「There is no transcript, reply or explanation, so the calling code makes the decision」。这直接决定了一件事，开放式问题例如「来电者为什么打电话」它答不了，必须改写成 choice 并列出你可能的原因。Hume Docs

真正需要先钉死的是概率的含义。文档写得很直白：「A probability is the estimated share of raters, not the model's certainty」，并给出两个可操作的解读，noul 为 0.5 表示评分者会分歧，0.6 表示约 60% 的评分者会答「是」，而不是「有点是」。confidence 也不是模型自评置信度，而是评分者之间的一致程度，choice 的定义式是

$$\text{confidence} = \frac{p_{\max} - 1/n}{1 - 1/n}$$

其中 $n$ 是候选个数，$p_{\max}$ 是最高那一项的概率。所以一个 0.68 的 confidence 只说明评分者比较齐，不说明答案正确率是 68%。

这层在语音栈里站的位置，比它的名字更容易被误读。官方发布稿的架构图把同一段客户音频并行分给两路：一路进 Audio Decision API，得到挫败、失望、负面语气、低能量、背景噪声五个分数；另一路进 ASR，得到同一句话的转写；两路结果一起进 LLM，再结合业务规则做决策，最后交给 TTS 生成回复。

图注：判定层与 ASR 是同一段音频的并行两路，不是先后关系；两路结果在 LLM 里合并成一次决策，再交 TTS 生成回复。图中 0.82、0.76、0.71、0.34、0.05 是示意举例，不是实测值，也不代表任何评测成绩；这张图能说明位置，不能证明「一次调用替代了多个模型」，因为 ASR 与级联都还在。Hume API

概率这个词在 score 上还有一个更隐蔽的坑：同一个均值可以来自两种完全不同的评分者分布。官方文档用两张并排柱状图说明这件事，左边多数评分者选第 2 级，confidence 0.68；右边评分者向两端分裂，confidence 为 0；两者的 Mean level 都是 2。

图注：两图的均值都是 2，但一个来自评分者集中在第 2 级，一个来自评分者在两端分裂。所以只读 score 会丢掉「这条判断有多少共识」，必须同时读 probabilities 与 confidence。这里的 confidence 是评分者一致度，不是准确率。Hume Docs

厂商自报的数字要分层读。发布稿称模型与人类评审团平均判断的一致率为 70.7%，单个评分者基线是 56.5%，比较对象是「评审团平均」与「单个评分者」，既不是人类上限，也不是其他模型；同一页还提到训练规模，但同一件事在不同位置有三个口径：X 帖写「10M+ human judgments」，博客正文写「Tens of millions of these judgments」，正文另一处又写「millions」；连「10+ models 变成一次调用」这句话也只出现在 X 帖里，博客正文的措辞是「一组人类听众与多个不同模型判断的组合」，两句不能混用。这些全是厂商自报，样本量、语种、题型分布与评测集都没有公开，也没有独立复核。Hume API

产品页另给了一组对比：10 个 benchmark 平均 0.82 分、每屏中位延迟 0.23 秒，同样没有公开评测集与方法，10 项 benchmark 里只点名了三个。产品还停在 waitlist 且全站无定价，所以成本与延迟主张在公开状态下无法核验。产品页唯一一句把位置写清楚的定位语是「Use the Decision Model API as a decision layer in a voice-agent system with speech recognition and generation」，也就是判定层与语音识别、语音生成并列，而不是取代它们。Hume 产品页

级联的账本：每多问一件事，就多一个模型或一次调用

级联语音 agent 是一条五段链：采集、语音识别、大模型、语音合成、播放。判断类任务在这条链上没有位置，只能外挂模型：VAD、说话人分离、情绪识别各挂一个，再用胶水代码把结果融合进 prompt。外挂一条判断，代价不是一行配置。

图注：七阶段流程图，从 VAD 隔离说话人、转写、意图识别、对话管理、生成回复、交付，到持续学习，底部另有与说话并行的工具调用。这张图出自同厂商另一篇官方洞察页，不是延迟预算那篇博客正文的配图，而且比五段链多出意图识别、对话管理、持续学习三层；图中的 150 ms 与 under a second 不是受控基准。ElevenLabs 洞察

延迟要按行项目算，不能用「模型推理时间」代替用户体验。厂商工程博客给了一份端到端 TTFA 预算，从用户停止说话算到听到第一个采样，作者自己声明这些是 illustrative ranges，不是保证值。

表里最大的两项是 LLM 首 token 与链首 endpointing，不是音色。原文对 endpointing 的解释很具体：系统为了判断用户已经说完而等待的静默总量，如果非要等 700 ms 静音才判轮次结束，就等于给每一轮加上 700 ms。表看起来像串行，作者自己就否定了这种读法，说真正省时间的是把各段重叠起来，例如把稳定的 STT partial 先喂给 LLM，把 LLM 输出按句边界切块喂给 TTS。这些毫秒数只能当结构参考，读数必须在自己的部署上重测，并报 P50 与 P95 而不是均值。ElevenLabs 工程

多挂一个判断的隐形账，VoxTurn 用一句话讲清了：开放式检测器下，「each extra decision costs another model or another call」，而在 14 语言 eot-bench 上，这类检测器在超过四分之一的中途停顿里把用户切断了。同一篇论文的引言把量级写得更具体，300 ms 预算下开放式检测器的 14 语言均值是 28% 或更高的误切断率。这就是级联账本的真实结构：每加一个判断，要付一次延迟、一次调用，以及一份误判带来的体验损失，而误判在轮次管理上等于直接打断用户。VoxTurn

同一件事的学术版本：一次前向就能读出多个判断，瓶颈在训练目标

把闭合判断压成一次前向，在学术侧已经被独立实现并量化，不是一家厂商的营销说法。DuplexJev 的做法是：冻结的 ASR 编码器产出逐层隐状态，经一个小连接器送进冻结的 LLM，每个问题把选项写成字母 A/B/C/D，跑一次前向，取答案位置的 logits 限制到选项 token 上重归一化，得到选项分布。整个过程不生成任何 token，所以输出恒为合法选项，取最大概率还能当弃答阈值。

图注：灰底是冻结，橙底是可训练，只有连接器被训练。变体 A 用交叉注意力融合三层编码器隐状态，变体 B 只投影最后一层；右侧冻结 LLM 跑一次前向，在选项 token 上直接给出分布，没有解码步骤。图中没有任何准确率或延迟数字，「0 decode steps」是机制描述，不等于端到端零延迟。DuplexJev

代价对比在这一层最直观。单张 H200 上，把 10 个判定读成单 token 需要 92 ms，让模型生成同样 10 个字段的 JSON 需要 1.57 s，级联还要另付 411 ms 的自回归转写；8 张 H200 的节点上，8 段音频的 80 个判定在 94 到 103 ms 内完成。这些是预印本作者自报的设置，绑定特定硬件与自建评测集，不能当任何商业产品的性能背书。

更有价值的结论是反面的。只用转写蒸馏训出来的模型，性别判定停在 53%，接近随机；而在同一个模型编码器的最后一层做线性探针，性别能解到 97–99%，情绪 88–93%。也就是说信息已经在表征里，是训练目标没有要求模型用它，问题不在连接器容量。换成混合目标，也就是内容蒸馏加选项 token 交叉熵，性别与情绪都能到 90，代价是 spoken QA 从 83% 降到 82%。DuplexJev

同样一件事在表征层有独立证据。四个开源音频语言模型都在编码器后三分之一层达到约 82–85% 的 7 类说话风格线性可解码度，随机基线是 14.3%，但在到达输出之前一致衰减：开放式语调识别只剩 19.68%、53.70%、22.57%。projector 的作用是把表征几何重排，不是删除信息，跨层探针在 projector 边界处仍有约 78–81%；真正的差异出现在解码器轨迹上，有的平坦保持，有的单调侵蚀，有的在骨干边界急降后部分回升。Paraling

图注：横轴是归一化层深度，纵轴是 7 类说话风格的线性探针准确率，四条曲线都在音频编码器后段达到约 82–85% 的峰值，随后在编码器、projector、解码器三段边界之后出现不同形态的衰减。这张图回答的是「信息在哪一段被丢掉」，不能反过来当作「判定层能把这些信息捞回来」的证据，该论文没有做任何判定层实验。Paraling

这套范式换个任务也成立。VoxTurn 在轮次管理上让四个问题共享一次音频编码，一次前向 9.0 ms，四次分别前向 33.2 ms，答案差异只在 bf16 舍入级别。但它的等价性论证有个明确前提：块隔离掩码依赖全注意力骨干，循环或线性注意力层上不成立。

所以制约判定质量的不是「模型听不听得到」，而是训练目标要不要它用这些信息。把判断压进一次前向在工程上已经成立，读出什么、怎么监督，才决定读出来的是不是可靠的东西。

语音在长对话上反超聊天，却在受控评测里只剩文本的三四成

生产数据与受控评测是两层不可互证的证据，各自只能支撑各自口径下的结论。先看生产侧。ElevenLabs 公布了一份自家 agent 平台的双渠道对照，结论形态是「交叉」，不是「越长越好」：

长会话上的差距不止成功率。超过 2 分钟且成功的对话里，语音平均 4.6 分钟解决，聊天 7 分钟；在两侧样本都够的 90 个 agent 中，78% 在语音上更快。方法论四条也一并公开了：每个 agent 在 2026 年 5 月至 7 月间至少处理 50 通语音与 50 通聊天；成功标准由各业务为自己的用例定义；每个 agent 与自身对比；不合并会话，因为合并会让「主要用语音且恰好成功率高」的业务把语音整体抬高。与此同时，原文没有给任何绝对成功率，也没有给各桶的原始计数，所以这张表只能读方向，不能读成统一指标下的百分点。ElevenLabs

这份材料同时要纠正两处流传很广的误读。原文写的是「across hundreds of production agents running both」，全文没有出现 469；可检索到的 469 来自另一份语音识别评测集 AA-AgentTalk 的样本数，与生产 agent 数量无关。原文也没有「对话越长成功率越高」这句话，它说的是「问题越复杂越该用语音」，而且厂商自己承认时长只是复杂度的代理变量，在聊天场景尤其不成立，因为客户可能在两条消息之间停顿。

受控评测给出的数字要冷得多。τ-Voice 在同一套继承自 τ²-bench 的任务、同一套工具与数据库上，只把交互通道从文本换成全双工语音，共 278 个任务，零售 114、航空 50、电信 114。文本基线 GPT-5(reasoning) 达到 85%，语音 agent 在干净条件只有 31–51%，在加入噪声、口音与轮次动态的真实条件掉到 26–38%，只保留文本能力的 30–45%。

图注：灰色是继承自 τ²-bench 的任务基础设施，绿色是为语音新增的组件：可配置人设的语音用户模拟器、按 tick 离散的全双工音频通道、用于接入新语音 API 的适配器。这张图解释的是「同一套任务只换通道」这句话的具体形状，图里没有任何分数、供应商名或模型名，85% 与 31–51% 那组数字另由正文给出。τ-Voice

失败归因比分数更能说明缺口的形状。91 个失败样本由两位评分者逐条标注，79% 到 90% 的首个关键错误归到 agent 行为，而不是模拟器副作用；错误类型里逻辑错误最多，认证环节是共同瓶颈，用户逐字母拼读姓名，agent 仍然转写错，后续动作全部阻塞，还有 agent 口头声称已更新地址却没有发出任何工具调用。口音消融给出平均 10 个百分点的下降，且高度供应商特异，一家相对下降 38%，另一家只下降 2%，不过作者自陈口音是用 TTS 人设实现的，结论应视为指示性。τ-Voice

延迟作为替代解释，量级不够。生产侧那组数据里，315 通切换到更快 LLM 的对话中，端到端平均延迟降低 16% 与成功率提升 26% 相关，原文用词是 correlated，相关而非因果；而受控评测里语音与文本基线的差距更大，单靠这组相关数字解释不了。还要注意这两组数字不能互相验证：一组是厂商自评的生产统计，成功标准由各业务自定义，样本量只写了 hundreds；另一组是固定任务集上的 pass@1 与统一判据，任务集、样本与条件都不同。拿 26% 去反驳长对话那一桶的成功率是错的，拿长对话反超去否定受控评测同样是错的。τ-Voice 自己也把 ASR→LLM→TTS 级联基线列为未来工作，所以它不能回答端到端语音与级联谁更优。

把「我认为发生了什么」写成字段，才谈得上回放、单测和人工复核

判定层在工程上的位置，用 harness 的分法最容易说清：agent 等于模型加 harness，harness 是模型之外的一切。harness 分两类，guides 在 agent 行动之前引导它，sensors 在行动之后观察并帮它自我纠正；只有反馈会反复犯同一个错，只有前馈则永远不知道规则是否奏效。这套框架原文面向编码 agent，移植到语音栈属于类比，但落位关系是对得上的。Harness

图注：左侧 Feedforward 在生成之前进入 Coding Agent，右侧 Feedback 按 initial generation、self-correction loop、human review、pipeline 依次观察并回流，底部大箭头把反馈变成新的提交。这张图不含任何语音、音频、ASR 或 TTS 组件，也不含质量或延迟数字；它只用来定位「把状态写下来、再由外围引导与传感消费它」这件事。Harness

语音栈里这层判断要变成可审计的记录，接口侧有三条硬约束。答案只来自 decisions 响应，run 端点只返回状态与被评估的请求，不返回答案；同一请求同一文件可复现，重复发不会让答案更准；模型可以在不改 API 的情况下更新，而同一段音频同一组问题的答案可能因此改变。所以必须把 run_id、提问原文、答案一起落库，否则事后无法复核，也谈不上重标阈值。

阈值不是模型给的，也不是一次标定终身有效。官方文档给的方法是双阈值把概率轴切成三段：0.3 以下忽略，0.3 到 0.7 送人工，0.7 以上执行。教学示意里，30 个已标注片段仍然产生 2 个错误，一个标 yes 的落在 0.3 以下，一个标 no 的落在 0.7 以上，中间 8 个进复核带。

图注：Yes 与 No 两行共 30 个示例片段落在 0 到 1 的概率轴上，0.3 与 0.7 两条虚线把轴切成忽略、送人工、执行三段。0.3 与 0.7 只是示范方法，不是官方推荐阈值；30 个片段是教学示意，不是真实业务样本，也不能据此算准确率或召回率。Hume Docs

真正落地时，阈值的有效范围比数值本身更重要。文档规定阈值只对设定它的那次请求有效，也就是同样的措辞、同样的其他问题、同样的顺序，而且只对设定它的那类音频有效，在录音棚音频上定的阈值可能对电话音频是错的。这也解释了为什么要把提问原文一起存下来：阈值不是挂在模型上的常数，而是挂在一次具体提问上的工程决策。

产品侧的规模数字同样要按档标注。产品页说判定层与语音识别、语音生成并列；演示里 56 秒的示例通话被切成 12 个 chunk，每 5 秒单独作答，三种提问形态并行展示，这是演示行为描述，不是吞吐承诺；另一个「25,642 files、每个 180 ms」是界面里的运行计数器，没有语料来源、硬件与测量口径。规模口径 1B hours 的标签是「处理的客户小时数」，10M+ 的标签是「跨 Hume 全部工作的人类判断」，两者都没有时间范围，后者覆盖的范围还宽于本模型的训练数据。

所以这一层的产出应该是一条可回放的记录：跑过哪个 run、当时问的是什么、判成了什么、阈值是多少。一个飘在日志外的分数，出问题时回答不了任何问题。

判定字段自己会错：概率不是置信度，人数会被系统性算少

把这层的字段当事实用之前，有三个问题必须先回答：这个 0.5 是谁的 0.5，问题和候选能不能换顺序，评测指标会不会把这个错藏起来。

第一个问题是概率的三种语义不能混用。厂商文档说的是评分者占比，0.5 表示评分者会分歧；AudioJev 说的是模型在候选上的 softmax，概率跟随候选标签，支撑集恰好等于调用方给的候选，没有隐含兜底类；DuplexJev 说的是选项 token 上的归一化似然。三个数形状一样，含义完全不同，混用就会把「评分者会分歧」读成「模型不确定」，或者反过来。

第二个问题是顺序：AudioJev 把它形式化了，一个候选的概率应当在保持语义的候选重排下保持不变。它的训练做法是同一问题的两个候选顺序视图进同一个分类器，按候选身份对齐后做对称 KL；推理只保留一次前向，不加校准头。

图注：上半是训练，同一问题的两个候选顺序视图进入同一个共享分类器，按候选身份对齐后计算对称 KL；下半是推理，一次前向给调用方给的候选打分并返回分布。图中 62%、24%、13%、小于 1% 是画图示例，不是论文结果。这张图处理的是同一问题内的候选顺序。AudioJev

代价必须一起说。随机顺序下的分布散度相对单视图消融下降了 43.8%、48.9%、60.5%，但消融模型的准确率其实略高，MMAU 69.47 对 68.88，MMSU 62.55 对 61.70，MMAR 55.93 对 55.33。正确说法是「用约 0.6 到 0.8 个百分点准确率换约一半顺序散度下降」，不是「顺序校准提升了准确率」。

两种顺序敏感也不是一回事。厂商文档讲的是同一请求内问题集合的增删与重排，因为一个请求内的所有问题共享一次推理；AudioJev 讲的是同一问题内候选选项的顺序。粒度不同，前者是问题集级，后者是选项级，所以 AudioJev 既不能解决也不能证伪厂商那条约束，它全篇也没有测量问题集合重排。AudioJev

第三个问题最硬：连「这段录音里有几个人」这种看起来最客观的字段都会系统性算少。端到端说话人分离的人数不是对音频的客观读取，而是存在性头经过 first-stop 规则读出来的，帧活动头另给逐帧归属；论文提出的门控耦合损失是训练期正则项，人数读出只在推理时用。

图注：存在性头给出每个 attractor 的存在概率，经 first-stop 规则得到人数，这条分支只在推理时使用；帧活动头给出逐帧归属，两者相乘进入只在训练期使用的门控耦合损失。这张图不含任何 DER 或 JER 数值，那些数字在论文表格里；它也说明人数字段需要被单独评测与标定，不能当客观事实读。Beyond DER

少算的幅度是硬的。5 人以上的拥挤会话里，8 人时 count bias 达到 −1.93 与 −1.89，也就是平均少算近两个人；拥挤子集整体是 −1.03 与 −1.13。这件事在 DER 上看不见，因为 DER 是时长加权的，多话的人主导分数，被丢掉的低活跃说话人几乎不产生罚分。论文的原话是模型可以报告一个健康的 DER，同时漏掉从用户角度看仍然重要的低活跃说话人；同一批拥挤录音上，DER 18.29 而 JER 38.17，exact-count 只有 32.9%，±1 accuracy 62.4%。所以这一层要同时报 JER、exact-count、±1 accuracy 与 count bias，四个一起看。Beyond DER

改善也不是全域单调。方法在拥挤集上把 JER 相对降约 6%、DER 相对降约 9%，稀疏录音不受损，但 CallHome 域的 exact-count 反而从 25 掉到 12，因为那里的漏检说话人几乎全是被吸收类而非被静音类，抬高存在性置信度救不回来，还会变成误报。

最后一条边界在时间片段上。span 是实验特性，对笑声、叹气这类语音爆发和电话铃这类声音事件最可靠；如果问的是「某个词在第几秒被说出」，官方建议先在已知答案的音频上验证，或者先用 span 找候选区间，再对每个区间切至少 5 秒的窗口用 noul 复核。这条建议本身就说明了判定层的正确用法：它不是一次调用就交出事实，而是交出一组需要被验证、被分层复核的判断。

回到开头那三个问题：这个 0.5 是谁的 0.5，问题和候选能不能换顺序，评测指标会不会把错误藏起来。三个都答上了，这层判断才是可以依赖的；答不上，它买到的仍然只是一次更快的调用。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Introducing Hume's Audio Decision API: A decision layer for speech and sound — https://www.hume.ai/blog/introducing-hume-audio-decision-api
2. Decision Model API | Hume AI — https://www.hume.ai/products/decision-model-api
3. Hume Audio Decision API — Documentation — https://dev.hume.ai/audio-decisions/docs
4. Batched Speech Decisions Without Decoding: Single-Token Supervision Lets a Frozen LLM Hear Beyond the Transcript — arXiv:2610.02638
5. AudioJev: Direct Audio Decisions with Order-Calibrated Probabilities — arXiv:2610.01293
6. Why voice wins for complex, stressful conversations — https://elevenlabs.io/blog/voice-wins-complex-stressful-conversations
7. Voice agent latency optimization: Techniques and methods — https://elevenlabs.io/blog/voice-agent-latency-optimization
8. VoxTurn: Answering Several Turn-Taking Questions in One Pass with One Model — arXiv:2610.21150
9. τ-Voice: Benchmarking Full-Duplex Voice Agents on Real-World Domains — arXiv:2603.13686
10. Beyond DER: Speaker Counting in Crowded End-to-End Diarization — arXiv:2609.27315
11. Heard but Not Heeded: Paralinguistic Information Encoding and Loss in Audio-Language Models — arXiv:2609.00727
12. Harness engineering for coding agent users — https://martinfowler.com/articles/harness-engineering.html