Google在这次发布里给自己贴上了“最精确”的标签,理由是Gemini 3.5 Transcribe的词错误率(WER)做到了流式4.0%、非流式2.6%。数字看着不错,但它们出自同一个第三方机构Artificial Analysis——而这家机构给出的完整榜单里,ElevenLabs的Scribe v2在流式和非流式两项上都比Gemini更准。Google引用的证据,反而拆穿了自己的宣传语。

发生了什么

8月26日,Google DeepMind发布语音转文本模型Gemini 3.5 Transcribe,替代此前的Chirp 3。模型拆成两套API:面向实时场景的Live API(gemini-3.5-transcribe-live,亚秒延迟),和面向录音的Interactions API(gemini-3.5-transcribe,带说话人识别和词级时间戳)。已经落地Android Rambler、Gboard、Gemini macOS应用、Antigravity、AI Studio,Chrome即将上线。

核心卖点:智能纠错(去掉“嗯啊”、处理“周二——不对,周三”这类自我修正)、支持85种以上语言、可调用其他Gemini模型完成图片生成等任务、识别自定义词汇。

“最精确”这句话,自己的跑分表先不同意

非流式WER对比(数字越低越准) ElevenLabs Scribe v2 2.2% Gemini 3.5 Transcribe 2.6% AssemblyAI Universal-3 Pro 3.1% OpenAI GPT-4o Transcribe 4.0% Deepgram Nova-3 5.2% 数据来源:Artificial Analysis AA-WER v2

在Artificial Analysis的完整榜单里,Gemini 3.5 Transcribe确实赢了大多数对手:比OpenAI的GPT-4o Transcribe(4.0%)低约35%,比Deepgram Nova-3(5.2%)低约50%,比AssemblyAI Universal-3 Pro(3.1%)低约16%。流式榜单同样领先。

但ElevenLabs Scribe v2,无论流式(约3.6%)还是非流式(2.2%),WER都比Gemini更低。Gemini是这轮竞争里最扎实的追赶者,不是榜首。“最精确”这个定语,站不住脚。

速度上还有另一层权衡:Deepgram Nova-3的WER虽然更高,但处理速度比多数基于大模型的转录方案快500倍以上。追求低延迟高并发的字幕场景,大模型架构未必是最优解——这次是拿准确率换速度,不是白拿。


博客说3个人,文档说8个人

原文没写的三条硬限制 10分钟 Live API 单会话上限 30分钟 开启说话人识别 后上限(原60分钟) 3 vs 8 说话人识别人数 博客与文档口径不一

DeepMind的产品博客写着:Interactions API的说话人识别“最多支持3人,3人以上为实验性”。官方技术文档写的却是最多8人。同一家公司,两份官方材料,同一个能力,数字对不上——这比WER差0.几个点更值得警惕,说明发布节奏赶在了内容对齐前面。

其他限制原文同样没提:Live API单次会话最长10分钟;Interactions API本来能撑到1小时,一旦打开说话人识别或词级时间戳,上限直接砍到30分钟;智能纠错模式不能和说话人分离、时间戳同时开启,三选二;自定义词汇官方说上限1000条,但建议实际控制在约100条以内才有效果。

这些限制单独看都不致命,拼在一起,决定了这个模型能不能塞进一条真实的客服录音分析流水线,而不是决定它在Demo里跑得多流畅。

  • 风险.智能纠错会主动删掉填充词、改写自我修正,这对聊天记录是优点,对法庭证词、医疗问诊记录这种要求逐字还原的场景,反而是隐患。

免费和付费,是两种隐私承诺

免费层 vs 付费层:数据去哪了 免费层 数据可能用于改进产品 人工审核员可查看内容 适合试用,不适合敏感内容 付费层 不用于模型训练 因安全监控留存55天 零数据保留需单独审批

用免费层调用Gemini API或AI Studio,语音数据可能被用来改进Google产品,也可能被人工审核员看到。付费层不用来训练,但依然会因安全监控留存55天。真正的“零数据保留”(ZDR)不是默认打开的,需要单独走项目审批,而且Live API的会话恢复功能可能把文本和音频状态留存长达24小时——用ZDR就得放弃这个功能。

这条信息原文完全没提。对普通开发者调个API试试水没什么影响,但对医疗、法律、金融这些处理敏感录音的场景,免费层和付费层之间的差距,可能就是能不能用的分界线。

现在能信几分

早期反馈大多来自Vivo、Intellitek Health、Lingopal这些合作方,以及开发者社区里零散的正面评价,谈不上独立、系统的复测。更关键的是,几乎没有人针对gemini-3.5-transcribe这个具体模型ID做过公开可复现的测评,大多数测试还停留在通用的Gemini音频路径上。今年7月还有用户反映,通用版Gemini在长文本转录截断后会编造后续对话——这个问题有没有传染给专用转录模型,目前谁也说不准。

号称最准,却被自己的跑分表反手打了一巴掌。

字幕、客服录音、多语言会议这类容错率高、追求效率的场景,Gemini 3.5 Transcribe值得一试,它在多语言和长音频延迟上的进步是实打实的。但只要涉及逐字存证——法律证词、医疗记录、金融指令——先别急着把“智能纠错”当卖点,那恰恰是最该被关掉的功能。