当前位置: 首页 > news >正文

机器翻译漫谈

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

  机器翻译(machine translation),又称机译(MT),是利用计算机把一种自然语言转变成另一种自然语言的过程。 用以完成这一过程的软件叫做机器翻译系统。

  世界上许多国家长期以来都一直在从事这项研究。事实上自本世纪40年代电子计算机诞生之日起就开始了将计算机应用于语言翻译的探索。我国机器翻译的 研究可以追溯到50年代中期。今年是我国第一次机器翻译试验成功演示的40周年。40年前的那次试验虽然规模不大,但是在当时已经是世界水平了。当时世界上 能进行这样试验的国家实在是屈指可数。半个世纪以来,世界范围和我国的机译研究都曾走过一段曲折的道路,都有过60年代中期以后约10年的停滞或沉寂,不 过原因不尽相同。国外主要是受了美国曾专门组织的一个机构于1966年发表的机译界无人不晓的ALPAC报告的影响,纷纷停止了对机器翻译研究的经费支持。ALPAC 报告主要说的是:经过调查,机器翻译速度慢,准确率差,比人工翻译费用高得多,在近期或可以预见的未来,开发出实用的机器翻译系统是没有指望的。这个 报告后来虽曾受到许多严肃的批评,认为它是带有严重偏见的,但它还是对机器翻译研究造成了很大的损害。直到70年代中期机器翻译才开始在世界范围内复苏 并日趋走向兴旺。日本却是极少数未受世界范围的停滞影响的国家。80年代初日本几乎所有的大计算机公司都进行机器翻译系统的研究和开发,如富士通、日立、 日本电气、东芝、夏普等。日本在推动机器翻译研究方面的贡献为世界所公认。在它的倡导下,于1987年在日本箱根举行了第一届机器翻译峰会(MT Summit), 并决定以后每两年轮流在亚、欧、美定期举行。不久又相继成立了亚太机器翻译协会,欧洲机器翻译协会,北美机器翻译协会,以及国际机器翻译协会,还定期 出版了《机器翻译通讯》。今年九月在新加坡举行了第七届峰会,它也是本世纪的最后一次峰会,其主题是"迎接新世纪翻译的机器翻译"。我国有代表 应邀在"世界各地机译进展"的主题研讨会上介绍了我国的机器翻译研究和开发的现状,还有代表应邀参加了经费投资的主题研讨会并介绍了我国各种渠道 对机器翻译研究的投资状况。笔者应邀在会前的学术研讨会上做了题为《英汉/汉英机器翻译的过去、现在和未来》的报告。

  如今机器翻译对于许多人来说应该已经不是很陌生的的词儿了。今天我们可以在软件商店买到形形色色的PC机译软件,各种语言对的,如英文到中文的, 中文到英文的,或者日文到中文的,甚至也有英文到日文的等等,还有什么家庭版的,专业版的,配带各种不同专业词典可供选择的等等。据估计,世界上 目前市场上有1000多种不同的机器翻译软件在销售,我国具有一定规模的PC机器翻译软件也有近20种。在世界范围内PC机译软件的价格都不贵,而且价格还 在不断地下降。现在我们甚至可以在网上免费享用翻译系统的服务。因此现在用户已有较大的选择余地。当然一个用户在选择机译系统时,应该首先很好地 弄清自己的需求。具体来说,我们有如下的建议。

  第一,如果你的翻译任务是较稳定的或长期的,专业单一的,翻译结果要达到出版水平的,你可能是一个翻译公司、或一个专业情报所,那么你可以选择 配有大规模相应领域的专业词典的,并且又经得起大批量、长时间翻译运行的(有的系统会死机的)系统。同时更理想的是你还可以再配备一个"翻译记忆 "系统,它可以帮助你处理文本格式问题(如字体、图表、脚注等),而且可以把你经过修改的正确译文保存起来供以后翻译时再利用。

  第二,如果你的翻译任务是临时性的,专业不单一,翻译质量要求无须达到出版水平的,那么你可以选择配有多个领域的专业词典的,但还是应经得起 大批量、长时间翻译运行的系统。

  第三,如果你是为了浏览网上信息要用到翻译,那么你一定要选择可以在网上运行的系统。如果你的外语水平还可以但词汇量有限,那么还可以选择一种 只有大规模词典但可随点随译的系统。

  今天机器翻译比起10年前,可以说相当繁荣。但是我们愿意提醒,在这繁荣的后面,却存在着危机。前面说到那个ALPAC报告曾给机器翻译带来的创伤 如今似乎已被抚平了。但实际上它的阴影始终会时不时地再出现在机译研究者的头上。如今随着有越来越多的机译系统走向市场,政府的投资者感到在这种 情况下如果还要投资攻关似乎有点名不正言不顺了。而商家则只是想现在该是把现成的技术包装包装就可以赚钱的时候了。经常会听到老板们会这样问研究 者,"你估计开发出产品要多长时间?你的系统正确率如何?",大概没有一个研究者会回答说,将来"正确率大约在百分之五十左右"的。 如果果真那样回答,那么他的项目还不当场就被"枪毙"了。可是现有的机译系统(不仅是英汉或汉英,国外的其他语言对的系统)在面对真实文本时, 其正确率实际上有多少呢?机译的译文质量确实还远不能令人满意。近来国外有些人挖苦地说"MT,不是machine translation的缩写,而是mad translation (疯子的翻译)的缩写。他们是近乎要跟机译来番决战似的。他们劝说人们不要购买机译系统,要翻译的话应该雇翻译人员。国内也有人讽刺地说,有了机器翻译, "满篇英文难不住,满篇中文看不懂"。这些固然是比较极端的评价,但机译译文质量确实一直是个老大难问题。著名的机译评论家Hutchins在最近的 机器翻译峰会上的发言中说,机译译文质量至今并没有取得实质性的进展,很多50年前未解决的问题如今依然存在。还有一种更加深层的危机,那是来自研究人员 自身的。他们说"在现有的技术条件下,机译译文质量也只能这样了。"说这话时似乎他们不是"现有的技术条件"的创造者。这样一来, 可能出现的情况将是投资者和研制者都在以较低水平的系统忙于行销赚钱,而不再有足够的经费和技术投入。机器翻译无论在理论上或是技术上都还未成熟。 现在只是由于人们对于克服语言交流的障碍有着很强烈的需求,尤其是因特网的出现这种需求更显突出,机器翻译才获得了以较低的译文质量满足这种需求的 机会,并利用这一机会来求得进一步的发展。我们对这一现实要有清醒的认识。在行销上,应切忌不切实际的宣传。现在在报纸杂志上常能见到关于机器翻译 系统的过度夸张的宣传。从长远看,这是"自砸牌子"的不智作为。正确的做法是把产品拿到用户那里去,老老实实地告诉他们机译系统能做什么和 不能做什么,如何来利用它,利用它之所长,避它之所短。同时根据用户的需求来调试和改进系统。换句话说,多做培养用户,培养系统,培养市场的工作。 近20年左右,机器翻译研究的方法真可谓花样翻新,令人目不暇接,有基于规则的、基于知识的、基于语料库的、基于统计和语料库的、基于例子的、基于 对话的等等,从另一种角度,还有直接法、转换法、中间语言法等等。但其中哪一种也未能在翻译质量上取得实质性的突破。如何才能取得实质性的改进呢? 我们不妨先对现有的机译和人译做一番比较。

  机译:

  1. 一句一句处理,处理第一句时不知道第二句的内容是什么,处理第二句时,也不再去参考第一句的内容了;

  2. 对源语言的分析只是求解句法关系,完全不是意义上的理解;

  3. 它的开发者要求它几乎是万能的,它似乎什么领域都能应付,从计算机到医学,从化工到法律,似乎只要换一部专业词典就可以了;

  4. 它的译文转换是基于源语言的句法结构的,受源语言的句法结构的束缚;

  5. 它的翻译只是句法结构的和词汇的机械对应。

  人译:

  1. 一般会先通读全文,他会前后照应;

  2. 对源语言是求得意义上的理解;

  3. 只有专业翻译人员,没有一个是可以包打天下的万能翻译人员的;

  4. 他的译文是基于他对源语言的理解,不受源语言的句法结构的束缚;

  5. 他的翻译是一个再创造的过程。

  机器翻译研究归根结底是一个知识处理问题。它涉及到有关语言内的知识、语言间的知识、以及语言外的世界知识,其中包括常识和相关领域的专门知识。 我认为从实用的角度看,全自动高质量的机器翻译不应该是个目标,至少不应该是近期的目标,但是从研究的角度说,全自动高质量却应该是个目标。因为这样 我们不仅能够建立机译系统,而且能够探索人译的机制。近年来我在许多场合都强调机器翻译应该到了有所突破、有所创新的时候了。下个世纪的机器翻译研究 应在如下三个方面有所突破:

  第一,大语境,而不再是一个句子一个句子孤立地处理;

  第二,基于理解,而不再是停留在句法分析的层次上;

  第三,高度专业化、专门化,而不再是个"万事通,样样松"了。




转载于:https://my.oschina.net/apdplat/blog/419497

相关文章:

  • 产生一个长度为100的int数组,并向其中随机插入1-100,不能重复
  • 去掉默认输入框按下时的蓝色边框
  • 阅读第8,9,10章
  • XenDesktop7.6安装部署入门教程
  • 我的视频教学之路
  • .aanva
  • 理念
  • HihoCoder第十一周:树中的最长路
  • Android 四种启动模式 已看晕
  • #etcd#安装时出错
  • mysql主从同步配置详解
  • 中海集运[601866]
  • 把man手册转换成中文
  • lambda 内容的介绍
  • debian7源码安装nrpe时Cannot find ssl libraries及解决办法
  • 【跃迁之路】【585天】程序员高效学习方法论探索系列(实验阶段342-2018.09.13)...
  • Android 初级面试者拾遗(前台界面篇)之 Activity 和 Fragment
  • CSS3 聊天气泡框以及 inherit、currentColor 关键字
  • CSS选择器——伪元素选择器之处理父元素高度及外边距溢出
  • JS变量作用域
  • JS字符串转数字方法总结
  • JWT究竟是什么呢?
  • Linux下的乱码问题
  • puppeteer stop redirect 的正确姿势及 net::ERR_FAILED 的解决
  • python学习笔记-类对象的信息
  • Rancher-k8s加速安装文档
  • Swoft 源码剖析 - 代码自动更新机制
  • Synchronized 关键字使用、底层原理、JDK1.6 之后的底层优化以及 和ReenTrantLock 的对比...
  • uni-app项目数字滚动
  • XML已死 ?
  • 第13期 DApp 榜单 :来,吃我这波安利
  • 飞驰在Mesos的涡轮引擎上
  • 关于for循环的简单归纳
  • 前端技术周刊 2019-02-11 Serverless
  • 前端之React实战:创建跨平台的项目架构
  • 使用SAX解析XML
  • 资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解 ...
  • ​configparser --- 配置文件解析器​
  • #控制台大学课堂点名问题_课堂随机点名
  • ${ }的特别功能
  • (delphi11最新学习资料) Object Pascal 学习笔记---第8章第5节(封闭类和Final方法)
  • (动手学习深度学习)第13章 计算机视觉---图像增广与微调
  • (力扣题库)跳跃游戏II(c++)
  • (太强大了) - Linux 性能监控、测试、优化工具
  • (原創) 如何使用ISO C++讀寫BMP圖檔? (C/C++) (Image Processing)
  • (转)Google的Objective-C编码规范
  • (转)清华学霸演讲稿:永远不要说你已经尽力了
  • *上位机的定义
  • .NET 8.0 中有哪些新的变化?
  • .NET CF命令行调试器MDbg入门(三) 进程控制
  • .NET CORE 3.1 集成JWT鉴权和授权2
  • .NET Core实战项目之CMS 第十二章 开发篇-Dapper封装CURD及仓储代码生成器实现
  • .NET Micro Framework初体验(二)
  • .NET/C# 使窗口永不获得焦点
  • .NET/C# 在代码中测量代码执行耗时的建议(比较系统性能计数器和系统时间)...