AI in the Translation Business: Beyond Machine Translation

当翻译行业遇上AI,就只是机器翻译吗?

2020-07-28 07:30 GALA

本文共1799个字,阅读需18分钟

阅读模式 切换至中文

The idea of this article is to identify and briefly describe areas in the translation business that may benefit from implementation of Artificial Intelligence and particularly Machine Learning. Since AI is not completely predictable, implementation of any kind of AI also brings new risks. So, the result of either introduction of AI or replacement of good old algorithmic automation with an Artificial Intelligence have impact Or a positive breakthrough. In linguistics, we have been seeing a continuous evolution of Machine Translation – the most evident example of ML, and we already know what to expect from it, what the benefits are, and how to address the risks. How we manage it also presents a great potential for applying ML to make improvements. This includes automated decision-making based on acquired data to either provide human workers with pointers or to eliminate them in order to resolve bottlenecks in Continuous Development/Continuous Translation. Or for making predictions and bringing to light potential risks (of missing a deadline, losing a client, etc.) and maybe to propose corrective measures. As there are different areas to which an ML technique could be applied and different learning approaches (supervised or unsupervised learning, reinforcement learning, transfer learning, etc.), a search of the best combinations is an interesting journey that we would like to follow. First steps: ML-powered vendor suggestion A couple of years ago, we conducted a survey among our project managers to find out in which area the use of machine learning could simplify and speed up their work. It turned out that the project manager spends quite a lot of time searching for the right vendor to do a particular job, and this is far from the project manager’s favorite activity. This was why we began experimenting with ML to select the best vendor for a project. To begin with, we wanted to find out how realistic it was to train a neural network to make the same choice as human Project Managers. We took the initial data and assigned vendors from several tens of thousands of already completed jobs and used them to train a model. Although a variety of sophisticated neural network architectures are available, we chose a simple regression classification model, and it performed fairly well. Validation showed that the model made the right choice in more than 99% of cases. However, when trying to use this model’s output in production, we found that often selected vendors were in fact not suitable. This was due inter alia to the fact that in the past, work was often given to a vendor that was far from the best one for the job from today’s perspective. The principle of "Garbage in – Garbage out" in action. Re-evaluation of PM activity landscape Recently, we conducted another survey to understand on which activities managers spend the majority of their time in project management. In addition, it was interesting to learn in which other areas it makes sense to experiment with machine learning. This survey showed that the search for the best vendor for a project is still the number one task. It also became clear in which other areas to work. The table below lists activities of project managers we are going to improve and ideas on how to partially automate this type of activity or completely pass it to the machine. The system means our Project Management / Enterprise Resource Planning system. Manual activity How to partially automate with ML How to eliminate the manual activity Looking for resources Suggest resources (vendors, TM, glossary, etc.) from similar projects Choose the best vendor for each job considering language pair, domain, qualification, experience, cost, availability, productivity, PM/reviewer feedback and other parameters. Project setup and planning Propose project workflow according to SLA and similar past projects, estimate task ETAs and critical path - Manual preparation of vendor instructions Extract key requirements and draft structured vendor instruction based on them - Deadline monitoring Estimate probability of not meeting deadline in real time based on historical data + PM alerts A few control layers could provide reliable deadline control to eliminate manual efforts altogether Correct data in the system Background analysis of data consistency based on common patterns + alert responsible about possible wrong data - Vendor suggestion 2.0 As mentioned above, the ML-based vendor suggestion worked, but often gave results which were wrong (or at least seemed to be “wrong” for some PMs). To resolve this, we decided to: Consider who is managing this project (and therefore receives a suggestion). This allows customization of ML output on a personal/department basis, thus, to continue re-using collected data across different PMs and eliminate “wrong” suggestions at the same time.) Reduce the weighting of records in the training/validation data set as they become obsolete. Thus, more recent data take precedence over data that is five years old, and the data older than five years is not considered at all. The results of using this improved architecture have not yet been announced, but we already have a list of adjustments for the next iteration. Instead of a complete regular retraining of the model on the data set over the past five years, we will try to switch to reinforcement learning on the data that will come after the initial training of the network. Apart from that, we can just compare a new project with completed past projects considering such characteristics as Client/Account, language pair(s), domain, SLA and a linguistic snapshot of text to be translated (hello Natural Language Processing!) And simply reuse resources from matching past projects where appropriate. What else on the ML roadmap? Correct data in the system While processing data contained in the records of completed jobs, we found a number of inconsistencies. Analyzing them, we realized that with a little extra effort it is possible to identify with a high degree of certainty such incorrect data, the existence of which also poisons the lives of project managers. Why incorrect data appears could be a wrong user action, an error in the program code or just a trivial typo. No matter what it was, at least we could identify it. And there is no reason not to do that. So, the way to detect erroneous data could be either an extra analysis during a scheduled data processing task or a separate scheduled data analysis task. In both cases it’s supposed to identify cases that do not match a common pattern (with a regression model). Automatic correction of data that seem incorrect would be too risky. Therefore, it is enough to report a potential error to the responsible employee who can verify and fix it if needed. Project setup and planning Often at the start phase of a project such as quotation or project acknowledgement, it is necessary to determine a realistic project deadline. To get an answer to this question, we need to evaluate the deadline for each stage in the project workflow, calculate the critical path and add some time buffer for contingency. The estimated deadline for each specific task can be found by a neural network that was previously trained on data from completed tasks. There is another option that would work for a quick preliminary estimation of the deadline: to train the network on the data of previously completed projects, taking into account the volume, language pairs, domain and other characteristics of the project. The estimate given by such a network will be approximate, but such an algorithm is much simpler to implement. Deadline monitoring For project deadline monitoring we can use the same approach as for project planning. However, when the project has already been launched and work is in full swing, we have much more data about it. For example, it is known which tasks have already been completed and which specific vendors are assigned to the remaining tasks. Accordingly, in this case, it is enough for us to evaluate the realistic completion time for the remaining tasks, calculate the critical path, add it to the current time to estimate the most probable project completion time and compare it with the agreed deadline. If the estimated completion time is earlier than the agreed deadline, we are happy – there is every chance to meet the deadline. And if it’s later, then by applying the difference to a suitable normal distribution histogram of the, you can roughly estimate the probability of still meeting the deadline (which in this case will definitely be lower than 100%). Manual preparation of vendor instructions Although preparation of clear, consistent and up to date instruction for vendors is an important part of the Project Management routine, it often ends up in copy-and-paste of client instructions which is crude and unrewarding. While maintaining a set of up to date instructions for all types of vendors (like Engineer, Translator, Editor, Proofreader, DTP specialist, …) involved in the workflow for a certain account is a good practice, this could be excessive or just not realistic in some cases. Here to help us are such Natural Language Processing techniques as Information Extraction and Named Entity Recognition. Running them on a project description received from a client in non-structured format, we could get all those project properties (such as volume, language pair, account, project name, deadline and many more) extracted as separate values. Then we just fill in a structured instruction template with them to get a draft of the vendor instruction. And if you do not have a corresponding project created in your Project Management System yet, it may be a good idea to create a project based on the extracted project properties. Build or buy As technology moves forward, and the world becomes more and more digitalized, software development becomes more and more important to Linguistic Service Providers. However, complex, relatively new and quickly evolving areas like Machine Learning could still be too difficult to adopt. To deal with this, a company may consider either building its own ML microservices with Python/R or use excellent cognitive services provided by such IT giants like Google, Amazon, Microsoft, or integrators like Intento. Machine Learning services provider Pros Cons Local proprietary development Better understanding of what happens under the ML hood Absolute confidentiality Better availability ML dev team may be too expensive for a small/mid-sized company Development may take longer Product quality may be lower Professional cloud service Quick start Proven quality solutions Higher peak performance Disclosing of data to a 3rd party More expensive in the long run Although the results of adopting ML could be amazing, they are accompanied with risks. So it makes sense to implement ML solutions as helpers in an operational environment but to keep a human eye on what they do until you can trust them and properly evaluate the possible risks.
本文旨在明确并简述翻译行业在哪些方面可以从人工智能(特别是机器学习)中受益。由于AI并非完全可以预测,因此采用任何一种AI技术时,都可能会带来新的风险。所以,无论是全新引入AI,还是用AI取代传统的算法自动化,都可能会产生负面影响,当然也可能带来积极的突破。 在语言方面,我们看到机器翻译在过去的不断演进,这是机器学习最有力的例子。我们已经知道它能带来什么,好处是什么,以及如何应对风险。我们对待机器学习的态度,决定了我们能从机器学习发挥多大的潜力。 比如,我们可以基于获取的数据进行自动化决策,要么为工作人员提供参考选项,要么自动决策从而解决持续开发/持续翻译过程中的瓶颈。还可以进行预测,揭示潜在的风险(项目延期、客户不满等),并提出建议性的改正措施。 由于机器学习技术可以应用于不同的领域,采取不同的学习方法(有监督或无监督学习、强化学习、迁移学习等),因此我们可以结合实际情况,寻影追踪,搭配最佳的使用场景和方法。 小试牛刀:借助机器学习来推荐供应商 几年前,我们向项目经理开展了一项问卷调查,希望了解在哪些方面可以使用机器学习来简化和加快工作。结果显示,项目经理经常花费大量时间来为某个特定的工作寻找合适的供应商,这与他们的期望相去甚远。于是,我们下定决心,尝试将机器学习用于为某个项目选择最佳供应商。 首先,我们想验证是否可以训练神经网络来做出与项目经理相同的选择。 我们从数万个已经完成的任务中获取初始数据和分配的供应商,并使用它们来训练一个模型。虽然有多种复杂的神经网络架构可用,但我们选择了一个简单的回归分类模型,它的表现还算不错。 经过验证,该模型在99%以上的情况下做出了正确的选择。 然而,当试图在正式生产活动中使用这个模型时,我们发现它选中的供应商经常在事实上并不适合。这是因为:过去任务所分配的供应商,从今天的角度来看并不是最适合的供应商。这就是所谓的“Garbage in – Garbage out”准则,种瓜得瓜,种豆得豆。 重新评估项目经理的日常活动 最近,我们进行了另一项问卷调查,借此了解项目经理们将时间主要花在了哪些活动上。与此同时,我们想看看机器学习还可以用在什么地方。这项调查显示,为特定项目寻找最佳供应商仍然是最为耗时的任务之一。当然,机器学习可用于哪些领域也变得明朗清晰。 下表列出了我们认为可以改进的活动,以及如何将这类活动部分自动化或完全交给机器。 下文中的“系统”是指项目管理系统或ERP系统。 人工操作 如何使用机器学习实现部分自动化 如何消除人工操作 查找资源 根据过往的类似项目来推荐资源(供应商、TM、词汇表等) 综合考虑语言对、领域、资质、经验、成本、可用性、生产率、PM/审校反馈意见和其他参数,为每项工作选择最佳供应商。 项目设置和计划 根据SLA(服务级别)和过去类似的项目,预设项目工作流,估算任务完成时间和关键路径 - 手工编写供应商任务指南 提取关键要求,并在此基础上起草结构化的供应商任务指南 - 监控截止时间 根据历史数据实时估算项目延期的可能性,并及时提醒项目经理 设计若干控制层,可靠地控制截止时间,从而完全消除人工操作 更正系统中的数据 基于公共模式,分析后台数据的一致性,对可能的错误数据发布警报 - 供应商推荐 2.0 (重磅升级) 如上所述,基于机器学习的供应商推荐在技术上是完全可行的,但是经常给出的结果是错误的(或者至少在某些PM看来是“错误”的)。 为了解决这个问题,我们决定: 先看看是谁在管理这个项目,也就是把推荐发给谁。这样就可以在个人/部门基础上定制机器学习的输出,从而持续重复使用由不同PM那里收集的数据,同时消除“错误的”推荐。) 降低训练/验证数据集记录的权重,因为它们已经过时。因此,最近的数据优先于过去五年的数据,而五年以上的数据则根本不再考虑。 这种改进后的架构的使用效果如何,暂时尚未公布。但是我们已经计划在下一个迭代中进行一些调整。与其根据模型定期重新训练过去五年来的数据集,不如改为对网络初始训练后的数据进行强化学习。 除此之外,我们在将新项目与已完成项目进行比较时,对照诸如客户/用户、语言对、领域、SLA等因素并快速分析待翻译的文本特征(这就用到自然语言处理啦!),选出匹配的项目,直接复用项目资源。 机器学习还能做什么? 更正系统中的数据 在处理已完成项目所记录的数据时,我们发现了许多不一致的地方。通过分析,我们觉得只需稍作努力,就可以快速准确地识别出这些不正确的数据,而这些数据的存在也令项目经理们头疼不已。出现错误数据的原因可能是错误的用户操作、程序代码中的错误或只是一个小小的打字错误。不管错误是怎么造成的,至少我们能识别出来。机器学习,责无旁贷。 具体而言,错误数据的检测可以在既定的数据处理任务中增加一项分析,也可以设成一项单独的数据分析任务。无论哪一种方法,都是要识别出不匹配公共模式(使用回归模型)的情况。对于那些看起来有错误的数据,自动更正的做法风险太大。因此,只要向负责的员工报告潜在错误就够了,该员工可以验证并修复它。 项目设置和计划 通常,在项目的开始阶段,例如报价或项目确认阶段,就需要确定一个可行的项目截止时间。为此,我们需要评估项目工作流中每个阶段的截止时间,计算关键路径并增加适当的缓冲时间以备周全。我们可以使用过去已完成任务的数据来训练神经网络,从而预估每项特定任务的截止时间。 还有一种办法可以迅速初步估计截止时间:根据过去已完成项目的工作量、语言对、领域和其他特征,对神经网络进行培训。这样的网络给出的结果是近似估算,但是这样的算法实现起来要简单得多。 监控截止时间 要监控项目截止时间,我们可以使用与项目计划相同的方法。所不同的是,项目已经启动,工作正在如火如荼地进行,我们掌握了更多的相关数据。例如,我们知道哪些任务已完成,剩余任务具体分派给了哪些供应商。相应地,在这种情况下,我们只需要评估剩余任务所需正常时间,计算关键路径,将其添加到当前计划中以估算最可能的项目完成时间,并与商定的截止时间进行比较。如果预计完成时间早于商定的截止时间,正合我意 -- 完全有机会赶上截止时间。如果晚于预期,则通过将差值应用于适当的正态分布直方图,可以粗略估计仍能满足截止时间的概率(在本例中,一定低于100%)。 手工编写供应商工作指南 为供应商编写明确、一致和最新的工作指南,是项目管理日常工作的重要部分。但是这项工作往往实际上就是复制和粘贴客户的工作指南,既无聊又无益。理想情况下,要针对某个客户的项目工作流中所涉及的所有类型的供应商(如工程师、翻译、编辑、校对、DTP专员等)维护一整套最新的工作指南。但在很多时候,这可能有点多余或不切实际。 这里,我们使用自然语言处理技术,例如信息抽取和命名实体识别。 在从客户那里接收到的非结构化格式的项目描述文本上运行它们,可以将所有这些项目属性(如工作量、语言对、客户、项目名称、截止时间等)提取为单独的值。 然后我们只需将它们填写到一个结构化的工作指南模板中,就可以得到供应商工作指南的初稿。如果您还没有在项目管理系统中创建相应的项目,那么正好可以根据提取的项目属性来创建项目。 自建或购买 随着技术的进步,世界变得越来越数字化,软件开发能力对语言服务提供商来说变得越来越重要。然而,像机器学习这样复杂、相对较新并快速发展的领域,仍然很难普遍采用。 从实际出发,公司可以考虑要么使用Python/R构建自己的机器学习微服务,要么使用谷歌、亚马逊、微软等IT巨头或者Intento等集成商提供的服务。 机器学习服务提供商 优点 缺点 内部自主研发 深入了解机器学习的原理和效果 绝对保密 可用性更佳 对于中小型公司而言,机器学习开发团队的投入太大 所需开发时间更长 产品质量不及预期 专业云服务 快速启动 解决方案优质可靠 峰值性能更高 向第三方披露数据 从长远来看更昂贵 尽管机器学习所带来的效果可能令人惊喜,但它同时也伴随着风险。因此,可行之道是将机器学习解决方案作为日常工作环境中的得力助手,但同时要密切关注它们的结果,直到能够信任它们并已正确评估可能的风险。

以上中文文本为机器翻译,存在不同程度偏差和错误,请理解并参考英文原文阅读。

阅读原文