语音模型

Hume 发布 Audio Decisions API：原始音频进、概率出，语音 Agent「听起来怎么样」终于能量化

2026年11月3日1 次阅读
Hume 发布 Audio Decisions API：原始音频进、概率出，语音 Agent「听起来怎么样」终于能量化

先讲结论： 11 月 2 日，做情感计算起家的 Hume AI 上线了 Audio Decisions API。它不吃转录文本，直接把一段原始音频和几个用大白话写的问题一起丢进去，返回的是概率——不是一段描述，也不是一句解释。比如问「客服专员有没有抢话」，它回你 0.13，意思是「大约 13% 的真人评审会认为有」。

这件事的意义不在「又出了一个语音模型」，而在于它把一件长期靠人耳的事标准化了：这段录音听起来怎么样。 以前你要么训一堆专用分类器，要么请人一条条听。现在是一条 HTTP 请求，输出结构化数字，可以直接接阈值和业务规则。

这篇内容基于 Hume 官方博客与官方 API 文档整理，并对照了 AlphaSignal、FourWeekMBA、SpeechTechMag 等多家媒体的同日转述。

3分钟看懂：它到底是个什么东西

一句话：一个「音频判断题」模型，你出题，它给概率。

  • 谁做的：Hume AI，纽约的语音情感 AI 公司，长期做人声情绪识别和 Real-World VoiceEQ 评测
  • 什么时候：2026 年 11 月 2 日发布，目前需要申请 waitlist 才能拿到 API key
  • 输入：一个音频文件（MP3 / WAV）+ 一组问题，可带一段 context 说明场景
  • 输出：每个问题一个概率或一组概率，外加 run_id 和本次计费的输入 token 数
  • 不输出：转录、回答、解释、建议。它是决策层，不是生成层

关键区别在这儿：Whisper 那类 ASR 给你的是「说了什么字」，它丢掉的是「怎么说的」——停顿、叹气、两个人抢话、背景里的警笛。而「客户到底是不是不高兴」「这个 AI 客服听起来自不自然」，答案往往就在被丢掉的那部分里。

它想解决的具体麻烦

Hume 在博客里举了个很实在的例子：呼叫中心给每通电话按评分表打分。想改一条评分规则，过去是一个项目——新规则、新流水线、新评测，几天到几周才见到第一个结果。因为跑在下面的只有转录文本，而转录里没有语气。

传统替代方案有两条，都不便宜：

  1. 训专用分类器：每加一个问题就要标一批数据、训一个模型，问题一改全部重来
  2. 请人听：准确但不可扩展。四万条录音，听到什么时候

Audio Decisions 的思路是把「问题」变成输入的一部分：加一个问题就是加一行 JSON，不用标注、不用重训。同一段录音可以同时问背景音、语种、口音、情绪表达，各自独立出概率。

怎么用：一次请求长什么样

请求是 multipart/form-data 的 POST，两个部分：request（JSON，装问题和可选 context）和 file（音频本体），鉴权走 X-Hume-Api-Key 头。端点：POST https://api.cloud.hume.ai/v0/decisions/file。

问题分四种「原语」，决定了答案长什么样：

  • noul（是/否）：返回「是」的概率。适合「专员有没有抢话」「这声音是不是 AI 合成的」
  • choice（多选一）：返回每个选项的概率和置信度。适合「客户这通电话的目的是什么」——退货、取消订阅、还是催进度
  • score（量表）：你给一列从低到高的档位，它返回每档概率 + 按概率加权的均值。适合「这位专员听起来多有耐心，1 到 5 分」
  • span（时间片段）：返回事件可能发生的起止时间。适合「哪里有人在笑、叹气、或者有电话铃响」

官方文档里那段示例请求问了两件事：专员有没有抢话，以及专员听起来多自然（五档）。返回是这样：

```json

{

"answers": {

"talks_over_caller": { "type": "noul", "noul": 0.1274 },

"agent_naturalness": {

"type": "score",

"score": 2.7195,

"confidence": 0.4229,

"probabilities": { "0": 0.0218, "1": 0.0874, "2": 0.2463, "3": 0.4385, "4": 0.206 }

}

},

"received": { "input_tokens": 11234 }

}

```

注意 2.72 这个分数：它落在「3」和「4」之间，是因为它是加权均值，不是某一档的硬判定。而 confidence 只有 0.42，说明评审在这段音频上的意见本来就分裂——这是设计上的语义，不是模型「不确定」。

一个必须讲清楚的反直觉点：概率不是置信度

这是整套 API 最容易被误读的地方，Hume 文档专门用一句话钉住了：

> 概率估计的是「会给这个答案的真人评审比例」，所以接近 0.5 意味着评审会分裂，而不是模型没把握。

换句话说，模型输出的是人类感知的分布，而不是它自己的确定性。这对用法影响很大：

  • 0.13 的抢话概率，不代表「模型有 87% 把握没抢话」，而是「大约一成多的评审会觉得抢话了」
  • 想做业务判断，得自己在你自己的、已知答案的音频上标定阈值，而不是拍一个 0.5
  • score 落在中间档，可能是大家一致给中评，也可能是两极分化，得回头看 probabilities 才分得清

这套设计的底气来自 Hume 多年攒的评审数据：数以千万计的人类判断，喂出了他们的 Real-World VoiceEQ 榜单。官方给的初始评测是——模型的判断与人类评审团平均判断的一致率 70.7%，而单个评审员与评审团平均的一致率是 56.5%。翻成日常话：它比随便拉一个路人更接近「群众平均看法」。但这是官方自评、单一数字、没有第三方复现，只能当参考。

硬限制：先看这几条，再想场景

  • 一个请求只能一个文件，MP3 或 WAV
  • 时长 5 秒到 5 分钟，请求体（含问题）不超过 25,000,000 字节
  • 每个请求最多 20 个 noul/choice/score 问题，外加最多 5 个 span 问题
  • 每个组织每分钟 60 个请求
  • 超过 5 分钟的录音要自己切片，一片一请求；切片有重叠会把同一段音频重复计费，重叠一半大约等于 token 翻倍

这几条决定了它现在的形态：批处理优先，实时场景还早。 官方自己在博客里写得很直白——live and ambient（实时与常驻环境）「remains a longer-term opportunity」，即仍是更远期的机会，先把录音文件和批量库跑通。

成本：按输入 token 计费，先算再发

价格是 $0.47 / 百万输入 token，无最低消费承诺。获得访问权限后，每个组织会给 100 万输入 token 的试用额度，平台计费页能看到剩余量和到期时间。

计费口径有两个细节值得记住：

  1. 按输入计费：音频 + 问题文本 + context。答案不计费。响应里的 received.input_tokens 就是这次账单
  2. 被 4xx 拒掉的请求不计费（比如音频太短、格式不支持）。所以调参阶段试错成本很低

官方给的估算样例挺直观：一条 10 秒的 TTS 片段评估自然度、瑕疵、错读，约 1,000 token；一通 5 分钟客服电话问 6 个问题，约 26,400 token。按 $0.47/百万算，后者一次大约 1.2 美分。真要做几万条录音的批量质检，这个量级是能算得过账的——但要记得静音也计费，每一秒都算。

适用场景：四个马上能落地的用法

1. TTS / 语音模型的回归测试。 这是最直接的一个。模型能听清，不等于听着自然。你可以批量问「这段合成语音听起来自然吗（1–5）」「有没有吞字、爆音、奇怪的停顿」，把主观听测变成一条能进 CI 的分数曲线，换模型、换 checkpoint 时对比。

2. 语音 Agent 的线上质检。 客户嘴上说「没事」，语气却明显不耐烦；停顿是在思考，还是已经说完了。这些信号转录里全没有。把音频判断和转录一起喂给下游 LLM，业务规则就能从「他说了什么」升级到「他怎么说」。

3. 批量客服录音的检索与抽检。 问「哪些通话里客户听起来很挫败」「哪些专员语气让人安心」「哪些通话有抢话」，先按概率排序，人工只复核头部。这比随机抽检效率高一个量级。

4. 语音语料的自动标注。 建数据集时用结构化判断替代人工听审，尤其是笑声、叹气、背景噪声这类声音事件——官方说 span 在这些「人声爆发和非语音事件」上最可靠。

不适用场景：三类现在别指望的事

  1. 别指望它给转录。 它明确不返回文本。要文本仍得配 ASR，两家一起用
  2. 别拿 span 去精确定位「某句话从第几秒开始」。 官方提示：span 对笑声、叹气、电话铃这类声音事件最稳；对「某句话被说出」这类事件，要先用你已知答案的音频验证过再依赖
  3. 别把它当实时组件。 waitlist + 文件级请求 + 60 请求/分钟的配额，现阶段是离线批处理的路子。Hume 另有实时 Expression API 做在线情绪测量，两者不是一回事

还有一点要提醒：它不是开源的，也不能本地部署。数据要发到 Hume 的云上（api.cloud.hume.ai），对音频出境的合规要求得先过一遍。官方对「私有 VPC、本地部署、驻留某国」只留了一句「联系销售谈企业版」。

避坑：四个最常见的误解

  1. 把概率当置信度。 0.13 不是「模型 87% 确定没抢话」，而是「约一成多评审会觉得抢话」。想定规则，必须用自己已知答案的音频标定阈值
  2. 拿它替代转录。 它不返回任何文本。要文字仍得配 ASR，两套并行跑
  3. 按整段长录音直接传。 单请求上限 5 分钟、25MB。访谈要自己切片，且切片别重叠太多，重叠一半 token 大约翻倍
  4. 拿官方 70.7% 当定论。 这是官方初始评测的单一数字，人类评审团均值本身也不是标准答案；第三方复现出来之前，只当方向性参考

放回这周的语音赛道看

这几天语音方向其实挺热闹，正好能看出各家在抢什么位置：

  • AssemblyAI 10 月底下场做 TTS，主打「为语音 Agent 而生」，按分钟计价、无限并发
  • Cartesia 把整条语音 Agent 流水线打包成产品卖，盲测登顶，每分钟 3 美分
  • Deepgram 直接把 Pipecat 背后的公司买了，想把「怎么说」统一到一条管道里

Hume 选的是另一层：不生成声音，不做管道，做判断。这条线目前竞争者少，因为它要的不是算力，是多年攒下来的人类感知标注——这也是它最难被快速复制的地方。

行动建议

  1. 手上有 TTS 或语音 Agent 的：先去 waitlist 排上，同时用 playground 试。playground 支持上传文件和实时两种方式，可以加自己的问题，不用配置
  2. 先定一个能验证的小任务：比如「同一文本、三个 TTS 模型各 30 条，比自然度分数」。别一上来就铺全量数据
  3. 阈值一定要自己标定：拿 20–50 条你已经知道答案的音频，看概率落在什么区间才对应你认的「有问题」，再定规则
  4. 算一遍账再上量：用官方的 input_tokens 估算端点（不计费）先跑一遍你的真实时长分布，别拿 5 分钟样例去推 40 分钟访谈的成本
  5. 合规先过：录音是否含个人信息、能否出境，比模型效果更早决定这个方案能不能用

一句话总结：它不会让你生成更好的声音，但会让你第一次能说清楚「这段声音到底哪里不对」，并且用数字说。

参考来源

  • Hume 官方博客《Introducing Hume's Audio Decision API》（2026-11-02）：https://www.hume.ai/blog/introducing-hume-audio-decision-api
  • Hume 官方 API 文档 · 概览（请求结构、原语、示例响应）：https://dev.hume.ai/audio-decisions/docs/overview
  • Hume 官方 API 文档 · Limits（时长、体积、题量、速率）：https://dev.hume.ai/audio-decisions/docs/limits
  • Hume 官方 API 文档 · Billing（$0.47/1M token、计费口径、样例估算）：https://dev.hume.ai/audio-decisions/docs/billing
  • AlphaSignal 报道（2026-11-02）：https://alphasignal.ai/news/hume-opens-its-audio-decision-api-to-answer-any-question-about-sound
  • FourWeekMBA 报道（2026-11-02）：https://fourweekmba.com/ai-humes-audio-api-matched-a-human-panel-70-7-of-the-time

本文事实部分以 Hume 官方博客与官方文档为准，媒体转述仅用于交叉印证发布时间与核心数字。

参考来源

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...