关键字: [亚马逊云科技， 生成式AI， Glosre Trivo， 大模型翻译优化， 翻译质量评估， 术语一致性增强， 上下文信息补充， 工程实践经验]

导读

在这场演讲中，李元博教授分享了大模型翻译的创新与实践，重点讨论了大模型翻译的技术趋势、业务价值、常见问题以及质量优化路径。他介绍了基于prompt、retrieval增强和MTQE流程的优化方法，并结合实际案例分析了各种方法的优缺点。最后，他总结了不同业务场景下的最佳实践，为大模型翻译的工程落地提供了宝贵经验。

演讲精华

以下是小编为您整理的本次演讲的精华。

大家好，我是亚马逊云科技的深圳AI学习方案教授李元博。今天，我将分享关于大模型翻译创新与实践的内容。相信大家在日常工作中都使用过大模型进行翻译，但可能大部分人并未接触过翻译的生产及项目。这是可以理解的，因为在大多数公司，翻译并非核心业务，而是一项重要的支持能力，尤其对于那些具有海外业务的公司而言。一些公司拥有本地化团队，而另一些则没有。在大模型应用于翻译之前，对于许多公司来说，技术层面的翻译能力相对有限，可能仅限于对接翻译API。但在大模型应用于翻译之后，我们能够做的事情和空间都更大了。通过今天的分享，我希望那些曾接触过大模型翻译生产项目的听众能获得一些参考和借鉴;而对于那些未接触过的同事，我希望能让他们对大模型翻译的问题及优化路径有一个全面的了解。

我今天分享的内容都源自于亚马逊在各个行业的实践，包括游戏、电商、在线旅游等行业。我们在这些行业进行了一些实践，今天分享的案例和示例可能会来自于这些行业。接下来，我们先来看一下整个分享的目录。整个分享主要分为7个部分:第一部分讲述大模型翻译的技术趋势;第二部分讲述翻译的业务价值，以及不同业务场景对翻译的诉求和特点;第三部分讲述大模型翻译的常见问题;第四部分讲述大模型翻译质量的优化路径，可能分为好几个层次;第五部分讲述在具体工程落地时经常关注的一些工程实践经验;最后是总结。

首先，让我们切入到第一部分，关于翻译技术的趋势。我个人使用大模型作为首选的翻译工具。在使用大模型翻译之前，我的翻译体验是先使用翻译工具进行初步翻译，然后进行人工修订，最后交付。但现在使用大模型翻译后，我发现很多时候翻译效果基本上不需要修改，说明大模型翻译的优势是比较明显的。我们也观察到，在过去一年多的时间里，越来越多的行业都在大量使用大模型进行翻译，这是一个非常有趣的现象。更有意思的是，在学术层面上，我们也观察到一个有趣的事情。在去年年底的WMT24会议上，当时的翻译评分中，获得最高分数的并非大模型翻译，但会议的结论认为，在整体翻译能力的评价上，ChatGPT 3.5取得了榜首的位置。这个结论同时指出，传统的评分指标与人工专家评估存在一定的矛盾，认为传统指标并不适合作为最终的衡量标准。这个结论与我们在很多场景的实践是相符的。

为什么会出现这种情况呢?我有一个个人理解，供大家参考。首先，传统的机器翻译模型是基于平行语料训练的专门模型，它只做翻译这一项任务。在迭代模型的过程中，它不可避免地会过度拟合到评估的数据集或面向特定的评估指标进行优化，比如BLEU分数等，可能会出现过拟合的现象。而大模型的区别在于，它是一个通用模型，不仅要面对翻译这一项任务，还有多项任务。在训练过程中，我们可能有多个评估指标，翻译只是其中之一。不同指标之间必然存在一种权衡，这意味着大模型不太可能针对翻译这一项任务进行过度优化。因此，大模型在翻译上的评分相对更加扎实。我们自己的感受也是，大模型翻译能够更好地捕捉语言的深层次含义，更好地适配文化背景，保留原文的情感和风格。从成本层面来看，在过去一年里，大模型翻译服务相对于传统机器翻译服务的成本更低。另外，由于大模型翻译是通过提示词触发的，因此它具有更强的技术可调整性，我们可以通过提示词引入更丰富的背景信息和上下文信息，要求模型更好地满足我们的业务诉求，这使得我们的技术发挥空间更大。唯一的挑战可能在于速度方面，但随着推理技术的发展，推理速度已经有了很大的进步。在真实的生产落地中，我们也可以选择不同的模型来平衡速度和质量。总的来说，大模型正在不断取代传统的机器翻译模型，这是我目前看到的技术发展趋势。

第二部分，我们来讲一讲翻译的业务价值。对于大多数没有接触过翻译业务的人来说，可能难以深刻感受翻译的价值。我这里举一些例子，翻译对我们的一些主流业务可能会有所帮助。在电商场景中，如果是面向海外市场，那么可能需要翻译商品标题、商品描述等。在这个翻译过程中，如果出现关键词翻译不准确的情况，比如品牌、款式等，可能会对搜索引擎营销和流量分发产生影响，进而影响整体营销绩效。在游戏社区场景中，社区的活跃度对于用户增长至关重要。一些面向全球发行的游戏社区，如果内容分散在各个语种之间，翻译质量不佳导致信息丢失，就会影响整个内容的丰富性，进而影响游戏的良性发展。除了游戏社区，其他社区论坛也是如此，在我们的实践中发现，为社区论坛提供翻译服务后，对整体业务增长产生了正面作用。另外，对于游戏、旅游出行等行业，他们有大量的条款和条文，如果出现翻译错误，可能会引起纠纷，整体风险概率会提高。这些都体现了翻译在不同业务场景中的价值。

在不同的行业和业务场景内，对翻译的诉求也有所区别。我们主要从三个维度来分解:时效性、翻译质量和成本敏感性。从时效性上来看，我们列举的大部分场景对时效性的要求并不太高，可能唯一要求较高的是游戏类即时聊天场景。从成本敏感性上来看，情况有所不同，大量的UGC(用户生成内容)内容翻译的成本敏感性较高，因为数量较大，整体规模也较大;而对于PGC(专业生成内容)内容，其翻译的成本敏感性相对较低。从翻译质量的角度来看，我们主要关注三个点:词汇的准确性和一致性、风格的一致性，以及达到一定的语言水准。

接下来，我们来看一看在翻译中常见的一些问题，这也有助于理解我们后面提出的优化措施。第一个问题是术语的一致性和精准性。比如在游戏领域，经常会出现一些技能的不同译法，如“嘲讽”一词可能会有多种记录，这会造成用户体验不佳。在电商领域，我们可能更关心品牌名称的准确性，比如将“SK-2”翻译成“SK 2”就会影响品牌感知。另一个例子是服装款式的描述，比如将“one shoulder”(单肩)翻译成“一字肩”就是错误的，因为“一字肩”实际上是“off shoulder”(无肩)的意思。在酒店旅游业，酒店名称的翻译也经常出现错误，大模型有时会给出一个全新的名字，这是不可取的。

第二个问题是行业黑话和文化适配。在游戏领域，有一些行业黑话如“buff”(增强的意思)，可能会被错误地翻译成“缓冲”。在电商领域，一些如“福袋”这样的促销词汇，如果直接翻译成“lucky bag”可能会造成理解偏差。除此之外，日期和金额的表达在不同国家和地区也有区别，如果处理不当，也可能出现问题。比如日元和人民币的符号相似，在单位换算时可能会出错。另外，在翻译过程中也可能会出现UI曝光的问题。

刚才讲到的这些问题，其实在大模型翻译之前就已经存在了。接下来我会展示一些与大模型直接相关的问题，这些问题可能是由于大模型的训练机制或推理机制导致的。比较典型的一个问题是拒绝翻译，对于一些敏感内容，比如成人用品，大模型由于做了无害化对齐，很多时候就会拒绝翻译，即使你告诉它当前是在翻译场景。另一类问题是语种夹杂，这主要是由于大模型的训练语料中可能存在不同语种的混杂，导致在某些语种的翻译中出现其他语种的夹杂。其他问题还包括文本重复、符号和拼写错误，以及格式变化(如输出成Markdown形式)等，这些都是由于大模型的概率输出导致的不稳定性。

为了解决这些问题，我们整理了三个层次的优化思路。第一个层次是基于prompt和agent的翻译优化。在这一层次上，我们最开始使用的优化方法是参考业务专家提供的更加精细的prompt提示词。比如对于泰语翻译，翻译专家从各个角度对翻译的风格和规范做了约束，同时还提供了一些专有名词和常用词语，通过这个优化的提示词来进行优化。这是最简单最基础的一步，也是我们最开始使用的方法。

第二步就是将单次的模型调用转化为多步调用。我举一个比较恰当的例子，就是做广告词的翻译。比如我们有一个洗面奶的广告词“遇见人间蜜桃肌”，如果不做任何解释，直接让翻译系统翻译，它可能无法准确翻译，会出现很多曲解。但如果我们将其拆分为多步，先对原文进行文学解释，让模型解析隐含的意义和修辞手法，然后扩展原文的上下文信息量，再提供背景信息(如这是广告词、是什么产品、目标受众等)，最后再翻译并进一步润色，要求保留原意、强调营销效果，通过这一系列拆解，模型就能更全面地理解上下文，翻译效果也就更好了。这种相对于传统机器翻译的优势，正是大模型翻译所带来的。

对于这一类基于工作流或agent的翻译优化，我们得出了一些结论。首先，在提示词优化这一层面上，我们发现在小规模的大模型上，提示词优化是能够有一定提升的，但相对于直接升级模型所带来的提升而言，提升幅度较小。如果我们非常追求翻译效果，建议直接升级到顶尖的翻译模型。另外，我们发现头部的一些大模型，比如ChatGPT 3.5及更高版本、OpenAI等模型，在做翻译时不太需要过于复杂的提示词和细节规则，反而可能会导致效果下降。再者，基于工作流或agent的翻译流程，我们目前观察到基本上都能提升效果，但也可能带来额外的多次调用成本。另外，整个上下文补充相对来说还不是最优，可能缺少一些动态信息。

这就接入到我们下一层次的优化，叫做基于retrieval增强的翻译优化。这个流程也非常简单，其实与之前的agent优化大体思路是一样的，就是在构建prompt之前，我们先通过召回的方式召回一些样例或术语词汇。有两种方式，一种叫做reference retrieval，主要是做样例召回;另一种叫做glossary retrieval，是做术语召回。

样例召回的好处是，我们可以通过召回样例，参考样例中的用词用法和风格。比如在电商场景中，有一个例子提到了“GenuineAI”这个词，它应该翻译成“原装”，而不是“真正的”。另一个例子是冰箱接水托盘，其中提到“4P”，之前的翻译没有翻译这个词，但通过样例就知道它指的是“四卷装”的意思。这些都是非常好的例子，说明reference retrieval能够指导我们做出正确的词汇使好的，我继续生成剩余的内容:

样例召回的另一个优势在于，它能够影响译文的风格。我们可以看到两个例子，直译和经过样例召回增强后的译文，它们的风格有明显的变化。这是样例召回的一个主要优势。但它也存在一些问题，比如样例长度的把控以及召回的精准性。如果我们按段落来召回样例，段落可能会过长，引入了过多的词汇信息;即使是按句子召回，也有可能召回的不是我们期望的最理想样例。另外一个问题是术语的一致性，由于原文在引入样例后可能发生了变化，我们召回的样例也会发生变化，导致最终参考的术语在不同译文中前后不一致。再者，长期维护会比较困难，因为我们真正上线服务后可能会遇到一些异常案例，需要优化样例，但我们无法保证新增的样例一定能被正确召回，也难以评估对整体质量的影响。

glossary retrieval则可以弥补样例召回的一些问题。我们先看一个来自论文的例子，它展示了大模型和传统机器翻译模型各自擅长的场景。其中指出，在专业领域如医药领域，传统模型可能表现更好。但是，如果我们通过glossary retrieval将专业术语召回并放入prompt中，我们就能非常好地解决这个专业术语的问题，即使使用的是一个小规模的模型。

实现glossary retrieval有一些前提:第一是需要有一个高质量的术语库;第二是需要有一个基于术语库的分词方法;第三是需要有术语管理的工程配套。关于高质量术语库，如果公司之前有本地化团队，那么可以直接检查和使用之前维护的术语库。如果之前没有构建过，我们也可以通过抽取历史翻译语料中的专业词汇映射来构建，在我们的实践中，这种抽取的效果还是不错的，召回率很高，非常适合构建初始术语库。

第二点是需要有一个基于术语库的分词方法。我们尝试了一些现有的开源分词包，如jieba、LTP等，但发现它们对多语种专词的支持都不太好，最多只支持中英文。因此我们自己实现了一种基于前缀树的分词方法，能够支持数十万规模的术语库，切词延迟只有几十毫秒，性能非常好。

第三点是术语管理，这对于生产环境是必备的。我们给出了一个亚马逊实践的架构图，包括一个KV数据库用于存储术语库并进行动态召回，一个S3对象存储用于存储前缀树数据，一个参数管理器用于指定当前使用的术语库版本并进行版本切换，以及一个前端界面用于术语库的上传、查询、验证等管理功能。

glossary retrieval的优势在于，它能够保证术语的全局一致性，只要在原文中出现同样的词，就一定会召回出一致的术语。由于只召回术语，额外的token开销也比较少，不会带来太多费用增加。它还便于我们在生产中长期维护，遇到问题一般就是术语缺失或不当，我们只需修改术语库就能解决。不过，它的缺点是无法提供翻译风格的参考。

我们提供了4种方法的定量对比:没有召回、数据召回、样例召回，以及两种方法结合。结果表明，在4个指标上，组合方法都能取得最高值。如果仅关注翻译质量，我们建议采用融合的方式，既召回样例也召回术语，样例主要通过reference retrieval来召回。对于glossary retrieval，我们发现它在一些传统的翻译指标上会有优势，主要是由于它更加强调词汇准确性，而传统指标如BLEU、METEOR等更多关注词汇匹配。

除了上述优化方法，我们还可以直接微调一个模型，针对专业领域构建翻译模型。但我个人不太推荐这种方式，因为它的门槛较高。你需要决定使用什么尺寸的模型，如果是小规模的开源模型，它的能力可能离商业模型有一定差距，很难追上;而如果使用商业模型，发布的版本更新非常快，你需要不断维护和微调你的模型，整体成本很高，难度也较大。

因此，我们建议构建一个称为MTQE(机器翻译质量评估)的流程。基本思路是，用大模型来做评委，将我们的业务知识规则融入prompt，让模型多次检查并输出检查到的问题及分数，最后我们综合这些分数和问题，给出最终的评估结果。这里需要强调的是，由于评委模型的能力要求较高，我们一般建议使用顶尖的大模型。

这种方法也存在一些问题，比如大模型有时候会吹毛求疵，召回的问题量过多且分数分布较为离散，难以筛选。另外大模型的评价尺度与业务上的评价尺度可能也有差距。为解决这个问题，我们在实践中采用了另一种方法，就是直接再构建一个打分模型，基于人工业务评估数据，对大模型召回的错误进行二次打分。这种方式能使评价标准更加接近业务标准，分数分布也更加连续，便于筛选。

另一种思路是，不通过大模型做问题召回，而是直接训练一个开源的小规模模型进行问题识别召回，成本更低、速度更快，可用于一些成本敏感的UGC内容场景。我们可以部署一个小模型，专门识别一些业务上非常敏感但并不困难的错误，如拒绝翻译、语种夹杂等，作为兜底方案。在构建这个小模型时，我们也有一些实践经验，比如采用CoT(constituional output transformation)的手段，以及区分简单问题和复杂问题进行训练等。

在训练方法上，我们的经验是Finetuning通常要优于Lorafintuning，后者效果不太稳定。另外，我们发现有时模型的输出意思是正确的，但最终得分可能与我们的业务规则不太匹配，比如0-2分需要人工审核，3-5分可以直接放行。这时我们可以采用RLPO(reward learning policy optimization)的方式，直接基于规则生成reward，以使模型的输出更贴近业务需求。

除了上述优化措施，在真实生产过程中我们还关注一些其他实践经验，比如费用优化、prompt缓存、低翻译标签等。费用优化的做法是，对于一些成本敏感的场景如即时聊天，我们可以构建一个极简的prompt，减少额外token的引入，降低费用。prompt缓存的原理是，对于重复的前缀内容，我们可以将其缓存，避免重复计算，从而节省成本。低翻译标签的意思是，有些内容我们不需要翻译，可以用标签将其包围起来，但这种方式存在一些不稳定性，我们可以先将原文转化为Markdown形式，再翻译，最后再反向替换，就能保证低翻译标签的效果。

最后，我们根据不同的业务场景，给出了相应的优化路径建议。对于质量优先型业务，如游戏剧情、品牌广告词、法律合规文件等，我们建议使用最好的大模型进行翻译，结合样例和术语两种召回方式增强上下文，引入MTQE机制并由人工做最后兜底。对于成本敏感型业务，可以使用小一点的模型，结合术语召回，构建简化版的MTQE小模型识别常见错误。对于实时要求较高的场景，可以使用小模型、极简prompt，必要时引入glossary retrieval。我们还列举了各种优化手段的难易程度，大部分公司都是能够实施的。

总的来说，这是一场内容丰富的技术分享，全面介绍了大模型翻译的现状、挑战及在亚马逊云科技的创新实践，并根据不同业务场景给出了相应的优化路径建议，具有很好的指导意义。

下面是一些演讲现场的精彩瞬间：

Li Yuanbo， an AI learning solutions instructor from Amazon Cloud Technology in Shenzhen， introduces himself and expresses his excitement to share insights on large model translation innovation and practice.

专家提供精细的提示词，优化泰语翻译效果

The speaker explains how breaking down a complex phrase like an advertisement slogan into multiple steps can significantly improve the translation quality by allowing the AI model to better understand the cultural context behind it.

通过对原文进行文学解释、上下文扩展、背景信息提供和润色修改，可以更全面地理解上下文，从而提高翻译效果。

通过具体例子展示了参考表(reference retable)如何指导AI正确翻译词汇和短语，提高翻译质量。

总结

亚马逊云科技在大模型翻译领域进行了深入探索和实践，总结了以下几个关键点:

大模型翻译正在快速发展，在质量和速度上都有明显优势。但同时也面临着术语一致性、行业黑话适配、语种夹杂等新挑战。为解决这些问题，亚马逊提出了三个层次的优化思路:基于prompt的翻译优化、基于retrieval增强的翻译优化，以及构建MTQE(机器翻译质量评估)流程。

基于prompt的优化通过精心设计prompt，为模型提供更多上下文信息，引导其生成更准确、风格更贴切的译文。基于retrieval的优化则通过召回相关样例和术语词库，为模型补充必要的背景知识。其中，术语词库的构建和管理是关键环节。

MTQE流程则是通过大模型评委识别译文中的问题，并结合人工评估模型对问题进行打分和筛选，从而全面评估和优化译文质量。此外，亚马逊还探索了一些工程实践，如费用优化、prompt缓存等，以提高翻译系统的性能和效率。

最后，亚马逊根据不同业务场景的需求，提出了相应的优化路径:质量优先型业务使用最佳模型并全面优化;成本敏感型业务使用小模型简化优化;实时要求高的场景使用小模型加极简prompt。总的来说，大模型为翻译质量的提升带来了新的机遇，但也需要相应的工程实践来充分发挥其潜力。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。