Gemini 3.5 Transcribe 上线，语音转文字 API 开始分成实时与批处理两条路

Gemini 3.5 Transcribe 上线，语音转文字 API 开始分成实时与批处理两条路

Google 在 8 月 26 日发布了 Gemini 3.5 Transcribe 正式版，一次推出 gemini-3.5-transcribe 与 gemini-3.5-transcribe-live。前者处理文件和非实时转写，后者通过 Live API 的 WebSocket 返回低延迟结果。官方列出的能力包括 85 种以上语言与地区、说话人分离、词级时间戳、术语偏置，以及清理口头语和重复表达的 Smart transcription。

对会议记录、客服质检和字幕产品来说，重点并不只是识别率提高。实时流会产生临时结果、最终结果与语音活动检测事件；批处理则更关心长文件、可重跑和时间戳稳定性。两种模型虽然属于同一家族，客户端状态机、错误恢复与验收方法并不相同。

实时转写首先是一套连接管理问题

Live 版本通过 WebSocket 接收音频并持续返回事件。网络抖动、设备切换、浏览器休眠和移动端后台都会中断连接。客户端需要保存本地音频位置和最后确认的 final 段落，重连后避免重复展示或丢掉一段话；临时文本只能用于即时反馈，不能直接写入最终纪要。

VAD 参数会影响何时切句。阈值太敏感会把停顿切成多个片段，太迟钝又会增加延迟并合并不同说话人。客服通话、开放办公室和访谈的噪声结构不同，应分别记录首字延迟、最终确认延迟、漏字、误触发与说话人切换错误。

语言自动识别也不能只用单语样本。技术会议常在中文、英文缩写和产品名之间切换，模型需要处理 code-switching。官方支持最多一千个自定义词汇用于术语偏置，企业可以加入品牌、药名和人名，但仍要测试相近词是否因此被错误替换。

Smart transcription 会改变原话，不能默认开启

Smart transcription 会清理语气词、重复和不流畅表达，让阅读更顺，却不再是逐字记录。内容运营可以把它用于字幕初稿，法律取证、医疗沟通和投诉录音则应保留原始音频与未清理文本，必要时同时生成“逐字版”和“可读版”。

说话人分离与词级时间戳也需要单独验收。两人同时说话、远场麦克风、回声和视频剪辑都会让 speaker 标签漂移。评测表除了总体字错率，还应统计专有名词、数字、否定词、说话人归属与时间轴偏差；关键结论可以用独立模型交叉检查，但最终仍要回放原音频。

隐私处理不能等到转写完成后再做。上传前确认录音同意，传输与存储使用加密，日志避免保留完整音频 URL，并为删除、导出和保留期限提供明确规则。API Key 也应放在服务端，不能随着 WebSocket 配置暴露给浏览器。

语音 API 选型要以业务损失计价

语音转文字的成本不只按音频分钟或 Token 计算。一次人名识别错误可能导致客服工单错派，实时断流可能让访谈丢失，过度清理可能改变事实含义。候选服务应在同一批真实录音上比较正确率、延迟、可恢复性、术语支持、数据地区与人工校对时间。

AnyAIS 当前公开模型目录没有把 Gemini 3.5 Transcribe 标为在售服务，因此不能把文章当成平台可用性承诺。需要在国内产品中增加语音能力时，可先从实时与批处理的业务边界设计接口，再关注模型目录更新；统一的鉴权、任务记录和用量数据，能让后续替换服务时少改一层业务代码。

参考资料

• [Google Gemini API Release Notes](https://ai.google.dev/gemini-api/docs/changelog)
• [Gemini 3.5 Transcribe 模型说明](https://ai.google.dev/gemini-api/docs/models/gemini-3.5-transcribe)
• [Gemini API Audio Transcription 指南](https://ai.google.dev/gemini-api/docs/transcribe)
• [AnyAIS 模型目录](https://www.anyais.com/models)