我们为何将 Deepgram + Google Translate 替换为 ElevenLabs Scribe v2 + Gemini 2.5

2026年5月

本文是103语言发布公告的幕后补充。如果那篇是"这是我们改变了什么",那这篇就是"这是我们为何选择这些供应商"。核心成果:语言覆盖范围大约翻倍、语音识别延迟更低、具备对话上下文的翻译,以及支持74种语言的实时AI语音播放。

我们为何更换供应商

旧技术栈使用 Deepgram 进行语音识别,使用 Google Cloud Translation 作为翻译层。上线时表现稳定,瓶颈在于语言覆盖范围。Deepgram 的流式模型在生产质量下支持约40–50种语言,而语言列表的增长速度远跟不上用户的需求——他们要求支持孟加拉语、泰米尔语、泰卢固语、马拉地语、粤语(作为有别于普通话的独立条目)、缅甸语、高棉语、威尔士语、希伯来语等更多语言。

第二个压力来自输出端。我们希望推出Audio mode——一种轮流式翻译模式,将翻译结果以听者的语言朗读出来。这意味着需要添加一个旧技术栈所没有的TTS层。既然要为流程的某一部分引入新供应商,不妨考虑是否可以顺势整合。

我们为何选择 Scribe v2 进行语音识别

ElevenLabs 于2026年1月发布了 Scribe v2 Realtime。ElevenLabs 公布的核心指标:约150毫秒的流式延迟、在 FLEURS 基准测试中5.8%的多语言词错误率,以及在与行业标准ASR模型对比的30个基准语言中达到93.5%的准确率。支持的语言列表约有100种,并发布了四级准确度分级,涵盖优秀(≤5% WER)、高(5–10%)、良好(10–15%)和发展中(15%+)。

我们针对已运行的语言,与 Deepgram 进行了自己的对比测试。延迟指标得到了验证——转录文字几乎与说话者的声音同步出现,快到让人感知到的瓶颈转移到了翻译步骤。在我们已支持的语言上,正面对比的转录质量持平或更优,在此前表现较弱的语言上提升最为显著:印地语从"能用但粗糙"变为"流畅可用",孟加拉语和泰米尔语从"未上线"变为"以高级精度上线"。

我们还喜欢的另一点是:Scribe 原生支持逐段语言识别,这大大简化了我们的双说话人处理逻辑,也意味着我们可以扩展语言列表,而无需为每次新增语言叠加集成工作量。

我们为何选择 Gemini 2.5 进行翻译

无状态的逐句机器翻译有一套已知的失效模式:代词在缺乏先行词的情况下被翻译、有性别区分的语言在对话中途出现漂移、语体风格突然切换、习语被直译成毫无意义的字面内容。这些问题都有一个共同根源:翻译器只能看到当前这一句话。

Gemini 2.5 能够在多个轮次中保持对话上下文。模型在翻译下一句话时,能看到对话的近期历史,这从根本上解决了大多数漂移问题,无需我们在上层额外搭建任何特殊机制。实际使用中,翻译结果不再像查字典,更像是一个全程陪伴在场的人所做的工作。代价是每次调用的延迟略高于旧的无状态机器翻译——在低数百毫秒级别而非数十毫秒——但从"说话者停止说话"到"听者看到翻译"的端到端时间,在我们测量过的语言上仍远低于一秒。

我们选择 Gemini 的另一个原因是:翻译端的语言覆盖范围不再是制约因素。Gemini 2.5 覆盖了 Scribe 能识别的所有语言,且支持任意方向互译,这正是"任意对任意10,506个语言对"这一说法成为现实而非愿景的基础。

我们为何选择 ElevenLabs v3 用于 Audio mode 的TTS

Audio mode 引入了一个新的流程阶段:将翻译后的文本转换为听者语言的语音。我们选择 ElevenLabs v3,原因在于其语言覆盖范围(目前约74种语言)和语音质量。这些声音听起来像真人,而非听写软件,多语言支持意味着同一产品界面可以覆盖我们支持语言列表的整个上半部分。对于支持 ElevenLabs Flash v2.5 的语言,我们优先使用它:速度更快、成本更低,质量差异小到难以通过并排对比察觉。

支持实时语音播放的语言列表会随着 ElevenLabs 发布覆盖范围更新而增长;新语言上线后,应用会自动获取。

用户会注意到什么

数据

如果您想了解面向用户的版本

发布公告文章从用户角度介绍了同样的变化——语言选择器中的新内容、各准确度等级的预期表现,以及 Audio mode 的实际使用体验。完整的权威语言参考页面位于 /languages。如果您想亲自体验,marquee 在这里Audio mode 在这里


立即体验 Live Translate Live

立即开始实时双语对话翻译。

免费开始使用