Google发布Gemini 3.5 Transcribe语音转文本模型

这里最具意义的细节并非功能本身，而是一项产品结构决策。评论指出，这是首款真正作为Gemini模型销售的Google语音转文本系统，共享与其他Gemini系列产品相同的API接口，包括原生函数调用能力，而不是归属于独立的Cloud Speech产品线^[1]。Google上一代ASR模型Chirp 3是在Vertex AI下作为独立产品发布的；而Gemini 3.5 Transcribe则被明确视为Chirp 3的直接继承者，但这种继承关系不仅是代际演进，更是架构层面的延续^[2]。实际上，这意味着开发者若已在使用Gemini进行文本或多模态推理，现在可通过同一API密钥和接口添加语音转录及由函数调用驱动的语音操作，而无需再单独接入Cloud Speech服务。此举将语音转录重新定义为旗舰模型系列的一项核心能力，而非附加工具——这一战略举措与Google长期以来将其他模态逐步整合进Gemini的做法如出一辙。

Gemini 3.5 Transcribe实际上以两个针对不同任务优化的独立端点发布：Live API使用模型gemini-3.5-transcribe-live处理实时流式音频，而Interactions API使用gemini-3.5-transcribe处理预录制或批量音频^[2]。这种区分直接体现在Google公布的基准数据中：流式转录的平均词错误率为4.0%，而非流式（批量）转录则明显更优，平均WER仅为2.6%，反映出速度与模型在最终输出前修订能力之间的权衡^[3]。在延迟方面，流式版本在语音结束仅0.40秒后即返回最终转录结果——有分析认为，这一数字正是决定语音代理供应商能否赢得企业合同的关键指标^[4]。这种组合——一条真正快速的流式路径加上一条更高精度的批量路径，同属一个模型家族——构成了其核心工程策略：Google并未只选择一种运行模式，而是发布了同一底层模型的两种优化变体。

在宣传数据中容易被忽视的一项能力是，Gemini 3.5 Transcribe不仅‘听’，在Google Antigravity设备上还会‘看’。在获得用户许可的前提下，该模型会结合屏幕内容和聊天历史，提升对文件名、代理思维过程和当前文档等信息的转录准确性^[5]，有效利用视觉和对话上下文作为消歧信号，就像人类速记员会借助周围语境来推断陌生词汇一样。在多说话人场景中，该模型可在预录制音频中为最多三位说话人标注发言时间戳，超过三人的情况仍被标记为实验性功能——对于计划将其用于小组会议或论坛录音而非一对一通话的用户而言，这是一个重要的限制条件^[5]。其发布策略进一步强化了“表面感知”这一特点：该模型已驱动Pixel 11系列手机上的Rambler听写功能和macOS版Gemini应用，未来还将通过Chrome浏览器实现网页表单字段的语音输入^[6]。

此次发布的市场宣传与其外部检验结果之间存在明显张力。Google宣称的70%延迟降低和WER数据，均源自其自身发布材料中引用的Artificial Analysis测量结果；独立评论指出，目前尚无第三方对开源权重的转录模型进行对抗性对比测试^[2]。此外，其他报道提到，在原始准确性方面，Gemini 3.5 Transcribe仍落后于专业竞品：ElevenLabs的Scribe v2和微软的MAI-Transcribe-1.5均被报告拥有更低的词错误率^[1]。社区反馈也呈现出类似的分歧判断而非统一结论。在X平台上，此次发布获得了大量官方推广——Sundar Pichai和Google官方账号均直接宣传，至少有一位拥有早期Google DeepMind访问权限的独立开发者报告已基于该模型构建并上线了一款应用，显示出开发者群体的真实热情。在YouTube上，观看量最高且最具权威性的视频是Google官方的开发者演示，将此次发布明确定位为面向开发者的API优先发布；虽然也有第三方评测，但均为当天新鲜内容。在Reddit上，舆论更为审慎和好奇而非狂热——一个帖子发现该模型在一项难度较高的芬兰语测试中优于Whisper和GPT-transcribe，而另一位用户的并排测试则显示AssemblyAI表现更佳，评论者也确认该模型已在Gboard的Rambler听写功能中上线。综合分析师评论、官方推广和社区实测来看，Gemini 3.5 Transcribe真正的优势似乎在于低延迟、API集成度和以开发者为中心的定位，而非在准确性上取得无可争议的全面胜利。