Gemini 3.5 Transcribe 发布：WER 低至 2.6% 的语音转写模型，听懂 85 种语言

原文来源：Google Blog — Gemini 3.5 Transcribe 发布：WER 低至 2.6%、支持 85 种语言和实时流式的语音转写模型。

语音转写这件事，过去一直有个尴尬：识别准确率还行，但转出来的文字没法直接用——"嗯""啊"这种填充词一大堆，说话人自己改口了（"周二见——不对，周三"）机器也不知道帮你圆回来。谷歌这次发布的 Gemini 3.5 Transcribe，思路就是把这些脏活直接做完：不只是把声音变成字，而是变成一段已经整理好的文本。

核心卖点：不是"识别"，是"整理"

Gemini 3.5 Transcribe 是谷歌目前最精准的语音转文字模型，定位是"智能语音交互"。它跟传统语音识别模型最大的区别在于，它处理的是原始音频流，输出的是干净、格式化好的文本：

• 智能转写：能处理说话人的自我纠正（"let's meet Tuesday—no, Wednesday" 会被正确整理成最终时间），自动删掉 "um"、"ah" 这类填充词，自动格式化文本。
• 函数调用：模型可以把复杂任务（比如生成图片、分析文件）委托给其他 Gemini 模型——目前这个能力在 macOS 版 Gemini 应用里已经可用。
• 自定义词汇表：行业术语、专有名词、特殊拼写可以直接喂给模型，转写时会自动适配。
• 多说话人识别：预录音频可以区分最多三位说话人并打上时间戳（3 人以上目前还是实验功能）。
• 语言覆盖：自动检测并转写 85 种以上语言，能处理地区口音和方言差异，还支持实时切换语言。

数字说话：WER 和延迟

根据 Artificial Analysis 的独立评测，Gemini 3.5 Transcribe 的平均词错误率（WER）在流式场景下是 4.0%，非流式场景下是 2.6%。在嘈杂的真实环境里，它能准确捕捉邮政编码、订单号这类字母数字实体。

跟上一代语音模型 Chirp 3 相比，进步是跨维度的：新增了上面这些能力，词错误率更低，延迟也显著改善。同样是 Artificial Analysis 的测量，最终转写完成时间（time to final transcription）提升了 70%。在 FLEURS 基准上，流式模式 WER 5.50%、非流式 5.04%，多语言表现优于 Chirp 3。

开发者怎么用：两条 API 路线

模型通过两个独立 API 开放，对应两种场景：

实时流式（Live API）：模型 ID 是 gemini-3.5-transcribe-live，提供双向流式传输，亚秒级延迟，适合交互式语音应用——语音 Agent、实时字幕、边说边转的会议工具。

预录音频处理（Interactions API）：模型 ID 是 gemini-3.5-transcribe，处理录音、会议、通话记录，带说话人归因和词级时间戳，适合通话后分析、质检、会议纪要这类管线。

两个 API 在 Google AI Studio 和 Gemini Enterprise Agent Platform 上都能直接用。谷歌官方给出的场景建议是：语音 Agent、实时字幕工具、通话后分析管线。

已经落地的地方

Gemini 3.5 Transcribe 其实已经悄悄跑在谷歌自家产品里了：

• Android 的 Gboard：新的 Rambler 功能，把口语想法转成格式良好的文本，过滤填充词，还能用语音做编辑、改拼写、换文风。
• Google Antigravity：结合屏幕上下文和聊天历史（需授权），提升文件名、Agent 想法、活动文档的转写准确度。
• macOS 的 Gemini 应用：不只是转写，还能用语音指挥复杂工作流——总结本地文件、跨应用改写文本、光标处生成图片。
• Google AI Studio：Build 模式下可以边说话边写代码。
• Chrome：即将上线"talk to type"，在任意网页输入框里用语音打字。

说点看法

这次发布值得注意的不只是"转写更准了"。把 gemini-3.5-transcribe-live 做成独立模型 ID 放进 Live API，意味着语音 Agent 的"耳朵"有了一个专门优化的组件——过去做实时语音 Agent，要么用通用 ASR 顶着高延迟，要么自己拼一堆后处理规则去清洗文本。现在这个环节可以整体外包给一个模型，还自带函数调用，可以直接把"听到的话"变成"要执行的动作"。

当然也要泼点冷水：2.6% 的非流式 WER 是平均值，嘈杂环境、专业领域（医学、法律术语）实际表现会打折；多说话人识别在三人以上还是实验状态；85 种语言的覆盖是"检测+转写"，小语种的准确度大概率参差不齐。语音转写这个赛道，模型只是起点，工程化（音频分段、降噪、领域微调）才是差距所在。

对独立开发者来说，值得关注的点是：语音交互类 App 的成本结构正在改变。过去要自己养 ASR 模型或者接多家服务拼管线，现在一个 API 就能覆盖转写+清洗+说话人分离，MVP 的搭建速度会快很多。等 Chrome 的 talk to type 上线后，网页端的语音交互也会跟着普及——这是个值得提前布局的方向。