正在加载，请稍候
Gemini 3.5 Transcribe 上线：流式 WER 4.0%、延迟改善 70%。本文从工程视角拆解 API 选型、落地三个坑与值得替换的场景。
某呼叫中心每天要质检 4000 通录音，过去用传统 ASR，行业黑话和订单号错误率高到没法自动生成工单。8 月 26 日 Google DeepMind 上线新语音转写模型，流式词错率降到 4.0%，语音链路的成本账要重新算了。
先说数字。根据 Artificial Analysis 的独立评测，新模型流式场景平均词错率 4.0%，非流式 2.6%；在 FLEURS 多语言基准上，流式 5.50%、非流式 5.04%，都优于上一代 Chirp 3。官方称最终转写时间比上一代改善约 70%，对实时交互场景是质的差别。
除了准确率，模型做了三件传统 ASR 做不好的事：一是智能转录，能处理说话人自我纠正（“周二——不，周三”），去掉“嗯、啊”填充词，自动排版；二是识别自定义词汇，把转写结果对齐到业务术语和特殊拼写；三是函数调用，把转写结果直接委派给其他模型做摘要、图像生成等后续任务，官方说 macOS 版 Gemini 应用已经在用。
| 能力维度 | 本代模型表现 |
|---|---|
| 流式词错率（Artificial Analysis） | 4.0% |
| 非流式词错率 | 2.6% |
| FLEURS 流式 / 非流式 | 5.50% / 5.04% |
| 最终转写时间 | 较上代改善约 70% |
| 说话人识别 | 最多 3 人（3 人以上为实验性） |
| 语言覆盖 | 85 种以上，自动检测 |
这次发布把 API 拆成两条，选错会直接拉高成本和延迟：Live API（gemini-3.5-transcribe-live）提供亚秒级延迟的双向流式，适合语音 Agent、实时字幕这类“边说边出字”的场景；Interactions API（gemini-3.5-transcribe）处理预录音频，带说话人归属和词级时间戳，适合会议纪要、通话质检、呼叫中心事后分析。
工程上判断标准很简单：如果下游要实时响应，比如语音助手要在对话中打断，走 Live；如果只是事后把录音变成结构化文本，走 Interactions，别为实时性多付钱。
我们一开始直接把 8 人会议的录音丢给模型做说话人识别，结果翻车——官方明确支持的上限是 3 位说话人归属，3 人以上属于实验性功能。会议室那种交叉讨论，需要先做 diarization 预处理，或者干脆按频道拆分。
第二个坑是自定义词汇。模型说支持专业术语，但前提是词表喂得对。我们试过把产品型号直接扔进去，效果一般；改成带发音提示的条目后，订单号识别率才上去。WER 是平均值，关键字段的错误率要单独盯。
第三个坑是成本账。转写输出不是终点，下游摘要、结构化抽取还要再吃一遍 token。做预算时不能只算转写这一层，要按“转写 + 后处理”整条链估，否则上线两周发现账单超预期。
值得换的：语音 Agent 实时交互、呼叫中心质检、实时字幕、会议纪要。这几个场景要么吃延迟、要么吃准确率，新模型的 70% 延迟改善和低词错率直接改变可行性。
先别动的：已经用领域专用 ASR 打磨了很久、词表很深且离线要求高的场景。云端 API 的优势在通用性和迭代速度，如果你对数据出境有硬约束，本地化部署的成熟方案仍然合理。换不换，最终取决于自家语料的实测结果，而不是发布会上的演示数字。
如果你的语音链路正在评估换模型，蓝曜炬辉可以带着你的真实音频样本做一轮转写与成本测算，把识别、摘要、结构化整条链的账算清楚，再决定动不动手。欢迎带上样本找我们聊。
4% 意味着平均每 100 个词错 4 个。对实时字幕、语音 Agent 是可用的；对医疗、法务这类错误代价极高的场景，建议拿自家语料跑一轮评测，重点看关键字段错误率而不是平均词错率。
官方标注支持 85 种以上语言自动检测，包含中文，能处理地区口音和方言。FLEURS 多语言基准的表现优于 Chirp 3，但中文具体准确率仍建议用业务音频实测。
开源方案胜在可控和离线，云端模型胜在迭代速度和智能能力，比如函数调用、自动格式化。没有统一答案，取决于数据合规要求和场景实时性，两条路线可以并行验证。