又有一段时间没发稿了，今天献上年终特稿，分享一组针对大模型在软件本地化翻译中应用的实证研究，看看通过一系列实验，我们能得到哪些有价值的结论——所有结论会在文章结尾总结给大家，不过也非常推荐大家看看正文，因为有很多测试的细节还是很有启发的。
这次测试由 Lingoport 和 RWS 联手完成，RWS 语言人工智能服务总监 Marina Pantcheva 和 Lingoport 全球化解决方案和服务副总裁 Milen Epik 一起解答了以下问题：
做了这么多年产品本地化（我自己也做过本地化译者），真心理解它可不是普通的文本翻译。
产品本地化翻译的核心难点主要有三个。
首先是歧义问题。软件里的字符串通常都很短，还都是单独出现的，译者根本没有足够的上下文来判断词义。这种歧义形式特别多，比如语义歧义，像“charge”这个词，可能是“给电池充电”，也可能是“收取费用”，甚至是某种财务定义；语法歧义也很常见，“empty folder”单独看，既可以是“空的文件夹”这个名词短语，也能是“清空文件夹”这个动作；还有词性歧义，“view”“open”这些词，没有上下文根本分不清是动词还是名词/形容词；另外还有结构性歧义，比如“new file viewer”，到底是“新的/文件查看器”，还是“新文件/的查看器”？指代歧义、视觉歧义也少不了，尤其是视觉歧义，必须知道字符串在软件界面的具体位置，才能确定正确的翻译方式。
其次是文本长度问题。英文界面的字段很短，翻译成中日韩语可能还会更短，但翻译成其他语言时会明显变长。比如西班牙语需要多留出25%的空间，而俄语、斯拉夫语系这类语言，甚至需要三倍于英文长度的空间，这对软件 UI 设计来说也是不小的挑战。
最后是格式化占位符与标签的困扰。软件字符串里经常会出现大量 HTML 标签和占位符，这些内容会破坏文本的连贯性，翻译时不仅要保留它们，有时候还得根据译文调整位置，对译者来说十分棘手。
这次测试比对了神经网络机器翻译和大模型翻译两种机翻的结果。他们测试了两类数据集：软件字符串和高歧义字符串。用到的工具包括 OpenAI 的 GPT-5、GPT-5 mini、GPT-4o、以及 GPT-4o mini，还有 Google 翻译。他们还开发了一个开源的翻译质量评估（TQE）工具来处理各语种译文数据、生成评估报告，后续也在 Trados Studio 中测试了该工具的运行情况。这个评估工具能算出平均质量分、中位分，列举有问题的句段示例并给出处理建议，还能展示评分分布、分析错误类型及占比，帮助人工审校人员快速定位问题句段，提升工作效率。
第一组核心实验就是原生 NMT 与 LLM 对比，也就是用未经训练的神经机器翻译，和只输入“将这种语言翻译成另一种语言”这种简单指令的大语言模型进行对比。
实验结果很明显，从评估数据来看，在测试的多种语言中，大语言模型的表现评分更高，不仅平均得分更高，需要人工审核的句段数量也大幅减少，这意味着能大大减轻人工负担、提升效率。
更有意思的是，通过分析问题分布情况发现，LLM 在准确率和语境连贯性得分上始终占优，而神经机器翻译则在风格和术语得分上表现更好。针对这个结果，我们推测，神经机器翻译能在术语和文风上胜出，可能是因为它此前接触过类似的软件文本，产生了溢出效应，而且无论是 LLM 的短板还是 NMT 的不足，其实都能通过优化提示词等方式轻松改进。
既然发现提示词优化可能改进两者的不足，他们接下来探索了第二个关键问题：当添加字符串级提示和多语种线索时，会对 LLM 翻译效果产生什么影响——即测试增强提示词对LLM翻译效果的影响
最初的实验思路是利用其他语言的译文作为参考信息，也就是“多语种三角校验”——如果一个项目已有多种语言的译文，新增语种翻译时，就把现有译文按字串为单位一块儿输入给 LLM。
实验结果最初并不统一：对于土耳其语、匈牙利语、芬兰语来说，翻译效果有所提升，但罗马尼亚语的效果反而下降了，挪威语的表现更糟。
他们深入分析后发现，问题出在评估工具上，负责质量评估的 AI 掌握的信息量少于采用多语种三角校验技术的翻译 AI，缺乏足够的上下文，无法准确评估译文质量，就像经验浅的审核员评估资深译员的作品一样，结果没有参考价值。
后来他们更新了 TQE 工具，让它也能识别上下文，结果非常显著，所有语种的翻译表现都有了明显改善，需要审核的句段数量也减少了。
更正后的评估有力地说明：从 NMT 过渡到优化后的 LLM，翻译质量全方位提升，得到了最理想的结果。
这里要给大家补充一个关键知识点：多语种三角校验要想发挥作用，核心是要寻找能消除歧义的参考语言，确保参考语言本身不会存在与源语言相同的歧义。
比如英语里的“cheese”，既可以指黄奶酪也可以指白奶酪，但在保加利亚语里这两种奶酪有不同的对应词汇，此时如果参考的是同样无法区分这两种奶酪的挪威语，就毫无意义；但如果参考能区分的斯洛伐克语或俄语，就能给翻译提供很大帮助。
他们还专门针对 20 个极容易出现歧义的句子做了测试（虽然这些句子不是真实的软件文本，但能很好地验证提示词的作用）。
结果显示，在缺失字串级提示的情况下，中文翻译得分是 81 分，提供字符串提示后，分数直接升至 96 分；土耳其语的提升更明显，从 70 分跃升到 94 分，主要提升体现在准确性和上下文连贯性上，这进一步证明了增强提示词的有效性。
前面的评估都是由 AI 完成的，为了验证结果的可靠性，他们还开展了人工评估实验，看看真实的生产力提升效果如何。
他们将经过字串级提示词优化的 LLM 翻译结果交给 RWS 进行典型的机翻产能评估，除了希腊语因测试问题数据无效外，其他四种语言的表现都很优异。这意味着 LLM 翻译能切实转化为实际效率提升：假设固定时间内人工原本只能翻译 100 个单词，那么审校 LLM 译文（配合字符串级提示词）时，处理量能达到 220 个。
因此，针对软件字符串翻译，与 NMT 机器翻译相比，大模型机翻：
除了多语种参考线索这种字符串级提示方案，他们还探索了另一个重要方向：视觉上下文（比如截图、Figma 设计稿）能否显著提升翻译质量？这也解决了“没有现成译文该怎么办”的问题。就像人类译员看到语境中的字符串能更好地翻译一样，给 LLM 提供软件界面的视觉上下文，也能大幅提升翻译精准度。
他们专门做了一个现场演示来验证这一点，选择了“coat”和“washer”这两个一词多义的单词作为待译对象，因为它们在不同场景下有不同含义，很能考验翻译的准确性。
演示使用的是基于 GPT-4 的提示词库，最初我们只设置了“将源语言翻译为目标语言”的简单系统提示词，翻译结果很不理想：在五金店场景下，“coat”本应译为“一层油漆”（法语“couche”），却被译成了穿在身上的上衣；“washer”本应指“洗衣机”，却被译成了“金属垫圈”。
随后我们优化了提示词，明确要求符合UI设计的简洁、清晰、一致、行动导向的要求，且只返回翻译内容不附带解释，同时给每个字符串配上了对应的上下文参考图片。重新翻译后，结果完全符合预期：“油漆层”译成了“couche”，“外套”译成了“un manteau”，“洗衣机”和“金属垫圈”也得到了精准区分。这个案例充分证明，通过设定全局提示词并结合图像等上下文信息，能精准锁定翻译语义，实现一一对应。
基于视觉上下文的有效性，他们探索了四种路径：截图、Chrome 浏览器（针对 Webapp）、API 以及 Figma，其中 Figma 是最高效的方式，还能实现“Figma2Dev”方案，让本地化工作在设计阶段就提前启动。
虽然这儿演示的是 Lingoport 的产品流程，但整体思路完全可以迁移到其他产品本地化流程和工具里。具体来说，设计师在 Figma 中完成设计后，通过插件发起翻译任务，插件会自动抓取文本内容和相关视觉图像作为参考上下文；系统整合后进入翻译阶段，既可以用 LLM 翻译，也可以用传统翻译方式接入翻译管理系统；翻译完成后，结果会通过本地化工具自动同步回 Figma，设计师能即时查看并调整设计方案，比如调整按钮尺寸、优化布局；同时本地化端会直接将内容推送到开发端，存入代码库或者内容管理工具（CMS），并经过开发转化语言资源文件，大大减轻了开发者的负担。后续开发端新增或修改字符串时，本地化负责人也能随时拉取变更、重新翻译更新，设计师也能同步获取最新版本。
对大家关心的成本问题，他们也做了相关研究：测试对象包含约 18000 个单词、2300 条字符串，每条字符串都配有专属图片，平均每条字串消耗约 1700 个 Token。经过测算，即使加入了图片，每个单词的成本依旧远不足一美分，而且最便宜的 GPT-4 mini 的成本低于市场上最便宜的 NMT 引擎。
不过有一点需要补充，虽然LLM成本可控，但处理图像时的响应速度会比纯文本翻译慢，因为需要将图像转化为 Token 处理。
最后，我们汇总一下本次所有实验和探索的核心结论：
祝大家新年快乐，明年本地化团队的影响力涨涨涨！
「产品本地化蓝皮书」（productloc）公众号是宣讲互联网产品全球化/本地化实践的平台，欢迎大家踊跃评论。 如果你也有兴趣和我、和大家分享自己对产品本地化的见解，请在公众号消息框发私信给我，或者和我在 LinkedIn 上建立联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。