很多语音识别模型在标准测试集上的表现已经相当不错。拿一段近距离、单人、环境安静的录音去测试，转写结果往往很接近人工听写。但一旦把同样的模型放到真实会议室里，情况通常就会复杂很多：人名和专业词更容易出错，多人发言时内容容易串到一起，短句被漏掉，甚至文字本身识别正确，却被归到了错误的发言人名下。

这并不一定意味着 ASR 模型本身能力不足。更常见的原因是，真实会议转写并不是一个单纯的“语音转文字”问题，而是一条由拾音、降噪、语音检测、语音识别、说话人区分、时间对齐和文本后处理共同组成的处理链路。

一、会议场景首先改变的是 ASR 的输入条件

单人语音识别的理想输入比较简单：

说话人 → 麦克风 → ASR → 文本

但真实会议室通常更接近下面这种情况：

说话人 A ─┐
说话人 B ─┼→ 房间混响 → 环境噪声 → 麦克风 → 音频流
说话人 C ─┘

问题首先来自远场拾音。

在桌面会议、培训、访谈或者多人讨论中，说话人与麦克风之间往往并不是十几厘米的近距离，而可能达到一米甚至数米。距离增加以后，麦克风收到的直达声变弱，而空调、键盘、翻纸、桌椅移动等环境声音的占比会上升。

与此同时，会议室中的墙面、桌面、玻璃都会造成声音反射，形成不同程度的混响。即使最终保存出来的音频依然是标准的 16 kHz PCM 文件，它和近场录音对 ASR 来说也完全不是同一种输入。

因此，判断会议转写能力时，不能只看音频格式和采样率，还需要关注真实环境中的信噪比、拾音距离以及房间混响情况。

二、多人会议真正增加了一个问题：谁在说话

普通 ASR 主要解决的是：

这段声音说了什么？

而会议转写还必须回答：

这句话是谁说的？

这就引出了 Speaker Diarization，也就是常说的说话人分离或说话人日志。

一个比较理想的结果可能是：

00:00 - 00:08  Speaker A
00:08 - 00:14  Speaker B
00:14 - 00:20  Speaker A

随后系统再将 ASR 文字与对应的说话人时间段进行匹配，最终形成：

张三：这个版本计划周五上线。

李四：我认为现在上线风险比较高。

问题在于，ASR 和说话人区分是两个相互影响的环节。

即使文字完全识别正确，如果 Speaker Diarization 判断错了，也可能得到：

张三：这个版本计划周五上线，我认为现在上线风险比较高。

从单纯的字错误率来看，这段内容几乎没有问题，但从会议记录角度看，信息已经发生了明显变化。

这也是多人会议转写和普通语音转文字最大的区别之一：

会议转写质量不能只由 ASR 字错误率决定。

三、重叠语音是多人会议里最难处理的情况之一

现实中的会议很少像录音棚采访一样，一个人说完之后另一个人才开始讲话。

常见情况包括：

• 中途插话；
• 多人同时说“对”“嗯”“可以”；
• 一个人还没说完，另一个人已经开始回应；
• 讨论激烈时出现几秒钟的多人同时讲话。

这类情况通常称为 Overlapping Speech，也就是重叠语音。

从信号角度来看，麦克风收到的内容可能近似表示为：

Audio(t) = Speech_A(t) + Speech_B(t) + Noise(t)

对于主要面向单说话人输入优化的 ASR 来说，这种混合信号很难直接处理。

系统可能出现几种典型结果：

只识别音量更大的说话人

把两个人的话拼成一句

漏掉其中一个说话人的内容

文字识别出来，但说话人归属发生错误

因此，在多人会议场景中，重叠语音不仅会影响 ASR 本身，也会进一步增加说话人区分的难度。

这也是为什么一些模型在单人录音测试中表现很好，进入实际会议以后却会明显下降。

四、很多转写错误，其实发生在 ASR 之前

另一个经常被忽略的模块是 VAD，也就是 Voice Activity Detection。

VAD 的作用并不是识别文字，而是判断：

哪些时间段有人说话，哪些时间段没有有效语音。

典型处理过程是：

完整音频
   ↓
VAD
   ↓
语音片段
   ↓
ASR

对于长达几十分钟甚至数小时的会议录音来说，系统一般不会直接把整段音频一次性交给 ASR，而是先根据语音活动进行切分。

这里的问题在于，如果 VAD 的边界判断不准确，后续识别模型拿到的输入本身就是残缺的。

例如一句完整的话：

关于明天的项目验收，我们下午再确认一次。

可能被切成：

关于明天的项目验收

我们下午

再确认一次

严重的时候，句首或句尾的几个音节甚至可能直接被截掉。

此时即使后面的 ASR 模型完全正常，也很难恢复已经丢失的语音信息。

所以实际工程中经常会出现一种情况：

ASR 模型没有变化，但调整 VAD 参数以后，整体转写质量发生了明显变化。

这也是语音识别从“模型测试”走向“工程应用”后必须面对的问题。

五、会议中的专有词，也会放大错误

会议语言还有一个特点，就是大量存在普通语料中出现频率较低的词汇。

例如：

项目名称
员工姓名
客户名称
产品型号
行业术语
英文缩写
数字
内部代号

技术会议里甚至可能出现：

Qwen3
RAG
VAD
RTF
CUDA
A800
CER

这些词在人类看来并不复杂，但对于 ASR 来说，低频词通常更容易被映射成发音接近的高频词。

因此，企业级语音识别系统通常还会增加一些额外机制，例如：

• Hotword；
• Custom Vocabulary；
• Contextual Biasing；
• Language Model Rescoring；
• 专有名词词典。

这些能力的目的，本质上都是给模型增加业务上下文。

所以所谓“语音识别准确率”，实际并不是一个脱离场景就能够单独讨论的数字。同一个模型在普通话测试集、会议录音、医疗讨论和技术评审中的表现可能完全不同。

六、为什么会议转写不能只看 CER 或 WER

ASR 常见评价指标主要有 CER 和 WER。

CER 可以简单理解为字符错误率：

CER = (替换 + 删除 + 插入) / 参考文本字符数

WER 则以单词作为基本统计单位。

对于传统 ASR benchmark，这两个指标非常有价值。

但如果评价的是完整会议转写系统，仅看 CER 或 WER 就不够了。

例如：

原始会议：

张三：预算没有问题。

李四：交付周期有问题。

系统输出：

张三：预算没有问题，交付周期有问题。

文字本身几乎完全正确。

但“谁说了什么”已经发生变化。

因此会议转写还应该关注：

ASR 识别准确度
+
说话人区分准确度
+
时间戳对齐准确度
+
重叠语音处理能力
+
上下文与专有词处理能力

对于 Speaker Diarization，本身也存在 DER（Diarization Error Rate）等评价方式。

这说明多人会议转写实际上已经从一个单模型问题，变成了一个多模块协同问题。

七、真正可用的会议转写，本质上是一条完整 Pipeline

从工程角度来看，一个完整的会议语音处理系统更接近：

音频采集
   ↓
降噪 / 回声处理
   ↓
VAD
   ↓
ASR
   ↓
Speaker Diarization
   ↓
时间戳对齐
   ↓
标点恢复
   ↓
专有词处理
   ↓
会议文本

更复杂的系统还可能额外加入：

Speaker Embedding
Forced Alignment
Noise Suppression
ITN
Hotword
语义纠错

最终用户看到的虽然只是一段会议文字，但背后实际上经过了多个语音处理模块。

这也是目前很多会议语音产品和直接调用一个 ASR 模型之间的重要差异。以熙瑾会悟为例，其语音转写能力实际涉及多人发言区分、声纹识别、语音识别以及离线处理等环节，而不是简单完成一次 Audio-to-Text 转换。

因此，从工程角度看，更准确的表达应该是：

普通 ASR：

Audio → Text

而多人会议转写更接近：

Audio
  ↓
Speech Segment
  ↓
Speaker
  ↓
Text
  ↓
Timestamp
  ↓
Context

普通 ASR 主要解决“说了什么”。

会议级语音转写还需要进一步解决：

谁说的、什么时候说的，以及多人同时讲话时如何尽可能准确地还原发言关系。

当应用从单人录音进入真实会议环境以后，真正决定最终效果的，往往也就不再只是某一个 ASR 模型，而是整条语音处理链路的工程能力。