万众瞩目的 iOS14 带来了全新的内置翻译功能。 打开它,第一眼看去平平无奇。 翻译应用本体非常简洁。在顶端选好互译的语言后,用户可以通过文字或语音输入需要翻译的内容,翻译后的文字会以蓝色字体显示在下方。 苹果翻译目前支持包括中文、英语、日语、德语、西语在内的 11 种常用语言。 不过,当我们仔细“把玩”了一下苹果的这个翻译软件后,发现事情并不简单。 一开始我们发现,除了日常用语外,连一些不太常见的说法,它也能轻松解决: 比如,输入“快乐肥宅水”后,苹果翻译给出的结果直接是“可乐”。 这勾起了我们的兴趣,翻出一些上古老梗试了试,居然也忠实地“还原”了—— “蓝瘦香菇”这一题苹果给出的答案是“Sad.gif”。(“蓝瘦香菇”是2016年火遍网络的梗,源自一失恋的南宁小哥拍摄的自拍视频,他用方言表达“难受,想哭”,被“直译”为了“蓝瘦香菇”) 这实在太神奇了。要知道,谷歌翻译在这一题的答案还是: 我们又接着试了试更多网络流行语,发现苹果翻译很有自己的想法。 输入“奥利给”后,苹果翻译表示这个词是“酷”的意思。 成精了! 而且,在面对跨文化交流的微妙场合时,苹果翻译也没有输掉。 日文的“月色真美”经了它的手就变成了“我爱你”。日本网友纷纷表示对苹果好感大增。 然而随着先用上 iOS14 的一批人,像我们一样不断“试探”苹果翻译,大家很快发现,这个应用开始有点不对劲了。 比如输入“五五开”,出现的英文是“卢本伟”……(卢本伟是一名前斗鱼主播,在一次游戏比赛中被问到和比自己实力强大很多的对手比赛什么感受,他强行回答了“五五开”,自此在游戏圈变成这个词的代名词,但在游戏圈外,可能并不是所有人都知道这个梗) 而输入“滚筒洗衣机”,日语直接显示“工藤新一”,不由让人替真的需要在日本购买洗衣机的人捏了一把汗。(因为“工藤新一”的日语发音,听起来很像滚筒洗衣机。所以许多中国动漫迷会这么称呼他。但放在一个“正经”的翻译软件里,是不是太随意了?) 至此,苹果翻译给人的感觉已经从“能精准翻译出晦涩中文梗的精髓”变成了“这是不是有点太随意,要耽误真正想要翻译的人的正事?”的疑惑了。 而且,在另一些时候,苹果翻译表现得更是好像沉迷于玩烂梗的小鬼。 明明只是普通的一句“一袋米要扛几楼”,都硬要翻译成“感受痛苦吧”。(因为后者的日文读音,听起来就像是中文的一袋米要扛几楼,诸君可以打开苹果翻译一试......) 类似的翻车时刻越来越多,大家就开始觉得苹果的“随心所欲二次元”浓度也未免太高了。 被“污染”的语料“把玩”至此,我们实在是好奇,是谁“教坏了”苹果呢? 虽然苹果一向对自家的技术三缄其口,这次也一样没有说明 iOS14 到底用到了什么模型,但我们可以参考苹果翻译的老前辈 Google 翻译。 Google 翻译用到的是 Seq2Seq (Sequence to Sequence) 模型,Seq2Seq 由两个循环神经网络模型协力组成,一个用于对输入序列进行编码,一个用于对输出序列进行解码。 当输入中文“知识就是力量”时,编码模型把每个字都标上一个矢量,其中每个矢量代表到目前为止已读取的所有字的含义。在整个句子编码结束后,解码器即会开始生成对应的英语句子。 通过分析大量的语料数据,模型能自动从中学习出相应的语法规则,也就是说,工程师教给模型什么,模型就学会什么。因此,苹果的工程师可能为苹果翻译 feed 了太多网络平行语料,导致苹果翻译被网络用语“污染”,而识别不出文本原来的含义。 苹果翻译出现失误的另一个可能性是,苹果翻译引入了知识图谱。 知识图谱是 Google 于 2012 年提出的概念,本质上是一种基于图的数据结构。在知识图谱中,每个名词(又叫实体)都是一个节点,每个节点间又有逻辑关系线相连。通过这种知识图谱,神经网络能更好地理解上下文之间的关联。 也许在苹果翻译构建的知识图谱中,“五五开”被链接到“卢本伟”这个实体,而这个实体又可以被翻译为“Lu Benwei”,同理,“滚筒洗衣机”也可能被链接到了“工藤新一”这个实体。 因为网络平行语料和知识图谱的存在,翻译模型在面对独立的名词时很容易翻车。比如说“瓜皮”,苹果直接按方言理解,翻译成“笨蛋”。 不过,根据我们对它原理的判断,想要更准确的翻译,解决方法之一就是在苹果翻译出现错误时,我们可以尝试为文本添加上下文,来帮助模型更好地理解。 比如把“瓜皮”改成“我不吃瓜皮”,把“滚筒洗衣机”改成“滚筒洗衣机多少钱”。 苹果的这些翻译确实带来了很多乐趣,但当人们真的需要用它来完成跨语言沟通时,又不由得捏一把汗。 现在问题来了,这样的苹果翻译你喜欢吗? |
Copyright © 1999 - 2024 by Sinoquebec Media Inc. All Rights Reserved 未经许可不得摘抄 | GMT-5, 2024-12-22 17:02 , Processed in 0.142050 second(s), 23 queries .