Google 发布 Gemini 3.5 Transcribe：语音转写开始从“听见”走向“理解”

Google 于8月26日发布 Gemini 3.5 Transcribe，一款强调“理解”而非仅“听见”的语音转写模型，支持实时和录音两条API路径，能处理自我纠正、填充词、专业术语和多人对话并输出格式化文本。开发者可通过 Gemini API 和 Google Cloud 平台调用，适用于实时语音代理、会议转写与企业工作流集成，同时需在具体环境中独立评估准确率与合规性。

Google 于8月26日发布 Gemini 3.5 Transcribe，称其为目前精度最高的语音转文字模型之一。与主要把语音转换为文本的传统自动语音识别系统不同，这一模型试图在转写过程中理解说话人的意图，处理自我纠正、口头语、专业词汇和多人对话，并直接输出经过整理和格式化的文字。

Google表示，Gemini 3.5 Transcribe 已经用于 Gemini 应用、Android 上的 Rambler 以及 macOS 版 Gemini 的语音功能。现在，开发者可以通过 Gemini API 和 Google Cloud 的 Gemini Enterprise Agent Platform 构建类似的语音交互产品。

同一个模型分成实时与录音两条路径

Google没有把所有语音任务放在同一个接口中，而是为不同使用场景提供两种API路径。

第一种是面向实时语音应用的双向流式转写，通过 Live API 调用 gemini-3.5-transcribe-live。Google称，该模式提供连续的双向音频流，延迟低于一秒，面向语音代理、实时字幕和其他需要边说边处理的应用。

第二种是面向预录音频的处理接口，通过 Interactions API 调用 gemini-3.5-transcribe。它可以处理会议录音、客服通话记录和其他音频文件，并提供说话人归属以及逐词时间戳。Google DeepMind 的 Gemini Audio 产品页称，3.5 Transcribe支持85种以上语言，并可在预录音频中识别最多三名说话人；超过三名说话人的识别目前仍属于实验性支持。

这种区分反映出语音产品的两个不同需求：实时系统优先考虑延迟和连续交互，录音处理则更重视准确率、结构化结果和事后分析。对于开发者来说，接口和模型名称的拆分也意味着可以根据工作流选择不同的成本、延迟和输出方式。

Google强调对口语和上下文的处理能力

Gemini 3.5 Transcribe 的主要卖点并不是单纯降低字错误率，而是让转写结果更接近可直接使用的文字。

Google举例说，模型能够处理“我们周二见——不，周三”的自我纠正，删除“嗯”“啊”等填充词，并自动整理文本格式。它还支持自定义词汇，使开发者可以向模型提供专业术语、特殊拼写以及企业内部使用的名称。

这类能力对客服、医疗、法律、金融和工程场景尤其重要。在这些场景中，转写结果是否保留订单号、邮政编码、药名、产品编号或其他字母数字组合，往往比普通句子的可读性更直接地影响后续工作。Google称，Gemini 3.5 Transcribe在噪声环境中也针对这类字母数字实体进行了优化。

在 Gemini macOS 应用中，模型还被用于更完整的语音工作流。用户可以通过自然语言口述内容，让系统清理口语并把结果写入当前光标位置；在获得许可后，Gemini还可以结合屏幕上下文，对本地文件和文档进行摘要、改写或触发图像生成等任务。AIFlux此前对Google为 macOS 版 Gemini 加入自然说话能力的报道显示，Google正把语音输入与桌面上下文和跨应用操作结合起来，而不只是把它当作传统听写工具。

Google还表示，Gemini 3.5 Transcribe可以通过函数调用把复杂任务交给其他 Gemini 模型。目前，这项能力已在 macOS 版 Gemini 应用中使用。这使语音输入从“把话写下来”进一步延伸到“根据口述执行任务”，但相关功能仍取决于具体产品的权限和集成方式，并不意味着API本身会自动完成所有桌面操作。

WER数据亮眼，但需要区分测试条件

按照Google引用的 Artificial Analysis 测量结果，Gemini 3.5 Transcribe 在流式场景的平均词错误率（WER）为4.0%，非流式场景为2.6%。Google同时称，模型相较此前的 Chirp 3，在最终转写结果出现前所需的时间缩短了70%。

Google还给出了FLEURS多语言基准上的结果：流式模式的WER为5.50%，非流式模式为5.04%。这些数字显示，实时转写和预录音频处理之间仍存在准确率差异，不能把不同测试模式下的结果直接放在一起比较。

此外，WER只反映文字错误，并不能完整衡量一个语音系统在真实环境中的表现。背景噪声、说话人重叠、口音、停顿、数字和专有名词，都可能在实际部署中改变结果。AIFlux此前介绍的 Hume Real World VoiceEQ 语音评测就指出，语音AI的能力通常是分维度的：一个系统可能在准确复述上表现良好，却在情绪、自然度、噪声或长对话稳定性上并不占优。

因此，Google公布的WER和延迟数据更适合作为模型发布时的性能锚点，而不是对所有设备、语言和录音条件的普遍承诺。开发者仍需要在自己的音频、行业术语和隐私环境中独立测试。

从通用语音模型到可组合的工作流组件

Gemini 3.5 Transcribe的另一个变化，是它被设计成更容易嵌入现有语音产品，而不是只作为一个独立的转写页面存在。

实时语音代理可以使用流式模型接收用户语音，再把转写结果交给对话模型和工具调用系统；会议和客服平台则可以用非流式模型生成带有说话人和时间戳的记录，再交给语言模型完成摘要、分类、质检或信息抽取。转写、理解和执行被拆成不同环节后，企业可以分别控制它们的模型、权限和成本。

这一思路与语音系统近年来的模块化趋势相吻合。AIFlux此前报道的 IBM Granite Speech 5.0 TurboCTC则代表了另一条路线：用更小的专用ASR模型追求高吞吐量和边缘部署能力。相比之下，Gemini 3.5 Transcribe更强调上下文、语言覆盖、说话人识别和与其他模型协作的能力。

这两种方向并不完全相互替代。大量录音的离线转写可能更适合轻量、快速的专用模型；需要实时交互、复杂术语、跨语言处理和后续任务执行的产品，则可能更看重上下文能力和接口整合。随着语音AI进入企业工作流，竞争重点也可能从“谁的模型最大”转向“哪一种组件组合更适合具体任务”。

开发者和企业目前可以如何使用

Google表示，Gemini 3.5 Transcribe已面向开发者在 Google AI Studio 中的 Gemini API 公开预览，并可通过 Google Antigravity 使用。企业用户可以在 Gemini Enterprise Agent Platform 的公开预览中访问它，未来还将进入 Gemini Enterprise for Customer Experience。

对普通用户而言，相关能力已经以产品功能的形式出现在不同入口：macOS 版 Gemini目前支持英语语音功能，Android上的 Rambler则在部分国家和语言中提供；Chrome版本的网页语音输入功能仍处于“即将推出”状态。

Google称，模型可以自动识别并转写85种以上语言，但目前公布的消费者功能并非所有语言和地区同时开放。企业在采用前还需要确认数据处理区域、音频保留政策、权限设置以及行业合规要求。尤其是在医疗、客服和会议场景中，准确转写并不等于可以不经人工审核地直接用于决策或对外发送。

Google没有在此次发布中把Gemini 3.5 Transcribe描述为解决所有语音识别问题的通用方案。它更像是Gemini音频模型家族中的一个专用组件：一方面提高原始语音到格式化文本的质量，另一方面为实时代理、桌面助手和企业分析流程提供更易连接的入口。

语音AI下一阶段的关键，可能不只是把每个词听对，而是能否在真实噪声、多人对话和复杂工作上下文中，稳定地理解用户要表达什么，并在获得明确授权的前提下完成下一步工作。

新闻来源

• Google：Intelligent transcription with Gemini 3.5 Transcribe
• Google DeepMind：Gemini Audio
• Google AI for Developers：Audio understanding