现在再看AI会议助手的产品介绍，实时转写、录音转记、自动摘要、待办提取已经不算少见。真正到了企业选型阶段，问题反而从“有没有这个功能”变成了“这个功能到底能做到什么程度”。

语音转写就是一个典型例子。

不少产品都会使用“高准确率”“接近人工”“支持多种口音”之类的描述，但语音识别并不存在一个脱离测试环境就能成立的准确率。安静办公室里的标准普通话、带地区口音的发言、多人同时讨论，以及会议室远场拾音，对ASR来说是完全不同的输入条件。

因此，判断一款会议助手的语音能力，不能只盯着一个百分比，更重要的是看这个数字是在什么条件下得到的。

一、ASR的准确率，本质上是在比较“识别文本”和“标准答案”

ASR是Automatic Speech Recognition的缩写，也就是自动语音识别。

评价一套ASR系统时，通常需要先准备人工校对后的标准文本，再把模型识别结果与标准文本进行比较。

英文语音识别里经常使用WER，也就是Word Error Rate；中文场景下则经常看到CER，即Character Error Rate。

CER主要统计三类错误：

• Substitution，替换：正确内容是“项目”，识别成了“项木”；
• Deletion，删除：原文中有一个字或词，识别结果里漏掉了；
• Insertion，插入：识别结果中多出了原文没有的内容。

基本计算思路是：

CER =（替换数 + 删除数 + 插入数）÷ 标准文本总字数

例如标准文本有1000个字，经过对齐后发现总共有20处插入、删除或替换，那么CER就是2%。

实际产品检测中未必直接使用CER这一名称，也可能采用综合识别率等指标，但背后的核心问题是相同的：模型输出与真实语音到底有多接近。

真正容易产生误解的地方并不是指标本身，而是测试材料。

如果测试样本全部来自安静环境、发音清晰的标准普通话，那么一个很漂亮的识别数字并不能直接说明它在真实会议室里也能获得相同结果。

二、为什么会议语音比普通录音更难识别？

实验室里的语音识别任务往往比较“干净”，但会议现场不是。

最直接的影响来自信噪比。

讲话人的声音是目标信号，空调、键盘、翻纸、桌椅移动等声音都是干扰。当讲话人距离麦克风变远时，目标语音能量下降，环境声和混响所占比例上升，识别难度自然增加。

会议室混响也是一个容易被忽视的问题。

人在房间里讲话时，麦克风收到的并不只有嘴巴到麦克风的直达声，还会收到声音经过墙面、桌面、玻璃等反射后的信号。这些延迟到达的声音叠加在一起，会让部分音节边界变得模糊。

再往后还有多人场景。

真实会议不可能始终按照“一人说完，另一人再说”的方式进行。有人插话、抢话，甚至两三个人短时间同时发声，都很常见。

这时候一套完整的会议语音系统面对的已经不只是ASR，还可能涉及：

VAD语音活动检测 → 降噪与前处理 → 说话人处理 → ASR → 标点与文本后处理

如果需要知道“谁说了什么”，还要进一步处理说话人分离或说话人识别问题。

因此，会议助手里所谓的“转写效果”通常是多个环节共同作用后的结果，而不是单纯由一个ASR模型决定。

三、为什么实时转写和录音转写应该分开测试？

这是会议助手选型时很容易被忽略的一点。

从使用者角度看，实时转写和上传录音都是“把声音变成文字”，但从系统处理方式来看，两者存在明显区别。

录音文件已经完整存在。

系统可以先做语音切分，再对音频进行识别，也有更多机会利用前后文信息进行修正。

实时转写则不同。

例如一个人正在说：

“关于下一阶段的预算，我们准备……”

系统听到这里时，并不知道几秒以后出现的是“增加”“减少”还是“维持不变”。

但字幕不能等整段会议结束以后再显示。

所以实时ASR必须在两个目标之间取得平衡：

一边是延迟，一边是上下文。

等待时间越长，可以获得的语义信息越多，但字幕出现得越慢；输出越积极，实时体验越好，但模型能够使用的后文信息越有限。

这也是为什么企业测试会议助手时，不应该只上传一段准备好的录音。

如果实际业务包含现场字幕，就应该现场测试实时转写；如果需要整理历史录音，则应该另外测试录音转记。

两者最好分别看结果。

在这方面，熙瑾会悟已经通过CNAS检测认证。检测中，安静环境下中文标准普通话实时语音转文字的综合识别率达到98.52%；上传安静环境录制的中文标准普通话音频进行转写时，综合识别率达到99.63%，对应测试要求均为大于97%。

相比只写一个“语音识别准确率99%”，把实时和录音两个场景拆开，更容易判断数字究竟对应哪种使用方式。

四、标准普通话测试很好，为什么还要看方言和地区口音？

中文ASR还有一个现实问题：企业员工并不会都说播音腔普通话。

同一家集团的会议里，可能同时有来自四川、广东、河南、湖南、浙江等不同地区的员工。

即使大家说的都是普通话，声学特征也并不完全相同。

例如不同地区可能存在平翘舌区别减弱、前后鼻音混淆、部分声母变化等现象。对人来说，只要熟悉这种口音，大多数时候不影响交流；对ASR模型来说，这却相当于实际输入和训练数据之间出现了分布差异。

这种问题通常可以理解为模型的泛化能力。

模型在训练数据中见过的发音模式越丰富，面对不同地区说话者时通常越容易保持稳定；如果训练数据比较单一，即使标准普通话表现很好，换一批说话人后也可能出现性能下降。

所以“支持中文”和“适应不同中文口音”其实是两件事。

对于人员高度集中在某个地区的企业，这个问题可能没那么明显；对于全国性集团、政企单位、大型医院、高校等组织，地区口音覆盖反而值得单独拿出来测试。

熙瑾会悟此次CNAS检测认证中，除了标准普通话，还覆盖了不少于25种方言及地区口音，包括粤语、吴语、湘语、赣语，以及东北官话、西南官话、中原官话等不同语音类型。

从选型角度看，“测试过哪些口音”通常比简单写一句“支持多种方言”更有信息量。

五、识别率很高，为什么关键会议仍然可能出问题？

平均准确率还有一个天然局限：它只统计错误数量，并不知道哪个错误更重要。

例如一段1000字的会议内容错了10个字。

第一种情况可能是：

“然后我们继续讨论”
被识别成
“然后我们继续讨伦”

这种错误会影响阅读体验，但基本不会改变会议结论。

另一种情况可能是：

“项目预算增加15%”
被识别成
“项目预算增加50%”

从纯粹的字符错误数量来看，可能同样只错了一个数字。

但对于业务来说，后者显然严重得多。

因此企业在实际做POC时，除了计算整体准确率，还值得额外检查几类信息：

数字和金额
预算、百分比、日期、数量、版本号。

专有名词
人名、公司名称、项目名称、产品型号。

行业术语
医疗、金融、制造、政务等行业都有大量通用ASR未必熟悉的词汇。

否定关系
“可以”和“不可以”，“通过”和“没有通过”，只差几个字，语义可能完全相反。

这一点在今天尤其重要，因为会议转写文本通常还会继续送给大模型。

典型处理链路是：

语音 → ASR文本 → LLM理解 → 摘要 → 决策事项 → 待办

如果ASR已经把“15%”写成“50%”，后面的模型看到的是一句语法完全成立的话。

它没有原始声音作为证据，很可能会继续把“50%”写进摘要，甚至进一步生成：

财务部门按照50%的预算增幅调整下一季度计划。

于是一个最初的ASR错误，就可能沿着后续处理链不断传播。

这也是为什么会议助手的语音识别底座并没有因为大模型出现而变得不重要。

恰恰相反，后面的AI能力越多，前面的输入质量越值得重视。

六、企业自己做POC，其实不需要很复杂

企业没有必要为了采购一套会议助手专门搭建ASR Benchmark。

准备几类有针对性的测试内容，往往就能发现很多问题。

第一类可以使用标准普通话，作为基准。

第二类加入大量数字、日期、金额和百分比，看看关键数字是否容易出错。

第三类加入公司的人名、产品名称、项目名称和行业术语。

第四类找几位来自不同地区的员工，用平时正常讲话的方式测试，而不是刻意字正腔圆地朗读。

第五类直接召开一场真实会议，把远距离讲话、正常插话、环境噪声都保留下来。

同时还可以把实时转写和录音转写分开观察。

企业真正需要寻找的并不是一款在所有测试里都“零错误”的产品——现实环境中很难做到这一点——而是要搞清楚：

错误主要发生在哪里。

如果偶尔出现普通错别字，后续人工校对成本可能并不高。

如果频繁错在人名、金额、数字、决策语句上，即使平均识别率看起来不错，也需要更加谨慎。

七、看AI会议助手，最好从“支持什么”继续问到“怎么验证”

AI会议助手早期主要解决的是功能有没有的问题。

能不能实时转写，能不能生成纪要，能不能提取待办。

现在这些功能越来越普遍以后，企业真正需要比较的已经逐渐变成：

实时情况下转写表现怎么样？

录音文件的结果是不是一样？

面对不同地区口音是否稳定？

专业术语和关键数字容易错在哪里？

宣传中的准确率是在什么测试条件下得到的？

这些问题看起来比比较功能列表麻烦一些，但反而更接近会议助手真正落地后的体验。

因为会议系统最终处理的并不是一段理想测试语音，而是一屋子真实的人。

有人离麦克风近，有人坐得远；有人说标准普通话，有人带着地区口音；有人完整发言，也有人随时插一句话。

对于这样的场景来说，一个“98%”或者“99%”本身并不是答案。

测试条件、输入类型、错误分布以及不同场景下的稳定性，放在一起看，才是一套语音识别系统真正有价值的技术指标。