语音模型评测

做语音应用的团队常卡在同一处：模型挑花了眼，却说不清该比什么。有人只盯字错率，上线才发现延迟高得没法对话；有人照着榜单选，结果自家口音、行业词全崩。这篇不讲抽象概念，而是把评测拆成可执行的几步：先定业务指标，再搭测试集，然后按流式延迟、并发成本、授权范围逐项打分，最后给出不同场景下的取舍顺序和排查路径。

做语音应用的团队常卡在同一个地方：模型挑花了眼，却说不清到底该比什么。有人只盯字错率，上线才发现延迟高得没法做实时对话；有人照着榜单选，结果自家口音和行业词全崩。问题不在模型，在评测方法。这篇把语音模型评测拆成可执行的几步：先定业务指标，再搭测试集，然后按流式延迟、并发成本、授权范围逐项打分，最后给出不同场景下的取舍顺序和排查路径。

先说一个前提：语音模型不是一个品类，而是四类东西——流式识别、离线转写、语音合成、端到端语音对话。它们的指标口径完全不同，混在一张表里比，比出来的结论往往是错的。下面每一节都按这个分类来给动作，你套自己的业务场景往里填就行。

语音模型的评测维度不止字错率

字错率是入场券，不是决策依据。识别侧要同时看字错率和专有名词命中率，而且必须按场景切分：安静近场、远场噪声、多人重叠、口音与方言，同一模型在这几层里的表现可能差出一个量级。只报一个总分，等于什么都没说。

• 每个维度都要写清「什么情况下不适用」：比如字错率低的模型，在强噪声或多人重叠场景下可能反而更差，这类结论不能跨场景套用。
• 评测表里给每个指标标注来源——是公开数据集、自建测试集还是线上抽样，来源不同结论的置信度不同。
• 对话类场景要单独看打断：用户中途插话，模型是能停住还是继续说，这一项过不了就直接淘汰。
• 合成侧别只用机器打分，自然度是主观感受，机器分高不代表人听着舒服。

先搭自己的测试集，再去比模型

公开数据集和榜单的题目，跟你的音频分布、行业词汇基本不会重合，所以它们只能用来筛候选，不能用来定终选。真正有决策价值的，是你自己攒的那套测试集。搭起来不复杂，但要守几条规矩才有效。

1. 抽样分层从真实业务录音里抽样本，按安静近场、远场噪声、多人重叠、口音方言分层，每层留固定条数，避免全用公开数据集导致分数虚高。
2. 标注三件套至少标逐字稿、关键实体（人名、金额、型号）、时间戳；合成侧另准备多音字、英文混读、数字与符号的长句文本。
3. 冻结版本测试集定下就冻结，后续换模型、换参数只用同一套，不然前后对比没有意义；每次改动都要重新起一版并记录。
4. 控制样本量内部工具几十条够看趋势；对外服务建议按层各留出足够样本，并分批回归，避免一次性跑完看不出是哪批变差。

这里有个常见坑：测试集越攒越大，却没人记得它当初是按什么场景抽的，结果新模型跑出来的分数没法解释。建议每层样本配一份简短说明——来源、录制条件、大致难度，比单纯堆条数有用得多。

延迟要分三段量，别只记一个总数

「延迟」这个词太粗。真正影响体验的是三段：音频采集与分片、模型首字返回、整句结束。流式识别要测「说完到出字」的间隔，合成要测「发请求到首帧音频」的间隔，对话还要额外测打断后重新起播的时间。只记一个总数，优化的时候根本不知道从哪下手。

• 测之前先量基线：用站内的 /tools/speed-test 把自己的网络与接口延迟打出来，避免把网络抖动算成模型慢。
• 流式识别重点盯尾点判定——静音多久算说完，判定太保守会让整体体验变拖。
• 对话类场景先给延迟预算再选型：先定可接受上限，再拿候选模型去卡这个上限，卡不住的直接排除。
• 同一模型不同接入方式（直连、中转、私有化）延迟可能差不少，评测时按你实际要用的接入方式来测。

测延迟要固定条件：同一台机器、同一条网络、同一段音频，重复几次取稳定区间而不是单次最小值。单次快不代表稳定，抖动的模型在真实通话里比慢一点的模型更难受。

准确率必须在你的场景里复测

榜单只用来筛候选。筛完之后，按业务分层复测：客服录音、会议多人、户外采访、电话窄带，同一模型在每层的表现可能差出量级。如果预算有限，优先复测你最赚钱或最影响口碑的那一层。

专有名词单独拎出来说：识别错一个型号或金额，比整句错几个虚词严重得多，因为业务动作会跟着错。所以评测表里最好把「关键实体准确率」单列，跟整体字错率分开看。

并发与成本：按分钟、按字符还是按订阅

计费口径先搞清楚：识别多按音频时长，合成多按字符数，不同厂商口径不同，换算错会把预算算歪。具体单价和单位到站内的 /official-api 与语音类厂商页核对当时的数字，这里只讲怎么算。

1. 统一口径把候选厂商的计费单位换算是同一种——比如都折算成「每分钟业务量」的花费，再横向比。
2. 压测并发同一模型在并发翻倍后，看首字延迟和错误率是否劣化；很多模型在压测下才开始掉字。
3. 算浪费成本按「每分钟业务量 × 单价」估算，再叠加重试与失败请求的浪费，别只算成功调用。
4. 定分界线自建还是调用看业务量与稳定性要求，具体账参照本分区关于自建与调用的那几篇，这里只给测算动作。

授权与部署形态会直接否掉技术分最高的方案

技术分再高，授权范围卡死也没用。这一节给的是准入清单：任何一条不满足，直接淘汰，不要留到最后再补。读许可证原文，不要看二手转述，转述里经常漏掉商用、地域和调用量限制。

商用授权

确认能不能用于商业产品，有没有按调用量或营收分档的限制。

权重与产品化

能不能把模型权重放进自己的产品里分发，还是只能调接口。

私有化部署

数据不出内网的场景要提前确认能不能部署，部署后是否还能拿到同等质量的更新。

端侧形态

端侧省延迟与合规成本，但要接受模型规模与识别质量下降，适合固定场景的短指令。

把合规、部署、更新这三条做成清单逐项打勾再进技术对比，顺序不要反。先比技术再发现不能商用，前面的评测时间全白花。

把评测收成一张打分表和一个决策顺序

评测到最后要能落到一张表上：列维度权重，按业务重要性分配，不要平权。每个候选按维度打分并写明依据——哪份测试集、哪次压测，分数后面必须有证据，否则就是拍脑袋。

• 决策顺序：先过准入清单，再看延迟是否卡上限，然后比准确率，最后比成本和长期维护。
• 留回退方案：至少保留一家备选与一套切换路径，避免主供应商调价或限流时被动。
• 打分表要存档：记录哪版测试集、哪次压测、什么参数，换人接手也能看懂。
• 权重写清楚理由，团队里有人质疑时能直接翻到依据，而不是重新吵一遍。

什么时候必须重跑评测

评测不是一次性动作。下面这些情况出现时，必须重跑，而且重跑要只跑受影响的分层和维度，不必全量重来——但测试集版本必须一致才能对比。

• 业务音频分布变化：新增了方言用户、换了录音设备、场景从室内转户外。
• 模型版本更新：供应商升级后准确率或延迟可能变，旧结论不能直接沿用。
• 计费或限流政策变动：成本模型和并发能力都可能被改写，到 /price-watch 核对当时的数字。
• 延迟明显劣化：线上监控发现首字延迟抬升，先排查网络再怀疑模型。
• 把每次结果存档，记录时间、版本与参数，方便判断是模型变差还是场景变难。

最后一句实话：监控比评测更重要。上线之后用质量监控和线上抽样持续看，评测只是起点，它能帮你把候选缩到两三个，真正决定体验的是上线后的持续观察和调整。