语音识别这门技术，看起来人人都懂，做起来处处是坑。Google DeepMind 新发布的 Gemini 3.5 Transcribe，则把这个细分赛道重新推到了聚光灯下。先说几个数字：流式平均词错率 4.0%，非流式 2.6%，相比上一代 Chirp 3，流式词错率降到了 4.0%，最终转录延迟改善了 70%。这串数据放在今天的大模型叙事里不算惊艳，但放到语音转文本的具体场景中，分量完全不同。
4% 的词错率，真不是刷出来的
流式与非流式的差别，藏在交付逻辑里
流式 API 和非流式 API 的服务逻辑截然不同。流式意味着音频一边进来，结果一边吐出，适合实时字幕、语音代理这类必须“边说边出”的场景；非流式则是等整段音频收齐再统一解码，追求的是最终文本的极致准确。Gemini 3.5 Transcribe 把流式词错率压在 4.0%，非流式压到 2.6%，二者之间的 1.4 个百分点差距，恰好暴露了实时性对识别质量的天然损耗——但这损耗已经小到让产品经理们愿意赌一把。
把 70% 的延迟砍掉，到底动了哪根神经
延迟改善 70%，不是简单的工程优化，而是解码路径的重新设计。上一代 Chirp 3 的流式方案，仍带着半同步的包袱；Gemini 3.5 Transcribe 则更激进地把流式解码打散到语音流推进的过程中，让系统在用户说完一个完整意群之前就提前产出中间假设。感知层面，语音代理的响应节奏从“机械感”向“对话感”挪了一大步；基建层面，每 100 小时音频省下的等待时间，足以改变实时字幕方案的成本结构。
多语言这件事，远不止“支持”两个字
85 种语言背后的工程底气
对大多数云厂商来说，“支持 85 种语言”这行字，背后是训练数据、音系模型、文字系统三座大山。梵文、斯瓦希里语、冰岛语这些低资源语言，不可能靠堆 GPU 就能硬扛过去；必须有一套足够聪明的跨语种表征，才能让模型在数据稀疏时依然保持稳定。Gemini 3.5 Transcribe 把这件事做成了产品默认值——用户不需要为“小众语言”单独付费，这让全球化的实时字幕和会议转录产品，第一次可以把长尾市场纳入规划。
自定义词汇：当 AI 开始学你说话
专有名词、行业术语、人名地名，历来是语音识别翻车的重灾区。Gemini 3.5 Transcribe 提供的自定义词汇能力，允许开发者在 API 调用时注入热词列表，对特定词条做权重偏置。听上去简单，实际很考验平衡能力：热词权重调太高，会把常见词误判成专名；调太低，等于没调。这意味着接入方可以把“DeepMind”“Gemini 3.5”这类词扔进去，让识别结果精准度再上一个台阶。对医疗、法律、金融这些术语密集的垂直行业，这项功能可能比词错率数字本身更具吸引力。
说话人识别：会议记录的下一个拐点
最多支持三人说话人识别，这项能力放在会议转录场景里，正好踩中痛点。线下会议室、远程访谈、播客录制——常见语音环境通常就两到三个人交替说话，单声道音频能自动区分“谁在说”，就足以让转写文本从“一段话”变成“一场对话”。过去这种功能要单独买昂贵的音频分析服务，现在 Gemini 3.5 Transcribe 直接内置，模型的交付逻辑正在悄悄改变行业分工。
语音代理与实时字幕，正挪向 AI 红利区
Chirp 3 退位，Gemini 3.5 Transcribe 补位
不能只看绝对数字提升，还要看相对成本。上一代 Chirp 3 的流式词错率更高，延迟也更为明显；如今 Gemini 3.5 Transcribe 在质量和时延上双杀，等于替开发者把“要实时还是要准确”这道二选一的选择题划掉了。更关键的是，这种更替发生在同一家公司的同一产品线上——说明这不是堆参数的蛮力胜利，而是模型架构和训练策略的系统性升级。
成本、质量与体验的三角博弈
语音代理类的产品，长期卡在一条隐形的边界线上：转录质量不够，下游大模型就会基于错误文本“一本正经地胡说八道”；转录延迟太高，用户等三秒才看到字幕，体验立刻归零。Gemini 3.5 Transcribe 同时压低词错率和延迟，相当于把这条边界线往外推了一大截。实时字幕服务商可以放心地把流式 API 作为默认选项，语音代理开发者也能省掉那层“先录完再转写”的笨拙缓存。归根结底，语音交互迈向自然化的路上，少一个数字陷阱，就多一分可用性。
