一张对比表解决不了选型问题
Whisper、FunASR 和其他中文 ASR 方案经常出现在同一份评测报告里。报告列出字错率、实时率和内存占用，读者很快就能看出谁高谁低。可如果没有看到音频来源、硬件条件和后处理规则，这些数字很难复核。
语音识别的结果是多层处理叠加出来的。模型负责从声音中得到文字，VAD 负责判断哪里有人说话，标点模块负责整理句子，热词规则可能又把一个词替换成另一个词。把这些环节混在一起，最后得到的“模型准确率”很可能并不属于模型。
中文场景先按音频分组
普通话播报、电话录音、会议室远场和工业现场不应放在同一组。电话音频的带宽有限，远场录音有混响和多人抢话，工业环境则可能出现持续的机械声。每组都要保留人工校对稿，并记录采样率、声道、说话人数和噪声条件。
评测集还要避免内容泄漏。训练或调词表时使用过的录音，不应再直接放入测试集；同一场会议的相邻片段也最好放在同一个集合中。否则结果会比实际使用看起来好，换一批录音后却突然下降。
术语错误要单独统计
普通句子的字错率下降，并不说明业务一定得到改善。企业更关心的通常是人名、机构名、产品型号、金额、日期和条款编号。可以把这些词做成小型专项集，分别统计漏识别、近音替换、数字格式错误和重复输出。
热词表能帮助系统记住固定名称，但它有副作用。权重过高时，模型可能把相近的普通词改成专业词；词表跨部门共用时，还会把一个业务线的名称带进另一个业务线。测试报告里应同时列出命中和误改，不能只统计正确案例。
如果错误集中在口音、混响或连续语句，单纯增加热词通常不会解决问题。此时应重新检查麦克风、降噪、切片和模型适配。
实时率和首字时间要分开
实时率反映处理速度，首字时间反映用户多久能看到初始结果，二者不是一回事。一个系统可以很快完成整段批处理，却不适合实时会议；也可以很快吐出一个词，但之后频繁回改，影响阅读。
测试实时识别时，应记录音频到达、任务排队、首个稳定文本、最终文本和结果展示这几个时间点。多人同时说话时，还要观察说话人分离和文字对齐是否失控。长时间运行则要检查队列、内存和连接数是否持续增长。
离线批处理要关注失败重试、断点续传和结果落盘。处理十小时录音时，单次任务中途失败比单段速度慢几秒更影响交付。
公平比较需要保持相同的后处理
两个模型都应使用同一套音频预处理和统计脚本。若一边使用了标点恢复、热词重排和数字归一化，另一边没有，这份评测只能比较两套组合方案，不能比较底层模型。
原始结果和修订结果都应保存。对于法律、医疗和金融材料，关键字段还需要人工复核，保留修改痕迹。这样做不是降低自动识别的价值，而是把系统边界说清楚：模型负责提供候选结果，业务流程负责确认高风险内容。
把评测做成可重复的工作
正式选型前，可以先建立一套不大的回归集，覆盖安静语音、电话、远场、噪声、多人和行业术语。模型、硬件、词表或后处理规则发生变化时，都用同一批音频重新跑一遍。报告中记录版本、配置和异常样本，下一次出现结果波动时才有依据。
对企业来说，适合的 ASR 不一定是某项指标最高的模型，而是能在既定硬件、数据边界和维护能力里稳定工作的组合。把模型能力、规则效果和人工复核分开，选型结果才不会被一张漂亮的表格带偏。
评测还要注意误报。热词规则把一个固定名词识别对了，并不代表整段文字质量变好；如果它同时把十个普通词替换错，业务人员的校对时间可能更长。报告里可以列出高频误报词、错误发生的音频条件和修正规则，帮助后续决定是否保留这条热词。
同一套测试也应在不同设备上运行。办公室服务器、机房 GPU 和边缘 NPU 的驱动、内存带宽和编译环境不同，识别结果和延迟可能发生变化。迁移时保留原始输出，才能区分模型变化和运行环境变化。
如果项目需要说话人分离，评测集还应包含多人交谈、插话和远场混响。文字转写正确，不代表发言人标签正确；后续检索和质检如果依赖说话人信息，这项错误会沿着业务流程继续放大。
最终报告不必写成一场胜负宣判。把适用音频、硬件条件、维护责任和已知限制写清楚，使用方反而更容易判断方案是否符合自己的工作流程。对于高风险材料，保留人工复核和原音频回听入口，通常比追求一个看似漂亮的单项指标更稳妥。