复旦新生提出革命性机器翻译理论

[145308] 主题：复旦新生提出革命性机器翻译理论


作者： leaflet	标题：复旦新生提出革命性机器翻译理论[转载]
昵称： Leaf	来自： 61.129..
经验值： 96654	发贴时间： 2004年01月04日 22:52:34
等级： ★★★★☆	长度： 9118字

	发信人: TheSameStar (伤心难画), 信区: DCST 标题: 发誓给清华计算机系一点颜色瞧瞧-复旦新生提出革命性机器翻译理论发信站: BBS 水木清华站 (Fri Jan 2 13:47:40 2004), 转信复旦计算机系新生姚子渊日前提出了题为“BABELCODE 方案简介 - 创作可机器翻译的内容”的介绍性文章，标新立异的在解决机器翻译这一世界难题上奠定了可行的理论基础。北京时间12月14日夜，复旦大学计算机科学与工程系大一保送生姚子渊，向他刚刚建立的“BabelCode 计划”网站 www.babelcode.org 上传了介绍这一革命性机器翻译研究成果的一篇文章（具体网址为 http://www.babelcode.org/do c/intro_cn.htm）。他充满信心的表示，将马不停个计划直到把具体的实用程序普及到每个人的日常生活而不懈努力。目前机器翻译和计算机辅助翻译的理论和实践存在严重问题: (1) 分析型与统计型机器翻译 (machine translation) 方式产出令人误解和不舒服的结果，主要归因于完美的歧义剔除是不可能的。所以它们对于行业级强度的应用是不合格且不可靠的。 (2) 计算机辅助翻译 (computer-aided translation) 牵涉到真人翻译员并且对多语言译本需要额外的努力，造成巨大的费用、时间和真人翻译失误的风险。而姚子渊提出的方法，则是帮助作者直接创作出可以被机器正确翻译的内容，并保证翻译的正确性、可读性和生产率，外加一个好处：你可以自动由单个源文件得到任意多个语言译本。他是如何做到的呢？首先让我们回顾机器翻译的致命弱点：无法剔除自然语言的二义性。自然语言的二义性是与生俱来的，可以说是自然语言的“原罪”。例如这个句子： I am told to read a book by Tom. 存在两种理解：(1) 我被告知去读一本 Tom 写的书。(2) Tom 叫我去读一本书。这两种理解都是正确的，那究竟应该如何选择呢？要知道，在实际操作中，计算机算法能把一个自然语言句子解析成远远超过两种理解。不难想到，原作者知道到底是哪种意思。那么，为什么不让原作者在写句子的同时，把语法结构和多义词的二义性解析成没有二义性呢？！于是不难想到，我们可以用类似书写数学算式或者计算机程序的格式来产生一个在翻译意义上没有二义性的句子。然后，特别设计的翻译程序就能在逐词翻译的基础上输出一篇像样的译稿。我们称这种书写方式为“解析式构建”。例如以上句子，只要加上一对括号就能帮助计算机选择你意图的那种句意：(1) I am told (to re ad a book by Tom); (2) I am told (to read a book) by Tom . 当遇到一个多义词，例如“伶俐”（1. 聪明; 2. 轻巧; 3. 爽快; 4. 正当）时，作者可以再附加一个“索引关键字”来取消歧义：伶俐:聪明。那么，是不是问题就解决了呢？不。可以想象，当一句子很长、很复杂时，对每个句子的每个成分逐个进行语法结构的标记和词义的解析，是一件非常繁琐的事。另外，解析性构建有一个致命的弱点：它本质上还是让翻译程序进行逐词翻译。这就会导致翻译结果比较生硬、绕口，而且遇到一些文化上、习惯上说法的不同时，更会让译作的读者不知所云。举个例子：中国人说“我在...上比谁强”，英国人说“我在...里比谁强 (better than sb. in sth.)”。如果一个中国作者仅仅按照解析性构建的方法，而对英语又一窍不通的话，他必然会导致介词“在...上”混入最终的英文译本，形成 “I‘m better than sb. on sth .“。这还算是个轻微的例子，但你已经意识到显然有更可怕的例子。怎么解决呢？索性，不要让作者亲自处理这些细节问题，而把精力集中在内容的写作上。于是姚子渊又提出了第二个必杀技：宏调用。什么是宏？你可以理解为函数，但怎么称呼不是主要的。我们假设现在有一个宏原型: PREDICATE 胜过 (名词短语 ThanWhom, 名词短语 InWhat); 那么作者可以直接调用这个宏来表达他的意思: 我胜过(小明, 跑步). 你发现, 作者根本不必去管小明和胜过是什么语法关系, 跑步和胜过是什么语法关系 , 不必去管任何内在的细节. 他只要简单的输入宏的名称, 然后 “填空“, 把参数填上即可. I am told to read a book by Tom. 存在两种理解：(1) 我被告知去读一本 Tom 写的书。(2) Tom 叫我去读一本书。这两种理解都是正确的，那究竟应该如何选择呢？要知道，在实际操作中，计算机算法能把一个自然语言句子解析成远远超过两种理解。不难想到，原作者知道到底是哪种意思。那么，为什么不让原作者在写句子的同时，把语法结构和多义词的二义性解析成没有二义性呢？！于是不难想到，我们可以用类似书写数学算式或者计算机程序的格式来产生一个在翻译意义上没有二义性的句子。然后，特别设计的翻译程序就能在逐词翻译的基础上输出一篇像样的译稿。我们称这种书写方式为“解析式构建”。例如以上句子，只要加上一对括号就能帮助计算机选择你意图的那种句意：(1) I am told (to re ad a book by Tom); (2) I am told (to read a book) by Tom . 当遇到一个多义词，例如“伶俐”（1. 聪明; 2. 轻巧; 3. 爽快; 4. 正当）时，作者可以再附加一个“索引关键字”来取消歧义：伶俐:聪明。那么，是不是问题就解决了呢？不。可以想象，当一句子很长、很复杂时，对每个句子的每个成分逐个进行语法结构的标记和词义的解析，是一件非常繁琐的事。另外，解析性构建有一个致命的弱点：它本质上还是让翻译程序进行逐词翻译。这就会导致翻译结果比较生硬、绕口，而且遇到一些文化上、习惯上说法的不同时，更会让译作的读者不知所云。举个例子：中国人说“我在...上比谁强”，英国人说“我在...里比谁强 (better than sb. in sth.)”。如果一个中国作者仅仅按照解析性构建的方法，而对英语又一窍不通的话，他必然会导致介词“在...上”混入最终的英文译本，形成 “I‘m better than sb. on sth .“。这还算是个轻微的例子，但你已经意识到显然有更可怕的例子。怎么解决呢？索性，不要让作者亲自处理这些细节问题，而把精力集中在内容的写作上。于是姚子渊又提出了第二个必杀技：宏调用。什么是宏？你可以理解为函数，但怎么称呼不是主要的。我们假设现在有一个宏原型: PREDICATE 胜过 (名词短语 ThanWhom, 名词短语 InWhat); 那么作者可以直接调用这个宏来表达他的意思: 我胜过(小明, 跑步). 你发现, 作者根本不必去管小明和胜过是什么语法关系, 跑步和胜过是什么语法关系 , 不必去管任何内在的细节. 他只要简单的输入宏的名称, 然后 “填空“, 把参数填上即可. 实际上, 宏和单词一样被定义在词典文件里, 针对不同的目标语言有不同的内部实现 . 正是这些内部实现决定了一个宏对于特定目标语言的翻译结果 . 而这些内部实现是预先写好的解析性构建. 要知道更详细的内容, 可以去上面的网址查看介绍. 显然, 宏调用相对解析性构建好处多多, 特别是遇到要表达难以用语法解释的习惯用法的时候. 者也应证了语言学家的一句话:“语法不是从来就有的, 是人们观察语言习惯的过程中总结出来的. 习惯用法相对语法总是第一位的.“ 具体创作的时候, 必然有大量预备好的宏供你调用. 一个人说话的种类是规律的(口头禅), 因此不难达到“任何可以想到的说法都有相应的宏“的境界. 只有当你创造性的表达一个构造的意念时, 才不得不使用解析性构建. 况且, 输入环境在人机界面 (HCI) 上的不断改进, 必将使解析性构建也越来越简单. 想象一下现在的微软拼音是多么顺手吧. 现在你对这个东西的原理也许有些明白了, 恭喜! 让我们了解一下姚子渊下一步要做什么. 首先, 他已经对这一整套方法进行了全面的理论探讨, 并完成了解析性构建和词典格式的具体格式规范. 可以说下一步就是人工模拟程序翻译几篇典型文章和编写演示程序来吸引更多程序员(特别是开放源码志愿者)投入这方面的软件开发了. 计划写三个 demo: (1) 对英语的集成创作环境. (2) 对汉语的翻译引擎. (3) 对德语的翻译引擎. 之所以选择德语是因为德语在科技文献和文艺著作方面的影响力, Google “时代精神“ 杂志也表明德语是第二大查询语言. 再者, 是对爱因斯坦, 歌德和一大批德裔核物理学家的纪念. 目前, 已经有多个计算机科学方面的资深青年参与或认同了姚的提议, 特别是现在就读于伊利诺斯州大学香槟分校 (UIUC) 的前国际信息学 PREDICATE 胜过 (名词短语 ThanWhom, 名词短语 InWhat); 那么作者可以直接调用这个宏来表达他的意思: 我胜过(小明, 跑步). 你发现, 作者根本不必去管小明和胜过是什么语法关系, 跑步和胜过是什么语法关系 , 不必去管任何内在的细节. 他只要简单的输入宏的名称, 然后 “填空“, 把参数填上即可. 实际上, 宏和单词一样被定义在词典文件里, 针对不同的目标语言有不同的内部实现 . 正是这些内部实现决定了一个宏对于特定目标语言的翻译结果 . 而这些内部实现是预先写好的解析性构建. 要知道更详细的内容, 可以去上面的网址查看介绍. 显然, 宏调用相对解析性构建好处多多, 特别是遇到要表达难以用语法解释的习惯用法的时候. 者也应证了语言学家的一句话:“语法不是从来就有的, 是人们观察语言习惯的过程中总结出来的. 习惯用法相对语法总是第一位的.“ 具体创作的时候, 必然有大量预备好的宏供你调用. 一个人说话的种类是规律的(口头禅), 因此不难达到“任何可以想到的说法都有相应的宏“的境界. 只有当你创造性的表达一个构造的意念时, 才不得不使用解析性构建. 况且, 输入环境在人机界面 (HCI) 上的不断改进, 必将使解析性构建也越来越简单. 想象一下现在的微软拼音是多么顺手吧. 现在你对这个东西的原理也许有些明白了, 恭喜! 让我们了解一下姚子渊下一步要做什么. 首先, 他已经对这一整套方法进行了全面的理论探讨, 并完成了解析性构建和词典格式的具体格式规范. 可以说下一步就是人工模拟程序翻译几篇典型文章和编写演示程序来吸引更多程序员(特别是开放源码志愿者)投入这方面的软件开发了. 计划写三个 demo: (1) 对英语的集成创作环境. (2) 对汉语的翻译引擎. (3) 对德语的翻译引擎. 之所以选择德语是因为德语在科技文献和文艺著作方面的影响力, Google “时代精神“ 杂志也表明德语是第二大查询语言. 再者, 是对爱因斯坦, 歌德和一大批德裔核物理学家的纪念. 目前, 已经有多个计算机科学方面的资深青年参与或认同了姚的提议, 特别是现在就读于伊利诺斯州大学香槟分校 (UIUC) 的前国际信息学奥赛金牌得主邵铮, 现在攻读 TAMU 电子工程博士的网友 Shanfeng 以及活跃在 “信息学奥林匹克论坛“ (www.ioiforum.org) 上的国内信息学高手们. 姚在保送复旦前也是一位信息学选手, 在最后一次全国比赛中仅差一名而与清华计算机系失之交臂, “发誓给清华计算机系一点颜色瞧瞧“正是他半年来发现和坚持本研究的最初动力. 姚认为, 强烈的动机, 适当的信息学竞赛锻炼, 良好的英语交流和信息查找能力, 通过英文共享软件开发与推广得到的对 IT 产业研发现状的深刻理解, 是有所研究建树的必备条件. 最后, 为了确保他人不能冒领专利权, 姚已经向 USENET 新闻组发表了他的理论文档和技术细节, 作为“事先存在 (prior art)“ 的证据. 更让我们认识到知识全面的重要性.
	========== * * * * * ==========


		Top