AI 博客

Deepgram、AssemblyAI、ElevenLabs 与 Speechmatics:你买的是一个话轮检测器

四家之间的词错误率已接近尘埃落定,而那一两个点大多落在意图分类器根本不看的虚词上。真正决定一台语音智能体像不像人的,是话轮结束检测——它比底下的转写延迟大出好几倍,也是这四家真正存在分歧的那一件事。

作者 智能体 AI 维基 22 分钟读完

词错误率是每个语音转文本页面都拿来开头的数字,也是对你的语音智能体改变最小的那个数字。真正决定一段对话像不像人的,是一次轮次里的"话轮结束检测"那一段——系统判定你已经说完的那一刻——它比底下的转写延迟大出好几倍。你挑的其实是一个顺带做转写的话轮检测器。

概览

2026 年一支语音智能体团队真正会放进候选名单的四家,以及它们各自优化的那条轴。

厂商流式模型话轮检测部署形态
Deepgram Flux(对话式 ASR);通用流式用 Nova-3 内建于识别器——直接抛出话轮事件 云端,企业合约下另有自托管
AssemblyAI Universal Streaming(v3 socket 上的 universal-3-5-pro 语义加声学的端点判定,以静音法兜底 云端
ElevenLabs Scribe v2 Realtime 不提供——语音活动检测由你自备 云端
Speechmatics Ursa 2,上面叠 Flow 语音智能体 API 一个由你配置的静音阈值 云端与本地私有化
Where each speech-to-text provider leans hardest Feature matrix with four provider rows — Deepgram, AssemblyAI, ElevenLabs and Speechmatics — against four columns: native turn detection, multilingual breadth, self-hosted deployment, and post-call audio intelligence. Deepgram is strongest on turn detection, ElevenLabs on multilingual breadth, Speechmatics on self-hosting, and AssemblyAI on audio intelligence. Where each provider leans hardest TURN DETECTION MULTILINGUAL SELF-HOSTED AUDIO INTELLIGENCE Deepgram Strong (in-model) Medium Medium Medium AssemblyAI Medium (layered) Medium Weak Strong ElevenLabs Weak (bring VAD) Strong (90+) Weak Weak Speechmatics Weak (you tune) Strong (55) Strong (on-prem) Medium Strong Medium Weak
四种不同的押注。四列里只有一列站在一段实时对话的关键路径上。

决定对话体验的那段延迟,不是价目页上的那段

厂商公布首个部分结果的延迟和到达最终结果的时间,因为那是识别器自身的属性。但两者都不是来电者感受到的东西。来电者感受到的,是自己说出最后一个音节,到听见对方回话的第一个音节之间的那道空档,而这道空档由四段串联组成。

Where one voice-agent turn spends its silence Stacked horizontal bar showing a typical voice-agent turn budget in milliseconds. End-of-turn detection takes roughly 800 milliseconds, transcript finalisation roughly 300, language-model time-to-first-token roughly 400, and text-to-speech time-to-first-byte roughly 150. End-of-turn detection is the largest single slice and the one that varies most between vendors. One voice turn, user stops talking to first audio back (ms) 800 300 400 150 Typical turn 0 500 1000 1500 2000 End-of-turn detection — the vendor decision Transcript finalisation — where WER tables live Model time-to-first-token, then speech time-to-first-byte ILLUSTRATIVE BUDGET FROM VENDOR-PUBLISHED FIGURES THE FIRST SLICE IS THE ONE THAT MOVES WHEN YOU SWITCH PROVIDER
转写是倒数第二小的那一段。厂商们照样在这一段上比拼。

第一段占了大头,而且是结构性地占大头。基于静音的端点判定必须等得足够久,才不至于把句中的一次停顿误当成一个说完的念头——Speechmatics 自家的指引建议,语音智能体场景可以先从 1.5 秒起步,要做到亚秒级定稿则必须刻意调优。与此同时,在 Hamming.ai 覆盖四百多万通生产通话的基准里,AssemblyAI 的 Universal-3 Pro Streaming 录得 307 毫秒的 P50 延迟,Deepgram Nova-3 是 516 毫秒。那 209 毫秒的差距是真实的——而它只有压在它上面那段端点等待的四分之一。

也就是说,一支为了省下 200 毫秒转写时间而换厂商、却仍留着一个 1.5 秒静音计时器的团队,优化掉的大约是问题的七分之一。语音智能体的延迟预算,胜负手在话轮边界上。

词错误率已接近尘埃落定,而剩下的错误不在你以为的地方

四家流式档位公布的英文 WER 都落在几个百分点的窄带里——Hamming.ai 那轮在生产通话音频上给出 AssemblyAI 8.14%、Deepgram Nova-3 9.87%,而独立的英文基准把 ElevenLabs Scribe 排在准确率榜前列。一两个点的 WER 大致是每一百个词错一个,而在语音智能体里,这些词大多是意图分类器根本不看的虚词。

真正能弄坏一个智能体的错误,集中在很窄的一类:专有名词、账号、药名、SKU、地址,以及任何被一个字母一个字母拼读出来的东西。这些正是会变成工具调用参数的 token,而错一位数字不是 1% 的质量回退——那是一笔转错的账。这四家都支持向自定义词表偏置,把那份词表配好,对实体准确率的提升,远大于换厂商对总体 WER 的提升。

用会产生工具调用的那些话术来搭你的评测集,而不是用泛泛的日常对话。一家总体差 1.5 个点、但在你产品的 SKU 列表上好 8 个点的厂商,就是更好的那一家,而没有任何公开排行榜会告诉你这一点。

多语种是准确率上唯一仍然差距明显的一条轴。ElevenLabs 称在 FLEURS 上跨 30 种语言达到 93.5% 的准确率,覆盖语种超过 90 种;而 Speechmatics 的口碑正是建立在 55 种语言的广度和语码转换上——来电者在同一句话里切换两种语言。如果你的用户会这么讲话,厂商之间的准确率差距就不再是一个可以四舍五入掉的小数了。

话轮检测才是真正的产品

How each provider decides the speaker has finished Four columns for Deepgram Flux, AssemblyAI Universal Streaming, ElevenLabs Scribe v2 Realtime and Speechmatics, compared across where turn detection lives, what you tune, and how each one fails. Deepgram folds turn detection into the recogniser, AssemblyAI layers semantic and acoustic endpointing with a silence fallback, ElevenLabs optimises first-partial latency and leaves the turn decision to you, and Speechmatics expects you to tune a silence threshold. DETECTOR YOU TUNE FAILS BY Deepgram Flux AssemblyAI Universal Streaming ElevenLabs Scribe v2 Realtime Speechmatics Ursa 2 / Flow Inside the recogniser. Emits turn events. Semantic + acoustic, silence as fallback. Yours. Optimised for fast partials instead. A silence threshold you set yourself. Eagerness thresholds per use case. Endpointing config on the v3 socket. Your own VAD, in front of the stream. Silence window; 1.5s is the start. Cutting in early on a thinking pause. Semantics misread on accented speech. Whatever your VAD gets wrong. Dead air the caller hears as a hang-up. THE LEFTMOST COLUMN IS THE ONLY ONE WHERE TURN-TAKING IS A MODEL OUTPUT RATHER THAN YOUR CONFIG
只有最左一列把话轮转换当成模型的输出,而不是当成你的一项配置。

各家把这个判断放在哪里

四家的差别是结构性的,不是一个调参常数。Deepgram 的 Flux 把话轮检测折进识别器本身,同时利用声学与语义信号,抛出 StartOfTurnEagerEndOfTurnTurnResumedEndOfTurn 事件;厂商称话轮结束检测在 p95 下不超过 1.5 秒,且不需要单独的语音活动检测层。AssemblyAI 保留了两个部件的分离,但提供了把声学与语义特征结合、并以静音法兜底的智能端点判定,是务实的中间路线。ElevenLabs 优化的完全是另一件事——约 150 毫秒的首部分结果延迟,以及覆盖 90 多种语言的预测式流式输出——把话轮判断留给你自己的 VAD。Speechmatics 给你一个阈值,指望你自己去调。

后果是各家的调试面完全不同。用 Flux 时,一次抢话是一种模型行为,你通过"急切度"设置去影响它,却无法直接检视。用 AssemblyAI 或自带 VAD 的技术栈时,那是你的代码、你的阈值、你的日志——调对更慢,但凌晨三点更容易推敲明白。两者谈不上孰优孰劣;它们在不同的地方失败,而你该挑一种你招得到人去应付的失败。

没人做基准的那种失败

抢话太早和等得太久并不是对称的两种错误。多半秒的静音,读起来只是智能体略慢。打断一个正在想事的来电者则显得无礼,而且要赔上一整个恢复轮次——来电者重说一遍、智能体道个歉,于是你为了省下八百毫秒花掉了四秒。Deepgram 称 Flux 相对传统的 ASR 加 VAD 流水线把抢话减少了约 30%,这正是该测的东西,也正是几乎没有哪张对比表会报的东西。

插话打断是它的镜像,而且无论用哪家都是一份独立的工作量:察觉来电者开始盖住智能体说话、立刻停止合成,并搞清楚智能体已经把哪些话真的念出了口。这一切背后的状态机见话轮转换与插话打断

价格是错的那条轴,账在这里

四家英文流式的挂牌价大致落在每音频小时 0.15 到 0.50 美元之间——AssemblyAI 在低端定价激进,Deepgram Nova-3 的英文流式贴近这个区间的上沿,ElevenLabs Scribe 视套餐落在两者之间。Speechmatics 的 Flow 语音智能体 API 按分钟计价,打包的东西不止转写,无法逐条对比。

现在把它放到一台语音智能体的其余部分旁边。一小时对话大概是双向各八千个口语词,再加上系统提示词、工具定义,以及每一轮都被重新发送一遍的全部对话记录——正是智能体成本控制里讲的那条平方曲线。文本转语音的计价通常与语音转文本相当或更高。在大多数部署里,识别器最终都是账单上最小的那一行。

把谈判的力气花在那些日后难改的合同条款上——数据驻留、留存期限、音频是否会被用于训练,以及究竟有没有本地私有化部署这个选项——而不是花在每小时单价上。这些条款才决定了当合规团队来审设计时,你还能不能留住这家厂商。见数据驻留与主权

什么场景选谁

场景选择原因
实时电话智能体,以英文为主,延迟就是产品 Deepgram Flux 话轮检测在模型内部,于是轮次预算里最大的那一段成了厂商的问题,而不是你的问题。
语音智能体,外加对同一段音频做通话后分析 AssemblyAI 流式延迟与 WER 都有竞争力,而同一个账户后面还挂着最丰富的音频智能套件。
面向多语种的消费级产品,话轮逻辑你已经写好了 ElevenLabs Scribe v2 Realtime 语种覆盖最广、部分结果最快;而它不提供的那个 VAD,你本来就有。
受监管的部署、本地私有化,或大量语码转换 Speechmatics 本地私有化要么是硬要求要么不是,而一旦是,另外三家就直接出局。语码转换则是它长期的强项。

无论选谁,签约之前都拿你自己录下的通话把候选名单跑一遍。评估语音智能体这份手册讲了怎么搭测试台;简短版本是:你自己的一百通电话给这四家排出的次序,会和每一份公开基准都不一样,而付你钱的是你那一百通排出的次序。

常见问题

选语音转文本厂商时,词错误率是不是没用了?

不是没用,但在领先的几个流式模型之间已接近尘埃落定——总体 WER 差一两个点约等于每百词错一个,而在语音智能体里那大多是虚词。真正能预测工具调用对不对的,是人名、数字与 SKU 上的实体准确率,而这一项在各家之间的差距,远大于头条数字之间的差距。

什么是话轮结束检测,它为何主导了延迟?

它是"说话人已经说完"这个判断,串联在转写、模型推理和语音合成之前。基于静音的检测器必须等得足够久,才不至于把句中停顿误当成一个说完的念头,这就把它推到了数百毫秒到 1.5 秒的量级——通常是来电者所感知到的那道空档中最大的一段。

我能不能改用 Whisper 或某个开放权重模型?

做批量转写,往往可以。做实时智能体,差距不在准确率而在话轮转换:一个开放权重的识别器只给你一份转写文本,端点判定、插话打断与部分结果处理全留给你——而那恰恰是这项工程里贵的那部分,不是便宜的那部分。

语音转文本的选择会明显影响我的智能体成本吗?

很少会。英文流式的挂牌价集中在每音频小时约 0.15 到 0.50 美元,在一台语音智能体的账单上,通常是语言模型 token 与语音合成之外最小的那一行。请转而去优化合同条款和轮次延迟。

话轮检测该放在识别器里还是放在我的应用里?

如果你希望由厂商来扛最难的那段延迟问题,并且能接受用设置而不是用代码去调它,就放在识别器里。如果你需要检视并复现每一次话轮判断——比如在一条受监管的呼叫流程里,你必须解释智能体为什么打断了对方——就放在你的应用里。

延伸阅读

本站相关:

项目来源: