首页2026 年 11 月 2 日，语音 AI 公司 Hume 正式发布 Audio Decision API，与传统 ASR 不同，这项 API 直接接收音频，根据开发者提出的问题，判断声音中的情绪表达、背景事件、说话方式及对话状态，并输出结构化概率。
它既不负责把语音转写成文字，也不负责生成 Agent 的回复，而是为语音系统增加一层能够直接分析声音的判断能力。
一. ASR 已经能识别语音，为什么还需要 Audio Understanding？
目前常见的 Voice Agent 通常由 ASR、LLM 和 TTS 组成。用户说话后，ASR 将音频转成文字，LLM 根据文本理解意图并生成回答，再通过 TTS 将回答转换为声音。
这种架构能够完成大量实际任务，例如查询订单、预约服务、回答产品问题。但它也存在一个容易被忽略的信息损失：当音频被转换为文字时，部分非语言信息可能随之消失。
1. 相同的文字，可能传递不同的意思
以“好的，我知道了”为例。
如果用户语速平稳、语气轻松，这句话可能表示已经理解；如果用户明显不耐烦，甚至在 Agent 尚未说完时插话，实际含义可能完全不同。
ASR 可以正确输出“好的，我知道了”，但仅凭这几个字，LLM 不一定能够识别对方的态度。
类似的信息还包括：
- 语音表达：语速、停顿、重音、语调、声音紧张程度。
- 非语言声音：叹气、笑声、喘息、哭声等。
- 对话行为：两个人同时说话、频繁插话、异常长的沉默。
- 声学环境：车辆鸣笛、警报、背景谈话、环境噪声。
这些信号不一定改变一句话的字面含义，却可能影响 Agent 下一步应该怎么做。
2. Audio Understanding 不等于情绪识别
谈到声音理解，很多人首先想到的是识别高兴、愤怒或悲伤。但 Audio Understanding 的范围更广。
例如，在一通客服录音中，系统可能需要判断：用户是否多次打断客服？背景有没有明显噪声？AI 的回答是否听起来自然？用户是否提出取消服务？
其中有些属于声学事件检测，有些属于对话行为分析，还有些涉及语言内容及主观感受。
传统方案往往需要组合多个模型：ASR 负责转写，VAD 检测语音活动，说话人分离模型区分不同说话者，再通过情绪分类或音频事件检测模型提供额外信息。
Hume Audio Decision API 的思路不同。开发者不必为每种判断单独训练分类器，而是直接向同一个音频模型提出问题，由模型返回相应的判断结果。
需要注意，这不意味着它能替代 ASR、VAD 或所有音频处理模块。尤其对于毫秒级语音活动检测和实时打断控制，专门的低延迟处理机制仍有必要。
二. Hume Audio Decision API 如何工作？
Hume 将新产品定位为音频决策模型（Audio Decision Model）。它的核心不是生成一段对声音的文字描述，而是回答开发者预先定义的问题。
开发者提交一段音频，同时指定要判断的内容和可选答案，模型直接返回概率、评分或事件时间范围。这些结果可以被业务程序读取，再决定是否触发对应操作。
1. 四种判断方式
根据 Hume 官方技术文档，Audio Decision API 提供四种基础判断类型：
| 类型 | 判断内容 | 应用示例 |
|---|---|---|
| noul | 判断是否成立 | 用户是否打断了 Agent？ |
| choice | 从多个选项中选择 | 声音更接近平静、急促还是犹豫？ |
| score | 按等级进行评分 | AI 语音的自然程度如何？ |
| span | 定位事件出现的时间段 | 录音中什么时候出现笑声？ |
四种类型可以在一次请求中组合使用。
例如，企业希望评估一通 AI 客服电话，不仅可以判断客服是否打断用户，还可以对语音自然度评分，并找出发生长时间沉默或其他声音事件的片段。
这比让大模型自由生成一段“通话评价”更容易接入自动化流程，因为输出具有明确的结构和数据类型。
2. 返回概率，而不是直接替业务作决定
假设开发者提出一个问题：“AI 客服是否在用户说话时插话？”
模型可能返回 0.8。根据 Hume 的定义，这类概率主要用于估计人类评审者会如何判断，并不是对客观事实给出的绝对置信度。
业务系统可以自行设定规则：当某项评分超过经过验证的阈值时，将录音加入人工复核队列，而不是直接判定客服违规。
这种设计把音频判断与业务执行分开。模型负责提供信号，业务系统负责决定如何利用信号。
它还有一个工程优势：判断标准可以调整。例如，企业最初只关注客服是否频繁打断用户，后来想增加“语气是否令人感到敷衍”这一维度，可以直接添加问题，而不必为了新增标签重新训练一套专用模型。
不过，问题的表述本身会影响输出。对于批量评测，应该保持问题、选项及上下文一致，才能进行有意义的横向比较。
3. 一次请求可以处理多个问题
现有文件 API 使用 POST /v0/decisions/file 接口，采用 multipart/form-data 提交音频与问题配置。
官方文档规定：每次请求接收一段 5 秒至 5 分钟的 MP3 或 WAV 音频，整个请求最大 25MB；普通判断类型最多合计 20 个问题，span 类型最多 5 个问题，每次请求最多 25 个问题。
开发者还可以提供简短的 context，说明音频属于客服、会议还是模拟对话，帮助模型在相应语境下进行判断。
Hume 同时提供 Python 和 TypeScript SDK，方便开发者在后端服务中调用。
三. 0.23 秒响应、70.7% 一致率，Hume 的性能意味着什么？
这次发布中，Hume 公布了两组值得关注的数据：模型处理速度，以及与人类判断的一致程度。
1. 0.23 秒是模型评测延迟，不是完整通话延迟
Hume 公布的测试数据显示，Audio Decision Model 在 10 项音频理解基准上的平均得分为 0.82，中位延迟约 0.23 秒。
官方还展示了与 Gemini、Qwen Omni 等模型的对比，认为其在特定测试配置下取得了较好的速度与准确性平衡。
但这里必须区分几个指标：
- 模型处理延迟：模型接收到评测输入后完成判断需要的时间。
- API 请求延迟：包括音频上传、网络传输、排队和响应返回。
- 端到端交互延迟：从用户说话开始，到 Agent 结合判断结果作出响应的完整时间。
0.23 秒属于官方基准测试结果，不能直接理解为用户说完话后，Voice Agent 只需要 230ms 就能完成理解并开口回答。
尤其是当前文件接口要求至少 5 秒音频。系统需要先积累足够的音频片段，再发起判断。因此，实际应用延迟必须将音频窗口长度计算在内。
2. 70.7% 衡量的是与人类群体判断的一致性
另一组数据来自 Hume 对人类感知判断的评估。
官方披露，Audio Decision Model 与人类评审群体平均判断的一致率为 70.7%，而单个人类评审者与群体判断的一致率基线为 56.5%。
这项结果说明，在相关评测任务中，模型输出与多人综合判断有较高一致性。但它并不代表模型能够以 70.7% 的准确率识别人的真实情绪，更不能据此证明它比所有人类评审都准确。
声音中的紧张、无奈、愉悦等表达本身具有主观性。不同语言、文化背景与交流习惯，也会影响听者的判断。
例如，一个人语速慢、停顿多，可能因为犹豫，也可能只是正在组织语言。模型即使判断其“听起来不确定”，也不能直接推断他不满意。
因此，实际部署时应当结合具体业务数据，验证模型输出与任务结果之间是否存在可靠关系。
3. 费用取决于输入 Token，而非单纯通话时长
Hume 当前公布的价格为每百万输入 Token 0.47 美元。计费输入包含音频、问题文本及 context，模型返回的答案不另行计费。
获得访问权限的组织可获得一次性 100 万输入 Token 试用额度，具体可用期限以平台显示为准。
对于企业而言，实际成本不仅取决于录音长度，还取决于需要判断多少个问题、多久采样一次，以及是否重复分析同一段音频。
如果每隔几秒就对同一通话发起判断，重复窗口可能增加处理成本。正式部署前，应使用官方 Token 估算接口进行测算，并结合业务价值决定采样频率。
四. Audio Decision API 如何接入实时 Voice Agent？
Audio Understanding 最值得研究的应用，是让 Voice Agent 在理解文字之外，获得更多有关交互状态的信息。
但它不应该简单取代现有 ASR、LLM 或语音打断模块，而是作为辅助判断能力加入系统。
1. ASR 与音频判断可以并行工作
以 AI 客服为例，用户正在描述订单问题，系统可以将音频分别交给两个处理分支。
第一条链路通过 ASR 获取转写结果，再交由 LLM 判断用户的业务诉求，例如退款、换货或查询订单。
第二条链路将符合长度要求的音频片段发送给 Audio Decision API，判断用户是否听起来急躁、是否出现频繁插话，以及周围是否存在明显干扰声。
之后，业务编排层再综合两类信息。
例如，用户表示没有听清楚，同时音频判断显示背景噪声较大，Agent 可以优先简化回复，或请用户确认关键信息，而不是机械地重复一大段内容。
这里的关键不在于让 AI “识别情绪后安慰用户”，而是让音频信号参与具体的任务决策。
2. 实时通信与音频理解承担不同职责
在一套完整的实时语音系统中，RTC 负责音频采集、编码、传输及播放等实时通信能力；ASR、LLM、TTS 负责语音内容的理解和生成；Audio Decision 一类模型则提供额外的声音判断。
可将整体架构理解为：
这种分层方式有利于系统独立优化不同能力。例如，开发者可以分别测量音频传输延迟、ASR 响应时间、音频判断耗时、LLM 推理时间及 TTS 首包延迟，避免把所有问题都归因于模型速度。
不过，当前 Hume 正式公开的接口是文件请求，并非持续输入音频帧的低延迟双向流接口。
在实时通话中使用时，需要截取最近 5 秒或更长的音频窗口，异步调用 API，再将结果交给业务系统。Hume 官方也建议，在判断连续通话时，不要仅凭一个片段行动，而应结合多个片段平滑处理。
因此，更合理的做法是将 Audio Decision 用于非关键路径的辅助决策，而不是让每一次用户打断都等待文件分析完成。
3. 不要让音频判断阻塞正常对话
假设一个 Agent 已经识别用户希望查询订单，它不应该为了等待音频判断结果，而停止回复数秒。
工程上可以采用异步处理：ASR 与对话主链路正常运行，Audio Decision 在后台分析最近一段音频；如果结果及时返回且与当前对话仍相关，再供后续决策参考。
同时，需要为判断结果设置有效时间。当用户已经开始新的话题，较早片段中的“语气急躁”就不应该无条件影响后续回答。
这与 Voice Agent 的 Tool Calling、上下文管理以及实时打断有相似的工程问题：辅助能力越多，越需要控制异步结果的时效性，避免旧结果干扰当前任务。
五. 哪些应用场景真正需要理解声音？
1. AI 客服：从转写质检到音频质检
客服质检通常需要检查是否遵守服务流程、是否频繁打断用户、表达是否自然，以及客户是否出现明显不满。
只分析转写文本，可以发现业务内容错误，却未必能识别双方同时说话、反复插话或长时间沉默。
Audio Decision API 可以针对这些问题直接分析原始录音，输出结构化结果，帮助企业筛选需要人工复核的通话。
它尤其适合批量录音分析：企业可以统一问题标准，对不同客服、模型版本或时间段的结果进行比较。
但模型评分不能直接等同于员工服务质量，更不应该未经人工验证就用于处罚或其他高影响决策。
2. AI 语音评测：除了准确率，还要衡量自然度
传统 TTS 评测关注语音清晰度、发音正确性和自然度。对于实时 Voice Agent，还需要考虑生成语音是否符合上下文、是否在不适当的位置停顿，以及有没有出现机械化、突兀的表达。
开发者可以对不同 TTS 模型或相同模型的不同版本提出一致的问题，例如“声音是否自然”“是否听起来过于急促”“是否存在异常停顿”。
模型输出可作为自动评测的一部分，帮助快速发现需要人工试听的样本。
这类方法特别适合大规模回归测试，但仍应保留人工听评作为校准依据，避免模型评分与真实用户体验脱节。
3. 智能硬件与陪伴机器人：从听懂命令到理解交流状态
对于接入对话式 AI 的智能硬件，用户不一定始终处在安静、清晰的语音环境中。
例如，家庭机器人与老人交谈时，可能同时接收到电视声音、家人说话和用户语音；儿童陪伴设备也可能遇到笑声、呼喊或多人轮流提问。
除了识别指令内容，设备还需要知道当前声音是否适合继续对话，是否需要澄清，以及是否存在明显的环境干扰。
音频判断可以为这类决策提供辅助信息。但设备本身仍需要独立的音频前处理、说话人管理、实时传输和本地安全控制机制。
如果系统必须在几十毫秒内响应用户打断，就不能依赖需要先积累数秒音频的分析接口。
更现实的设计是将快速反应留给本地 VAD、打断检测和实时音频系统，把复杂的声音理解交给异步 AI 模块。
六. Audio Understanding 的价值与当前局限
Hume Audio Decision API 代表了一种值得关注的技术方向：将声音理解从通用大模型的文本描述任务，转变成可以被业务程序直接调用的结构化判断任务。
它的优势主要有三个。
第一，保留转写文本容易遗漏的信息。 语气、声音事件和对话行为可以独立参与判断。
第二，让判断标准更容易调整。 开发者通过修改问题和选项，就可以改变分析重点，而不必为每项业务需求单独训练模型。
第三，便于规模化分析。 结构化概率、评分和时间范围，更容易用于录音检索、质量监控和自动化流程。
但当前仍有几项限制需要正视。
一是实时性。官方文件 API 要求输入 5 秒至 5 分钟音频，不适合直接替代高频、低延迟的语音活动检测；每个组织默认每分钟最多 60 次请求，多路并发通话需要合理分配额度。
二是判断可靠性。声音表达受到语言、文化、个人习惯和录音条件影响，模型输出应当被视为辅助判断，而不是对个人情绪、意图或心理状态的确定结论。
三是数据治理。客服录音、家庭语音及医疗场景可能包含个人信息。将音频发送至外部服务之前，需要明确用户授权、数据传输范围、留存政策和适用的合规要求。
四是评测标准。官方公布的延迟和一致率具有参考价值，但企业仍需要使用自己的语言、网络条件和真实通话数据进行测试，才能判断是否符合生产要求。
随着 Voice Agent 从简单问答进入客服、智能终端和机器人等复杂场景，语音交互的评价标准也会随之变化。系统不仅要回答正确、响应及时，还要在适当的时候等待、澄清、调整回复方式，并对异常情况作出合理处理。
Hume 这次发布提供了一条新的技术路径。它距离完全实时、持续感知的语音交互仍有工程距离，但已经让原始音频中的一部分非文本信息，变成了可以被程序直接使用的决策输入。
对下一代 Voice Agent 来说，这可能比单纯继续提高语音转写准确率更值得研究。
