语音输入这件事从最早只能识别标准普通话、错字连篇到现在中英混说、带口音、甚至环境嘈杂都能给你准确转出来中间也就隔了几年时间。但问题也随之而来市面上的 ASR 模型越来越多开源的、闭源的、大厂 API、本地部署的小模型各家都宣称自己识别率最高延迟最低多语种最强。真到自己要选一个落地的时候反而不知道该信谁。我最近因为项目需要把主流的一批 ASR 模型拉出来做了一轮系统评测从识别准确率、多语种支持、抗噪能力、延迟、部署成本几个维度逐一实测踩了不少坑也总结出一些选型上的门道。这篇就把整个评测过程、方法和结论完整分享出来不管你是要做语音输入法、会议转写、客服质检还是字幕生成都能从中找到适合自己的那一款。1. 为什么 ASR 评测不能只看识别率这一个数字1.1 单一指标背后的陷阱很多人做 ASR 选型第一反应就是看各家公布的 WER词错误率。这个指标确实重要但它是一个被高度美化过的数字。厂商在公布 WER 时用的往往是 LibriSpeech、AISHELL 这类干净朗读数据集录音环境安静、发音标准、语速均匀。可你真实业务里的音频是什么样电话客服带着 8k 采样率的窄带噪声会议录音有远场混响和多人抢话短视频字幕里全是网络热词和英文夹杂。拿朗读集的 WER 去预测这些场景的表现基本等于拿实验室油耗去衡量城市堵车路况。我在第一轮测试时就吃过这个亏。当时选了一个在公开榜单上 WER 只有 3% 出头的模型结果拿真实客服录音一跑错误率直接飙到 20% 以上专有名词几乎全军覆没。后来才明白公开榜单的测试集和真实业务数据之间存在巨大的分布差异这个差异在专业上叫域偏移Domain Shift。所以评测的第一原则是必须用你自己业务场景的真实音频做测试集哪怕只有几十条也比跑一百个公开榜单有参考价值。1.2 我实际采用的评测维度经过几轮调整我最终把评测拆成了六个维度每个维度都有明确的测试方法和权重。这套框架后来在团队内部复用效果比较稳直接列出来供参考评测维度测试方法权重说明基础识别准确率干净朗读音频计算 CER/WER20%作为基线参考真实场景准确率业务真实音频人工标注对比30%核心指标多语种与混说中英混说、方言、小语种样本15%看是否支持 code-switching抗噪与远场加噪、混响、远场录音15%决定鲁棒性推理延迟端到端 RTF 与首字延迟10%影响实时体验部署与成本显存占用、并发、授权费用10%决定能否落地这个权重不是拍脑袋定的而是根据语音输入这个具体场景调的。语音输入的核心诉求是边说边出字、准确、不挑环境所以真实场景准确率和延迟占了很大比重。如果你的场景是离线批量转写那延迟权重可以降到 5% 以下把省下的权重加到准确率上。1.3 测试集构建的几个关键细节测试集的质量直接决定评测结论的可信度。我构建测试集时遵循了几个原则这里展开说一下因为这是很多人容易忽略的地方。第一是覆盖发音多样性。我特意找了带南方口音、北方口音、语速快慢不同的说话人每种至少 3 人。因为 ASR 模型对训练数据里占比高的口音天然更友好如果你的用户群体口音集中测试集就必须反映这一点。第二是标注规范统一。中文标注要明确数字怎么处理2024是标成二零二四还是2024、英文单词怎么算算一个词还是按字母、标点是否计入。这些规则不统一算出来的 CER 没有可比性。我一般用字错率 CER作为中文主指标因为它对分词不敏感比 WER 更稳定。第三是样本量。每个场景至少 50 条、总时长不低于 30 分钟否则统计波动太大。我一开始只用了 20 条两次跑出来的结果差了 5 个百分点完全没有参考意义。2. 参评模型清单与各自的定位差异2.1 参评模型一览这一轮我选了 6 个有代表性的模型/服务覆盖开源本地部署、开源可商用、大厂闭源 API 三种类型。选它们的原因是它们在各自赛道里都有明确的用户群且定位差异明显对比起来有信息量。模型/服务类型参数量级主打能力典型场景Whisper 系列开源本地中到大多语种、鲁棒性强离线转写、字幕Paraformer 系列开源本地中中文准确率高、低延迟实时语音输入Conformer 自研开源本地小到中可定制、轻量端侧、嵌入式大厂通用 API A闭源云服务不公开综合能力强、生态好快速接入大厂通用 API B闭源云服务不公开中文优化、热词强客服、会议轻量端侧模型开源本地小低功耗、离线移动端输入法需要说明的是这里不点名具体商业品牌一是避免变成软文二是不同时期各家版本迭代很快具体名字意义不大方法论比结论更重要。你完全可以用这套框架去测你手头能拿到的任何模型。2.2 开源与闭源的真实取舍很多人纠结开源还是闭源我的经验是看三个条件数据敏感度、调用量、定制需求。如果音频涉及用户隐私或商业机密不能出内网那基本只能选开源本地部署。闭源 API 再准数据要传到别人服务器上合规这关就过不了。反过来如果只是做个 demo 或者调用量很小自己搭一套推理服务的运维成本远高于直接调 API那就别折腾开源自部署。调用量是个关键分水岭。我算过一笔账一个中等规模的语音输入应用日调用 10 万次、每次 10 秒音频用云 API 按量付费一个月下来费用不低而自部署一台带 GPU 的服务器虽然前期投入大但边际成本几乎为零跑满一年就回本了。所以高频场景自部署更划算低频场景调 API 更省心。定制需求则决定了开源的必要性。比如你要做垂直领域的语音输入满屏都是行业术语通用模型识别不了这时候就需要热词增强或者微调。闭源 API 一般提供热词表功能但微调基本不开放开源模型则可以拿自己的数据做微调效果提升空间大得多。2.3 一个容易被忽略的选型维度许可证开源模型的许可证差异很大有的允许商用有的仅限研究有的对商用有附加条件。我见过团队辛苦调优了几个月最后发现模型许可证不允许商用只能推倒重来。所以选开源模型前第一件事是看 LICENSE 文件确认商用条款、是否需要保留版权声明、是否有用户规模限制。这个坑踩一次就够了。3. 实测过程从环境搭建到逐项打分3.1 测试环境与统一变量控制为了保证公平所有本地模型都在同一台机器上跑配置是单卡 24G 显存、32 核 CPU、64G 内存。云 API 则在同一网络环境下调用避免网络波动影响延迟测试。测试音频统一转成 16kHz、16bit、单声道的 WAV 格式因为这是绝大多数 ASR 模型的标准输入格式采样率不对会直接影响识别效果。这里有个细节值得强调重采样质量会影响结果。我一开始用了一个简单的线性插值重采样结果高频信息损失严重识别率比预期低了一截。后来换成带抗混叠滤波的重采样比如用 sox 或 ffmpeg 的高质量模式同一批音频的识别率提升了 2 到 3 个百分点。所以预处理这一步千万别图省事。# 用 ffmpeg 做高质量重采样到 16k 单声道 ffmpeg -i input.mp3 -ar 16000 -ac 1 -sample_fmt s16 output.wav3.2 准确率测试CER 计算与人工复核准确率测试我用了两套数据一套是干净朗读音频作为基线一套是真实业务音频作为主战场。计算 CER 的公式是CER (替换字数 删除字数 插入字数) / 标注总字数我用 Python 的jiwer库做批量计算但机器算完必须人工抽检。因为有些错误其实是标注规范不一致导致的比如模型输出AI而标注写的是人工智能机器判为错误实际语义完全正确。我一般抽检 20% 的样本把这类假错误剔除后再统计结果才靠谱。实测下来有个反直觉的发现在干净朗读音频上几个模型的差距很小基本都在 3% 到 6% 之间但一到真实场景差距瞬间拉开到 10% 以上。这说明公开榜单的高分参考价值有限真正决定体验的是模型在脏数据上的鲁棒性。那些在训练时用了大量增强数据加噪、加混响、变速的模型真实场景表现明显更稳。3.3 多语种与中英混说的实测表现中英混说是中文语音输入的高频场景比如帮我打开这个 app 的设置页面这个 bug 什么时候 fix。测试时我专门准备了一批中英混说样本观察模型的语种切换能力。结果差异非常明显。有的模型会把英文单词强行识别成发音相近的中文比如把app识别成阿婆把bug识别成巴格这种错误在语义上完全跑偏。而支持 code-switching 的模型能正确输出英文单词甚至能根据上下文判断该用哪种语言。小语种方面我测了粤语和日语。粤语对大部分普通话模型来说是灾难除非专门训练过。日语则要看模型的多语种覆盖Whisper 这类多语种模型表现较好但中文专用模型基本不支持。所以如果你的场景涉及方言或小语种选型时一定要确认模型的语言覆盖列表别想当然。3.4 抗噪与远场真实环境才是试金石抗噪测试我用了三种方式加白噪声、加人声背景音、模拟远场混响。加噪用ffmpeg的anoisesrc滤镜混响用afir滤镜加载脉冲响应。# 给音频叠加白噪声信噪比约 10dB ffmpeg -i clean.wav -f lavfi -i anoisesrcd10:cpink:a0.05 \ -filter_complex [0:a][1:a]amixinputs2:durationfirst noisy.wav实测结论是近场加噪各模型都还能扛远场混响差距就出来了。远场录音的特点是声音经过墙壁反射频谱被严重改变加上距离衰减信噪比很低。这种情况下那些在训练时做过 RIR房间脉冲响应增强的模型优势明显错误率能比没做增强的低一半以上。这里分享一个实操心得如果你的场景是远场比如会议室、车载麦克风阵列和降噪前端比换模型更有效。我试过在同样的远场音频上先过一遍降噪再做识别效果提升比换一个更强的模型还明显。所以别把所有希望都寄托在 ASR 模型本身前端信号处理同样关键。3.5 延迟测试RTF 与首字延迟的区别延迟这块要区分两个指标RTFReal Time Factor和首字延迟。RTF 是处理时长除以音频时长RTF 小于 1 表示比实时快首字延迟是从音频输入到吐出第一个字的时间直接决定边说边出字的体验。对于语音输入场景首字延迟比 RTF 更重要。我用流式接口测试时发现有的模型 RTF 很低整体处理快但首字延迟高要等一大段才出字用起来就很别扭。理想的语音输入体验是首字延迟控制在 300ms 以内之后持续稳定输出。影响延迟的因素很多模型大小、是否流式、批处理策略、硬件。我实测下来流式模型的首字延迟普遍比非流式低一个数量级因为非流式要等整段音频结束才开始处理。所以做实时语音输入一定要选支持流式的模型或接口。4. 各模型实测结果与场景化推荐4.1 综合得分对比把六个维度的得分加权汇总后结果如下分数为相对值满分 100模型/服务准确率多语种抗噪延迟成本综合Whisper 系列829285708884Paraformer 系列907582928586Conformer 自研806578889280大厂 API A888886856084大厂 API B918088886285轻量端侧模型726070959576这张表只是我这次测试的一个快照不同版本、不同硬件下结果会变重点看趋势和取舍逻辑别把具体数字当圣旨。4.2 不同场景该怎么选实时语音输入输入法、语音助手首选 Paraformer 这类中文优化、支持流式的模型首字延迟低、中文准确率高。如果要在移动端离线跑轻量端侧模型虽然准确率低一些但胜在完全离线、功耗低、隐私好。会议转写与字幕Whisper 系列的多语种和鲁棒性优势明显尤其是涉及中英混说或外语内容时。如果会议是纯中文且对准确率要求极高大厂 API B 的中文优化和热词功能更合适。客服质检这类场景音频质量差电话窄带、有大量专有名词建议用支持热词增强的模型并且一定要用真实客服录音做验证。我实测发现热词功能对专有名词的识别提升非常显著能把相关错误率降低一半以上。离线批量转写延迟不重要准确率和成本是核心。开源自部署 大模型组合配合批处理性价比最高。4.3 一个被低估的优化手段热词与上下文不管选哪个模型热词表都是性价比最高的优化手段。把业务里的专有名词、人名、产品名整理成热词表喂给模型识别率提升立竿见影。我做过对比加了 200 个热词后相关专有名词的识别准确率从 60% 提升到 90% 以上。更进一步的是上下文注入。有些模型支持在识别时传入上下文文本让模型知道当前在聊什么话题从而更准确地选择同音词。比如聊苹果时是水果还是品牌上下文能帮模型判断。这个功能在会议、客服场景特别有用。5. 评测中踩过的坑与避坑经验5.1 采样率与位深不匹配导致结果失真这是我最开始踩的坑。测试音频有的是 44.1kHz有的是 8kHz我图省事直接喂给模型结果 8kHz 的音频识别率奇低。后来才意识到模型训练时的采样率是固定的输入采样率不匹配会导致频谱错位。正确做法是统一重采样到模型要求的采样率并且用高质量重采样算法。这个坑很隐蔽因为音频听起来没问题但识别结果就是差。5.2 用错评测指标CER 和 WER 别混用中文场景我强烈建议用 CER字错率因为中文分词本身就有歧义用 WER 会因为分词差异产生大量假错误。我一开始用 WER两个语义完全正确的句子因为分词不同被判为错误导致结论完全失真。换成 CER 后结果稳定多了。英文场景则相反用 WER 更合适。5.3 忽略标点与大小写的影响有些模型输出带标点有些不带有些英文全大写有些正常大小写。如果评测时不统一处理这些差异会污染 CER 计算。我的做法是评测前统一去除标点、英文统一转小写只比较核心文字内容。当然如果你的业务需要标点那标点准确率要单独作为一个指标来测。5.4 延迟测试受硬件和并发影响大延迟测试一定要在目标硬件上做并且模拟真实并发。我在开发机上测出来的延迟很漂亮一上生产环境、并发一上来延迟直接翻倍。因为 GPU 推理是共享资源并发高时排队严重。所以延迟测试要压测测 P99 而不是平均值平均值会掩盖长尾问题。5.5 盲目追求大模型大模型确实准确率高但推理成本也高。我见过团队为了追求几个百分点的准确率提升上了最大的模型结果显存不够、并发上不去、成本爆炸。选型要在准确率和成本之间找平衡点很多时候中等模型 热词 前端降噪的组合效果比单纯堆大模型更好成本还低得多。6. 把评测做成可持续的工程能力6.1 建立回归测试集一次评测的结论会过时因为模型在迭代、业务在变化。我的做法是维护一个固定的回归测试集每次模型更新或业务调整后重跑一遍看指标有没有退化。这个测试集不用很大但要覆盖核心场景并且标注质量要高。有了它模型升级就不再是凭感觉而是有数据支撑的决策。6.2 自动化评测流水线手工评测太累且不可复现。我后来搭了一套简单的自动化流水线音频预处理、批量推理、CER 计算、结果汇总全部脚本化一条命令跑完。核心就是用 Python 把各个环节串起来输出一份带对比的评测报告。import jiwer def compute_cer(refs, hyps): # 中文 CER按字符比较 return jiwer.cer(refs, hyps) # 批量评测 results {} for name, model in models.items(): hyps [model.transcribe(a) for a in audios] results[name] compute_cer(refs, hyps)这套流水线搭好后评测从几天缩短到几小时而且结果可复现、可追溯。6.3 持续关注线上真实数据评测集再全也代表不了全部线上情况。我习惯在线上埋点收集识别置信度低的样本定期人工复核把确认有问题的样本补充进回归测试集。这样测试集越来越贴近真实分布评测结论也越来越准。评测不是一次性任务而是一个持续迭代的闭环。7. 关于语音输入选型我个人的几点体会折腾完这一轮我最大的感受是没有最好的 ASR 模型只有最适合你场景的模型。公开榜单的高分只能作为初筛真正的决策必须基于你自己的数据、自己的硬件、自己的成本约束。如果非要给个优先级建议我会说先明确场景实时还是离线、近场还是远场、单语还是多语再确定部署方式云端还是本地最后才是在候选模型里比准确率。顺序反了很容易在错误的方向上优化。另外别忽视工程侧的优化空间。热词、前端降噪、上下文注入、流式策略这些外围手段带来的提升有时候比换模型还大。我见过太多团队把精力全花在选模型上却忽略了这些更容易见效的地方。最后分享一个小技巧做选型对比时一定要让最终用户参与评测。因为 CER 低不代表体验好用户对某些错误的容忍度是不一样的。比如把的识别成地用户根本不在意但把人名识别错用户会很恼火。让真实用户听几段识别结果他们的反馈往往比任何指标都直接。