传统的机器翻译长期以来一直存在问题,即使引入了神经机器翻译和大型训练数据集也是如此。 尽管当使用可预测和直接的语言针对特定领域进行微调和训练时,它可以产生有趣的结果,但当应用于各种领域、语言和情况时,它通常是不可靠和不稳定的。
许多知名的翻译人员仍然不喜欢机器翻译,并拒绝将其用作初稿或完全重写动态。 这凸显了机器和人类之间的鸿沟,即使近年来机器翻译发生了巨大的发展。 根据我们的调查,只有一小部分翻译人员认为机器翻译是一个有价值的盟友。
传统机器翻译要么过于通用且不稳定,要么过于具体,需要特定情况才能有效,例如具有简单语言结构或领域划分的大量内容,如技术手册、产品知识库和支持文献。 即使是经过训练的引擎也难以处理术语库、翻译记忆库和语言语料库训练之间的不一致和差异。
这些包括公司审阅者或译员在培训过程后更新的词汇表、词汇表与培训语料库之间的差异、为达到最高质量而需要创建和维护特定引擎、翻译记忆库与训练语料库的偏差,以及诸如翻译实体或其他专有名词的愚蠢错误,缺乏文化或语言敏感性。
这些示例导致动态不可靠,并且给翻译人员带来了具有挑战性的审核过程。 此外,管理调整和训练的 机器翻译 模型通常需要一个或多个专门从事这些工作的本地化工程师,而大多数中小型翻译机构和本地化项目没有足够的资源来支持这些工作。
然而,上下文感知翻译 大型语言模型改变了这一点。 上下文是指不是文本本身但帮助引擎理解文本以及如何处理文本的所有信息。 上下文的示例包括术语表、翻译记忆库、过去的反馈和退回率,但上下文可以是任何信息。 对于在设计上可以考虑数十亿个参数的大型语言模型,您决定使用的上下文数量实际上没有限制。
下面是一个考虑上下文的示例:

注意,这里有 89% 的翻译记忆库动态和一个机器翻译动态。 TM动态在葡萄牙语中将我们的“engine”称为“motor”,而MT在葡萄牙语中将engine称为“mechanism”。 然而,词汇表明确规定 “engine” 应保留为 “engine”。 当通过 Bureau Works Translate 进行处理时,我们的模型会考虑此首选项(以及其他首选项):

Bureau Works Translate 不仅根据最新的术语表版本插入正确的术语,还对文本进行必要的更改,以确保在目标语言中流畅阅读,同时也考虑到翻译记忆库提供的语言环境。
使用Bureau Works Translate,像ChatGPT这样的大型语言模型可以考虑其自身的训练数据集、特定的翻译记忆库、术语表和其他相关背景,为译员在特定项目中提供细致入微、具有上下文意识的动态翻译。 我们可以实时考虑最新的术语表和翻译记忆库的更新,这意味着无需反复提交更新的术语表和翻译给经过训练和调整的机器翻译服务器,以期望它们能考虑到语言偏好。

使用Bureau Works Translate,您可以即时训练和翻译,任何翻译项目、任何规模的翻译记忆库和任何规模的术语表都可以从其文本合并和语言概率功能中受益。 没有设置时间,也不需要事先训练。
根据我们的初步研究,这样的引擎可以为translators提供打破长期以来对利用机器输出的抵制的动态。 我们的引擎还为译员和引擎之间的对话打开了大门。 如果你能立即从中受益,那么丰富词汇表就更有意义,如果你从经验中知道至少有类似于批判性和适应性思维的东西,那么更容易信任机器。
除了 情境感知翻译之外,我们还为翻译人员打开了与语言模型互动的大门,以便他们可以重新审视自己的选择、获得替代建议,甚至在需要时开始对话。
使用大型语言模型的上下文感知翻译不仅仅是一个改进的翻译前过程。 这是朝着人类与机器合作以更少的努力和时间生产更好内容的坚实一步。
展望未来,上下文将继续以前所未有的方式扩展,我们将能够编写多语言文本,同时考虑到用户行为、网络分析以及大型语言模型可以使用和理解的大量其他信息体。 这只是一个开始,它已经改变了一切。