ServiceNow AI 在 Hugging Face 发布了一套代码切换 ASR 基准，专门测企业语音代理能不能听懂双语客户。
它测了 7 个语音识别系统，覆盖 Spanish-English、French-English、Canadian French-English、German-English 四组混合语音。场景也没有放在泛泛的闲聊里，而是集中在 HR 和 ITSM：薪资福利、密码重置、VPN 访问、设备故障。
这件事有意思的地方在于，它没有把 ASR 当“字幕准确率”来评估。企业语音代理里，ASR 是第一道关。第一道关错了，后面的意图识别、知识库问答、自动派单都会被带偏。
为什么双语客户要单独测
代码切换不是小语种边角料。
在企业支持里，一个员工可能用母语描述问题，用英语说系统名、工单类型、设备名或内部流程词。对人来说，这很自然。对 ASR 来说，这会突然变成难题。
因为模型不只要听清声音，还要判断每个片段属于哪种语言。更麻烦的是，它还不能擅自“翻译”。企业系统需要的是原样转写，保住实体、语言边界和请求意图。
这里的风险很具体。
如果 ASR 把 VPN 访问听成别的请求，ITSM 可能派错队列。把福利日期、账号、设备编号听错，HR 或 IT 自动化流程就会误判。用户听到的是“机器人没听懂”，企业看到的是处理成本上升。
所以这类基准最该影响的，是两类人：
- 企业语音代理负责人.不要只拿单语 ASR 分数做上线依据，要把代码切换样本放进 PoC。
- ASR/语音 AI 评估团队.不要只看 WER，要看转写错误会不会伤到下游任务。
一句话，双语不是“多支持一种语言”这么简单。它会改变风险位置。
这套基准怎么做，别把它当真实客服实测
这套数据不是来自真实呼叫中心录音。
ServiceNow AI 是从企业支持语料出发，筛选 12 到 40 个词的候选句，排除邮箱、电话、URL 等实体占比过高的内容。之后用 GPT-5 生成代码切换文本，再做口语化处理，用 ElevenLabs Multilingual V2 合成语音。
最后，数据由母语 AI/NLP 语言学家审核。
样本量不大，但边界清楚：
| 语言对 | 样本量 | 场景 | 这组数据主要看什么 |
|---|---|---|---|
| Spanish-English | 259 | HR、ITSM | 常见双语企业支持表达 |
| French-English | 298 | HR、ITSM | 样本最多，可看稳定性 |
| Canadian French-English | 188 | HR、ITSM | 区域语言差异带来的识别压力 |
| German-English | 173 | HR、ITSM | 英语嵌入后的转写退化 |
评估指标也不是一个 WER 打到底。
| 指标 | 看什么 | 对企业语音代理的含义 |
|---|---|---|
| WER | 字面转写错误率 | 听写准不准 |
| SWER | 语义错误 | 意思有没有被改坏 |
| AER | 下游问答理解失败率 | 业务会不会办错 |
我更在意的是 AER。
WER 低，说明转写表面更准。但企业语音代理真正怕的，是一句话看起来差不多，意思却变了。比如请求类型、对象、时间、系统名一错，后面再强的 RAG 和工作流也只能沿着错误输入往下跑。
不过，也别把这套基准神化。
它依赖 GPT-5 生成文本，也依赖 ElevenLabs 合成语音。真实客服通话里的口音、噪声、打断、迟疑、情绪、麦克风质量，合成语音很难完全覆盖。
所以它更适合作为筛选门槛，不适合作为上线结论。
结果说明：头部模型强在不同地方
ServiceNow AI 测试的 7 个系统包括 AssemblyAI Universal 3-Pro、Deepgram Nova 3 Multilang、ElevenLabs Scribe V2、Google Gemini 3 Flash、Mistral Voxtral Small 24B-2507、Nvidia Parakeet TDT 0.6b V3 和 OpenAI Whisper Large V3 Turbo。
综合表现靠前的是 ElevenLabs Scribe V2、Gemini 3 Flash、AssemblyAI Universal 3-Pro。
Scribe V2 和 AssemblyAI 在 WER 上更强。Gemini 3 Flash 的看点不一样：它的字面转写排名未必总是第一，但在 SWER、AER 这类语义和下游指标上，超过 AssemblyAI 的情况更多。
这说明一件事：企业不能把 WER 排名直接等同于业务效果。
传统 ASR 模型可能更擅长逐字转写。大音频语言模型可能在“保住意思”上更稳。哪条路线更适合企业，要看后面的任务是什么。
Whisper Large V3 Turbo 排名靠后，也不能简单写成“模型不行”。原文指出，一个关键原因是：未显式指定语言时，它面对混合语音容易把内容翻译成英文，而不是按原语言转写。
对字幕用户来说，翻译成英文有时还能接受。对企业语音代理来说，这可能是事故源头。因为系统需要的是可追踪、可对齐、可进入流程的原始输入。
采购和评估时，动作可以更硬一点：
| 决策点 | 不建议怎么做 | 更稳的做法 |
|---|---|---|
| 选型 | 只看 WER 榜单 | 同时看 WER、SWER、AER |
| PoC | 只测标准单语句子 | 加入本企业常见代码切换样本 |
| 上线 | 默认模型会原样转写 | 检查是否能显式控制“转写而非翻译” |
| 评估 | 用合成语音结论替代真实流量 | 用真实噪声、多轮对话、业务流程再压测 |
如果企业正在做客服自动化或内部支持语音代理，我会把这套基准当成一个预警信号。
不是马上迁移模型，也不是立刻推翻已有方案。更合理的动作，是延后“只凭单语测试上线”的决策，把代码切换样本加入 PoC，并把 AER 设成上线前必须过的指标。
接下来最该看的，也不是榜单名次小幅变化。
真正要看三件事：真实通话噪声下 AER 是否还能稳住；多轮对话里语言切换会不会累积错误；模型能不能稳定做到原样转写，而不是替企业“好心翻译”。
目前这套基准只覆盖四组语言对和 HR/ITSM 场景。它不能证明某个模型在所有双语客服里最佳。
但它已经把问题摆清楚了：企业语音代理的难点，不是会不会说多种语言，而是客户半句一换时，系统还能不能把事办对。