|
Google Translate 应用程序中 的转录功能可用于为会议和演讲等活动创建实时翻译转录，或者仅用于以您不懂的语言在餐桌上讲述的故事。在这种情况下，及时显示翻译文本很有用，有助于让读者保持参与和时刻关注。 但是，使用此功能的早期版本，翻译文本会受到多次实时修订，这可能会分散注意力。这是因为原文与译文之间的非单调关系，原文句末的词会影响译文开头的词。 今天，我们很高兴地介绍最近发布的谷歌翻译应用程序中转录功能更新背后的一些技术，该更新显着减少了翻译修订并改善了用户体验。两篇论文介绍了实现这一目标的研究。在第一个公式化的评估框架，针对现场翻译和开发方法，以减少不稳定性。在第二表明，这些方法都非常好比较的替代品，同时仍保留原有方法的简单。由此产生的模型更加稳定，并在谷歌翻译中提供了显着改善的阅读体验。 评估实时翻译在尝试进行任何改进之前，重要的是首先了解并量化衡量用户体验的不同方面，目标是最大限度地提高质量，同时最大限度地减少延迟和不稳定性。在“长篇、同声、口语翻译的重新翻译策略”中，我们开发了实时翻译的评估框架，此框架自此指导了我们的研究和工程工作。这项工作提出了使用以下指标的绩效衡量标准：
重要的是要认识到质量的这些不同方面之间的内在权衡。Transcribe通过在实时自动语音识别之上叠加机器翻译来实现实时翻译。对于已识别成绩单的每次更新，都会实时生成新的翻译；每秒可以发生几次更新。这种方法将Transcribe置于3 维质量框架的一个极端：它表现出最小的滞后和最好的质量，但也具有高擦除率。了解这一点使我们能够努力找到更好的平衡点。 稳定重新翻译减少擦除的一种直接解决方案是降低翻译更新的频率。沿着这条线，“流式翻译”模型（例如STACL和MILk）智能地学习识别何时已收到足够的源信息以安全地扩展翻译，因此永远不需要更改翻译。这样做，流翻译模型能够实现零擦除。 这种流式翻译模型的缺点是它们再次采取极端立场：零擦除需要牺牲 BLEU 和滞后。而不是完全消除擦除，偶尔不稳定的小预算可能会允许更好的 BLEU 和滞后。更重要的是，流式翻译需要重新训练和维护专门用于实时翻译的专用模型。这在某些情况下排除了流式翻译的使用，因为对于像谷歌翻译这样支持 100 多种语言的产品来说，保持精简的管道是一个重要的考虑因素。 在我们的第二篇论文“同声翻译的重新翻译与流式传输”中，我们展示了我们原始的实时翻译“重新翻译”方法可以进行微调以减少擦除并实现更有利的擦除/滞后/BLEU 交易-离开。在没有训练任何专门模型的情况下，我们将一对推理时间启发式应用于原始机器翻译模型——掩蔽和偏置。 正在进行的翻译的结尾往往会闪烁，因为它更有可能依赖尚未到达的源词。我们通过从翻译中截断一些单词直到观察到源句子的结尾来减少这种情况。因此，此屏蔽过程以延迟换取稳定性，而不会影响质量。这与流方法中使用的基于延迟的策略（例如Wait-k）非常相似，但仅在推理期间而不是在训练期间应用。 神经机器翻译经常在同样好的翻译之间“跷跷板”，导致不必要的擦除。我们通过将输出偏向我们已经向用户展示的内容来提高稳定性。除了减少擦除之外，偏置还倾向于通过更早地稳定翻译来减少延迟。偏置与掩码很好地相互作用，因为掩码可能不稳定的词也可以防止模型偏向它们。但是，此过程确实需要仔细调整，因为高偏差以及掩蔽不足可能会对质量产生负面影响。 掩蔽和偏置的结合产生了高质量和低延迟的重新翻译系统，同时几乎消除了擦除。下表显示了指标对我们引入的启发式方法的反应，以及它们与上面讨论的其他系统的比较。该图表明，即使擦除预算非常小，重新翻译也超过了专为实时翻译训练的零闪烁流翻译系统（MILk 和 Wait-k）。 系统 蓝色 团队 擦除 重新翻译（旧） 20.4 4.1 2.1
在WMT 14 English-German上比较重新翻译与稳定和专用流模型（Wait-k 和 MILk）。重新翻译的 BLEU-lag 权衡曲线是通过偏置和掩码的不同组合获得的，同时保持每 10 个生成的擦除少于 2 个字的擦除预算。与无法进行更正并且需要针对每个权衡点进行专门培训的流模型相比，重新翻译提供了更好的 BLEU/滞后权衡。 结论上面概述的解决方案非常快速地返回了一个不错的翻译，同时允许随着更多的源句子被说出来而对其进行修改。重新翻译的简单结构使我们能够以最少的努力应用我们最好的语音和翻译模型。然而，减少擦除只是故事的一部分——我们也期待通过新技术来改善整体语音翻译体验，这些技术可以减少翻译时的延迟，或者在多人说话时实现更好的转录。 更新说明：优先更新微信公众号“雨夜的博客”，后更新博客，之后才会陆续分发到各个平台，如果先提前了解更多，请关注微信公众号“雨夜的博客”。 |
|
|
