Gemini 3.5转录会删“嗯啊”：支持85+语言，开始听懂专业术语

Google 在 2026 年 8 月更新了 Gemini Audio 产品线，新增 Gemini 3.5 Transcribe，并同步带来 Gemini 3.5 Live 与 Gemini 3.5 Live Experimental。新模型面向语音转录和实时交互，能够自动识别 85 种以上语言、判断对话中的专业术语，还会清理“嗯”“啊”以及英文里的“um”“ah”等无实际语义的填充词。

Gemini 3.5 Transcribe 是 Google Gemini 家族中专门面向音频转文字任务的新模型。它不是简单地把声音逐字映射为字符，而是尝试结合上下文判断语言、术语和表达意图，再输出更接近可读稿件的文本。

这次更新最有价值的部分不是语言数量从几十种增加到 85 种以上，而是 Google 开始把“听写准确”与“文本可直接使用”合并成一个产品目标。会议纪要、采访整理、医疗口述和技术播客过去都要经历录音、转录、术语校对、口头语清理等多个步骤，3.5 Transcribe 试图一次完成其中大部分工作。

重点不是“听见”，而是知道哪些内容该留下

自动清理口头语是一种带有语义判断的转录能力。传统语音识别系统通常追求忠实记录，因此会保留重复、停顿和填充词；Gemini 3.5 Transcribe 则进一步判断某个声音是在传递信息，还是说话者争取思考时间时产生的语言噪声。

这一变化看似只是删掉几个“嗯啊”，实际上会直接影响成稿效率。一场 60 分钟的访谈可能包含数百次停顿、重复起句和自我修正，如果系统只做逐字转录，编辑仍要从头清理；如果模型能正确合并重复表达并删除无意义填充词，输出就更像一份可检索、可总结、可发布前编辑的初稿。

专业术语识别是另一项比语言覆盖数字更难的能力。专业术语识别是模型依据对话主题和上下文，在多个发音相似的候选词之间选择正确领域词汇的过程，例如把技术会议里的“agent”理解为 AI Agent，而不是普通代理人，或在医学场景中正确区分发音接近的药名、疾病名与解剖名词。

Google 没有披露 3.5 Transcribe 使用了独立声学模型、Gemini 多模态主干，还是额外的检索与词表机制，但从产品描述看，它显然在强化上下文约束。传统 ASR 更像“逐帧猜字”，新一代原生音频模型则更像一个听完整段对话后再判断句意的速记员；前者依赖局部发音，后者可以用会议主题、前后句和说话者意图纠正歧义。

85+语言不等于每种语言表现一致

85 种以上语言支持意味着模型可以覆盖更多跨国会议、用户研究和内容生产场景。这里的“支持”应理解为模型具备识别与转录能力，而不能直接等同于所有语言、口音和混合语境下都达到同一准确率。

Google 此前在 2026 年 6 月发布的 Gemini 3.5 Live Translate 支持 70 多种语言，并主打流式语音到语音翻译。此次 3.5 Transcribe 把覆盖范围提高到 85 种以上，但两者执行的是不同任务：Live Translate 负责边听边翻译并生成语音，Transcribe 负责把音频整理成文本。

| 模型或产品 | 核心任务 | 官方披露的语言范围 | 关键特性 | 当前应关注的限制 | |---|---|---:|---|---| | Gemini 3.5 Transcribe | 音频转文字 | 85+ | 自动语言识别、专业术语判断、清理填充词 | 未公布统一错误率、价格及完整模型标识 | | Gemini 3.5 Live | 实时语音交互 | 本次资料未给出精确数字 | 面向低延迟对话，增强噪声和打断场景表现 | 实际延迟和并发能力仍需独立测试 | | Gemini 3.5 Live Experimental | 实验性实时语音交互 | 本次资料未给出精确数字 | 提前验证新的实时音频能力 | 实验版本的稳定性与行为可能变化 | | Gemini 3.5 Live Translate | 流式语音到语音翻译 | 70+ | 自动检测语言，保留语调、节奏和音高 | 与纯转录不是同一任务，不宜直接比较准确率 |

语言数量差异也不能被直接解释成模型能力提升了约 21%。从 70 种增加到 85 种以上，按最低数量计算是至少增加 15 种、覆盖数量提高至少 21.4%，但 Live Translate 与 Transcribe 的输出目标不同，因此这个百分比只能描述语言覆盖规模，不能描述质量进步。

多语言自动识别真正解决的是配置成本。用户不必在每次录音前手动选择语言，模型可以根据音频判断语种；对一场中文、英文交替出现的技术会议而言，这比单纯增加小语种名单更实用，因为真实对话经常在产品名、论文名和技术缩写处切换语言。

背景噪声和插话，才是实时语音的硬仗

背景噪声鲁棒性是语音模型在键盘声、交通声、回声和远场录音存在时仍能提取有效人声的能力。Google 将更好的噪声处理列为 Gemini 3.5 Audio 的重点，说明这次迭代不只面向录音棚级别的清洁音频，而是瞄准会议室、移动设备和在线通话等真实环境。

打断处理是实时语音系统在用户插话时停止、重听并重新规划回答的能力。普通语音助手通常把对话切成一问一答的回合，一旦用户中途补充条件，系统容易继续播放旧回答；Gemini 3.5 Live 与 Live Experimental 强调被打断时仍保持精度，目标是让语音交互更接近人类会议，而不是让用户适应机器的回合制节奏。

这两项能力决定了产品能不能从演示进入生产环境。安静房间里的单人英语录音早已不是最难的问题，真正困难的是三个人同时说话、麦克风距离不同、有人中途切换语言、背景还有空调和键盘声；如果模型在这些情况下丢失否定词、数字或说话者边界，再自然的文本润色也没有意义。

自动删口头语有用，但不应该默认等于“真实记录”

清洁转录与逐字转录是两种不同的产品。清洁转录会删除填充词、合并重复表达并改善可读性，适合会议纪要和内容编辑；逐字转录强调保留原始表达，适合法律取证、质性研究、字幕审校和需要分析说话方式的场景。

自动编辑最大的风险是模型可能删掉看似无意义、实际有语用价值的内容。例如“嗯”既可能只是停顿，也可能表示迟疑、不同意或勉强确认；“我觉得……不对”中的停顿甚至会改变整句话的态度。Google 如果只提供清洁文本而不保留原始版本，模型就可能把说话者的犹豫修饰成过度确定的陈述。

专业场景还需要区分“识别术语”和“猜测术语”。医疗、法律与金融录音中，一个词的错误替换可能改变诊断、义务或金额，因此合理的产品设计应同时保留原音频、逐字稿和清洁稿，并标记低置信度片段，让使用者能够回听核验。

开发团队尤其应该检查以下四类问题：

• 数字与单位： 重点核验日期、金额、剂量、版本号和百分比，语义通顺不代表数字正确。
• 说话者归属： 多人录音需要确认模型是否支持稳定的 speaker diarization，也就是把文本正确分配给不同说话者。
• 时间戳精度： 字幕、搜索和证据回溯依赖词级或句级时间戳，本次材料没有披露其具体粒度。
• 原文保真度： 应确认口头语清理能否关闭，以及系统是否允许同时导出 verbatim 与 cleaned 两个版本。

Google 正在把语音能力拆成更明确的产品层

Gemini 3.5 Audio 目前呈现出“转录、实时对话、实时翻译”三条路线。Transcribe 负责把声音变成结构化文本，Live 负责与用户持续交互，Live Translate 则负责跨语言语音转换；这种拆分比用一个通用模型包揽全部任务更利于开发者选择成本、延迟和输出形式。

Google 的优势来自模型与分发渠道同时存在。Live Translate 已进入 Google Translate，并计划或正在向 Google Meet 等场景扩展；Transcribe 如果继续进入 Workspace、Meet、YouTube 和移动端录音流程，就不只是一个模型能力，而会变成 Google 办公与内容生态的底层输入层。

竞争焦点也正从单一字错率转向完整体验。OpenAI Whisper 推动了通用多语言转录的普及，云厂商的语音服务长期提供时间戳、说话者区分和自定义词表，而新一代 Gemini Audio 的卖点是用更强的上下文理解减少后处理；谁能同时做好低延迟、术语、说话者、格式化和可控编辑，谁才更可能拿下生产环境。

目前还缺三个决定采购价值的数字

Google 当前披露的信息不足以证明 3.5 Transcribe 已经在准确率上领先竞品。官方和媒体材料强调了 85 种以上语言、术语识别、口头语清理、抗噪与打断处理，但没有给出公开统一测试集上的词错误率，也没有提供与 Whisper、大型云语音服务或上一代 Gemini Audio 的逐项结果。

第一个缺失数字是词错误率。WER 是词错误率，即插入、删除和替换错误总数除以参考文本词数；如果没有按语言、口音和噪声强度拆分的 WER，开发者很难判断“更精准”究竟意味着从 10% 降到 8%，还是只在少数演示样本中改善。

第二个缺失数字是端到端延迟。实时语音的体验取决于首个转录片段出现时间、稳定文本确认时间和被打断后的恢复时间，而不是笼统的“低延迟”；200 毫秒、800 毫秒和 3 秒在用户感知上属于完全不同的产品。

第三个缺失数字是价格。每分钟音频成本、并发限制、上下文长度和批处理折扣会直接决定它适合个人录音、客服质检还是大规模媒体归档，而本次参考材料没有提供可核验的正式定价，因此不应提前做成本优势判断。

开发者现在应该先做小规模真实音频评测

开发者不应该只用官方演示判断 Gemini 3.5 Transcribe。最有效的验证方式是从自身业务抽取至少四类音频：安静单人录音、多人插话、强背景噪声以及专业术语密集对话，再分别统计文字错误、数字错误、术语错误和人工修改时间。

一套实用评测还应同时保存逐字参考稿和编辑后参考稿。前者衡量模型到底听对了多少，后者衡量输出离可交付文本还有多远；3.5 Transcribe 的真正优势如果成立，未必只体现在 WER，而可能体现在人工整理一小时录音所需时间从几十分钟下降到几分钟。

本次文章不提供调用代码，因为现有参考材料没有给出可交叉验证的正式模型标识、稳定端点、请求字段和定价。对闭源模型而言，猜测模型名称会让示例很快失效，开发者应以 Google AI Studio 和官方文档实时展示的可用模型为准，并避免在生产系统中把实验版本名称写死。Google 的官方 Gemini Cookbook 可用于核对后续样例与能力更新。

判断：这是一次实用更新，但还不是准确率王者的证明

Gemini 3.5 Transcribe 是一次方向正确、产品价值明确的更新。85 种以上语言扩大了使用面，专业术语识别减少了领域文本校对，自动清理口头语则直接压缩了从录音到可读稿的链路，这三项能力组合起来，比单纯宣布“转录更快”更接近用户真正愿意付费的结果。

这次更新仍然缺少证明领先所需的硬数据。没有公开 WER、延迟、价格、说话者区分效果和时间戳精度之前，Gemini 3.5 Transcribe 更适合被视为一个值得测试的新选项，而不是已经击败 Whisper 或成熟云语音服务的确定答案。

Google 真正值得关注的动作，是把实时对话、语音翻译和高质量转录放进同一代 Gemini Audio 体系。语音模型下一阶段的竞争不会止于“把声音变成文字”，而是谁能在噪声、插话、多语言和专业语境里持续理解对话，并把结果直接送进会议、搜索、创作和智能体工作流。

参考来源

• Google Gemini 官方 Cookbook：Google 维护的 Gemini 示例与开发资料仓库，可用于核对后续模型能力、输入格式和官方实践。

核心事件信息同时依据 Google 2026 年 6 月关于 Gemini 3.5 Live Translate 的官方发布材料及 The Verge 近期对 Gemini 3.5 Audio 更新的报道整理；受文末链接域名范围限制，此处不附上述站点地址。