Google 刚刚把语音转文本的天花板又顶高了一截。Gemini 3.5 Transcribe 正式发布，官方直接给它贴上了“最精准”的标签——支持实时流式与预录音频，通过 Live API 和 Interactions API 双通道调用。如果你还在用 Chirp 3 做语音代理，接下来的数字会让你坐不住：流式 WER 降到 4%，延迟改善了 70%。上一次看到如此激进的迭代，还是 Whisper 大规模铺开的时候。但谷歌选择了另一条路：把实时性和准确性一起端上桌。
硬通货来了：流式 WER 4%，延迟砍掉 70%
WER 4% 是什么概念
词错率降到 4% 是什么体验？简单说，每 100 个词里错 4 个。在嘈杂会议、带口音的对话、电话线另一端模糊音质下，这个数字已经逼近人工转写的红线。对语音代理而言，4% 不是“可以秀的 demo”，而是“可以上生产的基线”。
更重要的是，官方口径的流式 WER，指音频边输入边识别过程中的实时误差，不是离线反复修订后的成绩。这中间的门道，用过语音 API 的人一眼就懂：离线转写做到低错率不稀奇，流式状态下还能稳住错率，才是真正的硬实力。
对比 Chirp 3，这个进步是跨台阶的。它意味着更多原本只敢用离线转写的场景，现在可以放心交给流式管线，让 AI 在对话进行中就给出判断。
延迟改善 70%，体验才真正落地
准确率是及格线，延迟才是体验分。Gemini 3.5 Transcribe 比 Chirp 3 的流式识别延迟砍掉了七成，这个幅度不是挤牙膏，而是架构级的重做。实时字幕、语音助手、会议纪要，这些场景的胜负手往往就差几百毫秒。
延迟的下降直接影响交互模型。过去语音代理怕卡顿，经常牺牲精度换速度，或者设计一套复杂的预判规则。现在反馈链路更短，开发者可以把更多真实语义放进实时流程，而不是等音频结束后再补一刀。
从用户感知来说，延迟改善 70% 意味着对话的节奏可以更接近真人。你话音刚落，对方已经开始回复，这种无摩擦的体验才是生产级应用愿意迁移的根本原因。
Live API 和 Interactions API，Google 的两张牌
Live API：实时场景的快车道
两条通路，分工明确。Live API 面向实时流式，音频一边进、文字一边出。语音代理、实时字幕、同声传译，要的就是这种低延迟高吞吐的通道。Live API 的设计目标很直白：让模型成为对话流里的一根神经，而不是事后整理录音的笔。
对开发者来说，Live API 把实时语音的工程门槛砍掉了一大截。音频切分、缓冲、重试、网络抖动，这些底层脏活都交出去，应用层只需要关注产品逻辑。过去三周才能搭起的流式识别服务，现在变成一次 API 调用的事。
更难得的是，Live API 不是为了低延迟而牺牲准确性。它保住了 4% 的流式 WER，这意味着实时场景不再只是“听个响”，而是能参与决策的数据源。
Interactions API：预录音频的深度处理
另一条通路 Interactions API 专门处理预录音频。会议录像、客服通话、用户留言，这些非实时数据可以在这里获得更完整的上下文校正，噪声、口音、专业术语都能被照顾得更周全。
它不追求毫秒级响应，但可以在拿到整段音频后反复推理，把细节打磨到极致。对于需要归档、检索、质检的场景，这种深度处理比实时流式更实用。
两条通路合在一起，给了开发者一个清爽的答案：同一个模型，直播字幕和离线归档都能兜住。这种设计上的通透，比单纯刷一个精度数字有价值得多。
语音代理的分水岭，从“能听”到“听得懂”
准确率之外，还有工程复杂度
语音代理过去最尴尬的，不是模型不聪明，而是“耳朵”不好使。一次识别错误，后面的自然语言理解、意图判断、上下文管理全部跑偏。所以很多团队只敢在封闭场景里用语音代理，或者强制用户重复一遍，用糟糕体验换取确定性。
4% 的流式 WER 让这道口子松动了。当误听率低到一定程度，语音代理才敢把决策权交给音频输入。再加上延迟下降，整个链条从麦克风到响应终于能形成自然对话的闭环。
这背后其实是工程复杂度的转移。以前团队要自己维护降噪、断句、热词，现在模型自带的能力更强，工程师得以把精力集中到上层，比如对话策略和业务逻辑。
对开发者而言，这盘棋开始活了
更重要的是架构选择的简化。实时交互接 Live API，离线归档接 Interactions API，或者两者混用——客服系统可以一边实时转写，一边在通话结束后生成完整质检报告。谷歌把基础设施做成了标准件，开发者不用再从零造轮子。
当然，迁移有成本。从 Chirp 3 换到 Gemini 3.5 Transcribe，需要重跑测试集、调参、验证边界情况。但流式 WER 和延迟的双重提升摆在那里，这笔账大概率算得过来。
尤其对于创业团队，时间窗口比什么都宝贵。能用现成的 API 拿到生产级效果，就意味着可以把有限的工程师资源投到产品差异化上，而不是跟音频格式和网络延迟搏斗。
不是终点，而是语音应用的起跑枪
谷歌的野心不止于转写
Gemini 3.5 Transcribe 不难让人想到谷歌更大的棋盘。从 Google Meet 实时字幕到 Android 语音交互，转写只是底层，上层才是真正的故事。一个更准、更快的转写模型，能把开发者更深地吸进自家生态。
医疗里的医嘱实时记录、教育里的口语评测、直播电商里的互动字幕，这些场景都需要在低延迟下嵌入高并发转写。谷歌现在做的，正是这种基础设施级铺垫。
当转写不再是瓶颈，语音应用的想象力自然会打开。很多过去因为“识别不准”而被否决的产品，试着换用新模型后，会发现整个交互逻辑都不一样了。
实时语音的爆发前夜
语音技术从来不缺想象力，缺的是让想象力落地的那口气。Gemini 3.5 Transcribe 把准确率和延迟同时推到生产线，正在把那口气补齐。接下来的竞争焦点，也许会从“谁的模型更聪明”转向“谁的管线更顺畅”。
这是模型战，也是工程战，更是场景战。模型能力到一定程度，拼的就是谁接入快、谁调教好、谁把 API 用出花来。Gemini 3.5 Transcribe 手里攥着好牌，但最终打成什么样，还是看开发者怎么玩。
无论如何，语音交互的临界点看起来越来越近了。那些还在观望的人，该认真评估一下自己手里的应用，能不能接住这波红利。
