ASR 语音识别评测与选型

语音产品并不是“接一个语音识别 API”这么简单。用户说出一句话，设备要先采集声音、处理回声和噪声、判断什么时候开始与结束，再把声音转成文字、理解含义并生成回复，最后把回复重新合成为声音。

也正因为链路很长，语音服务看起来容易比较，实际却很容易测错。一个服务宣称“78 ms 返回”，可能指最后一个音频包发出到最终文字返回；另一个“328 ms”，可能指完整 WAV 准备好之后的整句请求耗时。两个数字的起点不同，放在同一个排行榜里没有意义。

本文以一次真实项目中的 100 条普通话语音、24 条本地与云端路线为案例，从语音交互的基本模块讲起，重点整理 ASR 的产品形态、评测指标、数据集设计、流式延迟、VAD 分工和工程选型，并提供主流厂商的官方文档入口，方便读者自行复现和扩展测试。

数据快照：2026 年 8 月 15 日。文中的厂商结果只代表当时的测试账号、模型版本、网络条件、参数和样本分布，不构成长期排名或采购建议。当前数据集中儿童语音占比较高，因此方法具有通用性，具体数值更偏向语音交互和儿童语音场景。

先认识语音交互系统

什么是语音

从物理上看，语音是人类发声器官引起的空气压力变化；麦克风把这种连续变化转换成电信号，再经过采样和量化变成计算机可以处理的数字音频。

一段数字语音至少包含几个重要属性：

• 采样率：每秒记录多少次声音变化，例如 16 kHz；
• 位深：每次采样使用多少位表示，例如 16-bit；
• 声道数：单声道或多声道；
• 编码与封装：PCM、WAV、MP3、Opus 等；
• 时序：每一帧音频在整段讲话中的位置。

ASR 接收的不是“已经整理好的句子”，而是一串包含说话人、口音、停顿、背景噪声、设备回声和传输抖动的时序信号。理解这一点，才能解释为什么同一个模型在安静录音、远场麦克风和设备自播放场景下会表现不同。

从听见到回答，需要哪些模块

一个常见的模块化语音助手可以表示为：

麦克风采集
  → 音频前处理（降噪 / AEC / AGC）
  → 唤醒词（可选）
  → VAD / Endpoint
  → ASR
  → 意图识别或 LLM
  → TTS
  → 扬声器播放

模块	解决的问题	常见输出或作用
音频前处理	怎样让输入声音更干净、更稳定	降噪、回声消除 AEC、自动增益 AGC
唤醒词	设备什么时候开始进入交互	“小 X 小 X”等低功耗触发信号
VAD	当前有没有人声	speech / silence、语音起止帧
Endpoint	这一轮表达是否已经结束	继续等待或结束当前会话
ASR	用户说了什么	Partial、Final、时间戳、置信度
意图识别 / LLM	用户想表达什么，应该怎样回答	指令、结构化意图或回复文本
TTS	怎样把回复文字变成声音	音频流、首包时间、音色和韵律
S2S	能否直接从语音输入生成语音回复	统一完成识别、理解、生成与合成

其中 VAD、ASR、TTS 是功能模块，S2S（Speech-to-Speech）更像一种端到端架构。传统链路能分别替换和评测每个模块；S2S 将多个阶段放入同一模型或服务，交互可能更自然，但错误定位、成本归因和单模块替换也更困难。

VAD、Endpoint 和 ASR 的边界

• VAD 更关注“这一帧有没有人声”，通常根据声学特征判断语音和静音；
• Endpoint 更关注“这一轮是否真的结束”，可能结合静音时长、服务端规则和语义完整性；
• ASR 更关注“声音里说了什么”，实时接口还会返回临时文本和最终文本。

自然口语中经常有犹豫、自我修正、拉长音和句中停顿。例如“我想要……那个蓝色的”，VAD 能发现中间出现静音，却不一定知道用户还没说完。服务端自带 VAD 不代表本地 VAD 一定多余，本地统一判停也不代表已经测出了厂商 Endpoint 的真实能力。

本文专注什么

本文的主角是 ASR 评测与选型：准确率、成功率、首个 Partial、句尾 Final、数据集、热词和不同 API 形态。VAD 与 Endpoint 会作为 ASR 前后的关键边界展开；TTS、AEC、唤醒词和 S2S 用来解释完整链路，但不进入本次 ASR 准确率排名。

用户感受到的“反应快”更接近：

用户停说 → 听到回复
= VAD / Endpoint 判停等待
+ ASR 句尾处理
+ 意图识别或 LLM 生成
+ TTS 首包
+ 网络、传输与播放缓冲

因此，本文给出的 ASR 毫秒数不能直接理解为产品端到端响应时间。

先看结论

如果只记住几件事，可以先记住这些：

1. ASR 准确率不等于语音产品体验。 用户感受到的响应时间还包含 VAD、Endpoint、LLM、TTS、网络和播放缓冲。
2. 整句耗时、首个 Partial、句尾 Final 和端到端延迟不能混排。 每个数字必须带上起止点。
3. 平均 CER 会掩盖人群和场景差异。 至少要分别观察年龄、环境、音频长度和说话方式。
4. 成功率和 P90 往往比单次最快值更重要。 一个偶尔很快、但会空转写或建连失败的服务不适合直接进入生产。
5. 固定 WAV 流式回放不是 VAD 验收。 它知道音频何时结束，真实设备必须自己判断用户是否说完。
6. 没有唯一的 ASR 冠军。 实时对话、会议转写、隐私部署、端侧降级和业务热词对应不同的最优路线。

ASR 路线与官方测试入口

常见 ASR 路线有什么区别

不同路线解决的问题不同。选型前应先排除产品形态明显不匹配的方案，而不是把所有接口都接完再比较。

路线	输入与返回方式	适合场景	主要局限
一句话/整句识别	完整音频准备好后上传，通常只返回最终文字	短命令、语音留言、内部服务	必须先得到完整音频
实时流式 ASR	音频持续分包上传，服务持续返回 Partial 和 Final	实时对话、字幕、语音助手	协议和状态处理更复杂
双向流式与二遍修正	上传音频的同时持续接收局部结果，并可能修正历史文本	对实时性和最终准确率都有要求的场景	Partial 不一定可以直接追加
文件/录音转写	上传文件或 URL，异步提交并轮询结果	会议、长录音、质检	不适合用户说完立即回复
本地/端侧 ASR	在本机、服务器或设备芯片上推理	离线、隐私、断网降级	受算力、内存、功耗和模型体积限制
端到端语音 S2S	服务内部完成识别、理解、回复和合成	快速构建自然语音对话	黑盒程度高，各模块不易独立替换

“双向流式”指客户端和服务端持续双向传输，不是两路麦克风。“二遍修正”则通常表示先返回局部结果，再利用更长上下文修正最终文本。

主流厂商官方文档

下面按厂商列出本次评测相关的官方入口。产品名称和能力会更新，真正测试时应以文档中的模型版本、区域、音频格式、时长限制和计费说明为准。

阿里云百炼

• 实时 / 流式：实时语音识别
• 整句 / 文件：非实时语音识别

腾讯云

• 实时 / 流式：实时语音识别 V2、实时语音识别
• 整句 / 文件：一句话识别

火山引擎

• 实时 / 流式：大模型流式语音识别、流式语音识别
• 整句 / 文件：录音文件识别标准版、录音文件识别极速版、一句话识别

科大讯飞

• 实时 / 流式：实时语音转写大模型、实时语音转写标准版
• 整句 / 文件：极速语音转写

百度智能云

• 实时 / 流式：实时语音识别
• 整句 / 文件：短语音识别极速版、短语音识别标准版

阿里云百炼链接会进入控制台文档页，可能需要登录；也可以从语音识别 API 总目录进入对应模型文档。

怎样快速开始自己的测试

1. 先按产品场景选接口。 实时对话选流式 ASR，短命令选一句话识别，会议和长录音选文件转写。
2. 准备一条规范音频冒烟。 推荐先使用 16 kHz、单声道、16-bit PCM WAV，并确认接口支持的格式和时长。
3. 流式接口按真实时间发送。 不能瞬间把整段 WAV 塞进 WebSocket，再把结果称为实时延迟。
4. 同时保存文本与时间点。 至少记录首个 Partial、最后一包音频、Final、原始响应和错误码。
5. 再扩展到统一数据集。 一条跑通后按 10 条小批量、正式全量逐步扩大，不要直接批量消耗额度。
6. 凭据只放环境变量。 AppID、API Key、Secret 和 Token 不应写入代码、结果文件或截图。

有了这些入口后，最重要的仍然是让不同厂商收到同一批音频、使用一致的文本归一化和计时定义，否则接口都能调用成功，也不代表结果可以横向比较。

评测指标：准确率、稳定性与延迟

准确率：CER 与 WER

中文通常使用 CER（Character Error Rate，字错误率）：

$$
\mathrm{CER} = \frac{S + D + I}{N}
$$

其中：

• $S$：替换字符数；
• $D$：删除字符数；
• $I$：插入字符数；
• $N$：参考文本字符数。

字准确率常写为：

$$
\text{字准确率} = 1 - \mathrm{CER}
$$

英文更常使用 WER（Word Error Rate，词错误率）。无论采用哪一种，文本归一化规则必须固定。本次评测采用相对保守的规则：

1. Unicode NFKC 规范化；
2. 删除空白与标点；
3. 英文统一小写；
4. 不把中文数字和阿拉伯数字强行视为相同；
5. 不进行语义改写或猜测式纠错。

严格规则会让数字表达更容易被计错，但它避免了不同平台的数字规整策略被悄悄掩盖。宽松规则并非一定错误，关键是提前定义并对所有路线一致执行。

稳定性：成功之外还要看失败形态

准确率只统计成功请求还不够，还应记录：

• 请求成功率；
• 空转写率；
• 建连失败和鉴权失败；
• 超时与限流；
• 音频过长或格式异常；
• 重试后是否恢复；
• Partial 正常但 Final 丢失；
• 是否出现重复文本或只剩标点。

“最快的一次”几乎没有选型意义。实际产品更关心连续运行时是否稳定，以及失败后能否识别、重试、降级和恢复。

延迟：先定义起止点，再讨论毫秒数

至少需要区分以下指标：

指标	起点	终点	回答的问题
整句请求耗时	完整音频已经准备好	最终文字返回	文件准备完成后服务处理多快
首个 Partial	开始发送音频	第一个可见临时文本	用户多久能看到第一批文字
流式句尾处理	最后一个音频包发出	Final 返回	音频结束后服务还要处理多久
停说到 Final	用户真实停说	Final 返回	VAD 与 ASR 合计等待多久
停说到 TTS 首包	用户真实停说	第一段回复语音到达	完整对话链路响应多久

一次流式请求的时间轴可以表示为：

开始说话         首个 Partial       最后一包音频       Final        TTS 首包
   │                   │                   │              │              │
   └──── 持续发送音频 ─┴─ Partial 更新 ────┴─ 句尾处理 ───┴─ 对话与合成 ─┘

本次正式流式结果中的“句尾延迟”，统一定义为：

固定 WAV 按真实时钟分包回放，最后一个音频包发出，到服务返回 Final 的时间。

它不包含本地 VAD 判停，也不包含 LLM、TTS 和播放。

为什么要看 P50、P70 和 P90

• P50：一半请求不超过该值，代表典型体验；
• P70：观察大多数请求的表现；
• P90：观察长尾和偶发卡顿。

平均值容易被少数极慢请求拉高，也可能掩盖双峰分布。产品体验通常应该同时看 P50 和 P90，并保留逐条数据检查异常点。

数据集与统一评测方法

怎样设计一个更有适用性的测试集

样本数量不是数据集质量的充分条件。100 条相似的安静朗读，可能不如 30 条经过分层设计的语音更有判断力。

一个综合 ASR 测试集至少可以考虑这些维度：

维度	建议覆盖
年龄与人群	儿童、成人、老年
性别	男声、女声及不同音高范围
说话方式	朗读、自然口语、犹豫、自我修正、拉长音
内容	日常对话、数字、英文混合、专有名词、业务热词
环境	安静、电视声、多人交谈、音乐、户外和设备自播放
距离	近场、中场、远场
时长	超短命令、短句、长句、长音频
设备	手机、电脑麦克风、目标硬件麦克风
网络	正常、弱网、丢包、重连

本次 100 条数据集

维度	分布
总样本	100 条，均有人工作为参考文本
人群	儿童 60 条、成人 40 条
性别	女声 50 条、男声 50 条
环境	干净 60 条、15 dB 确定性合成噪声 40 条
时长	90 条不超过 30 秒，10 条为 30～60 秒
音频格式	16 kHz、单声道、16-bit PCM WAV
最大时长	59 秒

每条样本都有唯一 ID、人工参考文本、场景标签、原始音频哈希、统一转码后哈希、来源和许可证字段。成人数据不仅用于增加数量，也用于观察模型问题来自通用识别能力，还是特定年龄人群。

这套数据仍有明确边界：

• 合成 white、pink、babble 噪声是可复现控制组，不等于真实家庭和户外环境；
• 固定 WAV 已知结束点，不能替代真实麦克风的 VAD 评测；
• 数据中儿童占比偏高，不应解释成完整普通话人群排名；
• 真实设备的远场、回声和扬声器自播放尚未覆盖；
• 热词还没有完成正样本与近音负样本 A/B。

公开分布和边界，比只强调“我们测了 100 条”更重要。

建立统一、可复跑的评测闭环

评测工作的核心并不是多接几个 API，而是让所有路线使用同一把尺子。

冻结 Manifest（音频、标注、标签、哈希）
                    ↓
统一转码（16 kHz / 单声道 / 16-bit PCM）
                    ↓
Provider Adapter（本地 / 内部 / 云端）
                    ↓
逐条 JSONL 结果 + 脱敏原始响应
                    ↓
统一 CER、成功率、P50/P70/P90
                    ↓
整体榜 + 人群/环境/时长分组报告

统一输入

所有接口调用前统一转换为 16 kHz、单声道、16-bit PCM WAV。否则模型 A 可能收到 44.1 kHz 双声道 MP3，模型 B 收到 16 kHz PCM，差异已经不仅来自模型。

统一结果结构

每条结果至少记录：

• 服务商、模型、路线类型和运行时间；
• 输入哈希与转码后哈希；
• 原始文字、归一化文字和 CER；
• 首个 Partial、最后音频包、Final 等时间点；
• 成功状态和结构化错误类型；
• 脱敏后的原始响应位置。

运行产物可以组织为：

run/
├── metadata.json
├── results.jsonl
├── summary.csv
└── raw/

API Key、Secret、临时 Token、内网地址和控制台实例 ID 只存放在本机环境变量或被忽略的配置中，不能进入 Git、评测结果和截图。可复现不等于把凭据也一起公开。

从一条冒烟到正式全量

每接入一条新路线，都采用相同节奏：

doctor（凭据、区域、模型和权限检查）
  → 1 条真实音频冒烟
  → 10 条小批量
  → 冻结清单的 100 条全量
  → 聚合报告与异常复查

这样可以把鉴权错误、协议解析错误、特定样本失败、长尾延迟和成本问题分开定位。直接让一个尚未打通的平台跑 100 条，只会制造一批难以解释的失败结果。

本次 24 条路线与执行方式

本轮主榜包含：

• 9 条整句或本地路线：包含本地模型、端侧可行性基线、内部整句服务和云端短语音接口；
• 15 条实时流式路线：覆盖阿里云、火山引擎、腾讯云、科大讯飞和百度智能云的不同实时模式。

整句路线比较完整音频准备后的请求耗时；流式路线按真实时钟发送 PCM 分包，并记录 Partial 与 Final。两者分别成榜，不使用一个总延迟排序。

正式实时评测共提交 1500 次 Session（15 路 × 100 条），其中 1493 次成功：

• 12 条路线达到 100/100 成功；
• 3 条路线累计出现 7 次失败；
• 15 条路线共同成功的样本为 93 条；
• 横向准确率主榜使用这 93 条计算，保证比较的是同一批音频。

为了减少网络争抢，本轮正式延迟测试采用固定网络、无代理、并发 1 串行运行。并发 8 的小批量只用于验证吞吐和接口稳定性，不进入单请求延迟排名。

结果解读与场景选型

为什么不能只选一个冠军

经过准确率、成功率、句尾延迟和接入形态综合比较，腾讯实时 ASR 2.0、科大讯飞实时语音转写大模型、火山豆包流式 2.0 双向优化进入了下一阶段联调。

这三条路线不是全项目的固定前三名，而是代表三种不同取舍。

三条实时候选的统一结果

下表准确率基于 15 条实时路线共同成功的 93 条样本；三条候选各自的调用成功率均为 100/100。

路线	字准确率	CER	首个 Partial P50	句尾 P50/P70/P90	当前观察
腾讯云实时语音识别 2.0	90.07%	9.93%	879 ms	78 / 86 / 112 ms	三者中句尾等待最低
科大讯飞实时语音转写大模型	90.53%	9.47%	1646 ms	125 / 145 / 157 ms	准确率与 P90 较均衡
火山豆包流式 2.0 双向优化	90.04%	9.96%	1466 ms	113 / 134 / 190 ms	速度、准确率和接入形态均衡

例如腾讯的 78 ms 表示：在固定 WAV 回放条件下，一半请求在最后一个音频包发出后的 78 ms 内收到 Final。它不表示用户停说后 78 ms 就能听到回复。

分组结果可能改变判断

三条候选在 54 条共同成功儿童样本上的 CER 分别约为：

• 腾讯：16.40%；
• 科大讯飞：14.59%；
• 火山：15.30%。

整体结果接近，不代表特定人群也完全相同。这也是为什么一个综合榜之外还必须保留人群、环境和音频长度分组。

没进入三条 Demo 的路线仍然有价值

• 某些云端实时路线在这批样本上的 CER 更低，适合作为准确率上限对照，但曾出现建连超时或首个可见结果偏晚；
• 内部整句服务在完整音频准备后的处理耗时较低，而且数据不需要发往外部云，但必须叠加本地 VAD；
• 本地与端侧模型不一定在 Mac 上的准确率和速度占优，却回答了隐私、断网、成本和降级问题；
• 文件转写适合长音频和会议，不应该因为不适合实时对话就被评价为“能力差”。

选型不是把所有维度压成一个总分，而是先定义产品场景，再判断哪些指标是门槛，哪些指标可以权衡。

按场景选择 ASR 路线

场景	优先关注	更适合的路线
实时语音对话	句尾 P90、成功率、Endpoint、弱网恢复	实时流式 ASR
实时字幕	首个 Partial、刷新频率、历史文本修正	高频 Partial 的流式路线
会议与长录音	长音频、时间戳、说话人、异步稳定性	文件/录音转写
短命令和语音留言	整句准确率、请求耗时、接入成本	一句话/整句识别
隐私与断网	端侧资源、RTF、内存、功耗	本地或端侧 ASR
专有名词密集	热词召回、误插入、数字和英文规整	支持可验证热词能力的路线
完整语音助手	VAD、AEC、打断、端到端延迟	ASR、对话和 TTS 联合评测
快速语音原型	链路完整性、集成成本	S2S，但需评估锁定风险

工程问题与架构边界

评测中最容易踩的工程坑

1. 最快的数字测的可能不是同一件事

完整 WAV 上传后的 300 ms 与最后一包后的 78 ms 起点不同。正确做法是先写延迟定义，再给数字，并把整句、流式、S2S 和真机端到端分别展示。

2. 100 条并不自动代表数据集质量

同一句话反复加噪不能被当成多个独立语义样本。数据集应公开人群、性别、环境、时长、来源和已知缺口，平均分之外还要有分组结果。

3. 合成噪声不等于真实世界

固定信噪比有利于控制变量，却不能替代电视声、多人交谈、设备回声和远场拾音。更准确的说法是“可复现噪声控制组”，而不是真实场景已经覆盖。

4. 固定 WAV 流式回放不等于 VAD 已验收

批量程序知道文件何时结束，可以明确发送结束包。真实设备面对的是未知长度的连续麦克风流，需要判断句中停顿和真正结束。

5. 服务端有 VAD，不代表本地 VAD 多余

多平台评测使用本地统一判停，可以让每家收到一致的结束控制；产品阶段则要重新决定由本地、厂商 Endpoint 或两者协同负责结束一轮。评测用统一控制器不能被当成厂商 VAD 的性能结论。

6. Partial 不是不断追加就行

不同协议可能返回增量文本、累计文本或对历史片段的替换。如果把每条 Partial 都直接追加，页面会出现重复句子；如果错误地让最后一个标点片段覆盖全文，Final 甚至可能只剩一个句号。

正确做法是根据协议中的 segment id、append/replace 语义维护当前文本，并保存原始事件用于复盘。

7. 热词配置成功不等于效果提升

控制台创建词表或接口参数成功，只能说明接入完成。热词验收至少要比较：

• 正样本召回率；
• 近音负样本误插入率；
• 整句 CER 变化；
• P90 延迟变化。

现场读对一次是演示，不是统计结论。

8. 网络、代理和并发会污染延迟

上行带宽、WebSocket 建连、本机事件循环、音频转码、云端并发限制和代理路由都会改变结果。延迟报告应同时记录数据集、网络、并发、音频时长和起止定义。

9. 同一品牌不等于同一个 API

一句话识别、实时识别、录音转写和大模型语音接口可能使用不同鉴权、区域、资源 ID 和协议。每条路线都应先执行 doctor，并在元数据中记录模型、模式、区域和认证类型，而不是只记录厂商名称。

10. 可复现不能以泄露凭据为代价

ASR 调试经常涉及 AppID、API Key、Secret 和临时 Token。代码只从环境变量读取凭据；公开结果必须脱敏；权限和 Token 应遵循最小范围与最短有效期。

VAD、语义判停和 S2S 应该怎么看

语义判停是 VAD 的补充，不是 ASR 排名项

传统 VAD 更擅长判断“有没有声音”，语义判停则尝试判断“表达是否完整”。一种可能的链路是：

轻量 VAD 发现持续静音
  → 语义判停判断 Complete / Incomplete
  → Complete：结束 ASR 会话
  → Incomplete：继续等待，不抢答

它适合处理自然停顿和自我修正，但会增加模型计算、实现复杂度和新的错误类型。是否值得引入，需要用带人工时间轴的真实语音统计提前判停率和额外等待，而不是只凭主观体验。

S2S 是另一条架构，不是更快的 ASR

端到端语音 S2S 把识别、理解、回复和 TTS 放进统一服务。它的优势是链路短、交互自然；代价是 ASR、LLM 与 TTS 更难独立替换，错误定位和成本归因也更复杂。

因此 S2S 应使用“停说到回复语音”的端到端指标，并单独评估打断、AEC、弱网和长音频，不应放入纯 ASR 的 CER 或句尾延迟榜。

适用边界、复用清单与总结

当前仍不能下哪些结论

完成 ASR benchmark 不等于完成语音产品验收。目前仍不能：

1. 宣布唯一生产主路线；
2. 宣称业务热词已经提升识别率；
3. 宣称 VAD 能正确处理所有自然停顿；
4. 用固定 WAV 句尾延迟承诺真实端到端响应；
5. 用开发机本地模型结果承诺目标芯片性能；
6. 忽略音频授权、云端上传、留存和密钥管理；
7. 忽略价格、配额、SLA、区域和模型版本变化。

下一阶段真正需要补充的是：

• 真机 VAD 起点/终点延迟、漏检、误检和提前抢答；
• 热词正样本与近音负样本 A/B；
• 扬声器播放时的 AEC、插话和打断；
• 弱网、丢包、重连和会话恢复；
• 连续运行稳定性、成本、配额和故障回退；
• 目标芯片上的内存、功耗、RTF 和启动时间。

一份可复用的 ASR 评测清单

后续再评估新的模型或厂商，可以按这份清单快速检查：

数据

• 每条语音有人工参考文本和唯一 ID
• 人群、环境、时长和内容分布公开
• 音频格式统一，原始与转换后哈希可追溯
• 数据来源、授权和云端上传边界明确

指标

• CER/WER 归一化规则固定
• 成功率、空转写和错误类型单独统计
• 整句、Partial、Final 和端到端延迟分别定义
• 同时报告 P50 和 P90
• 有整体结果，也有人群和场景分组

执行

• 新路线按 doctor → 1 条 → 10 条 → 全量推进
• 正式延迟测试固定网络、代理和并发
• 保存逐条结果与脱敏原始响应
• 记录模型、模式、区域、参数与快照日期

选型

• 先定义产品场景和门槛，再比较路线
• 不把固定 WAV 结果当成真机 VAD 结果
• 热词经过正负样本 A/B
• 评估隐私、成本、SLA、配额和降级路线
• 在目标硬件和真实网络上完成最终验证

总结

这次评测最大的收获，不是哪一家 API 的毫秒数最低，而是建立了一套能把声音、文本、网络、判停和产品体验拆开讨论的方法。

准确率、句尾延迟和成功率是 ASR 的第一层门槛；真正决定语音产品体验的，还包括用户自然停顿时系统会不会抢答、设备播放声音时会不会误触发、弱网下能不能恢复，以及业务热词能否稳定识别。

ASR 选型不是选一个分数最高的名字，而是持续使用同一把尺子，把每一项不确定性变成可测、可解释、可复跑、可回退的工程决策。