关键字: [亚马逊云科技， OpenSearch Percolator， 大模型智能文档翻译， 术语准确性保证， 企业文风遵循， Pdf格式渲染， 术语库构建]

导读

在这个演讲中，演讲者胡一凯分享了亚马逊云科技在基于大模型的智能文档翻译领域的实践经验。他介绍了如何通过术语库、样例库等方式，确保术语翻译的准确性并遵循企业文风要求。他还讨论了在PDF和Word文档翻译过程中遇到的工程化挑战及解决方案，以及如何将整个系统集成并部署到客户环境中。最后，他阐述了通过持续优化语料资产，实现翻译质量和应用场景的正向循环。

演讲精华

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

亚马逊云科技-基于大模型智能文档翻译实践

大家好，我是来自亚马逊云科技解决方案开发团队的胡一凯。今天，我很高兴有机会与大家分享我们在智能文档翻译领域的一些实践经验。这是一个名为“chinese-video-to-article”的活动。

一开始，我认为机器翻译这个有着50多年研究历史的领域，在当今大模型时代应该是一件很简单的事情。然而，当我真正与客户沟通时，发现事情并非如此简单。

我们的客户是一家跨国医疗器械公司，他们需要将200页的核磁共振说明书从英文翻译成中文。他们有一个内部术语库，包含200个术语。当时的现状是，他们需要将说明书外包给专业翻译机构，大约需要两周时间。但客户反映术语的准确度却没有达到他们90%的要求。

在接手这个需求后，我们发现存在两个主要挑战:

如何在使用大语言模型进行翻译的同时，保证术语的准确性。 如何在保证术语准确性的同时，遵循企业内部的文风要求。

今天，我将从五个方面进行展开。

首先，我们如何确保术语可以精确翻译?

最初，我们采用了最朴素的方法，就是直接将几百条术语塞入模型的上下文中。以右边的这个prompt为例，第一行是一个instruction，然后后面是我们200个术语对，最后是一个preview。将其送给大模型后，让它对每一句进行翻译。在200条术语的情况下，效果还不错，达到了业务方对90%术语准确率的要求。

但随着客户进一步使用，我们发现了新的挑战。当术语数量达到1，000多条时，出现了两个主要问题:

如果继续使用之前的方法，我们送给大模型的提示词中，90%的内容都被prompt所占据。根据大模型的注意力机制原理，我们会发现术语的遵循能力出现了下降。 对于PDF格式的翻译，PDF是由蓝色的block和红色的span组成的复杂格式。当术语非常多且直接塞入模型上下文时，PDF格式遵循能力会下降，导致渲染时出现乱码情况。

为了解决这个问题，我们引入了AC自动机算法。AC自动机的原理是将所有术语加载到内存中，然后用AC自动机在内存中进行键值匹配，实现毫秒级别的检索。这解决了大模型在上下文长度和注意力机制对术语长度的限制，以及术语数量的限制。

但随着数据量进一步增大，我们发现AC自动机在内存消耗和搜索时间方面也会出现增加。而且，串树没有模糊搜索的概念，无法处理客户术语中的特殊符号等情况，成为新的挑战。

我们遇到了一个真实的客户案例，是一家制药企业，他们使用了HUAQ这个术语库(规模约60万条)去翻译CSR文件。对于这种规模，之前的直接上下文和AC自动机方法都无法满足需求。

为了解决这个问题，我们使用了OpenSearch Percolator这个缓存。OpenSearch Percolator缓存与普通缓存不同，它是以术语作为索引，输入一段文章，然后检索出所需的术语，很好地满足了我们的翻译场景需求。客户可以将PDF中截取的一段话作为查询，我们就可以检索出所有匹配的术语，同时也解决了模糊匹配的问题。

简单总结一下，在数据量较少的情况下，我们可以使用任何数据库甚至S3来存储术语，在内存中使用AC自动机进行匹配。当数据量进一步增大或需要模糊匹配时，我们就可以引入OpenSearch Percolator。当数据规模达到百万级以上时，我们会使用更大的机型和更好的分词模型。在我们的产品中，我们根据数据规模的不同进行了分类，对于数据量较少时，直接将数据存储在RDS中;对于数据量较大时，则将其导入OpenSearch中。

接下来，我们如何解决企业需要遵循内部文风的需求?我们引入了样例库的概念。客户有历史的翻译文件，希望我们使用大模型进行新的翻译时，也能遵循之前的文风。

一开始，我们考虑是否可以微调一个大模型。虽然微调大模型可以解决这个问题，但它也有一些成本，比如启动成本较高、训练语料要求较高，并且每个客户都需要单独微调一个大模型，成本较高。

我们也考虑过是否可以训练一个罗拉(LORA)，虽然成本相对大模型会稍微低一点，但它也并非没有任何成本，并且它需要开源模型，每个客户也需要单独训练自己风格的罗拉。

我们还尝试在prompt中直接写明要求的文风，比如专家一点、简练一点或生动一点，这确实有一定效果，但也需要根据每个客户进行单独调整。

最后，我们找到了一个不错的方式，就是将RAG(Retrieval Augmented Generation)和FuseShot结合，构建一个Web知识库。它的效果更好，而且启动成本相对于其他方案会低很多。

这里有一个例子，我们的客户想翻译他们的病例。我们将他们之前老中医或老西医写好的病例，也就是已经翻译好的内容，导入到我们的术语库中。左边是没有使用术语库的翻译结果，是音译中，冗长许多。而右边使用了翻译库的结果，更加简练、精练。

我们将解决“信达雅”的工作流概括为在线和离线两部分。

离线部分，我们先将一些翻译的历史文档和内部术语库进行向量化和标注，然后放到OpenSearch中的术语库。

在线部分，我们将分词好的原文进行检索，拼成一个prompt，然后送给大模型进行翻译。

刚才我们解决了翻译内容的部分，接下来让我们看一看工程化的问题。

我们的客户中有很多都是翻译PDF文件，PDF在计算机看来就是一个个二维的方块组合。在渲染翻译后的PDF时，我们也遇到了一些问题。

第一个问题是，我们发现不同语言的信息浓度不一样。中文是信息浓度较高的语言，将相同内容从中文翻译成英文，体积会膨胀约30%。如果不做任何字体调整，直接对翻译后的内容进行覆盖，就会出现空间折叠的问题。我们在后来的算法中引入了高度限制，使用动态递归算法找到最佳大小，优化后的渲染结果如图所示。

第二个问题是，PDF中有一些特殊符号(如逗号)会将一段话切成多个block。如果不做任何合并，直接将block送到大模型进行翻译，有时会导致一句话被切成两段翻译，渲染时会出现奇怪的情况。我们使用动态评估的方式，判断两个block是否可以合并。如果可以，就将它们的空间和内容统一翻译和渲染。

第三个问题是空间没有被完全利用的情况。如果进行了空block的合并，但直接送给大模型翻译，有可能出现一大片文字被合并成一行的情况，导致中文字体过小，影响阅读。我们使用双指针算法，将所有可利用的空间全部检索出来，而不会覆盖到新的行，从而更好地利用空间。

接下来是一些真实的PDF和论文翻译场景展示。

相对于PDF，Word文档的翻译就简单多了，因为Word底层是XML结构。我们只需要将Word重命名为ZIP，解压缩后，大部分就是一个个XML文件。所以翻译时，我们只需要用一些开源包将Word解析成XML，送给大模型翻译，然后渲染回去即可。

好了，看完这些工程化的问题后，我们再看如何将它们串联起来，解决客户的问题。我们为客户做了一个试用的前端，用户可以在这里上传他们的术语库，我们会帮助导入到OpenSearch中。导入成功后，用户可以看到状态，并使用纯文本模式检验术语库是否真正生效。如果测试没有问题，用户就可以上传真实需要翻译的文件进行翻译，然后下载并预览。

整个系统都是使用Amazon CDK编写的，可以在用户的云环境中一键部署，大约20分钟就可以将整个平台部署好，用户就可以开始使用了。

在专业翻译领域存在飞轮效应。根据我们的观察，用户首先将内部语料(如翻译队)、文风的历史语料整理成数据资产，包括数据库、术语库和样例库，然后使用我们的翻译工序进行翻译。翻译结果可以再交给业务方进行人工反馈，比如标注哪些翻译好，进一步丰富内部语料，形成正向循环。

同时，我们也发现在这个循环中收集到的数据资产还可以应用到智能写作审核、AI校对等新的领域。

以上就是我今天分享的内容，希望对大家有所帮助，谢谢!

总结: 本次分享介绍了亚马逊云科技在智能文档翻译领域的实践经验。主要内容包括: 1. 如何保证术语精确翻译，从直接上下文到AC自动机，再到OpenSearch Percolator缓存。 2. 如何遵循企业内部文风，引入样例库、RAG和FuseShot构建Web知识库。 3. PDF和Word文档翻译的工程化问题，如信息浓度差异、格式遵循、空间利用等。 4. 整体系统架构，包括离线构建术语库、在线翻译流程。 5. 专业翻译领域的飞轮效应，数据资产的积累和应用。

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

The speaker expresses that machine translation， a field with over 50 years of research history， may seem like a simple task in the era of large language models.

The initial approach involved directly feeding hundreds of terms into the model’s context， resulting in decent performance with 200 term pairs and meeting the business requirement of 90% term accuracy.

To address this issue， we utilized the OpenSearch Percolator feature， which is a specialized type of index that allows us to index terms and then retrieve relevant documents based on those terms， perfectly suiting our translation scenario.

当面临中文视频转文章的需求时，考虑微调大型语言模型的可行性和挑战。

总结

在这场演讲中，演讲者分享了亚马逊云科技在智能文档翻译领域的实践经验。首先，他阐述了客户对于术语准确性和文风遵循的需求，以及如何利用大语言模型来满足这些需求的挑战。

他详细介绍了三种解决术语准确性问题的方法:直接将术语塞入模型上下文、使用AC自动机算法和利用OpenSearch Percolator缩影。这些方法分别适用于不同数据规模，可以有效提高术语翻译的准确性。

接着，演讲者阐释了如何通过构建基于RAG和FuseShot的知识库来满足客户对文风的需求，避免了微调大模型或训练罗拉的高成本。他还展示了一些工程化问题的解决方案，如字体大小调整、块合并和空间利用等，以确保翻译后的渲染效果良好。

最后，演讲者介绍了一个前端系统，用户可以上传术语库、样例库，并进行文档翻译和预览。整个系统可在云环境中一键部署，形成了一个正向循环，不断丰富内部语料资产，并可应用于其他领域。演讲者呼吁利用云科技实现智能文档翻译，满足客户多元化需求。

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