Gemini 3.5 Transcribe 发布：开发者如何把实时语音转写接进应用

做会议字幕或语音客服时，最难的往往不是把音频送进模型，而是先判断自己需要“边说边出字”，还是等录音结束后再做带说话人和时间信息的整理。Google 在 2026 年 8 月 26 日发布 Gemini 3.5 Transcribe，把这两类需求拆成了两条 API，开发团队可以按交互时延和后处理要求选入口。

需要实时反馈，就从 Live API 的 gemini-3.5-transcribe-live 看起；需要录音归档、说话人标注或词级时间戳，则优先评估 Interactions API 的 gemini-3.5-transcribe。先做字段和延迟验收，再决定是否扩大接入范围。

这次发布先解决了哪种开发现场

一场产品评审里，实时字幕要跟着发言滚动；会议结束后，运营又要拿到按说话人分段的文本。过去这两项经常被塞进同一个“语音识别接口”里，结果是实时链路背上了归档需求，归档链路又被迫追求交互级延迟。

Google 官方把 Gemini 3.5 Transcribe 描述为面向实时语音交互的语音转写模型，并明确给出了两种用法：Live API 提供持续的双向流式处理，Interactions API 面向录音、会议和通话记录。这个拆分比单纯增加一个模型名称更值得关注，因为它直接影响客户端连接方式、结果落库和验收指标。

两条 API 的边界要先画清

实时流式：字幕和语音代理优先看 Live API

需要用户边说边看到结果时，选用 Live API 的 gemini-3.5-transcribe-live。它对应持续、双向的流式会话，适合实时字幕、语音代理和需要快速反馈的交互。验收时应单独记录首个可用片段、连续输出是否稳定，以及网络短暂抖动后的恢复表现。

录音处理：归档和分析关注结构化结果

已有会议录音、客服通话或访谈文件时，Interactions API 的 gemini-3.5-transcribe更匹配任务。官方列出了说话人归属和词级时间戳，这些字段对检索、质检和回放定位比单一纯文本更有价值。它不等于自动完成业务分析，后续的敏感词、工单关联和人工复核仍应由应用自己负责。

发布信息里哪些能力值得做小实验

第一项是自定义词汇。制造、医疗、金融和内部项目都有一批普通词典不容易识别的名称，接入前可以准备一份包含产品名、订单号格式和缩写的测试音频，比较加入 custom vocabulary 前后的错误类型。不要只看总字数正确率，专有名词错一次可能比口头语漏掉几次更影响业务。

第二项是语言和说话人边界。官方页面写明模型可自动检测并转写 85 种以上语言，并支持录音中最多三位说话人的标注，三位以上仍是实验性支持。多语言会议要把口音、混说和专有名词放在同一组样本里；超过三人的圆桌录音，则应提前决定是否接受人工复核。

第三项是结果格式。词级时间戳应该真的能把字幕跳转到音频位置，而不是只在接口返回里存在一个没人消费的字段。说话人标注也要经过“人声角色是否稳定、交叉发言如何显示、低音量片段如何处理”的验收。

从公开预览到业务接入，建议按四个检查点推进

先把场景分成实时与离线

给每类音频建一份最小样本：实时场景记录网络条件和交互时延，录音场景保留原始音频、期望文本和说话人标记。两类样本不要混用，否则出了问题很难判断是链路时延还是转写质量。

再验收业务字段，不只验收文字

除了文本内容，还要检查自定义词汇是否生效、说话人标签能否稳定、词级时间戳是否可用于回放。对订单号、型号和人名建立单独错误清单，按错误类别复核，而不是只看一个平均数字。

小流量接入时保留回退路径

官方发布页把 API 标成 public preview，接口行为、配额或可用范围都不应被当作永久不变的生产契约。小流量阶段保留原有转写服务或人工上传入口，给每次调用记录模型名、请求时间、音频时长、结果状态和复核结论；当新链路超时或字段缺失时，业务仍能完成。

最后才扩展到复杂语音场景

先从单人、安静环境和固定词表开始，再加入多人交叉发言、方言、背景噪声和中途纠正。官方还提到模型可以处理自我修正、填充词清理和自动格式化，这些能力要用真实录音验证，不能仅凭发布页中的示例推断在自己的行业里同样稳定。

几个容易把新闻结论用过头的地方

官方页面引用了第三方 Artificial Analysis 的 WER 与最终转写耗时数据，这些数字可以帮助理解发布方强调的方向，但不能直接当作你的业务 SLA。噪声、语言、麦克风、音频切分和后处理都会改变结果。

同样，支持 85 种以上语言不代表每种语言在每个口音和领域词汇上都达到相同水平；最多三位说话人的标注也不等于多人会议无需人工确认。把公开预览能力接入生产时，最稳妥的做法是保留样本回放和人工抽检。

相关问题

实时字幕应该选哪条 API？

优先评估 Live API 的 gemini-3.5-transcribe-live，因为它面向持续的双向流式交互。

录音转写能直接得到说话人和时间吗？

官方发布页说明录音处理路径支持说话人归属和词级时间戳，但仍要用自己的音频验证标注稳定性。

公开预览可以直接替换线上服务吗？

不建议一次性替换。先做小流量和回退，记录结果字段与错误，再依据真实样本扩大范围。

把“能用”变成可验收的接入计划

Gemini 3.5 Transcribe 的新闻价值不只是模型名变新，而是把实时交互和录音整理的产品路径分开，并把自定义词汇、说话人归属、词级时间戳等能力放进同一套评估框架。开发者先选对 API，再用真实音频检查字段、延迟、噪声和回退，才能知道这次发布是否真的适合自己的业务。