This
is yet another post triggered by conversations in Rio at the ABRATES conference
in early June. As I mentioned in my initial conference post, the level of
interest in MT was unusually high and there seemed to be real and serious interest
in finding out ways to engage with MT beyond just the brute force and numbing corrective
work that is typical of most PEMT projects with LSPs.
MT has
been around in some form for decades, and I am aware that there have always
been a few translators who found some use for the technology. But since I was
asked by so many translators about the options available today I thought it
would be useful to write about it.
The
situation today for many translators is to work with low quality MT output
produced by LSP/enterprise MT practitioners with very limited MT engine
development experience, and typically they have no say in how the MT engines
evolve, since they are so far down the production line. Sometimes they may work
with expert developed MT systems where there is some limited feedback and
steering possible, but generally the PEMT experience involves:
1. Static MT engines that are developed
offline somewhere,
and that may have
periodic if any updates at all to improve the engine very marginally if at all.
2. Post-editors
work on batches of MT output and provide periodic feedback to MT developers.
This
is beginning to change in the very recent past with innovative new MT
technology that is described as Adaptive Interactive Dynamic Learning MT (quite
a mouthful). The most visible and elegant implementation of this approach is
from a startup called Lilt. This allows the translator-editor to tune and
adjust the engine dynamically in real time, and thus make all subsequent MT
predictions more intelligent, informed and accurate. This kind of an MT
implementation is something that has to be cloud based to allow the core engine
to be updated in real time. Additionally, when used in workgroups, this
technology can also leverage the individual efforts of translators by spreading
the benefit of a more intelligent MT engine with the whole team of translators.
Each user benefits from the previous edits and corrective actions of every
other translator-editor and user as this case study shows. This allows a team to build a kind of communal
edit synergy in real time and theoretically allows 1+1+1 to be 5 or 7 or even
higher. The user interface is also much more translator friendly and is
INTERACTIVE so it changes moment to moment as the editor makes changes. Thus
you have a real-time virtuous cycle which is in essence an intelligent learning
TM Engine that learns with every single corrective interaction.
CSA tells
us that the SDL Language Cloud also has similar abilities but
my initial perusal suggests it is definitely less real-time, and less dynamic
than Lilt i.e. it is not updating phrase tables in real time. There are several
little videos that explain it and superficially it looks like an equivalent but
I am going to bet it is not yet at this point in time anyway.
So for
a translator who wants to get hands on experience with MT and understand the
technology better, what are the options? The following chart provides a very
rough overview of the options available ranked by my estimation of the best
options to learn valuable new skills. The simplest MT option for an individual
translator has always been a desktop RbMT system like Systran or ProMT, and it
still is a viable option for many, especially with Romance languages. But there
has never been much that could be done to tune these older systems beyond
building dictionaries, a skill that in my opinion will have low value in the
future.
Good
expert developed MT systems will involve frequent interaction with translators
in the early engine development phases to ensure that engines get pattern based
corrective feedback to rapidly improve output quality. The more organized and
structured this feedback and improvement process, the better the engine and the
more interesting the work for the linguist.
Of the
“free” generic MT engines Microsoft offers much more customization capabilities and thus are a good
platform to learn how different sets of data can affect an MT engine and MT
output. This of course means the user needs to have organized data available
and an understanding of the technology learning process. MT can be trained if
you have some understanding of how it learns. This is why most Moses experiments fail I think, too much effort focused on
the low value mechanics, and too little on what and why you do what you do. I
remain skeptical about ignorant Moses experimentation because getting good SMT
engines requires good data + understanding of how your training corpus is
similar to or different from the new source that you want to translate, and a
variety of tools to help keep things synced and aligned when you see
differences. I am also skeptical that these DIY efforts are likely to get as
engines as good as the free generic engines, and I wonder why one would bother
with the whole Moses effort if you could get it at higher quality for free from
Microsoft or Google. There are some translators who claim some benefit from
working with Moses and its desktop implementations like Slate.
All these
options will provide some experience and insight into MT technology, but I
think it is useful to have some sense for how they might impact you from two
key perspectives shown below:
1.
What options are likely to give
you the fastest way to get to improved personal productivity?
·
I would expect that an Adaptive
MT solution is most likely to do this the fastest, but you need have good clean
training data – TM, Glossaries (the more the better). Also you should see your edit
experience improve rapidly as your corrective feedback modifies the engine in
real time.
·
Followed by the Microsoft
Translator Hub (if you do not have concern about privacy issues), SDL Language Cloud and some
Expert systems which are more proactive in engaging translators but this will
also involve an LSP middleman typically.
·
Generic Google & Microsoft
and Desktop RbMT (Romance languages and going to English tend to have better
results in general).
·
DIY Moses is the hardest way to
get to productivity IMO but there is some evidence of success with Slate.
2.
What options are most likely to
help develop new skills that could have long-term value?
·
My bet is that the SMT options
are all going to help skills related to corpus analysis, working with n-grams,
large scale corpus editing and data normalization. Even Neural MT will train on
existing data so all those skills remain valuable.
·
Source analysis before you do
anything is always wise and yields better results as your strategy can be
micro-tuned for the specific scenario.
·
Both SMT and the future Neural
MT models are based on something called machine learning. It is useful to have at
least a basic understanding of this as this is how the computer “learns”. It is
growing in importance and worth long-term attention.
There are tools like Matecat that show promise, but given that
edits don’t directly change the underlying MT engine, I would opt for a true
Adaptive MT option like Lilt instead.
The
traditional understanding of PEMT can be summarized in the graphic below and
this is the most common kind of interaction that most translators have with MT
if they have any at all.
However
the problem definition and the skills needed to solve them are quite different
when you consider an MT engine from a larger overall process perspective. It
generally makes sense to address corpus level issues before going to the
segment level so that many error patterns can be eliminated and resolved at a high
frequency pattern level. It may also be useful to use web crawlers to gather
patterns to guide the language model in SMT and get more fluent target language
translations.
The most interesting MT problems which almost
always happen outside the “language services industry”, require a view of
the whole user experience with translated content from beginning to end. This paper describes
this holistic user experience view and the resultant corpus analysis
perspective for an Ebay use case. Solving problems often involves data
acquisition of the right kind of new data, normalization of disparate data, and
focus on handling high frequency word patterns in a corpus to drive MT engine
output quality improvements. This type of deeper analysis may happen at an MT savvy LSP
like SDL, but otherwise is almost never done by LSP MT practitioners in the
core CSA defined translation industry. This kind of deep analysis is also often limited at MT vendors
because customers are in a hurry, and not willing to invest the time and money to do it right. Only the most committed will venture into this kind of
detail, but this kind of work is necessary to get an MT system to work at
optimal levels. Enterprises like Facebook, Microsoft and EBay understand the
importance of doing all the pre and post data and system analysis and thus
develop systems that are much more closely tuned to their very very specific
needs.
MT
use makes sense for a translator only if there is a productivity benefit.
Sometimes this is possible right out of the gate with generic systems, but most
often it takes some effort and skill to get an MT system to this point. It is
important that translators have a basic understanding of three key elements before MT
makes sense:
1. Their
individual translation work throughput without MT in words per hour.
2. The quality of
the MT system output and the ability of the translator to improve this with
corrective feedback.
3. The individual
work throughput with MT after some effort has been made to tune it for specific
use.
Obviously 3 has to be greater than 1 for MT use to make sense. I
have heard that many translators use MT as way to speed up the typing or to
look up individual words. I think we are at a point where the number of MT
options will increase and more translators will find value. I would love to
hear real feedback from anybody who reads this blog as actual shared experience
is still the best way to understand the possibilities.














