企业第一次接触AI会议助手时，通常很容易被功能表吸引。
实时转写、自动纪要、待办提取、说话人区分、录音回听、多语言识别......一张产品介绍页很快就可以排出十几项功能。但到了实际选型阶段，这类"支持/不支持"的比较价值正在下降，因为主流产品能够提供的功能已经越来越接近。
真正容易拉开差距的，反而是宣传页上不容易用一个图标说明白的指标。
比如同样叫"实时转写"，低延迟条件下能够保持怎样的识别效果？同样写着"支持方言"，究竟只是模型理论上能够识别，还是针对不同地区语音做过测试？再比如产品宣传一个很高的平均准确率，这些错误究竟错在语气词上，还是错在金额、人名和会议结论上？
对于准备将AI会议助手用于正式业务的企业来说，这些问题通常比功能数量更重要。
一、第一个指标：实时转写和录音转写，是否被当成两个任务测试
"语音转文字"很容易被包装成一个功能，但从ASR系统的处理方式来看，实时转写和录音文件转写并不完全相同。
对于完整录音，系统拿到的是一段已经结束的音频。语音切分、上下文利用以及后处理都可以在相对完整的信息条件下进行。
实时转写则不同。
假设会议中有人说：
"关于第三季度预算，我们准备......"
此时ASR需要开始输出文字，但它还不知道后面说的是"增加""削减"还是"保持不变"。如果等待更多语音，模型拥有的上下文会增加，但字幕延迟也会随之上升；如果过早输出，实时性更好，但部分判断只能依赖已经接收到的声音。
因此，实时ASR天然存在一个工程上的平衡：
Latency（延迟）--- Context（上下文）--- Accuracy（识别效果）
这也是为什么企业做POC时，只上传一段录音文件测试并不充分。
如果实际业务需要会议现场字幕，就应该直接测试实时流式输入；如果需要会后整理录音，还应该另外测试文件转写。两种场景最好分别给出结果，而不是用一个"准确率99%"同时概括。
这一点也可以从具体检测数据中看到。熙瑾会悟已经通过CNAS检测认证 ，其中安静环境下中文标准普通话实时语音转文字综合识别率达到98.52% ，上传安静环境中文标准普通话录音进行转写时，综合识别率达到99.63%，对应测试要求均为大于97%。
这里值得参考的并不只是两个百分比高低，而是实时转写和录音转写没有被混成同一个指标。
对于真正需要部署会议助手的企业来说，这种区分很重要。
二、第二个指标：所谓"支持中文"，到底覆盖了多少种真实口音
标准普通话上的ASR性能已经比较容易做到较高水平，但企业会议并不是标准普通话测试集。
尤其对于全国性集团、政企机构、大型医院、高校以及跨区域组织来说，一场会议里同时出现不同地区口音十分常见。
这些差异对人类交流影响可能不大，对ASR却未必如此。
从声学层面看，地区口音可能改变部分声母、韵母和声调的实际发音方式。例如部分地区对平翘舌区分较弱，部分地区前后鼻音差异较小，还有一些地区会保留明显的地方语音特征。
这实际上涉及ASR模型的泛化能力。
机器学习系统通常会遇到一个基本问题：训练数据和实际输入的分布是否一致。
如果模型训练期间大量见过某种发音，它通常更容易正确识别；如果实际用户的发音模式在训练数据中出现得很少，性能就可能下降。这种现象并不局限于语音识别，在图像识别、自然语言处理等任务中同样存在。
因此，产品页上的：
支持中文
和：
针对不同地区中文语音进行过实际验证
技术含义并不相同。
企业选型时，更值得问的是：具体测过哪些语音类型？
熙瑾会悟此次CNAS检测认证除了标准普通话外，还覆盖了不少于25种方言及地区口音，其中包括粤语、吴语、湘语、赣语，以及东北官话、西南官话、中原官话等语音类型。
这个指标对于全国性组织尤其有参考意义。
如果产品只需要服务一个地区，口音覆盖可能不是最优先的问题；但如果系统未来需要部署到多个省份，那么模型面对不同说话人的稳定性，就应该在正式采购前提前测试，而不是部署之后才发现部分地区识别效果明显下降。
三、第三个指标：不要只看平均准确率，还要看"错误发生在哪里"
这是最容易被一个漂亮百分比掩盖的问题。
语音识别通常可以通过WER、CER或者综合识别率等指标进行量化。
以中文常见的CER为例，核心思想是比较识别文本与人工标准文本之间的编辑距离：
CER =（Substitution + Deletion + Insertion）÷ 标准文本字符数
也就是统计替换、删除和插入错误。
这种指标非常适合评价模型整体性能，但它有一个天然局限：所有字符错误在计算时基本是等价的，而在业务上并不等价。
假设1000字的会议内容里出现了10个识别错误。
第一套系统主要错的是：
"这个" → "这各"
"然后" → "然候"
第二套系统主要错的是：
"15%" → "50%"
"150万元" → "1500万元"
"暂不通过" → "通过"
从编辑距离来看，两套系统的错误数量可能相近。
但如果这些文字还要继续进入AI纪要系统，结果完全不同。
典型的会议智能处理链一般类似：
Audio → ASR → Text → LLM → Summary / Action Items / Decisions
大模型通常接收到的是ASR输出文本，而不是直接重新判断原始音频。
如果ASR已经把：
"预算上涨15%"
识别成：
"预算上涨50%"
那么后面的语言模型看到的是一句语法和语义都成立的话，它没有充分理由自动把50%改回15%。
结果可能继续被整理成：
"会议决定下一季度预算增加50%。"
甚至进一步生成：
"行动项：财务部门按照50%的增幅调整下一季度预算。"
最开始只有一个数字识别错误，经过摘要和任务提取以后，却可能扩散成多项结构化错误。
因此，对企业会议来说，比普通错别字更值得单独关注的是几类高业务权重信息：
- 金额、比例、日期和数量；
- 人名、企业名称、项目名称；
- 产品型号、设备编号；
- 医疗、金融、制造等行业专业术语；
- "可以/不可以""通过/未通过"等否定关系；
- 决策结论和责任人。
严格一点的POC甚至可以在整体识别率之外，另外建立一个"关键字段准确率"。
它未必是通用ASR Benchmark里的标准指标，却往往更接近企业真正关心的问题。
四、为什么这三个指标往往不会完整出现在产品宣传页上
原因其实很简单：它们都需要上下文。
"支持实时转写"只需要一个对勾。
但如果要严谨描述，就需要进一步说明测试环境、语音类型、输入方式以及识别结果。
"支持方言"也只需要四个字。
但真正有技术意义的信息应该是测试了哪些地区语音、测试方式是什么、是否同时覆盖实时和录音场景。
"准确率99%"同样非常容易展示。
但真正进行技术比较时，还需要知道测试集、环境条件，以及错误主要集中在哪些内容上。
这也是企业采购AI软件和个人体验AI软件最大的区别之一。
个人用户可以根据几分钟使用体验决定要不要继续用，而企业部署往往意味着多人长期使用，甚至把转写文本、会议结论和待办事项继续接入知识库、项目管理或内部业务系统。
这时，小概率错误也可能因为使用次数增加而逐渐暴露。
所以企业真正需要的不是一个尽可能长的功能表，而是一组能够验证、能够复现、能够对应自身业务场景的指标。
五、企业自己做POC，可以怎样测试这三个指标
实际测试不一定需要建设复杂的ASR评测平台，一套设计合理的小规模测试集已经能够发现很多问题。
首先准备一段标准普通话录音，分别进行实时转写和文件转写，观察两种输入方式是否存在明显差异。
然后增加不同地区的说话人。这里不建议让员工刻意按照播音方式朗读，而是保持日常说话习惯，因为真实会议里的口音、语速和停顿才是产品最终需要处理的输入。
第三步可以专门设计一批"高风险语句"。
例如：
本次项目预算为185万元。
一期计划完成率为17.5%。
设备型号为XJ-3207。
目前方案暂不通过。
后续由李明负责系统验收。
把数字、人名、型号、否定关系和责任归属集中放进去，比单纯朗读普通文章更容易发现真正影响业务的问题。
最后再进入真实会议测试。
因为实验材料可以检查模型的基础能力，而多人发言、距离变化、会议室混响和临时插话，才能验证整套会议系统的实际表现。
六、会议助手进入企业阶段，选型思路也应该发生变化
AI会议助手最早竞争的是"有没有"。
有没有实时转写，有没有AI摘要，有没有自动纪要。
当这些功能逐渐成为常见配置以后，真正值得企业花时间比较的问题已经变成：
实时状态下表现怎样？
录音文件状态下表现怎样？
换一批不同地区的说话人还能不能保持稳定？
错误究竟集中在哪里？
宣传里的性能指标有没有经过实际检测？
这三个指标------实时与录音场景的差异、方言与地区口音的泛化能力、关键业务信息的错误分布------都很难用一个简单的功能图标表达，却往往比再增加几个AI功能更能决定产品落地后的体验。
对于会议助手而言，"能够识别"只是第一步。
真正进入企业使用阶段以后，更重要的是知道它在什么条件下能够识别到什么程度，以及出错时最可能错在哪里。
这才是技术选型时值得认真比较的部分。