做语音转写选模型时，最容易踩的坑是照着某张榜单直接下单，结果发现自家场景里口音、嘈杂环境、专业术语全对不上，账单还比预期高一截。这篇不给你一个写死的名次，而是给一套可复用的对比顺序：先把自己的音频场景拆开，用同一个测试集横评，再去比计费和返工成本。
做语音转写的开发者选模型时，最常见的错误是打开一张排行榜，看谁排在前面就下单。问题在于，排行榜的测试集和你手里的音频往往不是一回事：人家测的是朗读近场，你处理的是多人会议；人家测的是标准普通话，你手上带着方言和行业术语。结果就是跑分挺好看，落地后错误一堆，账单还比预期高出一大截。
这篇不给你一个写死的名次，而是给一套可复用的对比顺序：先把音频场景拆开，定好硬约束和指标侧重；再学会正确读榜单，不被口径忽悠；然后自己搭一个小测试集横评；最后把按分钟计费和人工返工两笔账一起算清楚。按这个顺序走，选出来的模型不一定是最有名的，但大概率是最适合你那条业务线的。
先定场景指标，再去看排行
同一个 ASR 模型，在不同音频类型上的表现能差出一个档次。排行榜通常只覆盖其中一到两类，所以第一步不是去搜排名，而是把自己要处理的音频做分类。分完类你会发现问题一下子具体了：到底是要转写客服电话，还是给视频加字幕，还是把线下会议录音整理成纪要。
- 把音频按「近场单人 / 会议多人 / 电话窄带 / 嘈杂现场」分四类，分别统计各占多少条、多少时长，占比最高的那类才是你真正要对比的重点场景
- 列清硬约束：需不需要实时流式、支不支持方言与小语种、要不要说话人分离和时间戳，缺一项就直接淘汰，不用再往下比准确率
- 按业务容忍度定指标侧重：字幕生成更怕错字和断句、会议纪要更怕漏说人和专业名词、客服质检更怕时间轴漂移
榜单怎么读，才不把跑分当结论
榜单不是不能用，而是要先看它的口径说明再引用。固定测试集跑出来的分数可比性强，但样本覆盖窄；众测众包的分数贴近真实使用，但不同批次之间波动大。两类榜单解决的是不同问题，混着看就容易得出错误结论。建议先到 /benchmarks 和 /crowd-radar 看清每张榜单的测试集构成、评分方式和更新节奏。
| 看榜单时问的问题 | 说明了什么 | 对你的意义 |
|---|---|---|
| 分数是按字符还是按词算 | 口径不同不可直接并排比 | 先统一口径再看差值 |
| 有没有做文本归一化 | 数字、标点、大小写的处理差异 | 归一化宽松的分数会偏高 |
| 测试集里有没有口音和领域词 | 覆盖面决定了参考价值 | 没有你那类样本就不适用 |
| 是固定集还是众测 | 可比性与真实性的权衡 | 固定集看趋势，众测看手感 |
还有一个容易被忽略的点：榜单维度里如果没有「领域词表」和「带口音样本」，那它对你的垂直场景参考价值就有限。这就是判断「不适用」的标准——不是榜单不合格，而是它测的东西和你要解决的问题不是同一件事。
搭一个自己的小测试集，半天能做完
与其反复刷榜单，不如花半天做一个自己的基准集。规模不用大，能用就行。关键在于这批音频必须来自你的真实业务，而不是网上随便找的公开数据集，因为你要测的正是模型在你场景里的表现。
- 挑样本从真实业务录音里选 20 到 30 条，覆盖长短音频、清晰与噪声、主要说话人，避免全是同一类音频。
- 人工校对逐条人工写出标准答案，这就是你的基准。校对时把说话人标记也保留下来，后面测说话人分离用得上。
- 同批横评同一批音频跑候选模型，只统计三件事：字错率、断句可读性、时间戳偏移，逐条打分而不是只记一个总数。
- 留档复测把结果记成一张对照表，用 /tools/quality-check 和 /tools/quality-monitor 的思路做版本留档，模型换代时能直接复测。
这个方法的好处是，它把你的主观感受变成了可比较的数字。下次有人推荐某个模型，你不用争论哪个更好，直接拿测试集跑一遍，用同一套标准看结果。
成本要按「分钟 + 返工」两块算
语音接口的计费口径至少有两种：按音频时长和按文本量。这两种换算方式在长音频和短音频上的差异会很大。具体单价各家不一样，也会调整，所以别记死数字，到 /voice 和 /ai-nav/category/ai-voice 核对当时的数字，再按你自己的音频时长分布估算月度开销。
实时流式与批量转写往往不是一个价，长音频还有分片、静音裁剪带来的重复计费。预算要按最坏情况估，别按平均值算，否则上线第一个月就容易超支。另外，延迟也是成本的一部分：需要实时字幕的场景，延迟高一点体验就差一截，先用 /tools/speed-test 量出各家的延迟基线。
还有一笔常被忽略的账是人工校对成本。字错率每高一点，校对工时就线性上升，这部分常比接口费更贵。所以低错率模型贵一点，算上返工反而可能更划算——但前提是你的音频量和校对人力确实存在，如果是一次性、低价值的转写，这笔账就不适用。
落地前的核对清单
技术对比做完，别急着全量上线。下面这张清单里的每一项，都建议在灰度阶段就验证一遍，很多问题是在压测和合规审查时才暴露的。
| 核对项 | 怎么验证 | 不通过怎么办 |
|---|---|---|
| 音频格式与时长上限 | 用最长、最怪的样本实测 | 超限部分先做预处理或分段 |
| 并发与限流 | 按峰值流量做一次压测 | 申请提额或做队列削峰 |
| 数据留存与合规 | 到 /safety 看厂商条款 | 涉及敏感录音先做脱敏 |
| 延迟基线 | 用 /tools/speed-test 量出数据 | 延迟不达标就不上实时场景 |
| 灰度与复测 | 小流量上线，定期复跑测试集 | 指标漂移就回退或换模型 |
- 确认接口能传的音频格式和单文件时长上限，这两项最容易在集成阶段卡住
- 确认并发限制，很多方案在压测阶段才暴露限流问题
- 确认数据留存与合规口径，涉及通话录音时要看厂商的存储与训练用途条款
- 上线后先小流量灰度，用同一测试集定期复测，指标稳定再逐步扩量
- 把延迟基线记录下来，作为后续换模型时的对照参考
常见问题
语音识别模型排行里第一名，直接拿来用行不行？
不一定。榜单第一通常是在某一类公开测试集上表现最好，你的音频如果是电话窄带、强口音或专业术语密集，排名可能完全反过来。建议用自己二十来条真实音频复测一遍，再决定，别只看名次。
按分钟计费和按字符计费，哪种更省钱？
取决于语速和静音比例。语速快、静音少的录音按分钟更划算；语速慢、停顿多的内容按字符可能更省。具体口径和换算方式到 /voice 页面按当时的计价单位核对，再拿自己一段典型音频算一遍。
实时转写和批量转写要不要用同一家？
可以分开。实时场景对延迟和稳定性更敏感，批量场景更看重准确率和单价，两条链路拆开选往往整体更优。代价是要多维护一套接入和一套校对流程，团队小的时候先统一一家也行。
