今天你再去看,会发现一个有点反常识的事实:在不少新产品里,那一段文字根本不存在了。语音进去,语音出来,中间没有任何一步是"文本"。Whisper 这种纯 ASR 模型,正在从"语音 AI 的地基"退化成"一个还在用、但不再激动人心的工具"。

这不是 ASR 变差了——它一直在变好。是语音模型这条线,这一两年走完了一次三级跳。我想把这三级讲清楚:每一步解决了什么、赔进去了什么,以及 2026 年的此刻,你手里的场景到底该站在哪一级。

三级跳:一张时间线

timeline
    title 语音模型的三代演进
    第一代 专用 ASR : Whisper 系 / 各家流式 ASR
                    : 语音 → 文字,只做识别
    第二代 多模态语音理解 : Qwen-Audio / Qwen3-Omni
                        : 语音直接进 LLM,听懂语气与事件
    第三代 端到端语音 : Moshi / Sesame CSM
                     : GPT-Realtime / Gemini Live
                     : 语音进语音出,中间不落文字

这三代不是互相取代的关系——更像三层楼,新楼盖起来了,旧楼还有人住,而且住得挺好。下面一层一层说。

第一代:专用 ASR,把语音"压扁"成文字

ASR 模型只干一件事:把声波转成最可能的那串字。Whisper large-v3 仍然是这条线上的标杆,多语言、抗噪、开源、便宜,2026 年依然是无数转写流水线的默认选项。

它解决的问题很实在:语音是连续的、模拟的、信息量巨大的信号,文字是离散的、规整的、好处理的符号。ASR 在两者之间架了一座桥。有了这座桥,语音才第一次能接进所有为文字设计的系统——搜索、数据库、传统 NLP、LLM。

代价也恰恰在这座桥上。ASR 是一次有损压缩,而且丢掉的东西,常常正是你最想要的。

同一句"你这是什么意思",可以是真诚发问,可以是压着火,可以是开玩笑。转成文字之后,这九个字一模一样,语气全没了。一段录音里有人在笑、有人在哭、背景有玻璃碎掉的声音——ASR 给你的还是那行字,这些"非文字信息"在转写的瞬间被抹平。

对"我要把会议录音变成文字稿"这种任务,这种丢失无所谓,甚至是好事。但对"我要做一个能察言观色的语音助手",这就是地基上的裂缝:你的下游模型再聪明,也只能在 ASR 留下的那点信息里打转。

第二代:多模态语音理解,让 LLM 自己去听

第二代的想法很直接——既然转文字会丢信息,那就别转了,让语音直接进 LLM。

阿里的 Qwen-Audio 是这条路上的代表,到 Qwen3-Omni 已经做成了一个统一的多模态模型:文本、图像、音频、视频一起进,音频部分支持几十种语言的语音理解,单条最长能处理 40 分钟的录音。今年 3 月发的 Qwen3.5-Omni 把语音识别的语言数推到了上百种。它们在几十个音频基准上拿了开源 SOTA,有些项目上压过了闭源的 Gemini 和 GPT-4o 系列。

关键不在跑分,在模型"听到"的东西变多了。你可以直接问它:“这段录音里说话的人情绪怎么样?““背景里那个声音是什么?““这两个人谁更着急?"——这些问题,纯 ASR 永远答不了,因为答案在它转写时丢掉的那一层里。语音不再被压扁成文字,而是作为一种"模态"被模型整体地理解。

这一代解决的是理解的深度。代价是两条:

一是贵且重。一个 Omni 模型比一个专用 ASR 大得多,推理成本、显存占用都不在一个量级。你要的只是把客服录音转成文字做质检,上一个 Omni 模型就是高射炮打蚊子。

二是它还是"听-想"模型,不是"说"模型。Qwen3-Omni 这类有 Talker 模块能合成语音,但整体设计重心是"理解”。真正把"说"也做到极致、做到能跟人自然对话的,是第三代。

第三代:端到端语音,中间那行字彻底消失

第三代最激进:语音进,语音出,中间一个文字都不落。

flowchart LR
    subgraph 级联["级联管线(第一/二代拼起来)"]
        A1[语音] --> A2[ASR] --> A3[LLM] --> A4[TTS] --> A5[语音]
    end
    subgraph E2E["端到端语音(第三代)"]
        B1[语音] --> B2[单一语音模型] --> B3[语音]
    end

为什么要这么激进?因为级联管线有两个治不好的病。

一是延迟。语音转文字、文字进 LLM、文字再转语音,三段串起来,每一段都有自己的首包延迟,加上轮次判定,用户说完到 AI 出声常常要 500ms 往上。Kyutai 的 Moshi 主打全双工对话,理论延迟做到 160ms、实测约 200ms——已经摸到人类对话轮次间隔(中位数约 200ms)的水平。这是级联架构怎么调都很难够到的。

二还是那个信息丢失问题,而且这次是双向的。级联管线里,你的语气在 ASR 那步丢一次,AI 想表达的语气又得靠 TTS 那步硬"演"出来。端到端模型把这两步合一了,语气、韵律、节奏、什么时候停顿、要不要轻笑一声——这些东西在模型内部是连续表示,不经过文字这个瓶颈。Sesame 的 CSM 主打的就是这种"对话级"的自然度。

到 2026 年中,这一代已经分成两个明显的阵营:

OpenAI 5 月发的 GPT-Realtime-2 把 GPT-5 级的推理塞进了实时语音对话,128k 上下文,还能调推理强度;Google 3 月的 Gemini 3.1 Flash Live 是纯 audio-to-audio,支持 90 多种语言,简单问题的响应速度更快。两家是目前生产环境里最主流的两个闭源选项。

但端到端不是免费的午餐,它赔进去的东西很具体:

• 难调试、难审计。中间没有文字,出了问题你没有那行可以打断点、可以给合规看的文本。客服、金融这类场景,“这通电话 AI 到底说了什么"必须留痕,纯端到端反而是负担。
• 不能换脑子。级联管线里 LLM 是可插拔的,你想换更强的、更便宜的、自己微调的,随时换。GPT-Realtime、Gemini Live、Moshi 都用自带的推理内核,绑死了,你没得选。
• 业务逻辑没地方插。语音直接到语音,中间那行文字本来是你塞 RAG 检索结果、塞函数调用、塞业务规则的地方。它没了,这些就得用别的机制绕。

所以一个容易被忽视的事实:即便 Sesame CSM 的合成首包能做到 150ms,那也只是"合成"这一步。真接进产品,你还是得在前面加 ASR 或语音理解、加你自己的检索和业务逻辑——算下来总延迟未必比一条调好的级联管线低多少。端到端解决的是架构的优雅和上限,不是按个开关就提速。

2026 年,你的场景该站第几代

把上面三代收一收,我给一个明确的、带取舍的判断,不和稀泥:

只要把语音变成文字——还是第一代,而且别犹豫。 会议纪要、字幕、录音转写、关键词检索,这些任务的本质就是"我要那行字”。Whisper large-v3 这类专用 ASR 又快又便宜又好部署,上 Omni 或端到端纯属浪费钱。这一代不会消失,它只是退回到了它本该待的位置:一个成熟、无聊、好用的工具。

要"听懂"而不只是"听见”——上第二代。 你要分析情绪、识别声音事件、理解一段音频里到底发生了什么,Qwen3-Omni 这类多模态语音理解模型是对的选择。它贵,但你买的是 ASR 给不了的那层信息。典型场景:智能质检、音视频内容理解、需要"察言观色"的分析类应用。

要和人实时对话——第三代,但分两种情况站队。

• 陪伴、互动、教育、Web 端的语音玩法,延迟和自然度是命门,数据还可能敏感——Moshi、Sesame CSM 这类开源端到端值得自己跑起来。
• 语音应用要做复杂的多步推理、要调一堆工具、要 agentic 的能力——GPT-Realtime-2、Gemini Live 这类闭源 API 更现实,你买的是它背后那个强推理内核。
• 而强管控、强合规的电话客服,我的判断仍然没变:老老实实用级联管线。可控、可审计、LLM 可替换,这些在合规场景里比那两百毫秒值钱得多。

最后说句容易被宣传带偏的话:新一代出来,不等于旧一代该被扔掉。 这一两年真正发生的,不是"端到端取代了 ASR”,而是语音模型从"只会一件事"长成了"一个谱系”——专用 ASR 在一头,端到端语音在另一头,中间是多模态理解。会选型,比追新更重要。先想清楚你的场景到底要什么:是要那行字,要那层情绪,还是要那两百毫秒。想清楚了,该站第几代,自己就有答案了。

这不是魔法,是流式 TTS 的基本盘。差别在于:你是等整句音频生成完再播,还是第一个音频块一出来就往用户耳朵里塞。前者用户等 1.2 秒,后者等 150ms——同一个模型,同样的算力,体验差一个数量级。

我在《实时语音对话的延迟预算》里把整条语音 Agent 链路拆过一遍,TTS 那一段只给了一句话:“要流式,首包出来就播。“这篇把那一句话展开,只讲 TTS。

为什么是"首包”,不是"整句”

先说清楚一个被混淆得很厉害的指标。

很多 TTS 厂商的官网首页挂着"实时率 0.3"或者"合成速度比真人快 3 倍"——这说的是整句合成耗时:一句 5 秒的话,1.5 秒合成完。这个数字对离线场景(把一本书转成有声书)有意义,对实时对话几乎没意义。

实时对话里真正决定体验的是 TTFA(time-to-first-audio,首包音频延迟):从你把文字喂给 TTS,到第一段能播放的音频抵达用户、开始出声,中间隔了多久。

道理和流式 LLM 一样。LLM 看的是首 token 延迟(TTFT),不是整段生成完的时间;TTS 看的是首包,不是整句。因为一旦第一个音节开始播,后面的音频是边合成边播的——只要合成速度比播放速度快(实时率小于 1),用户就永远听不到"卡壳"。整句要 1.5 秒还是 3 秒,用户根本感知不到,他在听前半句的时候,后半句已经悄悄合成好排在缓冲区里了。

所以这篇标题里的"150ms",指的是 TTFA。这是 2026 年一个够格但不极致的数字:对话不会让人觉得"AI 在想",但还没到 Cartesia Sonic-3 那种 40ms 模型延迟的极限。

有个数字陷阱要先点破。厂商宣传的"75ms"或"100ms"通常是纯模型推理时间——在一块独占 GPU 上,喂一段短文本,模型吐出第一块音频要多久。它不含网络往返、不含 API 网关排队、不含音频编码、不含你播放器的缓冲。一个 benchmark 跑 100ms 的模型,部署在共享云上、赶上流量高峰,端到端能轻松飙到 800ms。所以看 TTFA 数字,永远要问一句:这是模型延迟,还是用户真实感知到出声的延迟?这篇说的 150ms,是后者。

首包延迟花在哪

把 TTFA 拆开,大致是这么几块:

看这张表,有两件事值得拎出来说。

第一,播放器缓冲常常是最肥的一块,也最容易被忽略。工程师盯着模型延迟抠了半天,把模型从 120ms 压到 80ms,结果播放器为了抗抖动设了 200ms 缓冲——白忙活。这块后面单独讲。

第二,网络往返是固定成本,且省不掉,只能靠部署位置压。一次上下行加起来 40–160ms,如果你的 TTS 服务在弗吉尼亚,用户在上海,光物理距离就吃掉 200ms 以上。这部分不优化,模型再快也是纸面数字。

怎么把它压下去

按收益从大到小排,六个手段。

1. 流式合成:这是地基,不是优化项

如果你的 TTS 是"等整句文本到齐 → 整段合成 → 整段返回",那前面所有讨论都不成立。流式 TTS 的协议(通常是 WebSocket)允许文字一边到一边合成:LLM 还在生成后半句,前半句的音频已经在合成了。

2026 年主流的实时 TTS 都走这条路。ElevenLabs Flash 官方标的端到端 135ms TTFB;Cartesia Sonic-3 靠 SSM(状态空间模型)架构做到 40ms 首包、90ms 模型延迟;Deepgram 的 Voice Agent TTS 标 sub-200ms。这些数字的前提全是流式——没有流式,谈不上首包。

2. 按句/标点分块,而不是按字数

LLM 吐出来的是 token 流,你不能每来一个 token 就喂给 TTS——那样韵律会碎成渣。你需要在中间攒一个最小可合成单元再发。

分块策略大致三种:

• 固定字符数(比如 150–300 字符):延迟可预测,但会从句子中间切开,韵律遭殃。
• 句子/标点边界:在句号、问号、逗号处切。韵律自然,但延迟不固定——遇上一个长句,首块迟迟攒不齐。
• 动态自适应:首块用最激进的策略(凑够一个短语就发),后续块按标点切。

我的建议很明确:首块和后续块用不同策略。首块只追求"快"——攒到第一个逗号、或者凑够一个能独立成韵的短语(7–10 个字)就立刻发出去,让用户尽快听到声。从第二块开始切回句子边界,保住整体韵律。用户对首块的韵律宽容度其实很高,他在乎的是"AI 开口了没";但要是整段都按短语切,听感就会一顿一顿的。

3. 模型预热:别让第一个用户当小白鼠

冷启动是隐形杀手。一个刚拉起的 TTS 实例,第一次请求往往要额外几百毫秒——CUDA context 初始化、模型权重换入显存、KV cache 分配。

解法是预热:实例就绪后、接真实流量前,先用一段哑文本跑几次完整合成,把所有 lazy 初始化的路径走通。配合发布策略——新实例预热完成才进负载均衡的轮转。否则每次扩容、每次滚动发布,都会有一批倒霉用户撞上冷启动的尾巴。

4. 合成与播放重叠

这是流式 TTS 的核心收益,也是最容易在实现上漏掉的地方。原则一句话:链路上任何一环都不能"攒齐再传"。

flowchart LR
  L[LLM 输出 token 流] -->|按标点切块| C1[文本块1]
  L -->|按标点切块| C2[文本块2]
  L -->|按标点切块| C3[文本块3]
  C1 --> T1[TTS 合成 块1]
  C2 --> T2[TTS 合成 块2]
  C3 --> T3[TTS 合成 块3]
  T1 --> P[播放队列
边收边播]
  T2 --> P
  T3 --> P
  P --> S[用户听到连续语音]

块 1 在播的时候,块 2 在合成,块 3 的文本还在 LLM 里生成。三件事并行。只要合成速度跟得上播放速度,用户听到的就是一条不断的声音。一旦某一环改成"等齐",感知延迟立刻塌回真实延迟。

5. 就近部署

网络往返省不掉,但能缩短。把 TTS 推理节点放在离用户近的区域,40–160ms 的往返能压到几十毫秒。对全球业务,这意味着多区域部署 + 按用户地理位置路由。这条不涉及任何模型技巧,纯靠基建,但收益实打实。

6. 选对音频格式

回传格式直接影响首包能多快"可播"。这里有个反直觉的点:很多 TTS 流式返回的头几个字节根本不是音频,而是容器元数据——WAV 头、Ogg 识别页、MP3 的 ID3 标签。播放器要等这些 + 第一个真实音频帧才能起播。

实时场景优先用裸 PCM(比如 pcm_22050):没有容器头,第一个字节就是可播音频,省掉解析开销。代价是带宽——PCM 不压缩,流量大。带宽敏感就退一步用 Opus,它的帧结构对低延迟友好,别用 MP3。

首包延迟、音质、成本:三角取舍

没有免费的午餐。把首包压到极限,一定在别处付了代价。

我的取舍偏好,按场景分:

实时对话(客服、语音助手):首包延迟优先,音质够用就行。用户在打电话,他不会拿着话筒细品音色,他要的是不卡、不等。这种场景我会接受首块韵律略糙,换 150ms 的 TTFA。

有声内容(播客、有声书、视频配音):音质优先,首包延迟根本不是问题——这是离线批处理,慢就慢。该上最好的模型、最细的韵律控制。

成本敏感的规模化场景:别盲目追 P50。真正影响体验的是 P99——你不能让 1% 的用户等 2 秒。Cartesia 用 SSM 架构主打的卖点就是 P99 比 transformer 稳,因为 SSM 是线性扩展、不像 transformer 那样随序列长度二次膨胀。规模一大,P99 的稳定性比 P50 的漂亮数字值钱得多。

一句话:先明确你在哪个场景,再谈压到多少毫秒。脱离场景比拼 TTFA 数字,是营销,不是工程。

实践中真正会咬人的坑

前面讲的是怎么做对。这一节讲怎么做错——这些坑我和身边的人基本都踩过。

坑一:分块切太碎,韵律断裂。 为了压首包,有人把分块阈值设得很激进,每凑 3–5 个字就发一块。结果 TTS 拿到的全是没头没尾的碎片,它无法预测句子级的语调走向——该升调的地方平了,该停顿的地方连上了,整句听起来像机器人念词卡。根因是流式 TTS 在局部上下文下做韵律预测,缺了句子的全局结构。务实的做法:首块可以碎(用户宽容),但从第二块起一定切回标点/句子边界,把韵律的锅甩给完整的句子。

坑二:首块太短,反而更慢。 听起来矛盾——首块越短不是越快发出去吗?但太短的首块(比如 2 个字)会触发两个问题:一是 TTS 对超短文本的相对开销更高(prefill 的固定成本摊不开);二是它播完只要零点几秒,而第二块还没合成好,中间出现空隙,用户听到"你好……(停顿)……我是客服"。首块不是越短越好,要够短到快、又够长到能撑住后续块的合成时间。经验值是凑够一个完整短语,7–10 个字。

坑三:缓冲欠载(buffer underrun)导致卡顿。 播放器从网络收音频块,凑够一点就开播。如果某一块因为网络抖动或合成慢迟到了,播放队列被掏空——这就是缓冲欠载,用户听到爆音或者卡顿。

缓冲设置是个跷跷板:缓冲小,起播快(TTFA 低),但抗抖动差;缓冲大,起播慢,但播得稳。没有放之四海的数值。数据中心内部、网络稳定,50–100ms 缓冲够了;移动端、网络飘忽,得放到 150–250ms 来吸收抖动。

更关键的是把欠载率当独立指标监控,别只看 TTFA。一个务实的阈值:如果缓冲欠载超过请求总数的 2%,就该调大缓冲——哪怕这意味着 TTFA 涨几十毫秒。卡顿对体验的伤害,远大于首包慢那一点点。慢半拍用户能忍,中间卡一下用户立刻出戏。

坑四:只测了模型,没测端到端。 回到开头那个数字陷阱。你在本地用独占 GPU 测出 80ms 首包,上线后用户反馈"AI 反应慢"。因为真实链路上还叠着网络、网关排队、编码、播放器缓冲。测 TTFA 一定要从用户视角测——从发出请求到扬声器真正出声,端到端打点,而且要测 P99,不是 P50。

落地优先级

如果你正在做 TTS 这一段,顺序是这样:

1. 先确认是流式的,而且整条链路没有任何一环"攒齐再传"。这步收益最大、几乎不花钱。
2. 调分块策略——首块激进、后续块按标点。这步直接决定 TTFA 和韵律的平衡。
3. 加预热,别让扩容和发布把冷启动甩给用户。
4. 测端到端 P99,把播放器缓冲和欠载率纳入监控。
5. 最后才谈就近部署、换更快的模型——这些是基建和钱的问题,放在管道理顺之后。

很多团队一上来就到处比价"哪家 TTS 首包最低"。但如果你的播放器缓冲设了 250ms、链路里还藏着一个"攒齐再传"的环节,换哪家模型都救不回那种慢半拍。先把自己这边的链路理顺,再去谈毫秒。

参考来源:ElevenLabs Latency 文档 · Cartesia Sonic-3 · Gradium: Best Low-Latency TTS APIs 2026 · Deepgram: Streaming TTS Latency Tradeoff · Picovoice: TTS Latency

这些数字背后有一个让人不舒服的事实:克隆一个人的声音,现在只需要三秒公开音频。你公司高管参加过的每一场财报电话会、每一次大会演讲、每一段播客采访,都躺在公网上,对想用它的人来说就是现成的训练素材。

克隆技术本身已经不是新闻——这个博客之前写过《声音克隆:60秒复制你的声音,然后呢?》。这篇讲"然后"的另一面:声音一旦能被以假乱真地复制,我们靠什么分辨真假,以及这件事到底能做到多好。

滥用长什么样:三种,不是一种

把"AI 语音诈骗"当成一个笼统的词,会让你低估它。它至少是三类性质不同的攻击。

第一类是社工诈骗。 最经典的是"亲人求救":伪造你孩子的哭腔打电话说出事了急需用钱。但 2025 年真正造成大额损失的是企业版——伪造 CEO 或 CFO 的声音,指示财务转账。香港那起 2.56 亿港元的案子是个标志:财务员工参加了一场视频会议,会议里的 CFO 和同事全是 AI 生成的,人脸、口型、声音都对得上,他一开始怀疑是钓鱼,但一场"活的"视频会把他的怀疑全打消了,直到事后跟总部人工核对才发现。

第二类是声纹绕过。 不少银行和券商用"我的声音就是我的密码"做身份验证。克隆语音直接攻击这套系统。它比社工诈骗更隐蔽,因为受害的不是某个被吓住的人,而是一套自动化的认证流程——没有人在场可以"觉得不对劲"。2025 年 1 到 8 月,某金融机构的活体检测被 AI 伪造尝试绕过了 8000 多次。

第三类是假音频内容。 伪造公众人物的录音、伪造一段"泄露的会议录音"、给某段视频配上从没说过的话。它不针对个人钱包,针对的是舆论和信任。2024 年美国大选期间出现过伪造拜登声音的自动外呼电话,就是这一类。

三类攻击的防御手段完全不同。社工诈骗要靠流程和人的警觉,声纹绕过要靠活体检测,假内容要靠溯源和检测——别指望一招通吃。

检测合成语音:能做到,但有前提

检测分两条路:被动检测(拿到一段音频,判断它是不是 AI 合成的)和主动标记(生成时就打上记号)。先说被动。

被动检测模型在学术基准上的成绩相当好。这个领域有一套延续多年的评测体系——从早年的 ASVspoof 挑战赛,到 2026 年 ICME 的环境感知语音检测挑战赛(ESDD2)、ACM Multimedia 的全类型音频伪造检测挑战赛(AT-ADD)。检测模型也在进步:用 Whisper 这类大规模语音模型抽特征,比传统声学特征的等错误率(EER)低了约 21%,再针对反伪造任务微调 Whisper 编码器,还能再降近 15%。

听起来不错。但"在干净数据集上 EER 很低"和"在真实世界管用"之间,差了一整条鸿沟。

flowchart TD
  A[一段语音] --> B{被动检测模型}
  B -->|实验室条件| C[准确率很高]
  B -->|真实世界| D[麻烦开始了]
  D --> E[电话信道压缩]
  D --> F[录音回放/翻录]
  D --> G[训练时没见过的新 TTS]
  D --> H[环境噪声/混响]
  style C fill:#d8f0d8,stroke:#5aa05a
  style D fill:#fde7c2,stroke:#e8b23c

真实世界里有三个东西在持续打击检测准确率:

• 信道劣化。 一通诈骗电话经过窄带编码、丢包、压缩,把那些"AI 痕迹"——比如不自然的高频细节、过于平滑的频谱——磨掉了大半。检测模型训练时见的是高保真音频,推理时拿到的是被电话线榨过的音频。
• 回放攻击。 攻击者把合成音频用音箱播出来、再用麦克风录下来。这一录一放,等于给假音频套了一层"真实物理世界"的外衣,很多检测器会被骗过。专门为这种场景做的数据集(比如 EchoFake)就是冲着这个问题来的。
• 泛化。 这是最根本的。检测模型本质上是在学"已知的几种 TTS 系统留下的指纹"。一个训练时没见过的新模型出来,检测器对它就是睁眼瞎。而新的 TTS 模型几乎每个月都在出。

所以我的判断是:被动检测有用,但不能当成单点防线。 它适合做大规模内容平台的初筛、做事后取证,不适合做"接到电话实时告诉你这是假的"那种承诺——任何号称能实时、高准确、对所有声音通杀的检测产品,你都该多问几句它在什么数据上测的。

声纹活体:防的是"录音",未必防得住"克隆"

声纹认证系统自己也有反伪造机制,通常叫"活体检测"(liveness detection)。但要分清它原本是防什么的。

活体检测最早是为了防回放攻击——防止有人拿一段你说话的录音来冒充你。它会去找录音特有的痕迹:音箱的频响特性、二次录制引入的失真、缺少真人说话该有的呼吸和微小变化。对着录音,这套机制管用。

问题是,高质量的神经网络合成语音不是"录音"。它没有音箱频响的指纹,它的呼吸、停顿、韵律是模型直接生成的,看起来比一段翻录干净得多。换句话说,为防回放设计的活体检测,面对端到端克隆语音时,部分假设已经不成立了。

更麻烦的是"语音变形"(voice morphing)攻击——把攻击者自己的真实语音和目标人的声纹特征混合,生成的音频既带着真人说话的所有物理特征(因为底子是真人录的),又带着目标人的声纹。这种攻击专门钻活体检测和声纹比对之间的缝。

现在还有"深度伪造即服务"(Deepfake-as-a-Service)——黑产把克隆和绕过工具打包成服务卖,一套合成身份、克隆声音的素材,在地下市场只要五美元。攻击的门槛已经低到不需要任何技术。

我的看法直接一点:2026 年,“声音即密码"这个产品设计应该被淘汰了。 声纹可以作为一个信号参与风险评分,但不能作为单一凭证去解锁转账、改密码这类高危操作。把一个已经能被三秒素材复制的东西当成身份证明,是设计缺陷,不是技术细节。

音频水印:把检测的难题倒过来

被动检测难,难在它要从音频里"反推"真假。主动水印换了个思路:在 AI 生成语音的那一刻,就在音频里嵌一个人耳听不见、但机器能检出的标记。这样要回答的问题从"这段音频是不是假的"变成了"这段音频里有没有我的水印”——后者好回答得多。

Meta 的 AudioSeal 是目前最有代表性的方案。它的设计有两个关键点值得说:

一是定位能力。 它不只能判断"整段音频有没有水印",还能精确到样本级——在 16kHz 采样率下,能指出每一个 1/16000 秒的片段是不是带水印的。这意味着如果有人把一句真人录音里只抠掉几个字、换成合成的,水印检测能定位到那几个字。

二是检测速度。 它用单次前向的检测器,比靠水印密钥逐一解码的老方法快两个数量级。这点对落地很重要——内容平台要扫的是每天上传的海量音频,检测器慢一点,整个方案就不可行。

水印的真正价值不在"抓坏人",在给善意内容一个可以自证清白的办法。一家正规 TTS 服务给自己所有输出打上水印,等于主动声明"这是我生成的";新闻机构给自己的真实采访录音打上来源标记,等于主动声明"这是真的"。社会需要的不是"找出所有假音频",而是逐步建立"没标记的内容默认不可信"的预期。

但水印不是银弹,它有两个硬伤:

所以水印解决的是"占大多数的正规生成内容如何被标记"的问题,不解决"恶意攻击者"的问题。把它和被动检测、和内容来源标准(比如 C2PA 那套溯源元数据)叠在一起,才构成一张有意义的网。

为什么这注定是猫鼠游戏

讲到这里该说一句不太好听的:合成语音检测,在原理上就是一场打不赢的军备竞赛。

原因不在哪个团队不够努力,在结构。生成模型和检测模型之间存在一个根本的不对称——

flowchart LR
  G[生成方] -->|留下可检测痕迹| D[检测方学会识别]
  D -->|痕迹被公开| G2[生成方针对性消除痕迹]
  G2 --> D2[检测方需要新痕迹]
  D2 -.循环.-> G
  style G fill:#fde7c2,stroke:#e8b23c
  style G2 fill:#fde7c2,stroke:#e8b23c

每当检测方发现一类"AI 痕迹"并公开(发论文、开源模型、办挑战赛),这个发现立刻变成生成方的优化目标——下一代 TTS 训练时,只要把"骗过这个检测器"加进损失函数,痕迹就被磨掉了。检测方天然滞后,因为它只能对已经存在的生成模型做出反应。

更不利的是终点不一样。生成方的目标是"无限逼近真人",而真人语音是存在的、有上限的;一旦合成语音在物理特征上和真人无法区分,检测方就没有信号可用了——不是检测器不够好,是信息论意义上无东西可检。

那是不是就躺平?不是。结论应该是:别把宝押在"检测出假的"上,要把重心移到"验证出真的"。

• 检测假音频是开放问题,可能永远做不到 100%。
• 验证真音频是封闭问题:水印、数字签名、内容来源链(C2PA),这些是可以做到接近确定的——因为它不依赖猜测,依赖密码学。

防御的长期方向,是让"可信"成为需要主动证明的东西,而不是默认状态。

平台和个人,各自能做什么

技术讲完,落到行动。

对平台和企业:

• 高危操作做带外验证(out-of-band)。 转账、改预留信息、授权放款,绝不能只凭一通电话或一段语音确认。换一个独立信道——回拨已登记的号码、在内部系统二次确认、设一个对方知道你知道的口令。香港那 2.56 亿的案子,只要一通打回总部的电话就能拦下。
• 声纹只做风控信号,不做唯一凭证。 把它和设备指纹、行为特征、信道分析一起喂进风险评分,任何一个高危动作都要多因子。
• 自家生成的语音一律打水印、留来源标记。 这不是为了抓别人,是为了让你的正规内容可被验证,也是给行业立规矩。
• 检测模型当初筛和取证用,别对外承诺实时通杀。 同时持续用新出的 TTS 系统更新训练集——你的检测器和攻击者用的生成器,得在同一个时代。

对个人:

• 认知层面接受一件事:听到的声音不再等于身份证明。 这是 2026 年最需要更新的常识。电话里"你妈的声音"、“你老板的声音”,都不构成"确实是本人"的证据。
• 和家人约一个口令。 一个只有你们知道、不会出现在任何社交媒体上的词。接到"家人急用钱"的电话,先问口令。土办法,但有效。
• 挂掉,回拨。 任何涉及钱或敏感信息的来电,无论声音多像,挂掉,用你通讯录里原本存的号码打回去。克隆语音能伪造声音,伪造不了你主动拨出的这通电话。
• 少喂素材。 三秒就够克隆。公开演讲、播客、短视频里的长段清晰人声,本质上是在公网上发布自己的声纹。这不是让你别说话,是让你知道代价。

最后留一句判断:这场对抗里,纯技术解(更强的检测器)只能拖时间,拖不到终局。真正能把损失压下去的,是流程——带外验证、口令、回拨这些听起来很"低科技"的东西。当声音不再可信,可信的得是别的:你拨出去的号码、你和家人之间的暗号、系统里另一个独立的确认信道。技术制造了这个问题,但解决它,要靠把"信任"重新放回那些不能被三秒音频复制的地方。

参考来源:FBI AI 语音钓鱼预警、深度伪造 CEO 诈骗案例分析、AudioSeal:语音克隆的主动检测水印、ESDD2 环境感知语音伪造检测挑战赛、语音生物识别攻击面扩大、深度伪造即服务报告。

两套都咬字清楚、没有杂音、采样率拉满。但其中一套你一听就知道是机器——不是因为它念错了,恰恰是因为它念得太"齐"了。每个字的时长几乎一样,每个停顿都卡在标点上,整句话像被一把尺子量过。

人不是这么说话的。人说"还真没想到"的时候,“真"会拖长一点,“没"会轻一点,“想到"前面会有个几乎听不见的迟疑。这些东西加起来,就是韵律(prosody)。发音准是 2020 年就解决的问题;韵律和情绪,才是 2026 年还在啃的硬骨头。

这篇讲清楚:念稿感到底差在哪儿,以及现在有哪几条路去补。

念稿感不是发音问题,是韵律问题

先把概念拆开。一段语音里,“说了什么"是文本内容,“怎么说的"是韵律。韵律不是一个东西,是四样东西叠在一起:

• 节奏(timing)——每个音、每个词占多长时间,语速是匀的还是有快有慢。
• 停顿(pause)——停在哪里,停多久。停顿不只在逗号句号,也在一个意群说完、或者你要强调下一个词之前。
• 重音(stress)——哪个词被加重了。”我没说过"和"我没说过”,意思完全不同。
• 语调(intonation)——句子的音高曲线。陈述句往下走,疑问句往上挑,反问句又是另一条线。

念稿感的根源,是早期 TTS 把这四样都做成了"默认值”:语速恒定、停顿只认标点、不分轻重、语调按句型套模板。结果就是每句话都念得四平八稳,像新闻联播里的提示音。

更麻烦的是,韵律和情绪是强耦合的。同样一句"你来啦”,高兴时音高整体偏高、句尾上扬;敷衍时又平又短;惊讶时第一个字猛地拔高再回落。情绪不是在准确的发音上再"刷一层颜色”,情绪本身就是通过韵律表达出来的。所以"TTS 加情感"这件事,本质上是"让 TTS 学会控制韵律"。

学术界很早就指出了拦路的三个问题:标签依赖(模型只会照训练时见过的"高兴/悲伤"几个标签走)、风格纠缠(想让它变开心,音色也跟着变了)、控制粒度太粗(只能整句一个情绪,改不了某个词)。这三条到现在也没完全解决,只是被绕过的方式越来越多。

控制韵律的四条路

2026 年要给语音"调情绪",大致有四种手段,从"最可控"到"最自然"排开,正好是个谱系。

flowchart LR
  A[SSML / 标记
精确·机械] --> B[参考音频
自然·难复用]
  B --> C[指令式控制
灵活·偏意会]
  C --> D[上下文感知
省心·难调试]
  style A fill:#fde7c2,stroke:#e8b23c
  style D fill:#cde9d6,stroke:#3c9e6a

第一条:SSML 和标记。 这是最老、也最确定的办法。你用标记语言显式地告诉引擎:这里停 300 毫秒、这个词音高升 10%、这段语速放慢。SSML 至今仍是工业界控制语音合成的事实标准,因为它可复现——同样的标记,出来的语音每次都一样。它的代价也明显:你得手动标,标多了维护成本极高,而且本质上是在用规则逼近一个连续的东西,生硬的接缝藏不住。新一代模型在 SSML 之外加了实验性的情绪标签,比如在句首写 [surprised],让整句带上惊讶的底色——比纯 SSML 省事,但仍然是离散的、一句一个。

第二条:参考音频。 不告诉模型"要开心",而是直接丢给它一段开心的录音,让它"照着这个感觉说"。Qwen3-TTS 这类模型 3 秒参考音频就能克隆音色和说话风格,Fish Audio S2 用 10 秒参考做跨语种迁移。这条路的好处是自然——韵律是从真人录音里"抄"来的,不是算出来的。坏处是难复用:你想要一个"略带歉意但又不卑微"的语气,得真去找到或录一段这样的音频,而且参考音频里的情绪和音色经常分不干净。

第三条:指令式控制。 用自然语言描述你要的效果:“用安慰的语气,慢一点,句尾别上扬。“这是 LLM 时代才成立的玩法。它灵活到几乎没有边界,你能描述出任何细微的语气。但它也最"意会”——同一句指令,不同模型、甚至同一模型不同时候,理解都可能有偏差。它适合创作和探索,不适合需要每次结果一致的生产链路。

第四条:上下文感知。 前三条都是"你来告诉模型怎么说”,这条是"模型自己看着办"。模型读完整段对话历史,自己判断这句该用什么韵律——上一句用户在抱怨,这句回应就自然带上安抚;聊到一半用户开了个玩笑,这句就轻快一点。它把每句话当成对话的一部分,而不是一段孤立的朗读。这是长对话语音最舒服的形态,代价是你几乎放弃了控制权:它念错了情绪,你很难定位是哪一步出的问题。

四条路不是互斥的。现实里常常是混着用:主体走上下文感知或参考音频拿到自然度,关键节点用 SSML 或情绪标签做精确兜底。 纯靠某一条都会有明显的短板。

端到端模型为什么天生更会"演"

级联式 TTS——文本进、语音出——有个绕不过的结构问题:情绪信息在文本里就丢了。

用户说了一句带着委屈的话,ASR 把它转成文字,委屈没了;LLM 生成一句回应文本,这段文字本身不携带"该用什么语气念"的信息;TTS 再从这段干巴巴的文字里凭空"猜"情绪。整条链路上,情绪经过了一次"压成文字、再还原成声音"的有损转换。你可以用前面那四条手段把情绪再"贴"回去,但贴回去的,终究是你猜的,不是原本就在那儿的。

端到端语音模型(speech-to-speech)走的是另一条路:语音直接进、语音直接出,中间不落文字。用户语气里的委屈,模型直接"听"到了,生成回应时也直接带着合适的语气出来。情绪从来没被压成文字,自然也就没丢。

这就是端到端在情绪和韵律上的天然优势——不是它的模型更聪明,是它的信息通路上没有那道有损的瓶颈。一句话里"说了什么"和"怎么说的"始终捆在一起走。

flowchart LR
  subgraph 级联
    A1[语音] --> A2[文字
情绪丢失] --> A3[文字回应] --> A4[TTS 猜情绪] --> A5[语音]
  end
  subgraph 端到端
    B1[语音] --> B2[语音回应
情绪全程保留]
  end
  style A2 fill:#f5c6c6,stroke:#c0392b
  style B2 fill:#cde9d6,stroke:#3c9e6a

代价也得说清楚:端到端难调试、难审计、难合规。它没有中间的文字可以打日志、做敏感词过滤、给客服质检看。所以电话客服这种强管控场景,2026 年的默认仍然是级联;但陪伴、互动、娱乐类的产品,端到端那种"接得住情绪"的体感,是级联怎么调都很难追上的。

对话里的韵律:笑声、犹豫和那些"嗯"

前面讲的还是"把一句话念好"。但真实对话里,韵律的战场不只在句子内部,更在句子之间和词语之外。

人在对话里会发出大量非词汇的声音:笑、轻笑、叹气、清嗓子、吸气,还有"嗯"“啊"“这个"“那个"这类填充词。学术上把它们分成几类——生理性的(呼吸、咳嗽)、情绪爆发性的(笑声、叹息),还有对话管理性的(填充停顿、应答词)。最后这类最关键:它们不传递字面信息,但传递"我在听"“我在想"“我有点犹豫”。

为什么这些对"不像念稿"特别重要?因为念稿的人不会有这些。念稿是单向输出,对话是双向协调。一段语音里如果完全没有犹豫、没有应答词、没有一丝换气的痕迹,它再准也是在"播报”,不是在"对话”。

现在面向对话的模型已经开始原生支持这些。Chatterbox-Turbo 内置了 [laugh]、[cough]、[chuckle] 这类标签;Nari Labs 的 Dia 能直接从剧本生成带笑声、叹息的多人对话。研究侧也出现了专门的非词汇发声基准(NVBench、NV-Bench),开始系统地评测模型这方面的能力。

但工程上有个真问题:这些声音不能硬塞。 一段回应里"哈哈"加在哪、犹豫的"嗯"放哪,本身就需要韵律和语义的判断。“嗯"放在思考一个难问题之前是自然的,放在回答"今天星期几"之前就很怪。笑声接在一个并不好笑的句子后面,比没有笑声更出戏。理想情况下,这些应该是上下文感知模型自己学出来的分布,而不是靠规则往里撒。

我的判断:对话语音的"像不像人”,非词汇的部分占的权重,被严重低估了。很多团队把全部精力花在"把字念得更准更自然”,但用户感觉别扭,常常是因为整段话太流畅、太干净了——干净得不像一个真人在即兴说话。

别演过头:过度表演的反效果

最后一条,也是最容易踩的:情绪不是越多越好。

当一套 TTS 终于能"演"了,很多人的第一反应是把它用满——每句话都加情绪标签,高兴就拉满高兴,惊讶就拉满惊讶。结果是另一种不像人:像一个用力过猛的配音演员,或者一个营业感很重的客服。

真人对话里,大部分句子的情绪其实是接近中性的,只是带着一点不易察觉的底色。情绪的高峰是稀疏的、有铺垫的——你不会每句话都惊讶,惊讶之所以是惊讶,是因为前面十句都平。如果每句都拔高,惊讶就不再是惊讶,只是噪音。

业界已经形成共识:情绪标记的正确用法是克制、刻意,只在对话真正需要的那个点上用。多轮里满屏标记,听感是戏剧化的、假的。这跟写文章一个道理——感叹号用一个有力量,每句都用就废了。

还有个更隐蔽的坑:情绪要和内容对得上。 模型用欢快的语气念一句报错信息,用户感受到的不是"这个 AI 很有活力”,是"这个 AI 没听懂我在说什么"。情绪一旦和语义错位,比完全平淡的念稿更糟——平淡只是无聊,错位是诡异。

所以"让 AI 不像念稿"这件事,真正的目标不是"让它充满感情",而是让它的情绪和韵律,恰好匹配它在说的内容和它所处的对话。多数时候,这意味着克制;少数关键时刻,才需要那一下到位的起伏。

怎么落地:一个务实的顺序

如果你在做语音产品,想摆脱念稿感,建议的优先级是:

1. 先解决韵律的基本盘——节奏有变化、停顿不只卡标点、意群之间能换气。这一步不需要"情绪",做好了念稿感就去掉一大半。
2. 再决定走级联还是端到端——对话类、容忍度高的产品,认真考虑端到端,它在情绪上的优势是结构性的,不是调参能补的。
3. 情绪控制混着用,别迷信单一手段——主体拿自然度,关键节点拿可控性。
4. 对话场景补上非词汇的声音——但让它自然分布,别用规则硬撒。
5. 始终把"克制"放在心里——情绪的默认值应该接近中性,高峰留给真正需要的时刻。

发音准早就不是门槛了。2026 年区分一套语音"像人"还是"像机器"的,是它会不会在该停的地方停、该轻的地方轻、该犹豫的时候犹豫——以及更难的:它知不知道什么时候该不动声色。

参考资料

• The Best Open-Source Text-to-Speech Models in 2026 — BentoML
• Qwen3-TTS:2026 开源语音克隆与生成完整指南
• Best Voice Cloning API for Developers (2026) — Inworld
• Best TTS for Long-Form Conversations (2026) — Inworld
• PROEMO: Prompt-Driven Text-to-Speech Synthesis Based on Emotion and Intensity Control
• NVBench: A Benchmark for Speech Synthesis with Non-Verbal Vocalizations
• SSML: The Practical Standard for Controlling Speech Synthesis

然后你把它接进真实业务。客户在马路边打来电话,背景是车流声;他说到你公司的产品名,转写出来是三个完全不相干的字;他报了一串订单号"一三幺零",屏幕上是"一三妖灵"。Demo 里的惊艳,到这里一点都不剩。

问题不在模型菜。开源的 Whisper、各家的流式 ASR,安静环境下的中文字错率早就压到了 3% 以下,这已经接近人工转写的水平。坑全在"安静环境、念稿子"这八个字之外——真实的语音是脏的,而工程的活,就是处理这些脏东西。这篇把落地之后才会碰到的坑,一个一个拆开。

第一个岔路口:流式还是非流式

这是接 ASR 之前必须想清楚的第一件事,选错了后面全是返工。

非流式(批量):把一整段音频丢进去,等它整段识别完,返回结果。流式:音频一边录一边送,模型一边听一边吐字,你能拿到不断更新的"中间结果"。

差别不只是"快一点慢一点"。它们是两类不同的产品形态:

记住一个核心事实:流式之所以准确率低,是因为它在"说完之前"就得交答案。它做"我想订一张去——“的转写时,根本不知道后面是"北京"还是"报告”。非流式没这个包袱,它能等整句听完再回头修正,所以同样的模型,非流式版本的字错率往往低一两个百分点。

这里有个 2026 年很常见、但容易踩反的折中:用 VAD 把长音频切成"准句子",每段当成一个 mini-batch 走非流式模型。这套做法在"实时字幕"这种场景里很香——它不需要逐字滚动,用户能接受"一句一句往外蹦",于是你既拿到了非流式的准确率,延迟又只是一句话的长度。但如果你做的是语音 Agent,用户在等 AI 回话,那这套就不行——你必须真流式,让 ASR 和用户说话并行跑,说完文字基本也就好了。

别被"我两个都要"骗了。 一个产品里通常只有一条主链路。先确定用户是不是在"等",再选。

专有名词、中英混读、数字:错得最离谱的三类

通用 ASR 在通用语料上训练,所以它对"通用的话"很强,对"你的话"很弱。落地后用户投诉最集中的,永远是这三类。

专有名词。 你公司叫"声析",模型从没见过这两个字的组合,它会按发音找一个最像的常见词——“声息"“生气"“省吃”。这不是模型蠢,是它在做概率上最合理的猜测。人名、产品名、内部黑话、行业术语,全是重灾区。

中英混读。 中文工程师说话天然混英文:“这个 bug 我提了个 PR"“把 latency 压下来”。问题是很多 ASR 在"语种判定"上是僵的——它先猜你这句是中文还是英文,再用对应的解码路径。猜错了,“PR"变成"批 R”,“latency"变成一串看不懂的拼音。2026 年好一些的方案(比如 Gladia、Deepgram Nova-3)做了句内 code-switching,语种切换不需要整句重判;但便宜的、老的模型,中英混读仍然是硬伤。

数字。 这是最隐蔽的坑。“一千二百三十四"应该写成 1234 还是"一千二百三十四”?电话号码、订单号、金额、日期,各有各的格式。这件事叫逆文本规整(ITN,Inverse Text Normalization)——把"口语形式"转成"书面形式”。ITN 做得糙,用户就会看到"我要订 2026 年 4 月 25 号"被写成"二零二六年四月二十五号”,或者反过来把门牌号"幺零幺"写成"101”——而它其实是房间名。

这三类问题的通用解药是热词 / 定制词表,下一节单讲。但要先有个心理预期:通用 ASR 在你的垂直场景里,开箱就是会错,而且错得很集中。 上线前必须拿你自己的真实音频跑一遍,把高频错词捞出来。

噪声和远场:训练集里没有的世界

录音棚的音频干净到不真实。真实音频里有空调声、键盘声、车流、回声、别人说话。

这里要分清两个不同的问题:

• 噪声(near-field + noise):用户离麦克风很近,但环境吵。手机贴着脸打电话属于这类。现代 ASR 对平稳噪声(空调、风扇)已经相当稳,因为训练数据里加了大量噪声增强。难的是非平稳噪声——突然的关门声、背景音乐、旁边一句人声。
• 远场(far-field):用户离麦克风一两米,信号本身就弱,还叠加了房间混响。智能音箱、会议室麦克风阵列属于这类。远场的难点不是"吵”,是"糊"——混响把语音的时间结构抹掉了。

工程上,别指望单靠 ASR 模型扛下这些。真正有效的是前面那一段链路:

flowchart LR
  A[麦克风阵列] --> B[波束成形
对准说话人]
  B --> C[降噪 / 去混响]
  C --> D[AGC
自动增益]
  D --> E[VAD
切掉静音段]
  E --> F[ASR]
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c

橙色的两块——波束成形和降噪去混响——是远场场景里 ASR 准确率的真正杠杆。一个被忽略的细节是 VAD 的位置:它把长段静音和纯噪声段切掉,不送进 ASR。这既省钱,又能防止 ASR 在没人说话时"幻听"出几个字来。Whisper 这类模型在长静音上幻听是出了名的,VAD 是最便宜的止损。

还有一个反直觉的点:降噪不是越狠越好。激进的降噪会把语音本身的高频细节也削掉,ASR 反而更难听清。降噪是为人耳服务还是为 ASR 服务,目标不一样,参数也不该一样。

标点、顺滑、热词:让转写"能用"的后处理

原始的 ASR 输出是一长串没有标点、保留了所有口水词的文字流。它"对",但不"能用"。中间隔着三层后处理。

标点恢复。 给文字流加上逗号句号问号。没有标点的转写,人读着累,喂给下游 LLM 也容易断句错误。

顺滑(disfluency removal)。 真实口语里全是"嗯"“那个"“就是说”,还有"我要去北——啊不是,去南京"这种自我修正。顺滑就是把这些口水词和修正痕迹删掉,留下干净的意思。这件事在"会议纪要"“客服质检"里是刚需——没人想看逐字的"嗯嗯啊啊”。但在另一些场景里你恰恰不能顺滑:比如做语言学研究、或者要分析用户的犹豫和情绪,口水词本身就是信号。所以顺滑要做成可开关的,别在管道里写死。

2026 年的趋势是把标点、ITN、大小写、顺滑这四件事用一个统一的标注模型一次做完,而不是串四个独立模块——后者每一层的误差会往下传。

热词 / 定制词表,这是对付上一节那三类错误最直接的手段。原理是在解码时,对词表里的词做上下文偏置(contextual biasing)——让模型在"声息"和"声析"之间犹豫时,因为"声析"在你的热词表里,而把概率掰向它。

热词不是免费的,有几个坑:

1. 热词表不能无限长。 表越大,偏置越稀,而且容易"过纠”——把本来对的常见词改成热词。几百到几千个词是合理区间,上万个就要换成"按场景动态注入"的检索式方案。
2. 热词要给对发音。 “GPU"这个词,用户可能念"G-P-U”,也可能念"鸡皮优"。热词只配字面,模型对不上音,偏置就不生效。
3. 热词救不了"完全没听清"。 它只在模型已经有几个候选、正在犹豫时起作用。如果信号烂到模型根本没把你的词列进候选,热词无能为力——那是降噪和远场该解决的问题。

多人说话:转写之外的另一道题

一对一的语音 Agent 不用操心这个。但只要场景里有两个以上的人——会议、多人客服、访谈——你就多了一道题:说话人分离(speaker diarization),也就是"谁在什么时候说了什么"。

这是和 ASR 正交的另一个能力。ASR 回答"说了什么",diarization 回答"是谁说的"。两件事各自都不简单,叠在一起更难,难点集中在:

• 重叠语音:两个人同时开口。这是 diarization 错得最多的地方,人耳都未必分得清。
• 说话人数未知:你事先不知道这场会有几个人,模型得自己估。
• 音色相近:两个声线接近的人,容易被归成同一个。

2026 年一个值得关注的变化是联合建模:微软 1 月开源的 VibeVoice-ASR 把转写、说话人分离、时间戳放在一次前向里一起做,一遍处理 60 分钟音频。这条路线的好处是各个子任务能互相借力——知道"说话人换了",有助于判断句子边界;反过来也成立。如果你的场景重度依赖 diarization,这类联合模型比"ASR + 一个独立的 diarization 模块"串起来要省心。

但提醒一句:diarization 的错误会污染下游。如果你拿带说话人标签的转写去做"客服话术分析",标签错了,整份分析的归因就错了。先评估你的场景对说话人准确率的真实要求,再决定要不要上。

WER 会骗你:关于评测的真话

聊到这里必须说说那个所有人都在用、但被严重高估的指标——WER(词错误率)。

WER 的算法是:把识别结果和标准答案对齐,数出替换、删除、插入三类错误,除以总词数。听起来很客观。但它有几个会让你做错决策的毛病:

第一,WER 把所有错误当成一样重。 “我要订机票"识别成"我要定机票”,和识别成"我不要订机票",WER 给的惩罚可能差不多。但对你的业务,一个无所谓,一个是事故。关键信息(数字、人名、否定词、专有名词)错一个,比十个虚词错都严重。

第二,中文用 WER 本身就不对。 中文没有天然的词边界,“语音识别"算一个词还是两个词,取决于分词器。分词器一换,WER 就变。所以中文场景应该看 CER(字错误率)——按字算,跨分词器稳定。中英混读场景再进一步,业界用 MER(混合错误率):中文按字、英文按词。你要是还在拿 WER 横向比中文 ASR,比出来的排名是不可信的。

第三,WER 对"语义等价"零容忍。 “2026 年"和"二零二六年”、“OK"和"okay”,意思完全一样,WER 照样判错。一个 ITN 风格不同的模型,WER 会无端偏高。

那该怎么评测自己场景的 ASR?给一份可以照着做的清单:

1. 用你自己的真实音频建测试集,别用模型方给的 benchmark。至少几百条,覆盖你真实的口音、噪声、设备、语速分布。这一步最花时间,也最值钱。
2. 中文看 CER,中英混读看 MER,不要用 WER。
3. 单独算"关键实体错误率”:把数字、人名、产品名、否定词单拎出来统计准确率。这个数字比总体 CER 更能预测线上投诉量。
4. 分桶看,别只看一个平均数。按噪声等级、按远近场、按是否中英混读分别算 CER。平均数会把"安静场景拉高、嘈杂场景拖垮"这种结构性问题藏起来。
5. 测延迟,而且测的是首字延迟和稳定时间,不是整段耗时。流式 ASR 的中间结果会反复跳变,你要测的是"结果多久不再变"。
6. 做人工抽检。CER 降了 0.5%,但如果新错的全是关键词,体验是变差的。指标之外,定期让人看一眼真实转写。

最后:把顺序理对

如果你正要把 ASR 落地,优化的优先级应该是这样:

先选对流式 / 非流式。 这是产品形态决策,选错了后面全白干。判断标准只有一个——用户是不是在等。

再用真实音频建评测集。 没有这个,你后面所有的"优化"都是在拍脑袋。它还会直接告诉你高频错词是哪些。

然后配热词、调 ITN、补降噪。 针对评测集暴露的具体问题对症下药——错词集中就上热词,数字老错就调 ITN,嘈杂场景拖后腿就补前端降噪。

最后才考虑换模型或微调。 这是最贵、最慢的一步,而且很多时候,前面三步做扎实了,根本轮不到这一步。

ASR 落地真正难的,从来不是模型本身——模型早就够好了。难的是真实世界的语音很脏,而你的业务对"哪种错误不可接受"有自己的定义。把脏数据处理干净,把评测对齐到你的业务,模型才能真正帮上忙。

参考与延伸阅读:

• How to Evaluate ASR in 2026: Accuracy, Latency and Cost — Smallest.ai
• Best Speech-to-Text APIs in 2026 — Gladia
• AssemblyAI vs Deepgram: Best Voice Agent API
• microsoft/VibeVoice-ASR — Hugging Face
• Contextual Biasing for LLM-Based ASR with Hotword Retrieval and Reinforcement Learning
• Advocating Character Error Rate for Multilingual ASR Evaluation
• Four-in-One: A Joint Approach to ITN, Punctuation, Capitalization, and Disfluency