最好的机器翻译 API 是哪些？
翻译 API 无处不在。 但并非所有语言都提供相同水平的性能。
最近的一项研究 表明，所有语言都没有单一的赢家，与开源引擎相比，商业引擎具有卓越的性能。
这项基准研究测试了顶级参与者——谷歌、亚马逊、微软和DeepL——使用了七种语言（包括葡萄牙语、中文和日语）的超过200,000个人工翻译片段。
DeepL和亚马逊名列前茅，DeepL在欧洲语言方面表现出色，亚马逊在亚洲语言方面领先。
虽然大多数引擎都能提供快速响应，但 DeepL 在实时翻译场景中落后——每个句子的中位延迟接近 1 秒。 对于依赖即时结果的应用程序来说，这是一个重大差距。
我们计算他们翻译的BLEU分数，并与人工翻译进行比较，分析不同方面，如目标语言和源语言中句子的长度。
此外，我们还测量这些翻译API的响应时间，因为这是需要实时翻译的应用程序（如旅行应用和翻译机构）的一个重要特性。
因此，在选择最佳翻译 API 时，不仅仅是谁支持的语言最多。 关键在于在质量、速度和语境之间取得正确的平衡。
这是我们关键查找的总结
- DeepL和Amazon Translate整体上提供了最高的翻译质量，其中DeepL在欧洲语言中领先，而Amazon在日语和中文等亚洲语言中表现更佳。
- 没有万能的引擎：性能因语言对、句子长度和翻译上下文而异。
- 较长的句子往往会在所有引擎中产生更好的 BLEU 分数——在每种测试的语言中都观察到了一致的模式。
- Microsoft Translator 的响应时间最快在单句段翻译中（中位数： 0.09 秒），而 DeepL 最慢（每个分段接近 1 秒）。
- 在批量翻译模式下，Google 和 Microsoft 提供每个句段的亚秒级速度，而 Amazon 由于缺乏真正的批量支持而表现不佳。
- BLEU分数显示引擎之间存在统计学上的显著差异，Friedman 和 Nemenyi 测试证实了这一点——验证了超越轶事证据的结果。
- 可扩展性不相等： 随着细分数据量的增长，DeepL 的响应时间会更急剧地增加，这可能是高容量使用案例中的一个限制因素。
- 所有引擎在实时应用程序中表现得足够好，除了单次调用模式下的 DeepL 和批量场景中的 Amazon。
- 巴西葡萄牙语的评估片段数量最多，使其成为研究中最强大的语言对之一。
- 数据多样性很重要：使用的数据集涵盖健康、法律和 IT 等领域，以高可靠性模拟真实世界的翻译需求。
什么是机器翻译 API？
机器翻译API是基于云的服务，允许开发人员和平台使用机器学习模型在不同语言之间自动翻译文本。
公司可以将这些API集成到网站、应用程序或内部系统中，以提供快速、可扩展和多语言的内容，而不是从头开始构建自己的翻译引擎。
一些最流行的 机器翻译 API 包括：
- Google Translate API – 涵盖 100 多种语言，并与 Google Cloud 轻松集成。
- Amazon Translate – 专为大规模、快速翻译而设计，在亚洲语言中具有强大的性能。
- Microsoft Translator – 支持 90 多种语言的预算友好型选项，非常适合实时应用程序。
- DeepL API – 以其高质量的欧洲语言翻译而闻名，尤其是在流利度和细微差别方面。
这些 API 广泛用于电子商务、旅游、法律、医疗保健、客户支持和本地化等行业，在这些行业中，准确、实时的翻译可以极大地改善用户体验和运营效率。
但并非所有API都是平等创建的——选择正确的API取决于您的具体需求：语言对、速度、成本，当然还有翻译质量。
机器翻译引擎
在本次评估中，我们选择了四个支持我们数据集中所有语言对的商业机器翻译引擎。 我们将在下面介绍它们及其截至 2022 年 1 月的相关费用值。
- Amazon Translate： 由 Amazon 开发，它为 70 多种语言的机器翻译提供支持。 其 Python API 与 AWS 服务完全集成，每 100 万个字符的成本为 15 美元。
- DeepL ： 这是一家专注于机器翻译的公司。 其 API 支持 26 种语言，成本为每百万个字符 25 美元。 我们使用了它的 Python API，它支持从英语到其他语言以及从其他语言到英语的翻译。
- 谷歌翻译： 它为 100 多种语言提供机器翻译支持，是支持语言范围更广的引擎。 它还提供与所有 Google Cloud 服务集成的 Python API。 翻译定价为每百万个字符 20 美元。
- 微软翻译： 这是 Microsoft 提供的机器翻译服务，成本为每百万个字符 10 美元，是所有评估的 MT 引擎中最低的定价。 该引擎支持近 90 种语言。
选定的 MT 引擎都能够通过其各自的 API 翻译单个句段，并且除了 Amazon Translate 之外，它们还可以在一次提交并返回句段列表时响应批量调用。
为了解决 Amazon Translate 的批量限制，我们在单次调用中进行了细微的编码优化，以消除每次翻译时都需要建立与 API 的连接的需求，这虽然不是批量翻译，但有助于缩小与支持批量翻译的其他引擎之间的差距。
尽管所有提到的 MT 引擎都适合使用并行数据或特定术语的词汇表来调整其模型，但我们决定在本次评估中将这些选项放在一边。
我们还尝试评估其他 MT 引擎（例如，百度翻译、腾讯、Systram PNMT、Apertium、阿里巴巴），但由于以下原因之一而无法使用它们：
- API 不可用
- 缺少文档，
- 不支持所有目标语言。
指标
我们使用 BLEU 分数来评估引擎的翻译质量（Papineni et al., 2002）。 我们使用 Friedman 检验（Friedman，1940）来比较不同引擎的分数，并使用事后 Nemenyi 检验（Nemenyi，1963）来验证单个 MT 引擎之间的统计显著差异。
为了计算 API 的响应时间，我们从数据集中选择了 100 个片段的样本，遵循片段大小间隔的分布（图 2），并在每个引擎中将它们从英语翻译成葡萄牙语。
我们每天用选定的句子敲击引擎一次，持续一周，以评估 API 的方法：单个和批量。 我们没有使用整个数据集，只翻译了一种目标语言来评估响应时间，因为用 7 种语言的 200k 个片段运行引擎一周的成本会很高。
实验结果
在本节中，我们介绍了第 2 节中描述的机器翻译引擎性能的调查结果。
质量评估
下表显示了四个引擎在每种目标语言上的平均BLEU分数。 对于所有语言，Friedman 检验的 p 值都小于显著性水平（0.05），这意味着引擎的分数在统计上存在显著差异。 此外，根据事后 Nemenyi 检验，每种语言得分最高的引擎的性能与其他引擎在统计学上有显著差异，p 值低于显著性水平 0.05。 Amazon 和 DeepL 在 4 种目标语言中取得了最好的总体结果，得分最高。 谷歌在西班牙语方面与 DeepL 并列，在中文方面与 Amazon 并列，而 Microsoft 翻译引擎在任何语言中都没有优于任何 MT 引擎。
下图显示了每种目标语言中不同区段大小的 BLEU 分数分布。 这些图中的一个常见趋势是句子越长，BLEU 分数越高。
例如，所有以德语为目标语言的 MT 引擎的中位数得分，对于大小在 1 到 10 之间的句段约为 0.6，对于大于 40 个单词的句段，中位数接近 0.7。
日语是唯一的例外：句段大小不会影响 Amazon 和 DeepL 的翻译质量，但影响了 Microsoft（1-10 区间的 BLUE 得分中位数为 0.61，40- 区间的 BLUE 得分中位数为 0.58）和 Google（1-10 区间的 BLUE 得分中位数为 0.62，40- 区间的 BLUE 得分中位数为 0.6）的质量。
翻译时间评估
每个 MT 引擎每个句段的翻译时间分布（一次发送一个句段（单个）和一次发送 100 个句段（批量）时）可以在下面分析。
在单个方案中，Microsoft 提供的翻译速度最快（每个句段的中位数为 0.09 秒）。 Amazon 和 Google 的速度慢了大约两倍（中位数接近 0.2 秒），而 DeepL 是最慢的（每个段落的中位数为 0.96 秒），几乎是 Microsoft 的十倍。
与单个 API 相比，使用 API 的批量调用时，首先要注意的是，每个区段的翻译时间大大缩短。 例如，对于 DeepL，每个句段的翻译中位时间从单次执行的 0.95 秒减少到批量执行的 0.02 秒。
这些结果清楚地表明，批量操作比单独发送句段进行翻译要高效得多。 关于引擎的单个性能，Microsoft 和 Google 的翻译时间最短（每个句段的中位数分别为 0.003 秒和 0.002 秒），而 Amazon 的翻译时间最长（中位数为 0.09 秒）。我们认为 Amazon 表现不佳的原因是它没有提供真正的批量调用。如前所述，我们在实验中不得不对其进行近似。
因此，评估的 MT 引擎每个句段的翻译时间较短，这使得它们适用于实时翻译应用程序。 唯一的例外是 DeepL，在单一场景中，单个句子的中位翻译时间接近 1 秒。
为了分析引擎的可扩展性，我们在下面展示了 MT 引擎在改变段数时的响应时间。 在所有曲线中，时间随线段数的增加而线性增长。
但是，一些发动机的线性系数比其他发动机小得多。 例如，DeepL 在单一场景中的系数最高，而 Amazon 在批量场景中的系数最高，这意味着它们在各自的场景中的扩展能力不如竞争对手。
结论
在本文中，我们介绍了四种机器翻译引擎的质量和响应时间的评估。 我们的评估显示，引擎的质量相似，但 Amazon 和 Deepl 表现最佳。 在响应时间方面，总体而言，各引擎表现良好，但 DeepL 在一次发送一个片段时表现例外，而 Amazon 在批量调用时表现例外。
实验设置
在本节中，我们将介绍我们在实验评估中使用的设置。 更具体地说，我们描述了真实数据集、机器翻译引擎以及用于评估引擎的指标。
数据
本次评估使用的数据集来自专业翻译人员生成的来自不同公司的 13 个翻译记忆库，以英语为源语言和七种目标语言：
- 德语（de）
- 西班牙语（sp）
- 法语（fr）
- 意大利语（it）
- 日语（ja）
- 巴西葡萄牙语（pt）
- 中文（zh）
英语的每个句子至少有一个与上述目标语言之一对应的对应对。 数据集中共有 224,223 个英语片段和 315,073 对。
下图显示了每种目标语言的区段数量分布。 巴西葡萄牙语的句段数量最多（接近 60k），而日语和西班牙语的句段数量最少，约为 20k。 该数据集用于此评估的一个重要特点是它涵盖了多种主题。
下图显示了英语句段的词云。 正如人们所见，这里有与健康、法律、信息技术等相关的内容。
数据集的结构包含源语言的文本段和包含目标语言翻译的参考列表。 这些参考列表至少有一个与原始文本关联的翻译，尽管它可以有多个翻译，因为一个句段可以有多个可能的翻译。
为了简化我们的分析，我们将句段分组为大小为10的范围，如下图所示，以评估句段大小对引擎翻译质量的影响。
这篇论文是用来的...
每家计划实施任何类型翻译的公司都需要阅读本文，因为我们概述了每种机器翻译工具在质量和响应时间方面的各种优缺点。 这篇深入的内容面向那些积极参与改进其翻译相关产品和服务的专业人士，例如：
- 产品经理,
- 项目经理,
- 本地化经理,
- 工程领导者,
- 翻译人员,
- 翻译机构.
本文由 Bureau Works 的工程师撰写。
Bureau Works 在我们的本地化平台上提供全面的内部翻译服务，支持深入报告、不断发展的翻译记忆和自动化本地化。
最重要的是，我们将本地化的业务和技术元素结合在一个屋檐下。
加布里埃尔·梅洛、卢西亚诺·巴博萨、菲利佩·德梅内塞斯、瓦尼尔森·布雷吉奥、恩里克·卡布拉尔。
Bureauworks，Universidade FederaL de Pernambuco，Universidade FederaL RuraL de Pernambuco
3685 Mt DiabLo BLvd，Lafayette，CA，美国，Av. 莫赖斯·雷戈教授，1235，累西腓，伯南布哥，巴西，鲁阿·多姆·曼努埃尔·德·梅德罗斯，无门牌号，累西腓，伯南布哥，巴西
3685 迪亚布洛山大道，拉斐特，加利福尼亚，美国，Av. Moraes Rego 教授，1235，累西腓，PE，巴西，Rua Dom Manuel de Medeiros，s/n，累西腓，PE，巴西
{gabrieL.meLo，fiLipe，henrique}@bureauworks.com Luciano@cin.ufpe.br，vaniLson.buregio@ufrpe.br
Unlock the power of glocalization with our Translation Management System.
Unlock the power of
with our Translation Management System.
