SARAH WELDON: Hello.
Thank you for joining us today to learn about machine
translation at Google and how companies like Eli Lilly
leverage it to globalize their content.
Many multinational companies have multilingual employees
and customers, and so they need to be able to offer information
in many languages.
And that can be a challenge.
If you're interested in learning about how you can safely
and securely use machine translation to help
solve this problem, you're in the right place.
I'll introduce myself and my co-presenter in a moment.
We'll be talking to you today about how
Eli Lilly uses Cloud Translation to translate content globally.
To give you a sense of what we'll cover, here's our agenda.
In a nutshell, we'll familiarize you
with Google Cloud Translation and what
we can do to help you with serving content
in more languages.
Then we'll switch gears to a company putting this
into practice, health care company Eli Lilly,
for them to tell us how they built their in-house solution
powered by Google Cloud APIs to solve this for their people,
including offering a demo.
I'm Sarah Weldon, product manager for Google Cloud
Translation on GCP.
And in the second half of this presentation,
I'll be joined by Tom Griffin, translation tech
lead and global regulatory architect at Eli Lilly.
As I mentioned, today we're discussing
language translations produced for machine learning, often
called machine translation, or neural machine translation.
Google heavily invests year over year
in advancing the quality of our translations
across apps, Cloud APIs, Chrome, and enabling
multilingual answers in Search.
We constantly pursue advancing state-of-the-art in technology
and linguistics.
A popular metric for automatic quality evaluation
of machine translation systems is the BLEU score,
which is based on the similarity between a system's translation
and the reference translations that were generated by people.
While we push out incremental improvements
for individual models on a monthly cadence,
there are also times when we make significant leaps.
And that's what this graphic on the right-hand side shows.
In the releases since late 2019, we've
improved average BLEU score across our models
by five points across 100-plus languages, on average,
and seven points in those low-resource languages.
These are the languages that you see
towards the tail on the right.
BLEU score helps our models with increasing
the overall quality of the translations for our end users.
The green that you see is the delta
between our previous translation BLEU scores
and the difference of what we delivered
in the last couple of years.
Part of why machine translation can be so challenging
is the sheer volume of content and breadth of content types
that still add value when translated
into multiple languages, like Polish to English for customer
support, or Japanese to German for financial news,
or Indonesian to English for customer reviews on products.
Let's face it, in a globalized world, and now more than ever
a digital demand world, you need the help to scale and reach
your customers right where they're at,
from translating content for a pipeline of data
analytics to audio content for your videos.
Google Cloud Platform makes it possible to take
the power of our Machine Translation API
and bring it into your company for easily consumable,
pay as you go translations, or our platform for custom
training your domain-tuned translation models.
If you need to get started fast, we
have Translation API Basic to translate your text
and detect language on demand in real time.
Because our APIs are global, you can expect high availability
and rapid translations to move at the speed
of your on-demand content.
If your content has jargon and it is a specialized domain,
like finance or manufacturing, we have customization features
that you can apply to improve the quality and accuracy
of translations from the APIs.
And if you need to translate audio, either real-time
or from transcriptions, you can then
check out Media Translation API or combine or Text
Translation APIs with Video Intelligence API
or Speech-to-text API.
Let's say your company has more domain-specific content
and needs to be able to context fine tune machine
translation to better handle that,
or to enforce specific terms, like product names,
to be translated in a certain way.
Translation API Advanced includes additional features
for you to do just that.
And that's just the start.
Translation API Advanced also includes
features such as Glossary, batch translation with GCS,
and newly released features, which I'll discuss shortly.
If you've created custom models for machine translation,
we don't think that you should have to have multiple client
libraries and multiple APIs to maintain in order for you
to use the best model for your needs.
So Translation API Advanced now supports model selection.
Pick your pre-trained models or pick your custom AutoML models
for any language pair that you've created them in,
and use the same API and the same client library.
Additionally, recently, if you were a customer operating
in the European Union, we recently
launched an endpoint specifically
for EU regionalization.
This is a configurable endpoint for customers
to store and perform machine translation
processing of customer data only in the EU multiregion.
For now, this only supports our [? pre-trained ?] translation
models and Glossary.
Batch will be coming soon.
Let's talk a little bit more about Glossary.
Glossary is our terminology control feature.
It allows you to import source content of preferred
translations, such as product names or department names.
And then when calling the Glossary in the API request,
your preferred translations will be enforced.
This will work for words as well as phrases.
AutoML Translation is a suite of machine learning products
to enable you to build high-quality machine learning
models for your own use case or data with limited to no machine
learning expertise or coding required.
Bring your past human-validated translations
to your company to improve translation specificity
and influency for your domain.
For example, let's say you're translating
manufacturing guides.
They are likely written in a common style
and include a lot of context-specific translations,
like "solution" in English is referring
to the chemical mixture for you and not a generalized tool that
fixes the problem for the day.
AutoML translation has a simple UI
and handles many of the complex tasks for you,
like algorithm tuning or maintaining, serving,
and training platform.
Additionally, because they are fine-tuned on top
of our general translation models,
you'll already be starting from a very solid base.
But it's all kept, just for you, within your GCP project.
Now our most recent feature launch, document translation
of formatted documents is directly
supported through Translation API Advanced.
We're excited to announce this new feature for Google Cloud's
translation services.
And the feature allows customers to directly translate documents
in over 100 languages and formats,
such as DOCX, PowerPoint, Excel, and PDF,
while still preserving the document formatting.
Previously, to solve this problem,
you'd have to build into your developer pipeline steps
extracting the text from the original file,
tracking and formatting it just to let it go
or to have to redo it after you've received the resulting
translations.
This is a lot of extra work to develop
and additional code for you to maintain.
Now you can skip those steps and get
formatting retained and handled directly for you by our APIs
instead.
This is easy to integrate with our APIs via REST or gRPC
with your browser application, and will give you
instant access to over 100 language pairs
so that chat or user reviews can be
understandable in any supported language.
Document translation also works with the other features
that are available on Translation API
Advanced, including the power of Glossary and AutoML translation
models, and even batch translations.
So this enables you to both use all of your custom content
to control terminology within the documents,
as well as have all of the formatting retained.
And just to remind you, you also still get
all of the language quality improvements
that we deliver to our machine learning APIs year-over-year.
This has really benefited a lot of customers
and helped even partners, such as Welocalize, which
is a language service provider, deliver improved document
translation for their end users.
And now I'm excited to be joined by Tom Griffin, translation
tech lead and global regulatory architect at Eli Lilly.
Tom, go ahead.
TOM GRIFFIN: Thank you, Sarah.
Hi, everybody.
My name is Tom Griffin, and I'm the translation tech lead
and full stack developer on Eli Lilly's Translate project.
And I'm also the global regulatory affairs architect.
So historically, translations at Lilly have cost us too much.
They're too complicated, and they take too long.
And we found a way to solve this problem
is to provide ourselves with a code [? defined ?] approach
to leveraging cloud translation engines.
So we created an API layer to do just that.
So our translations have cost too much
because leveraging multiple translation providers
prevents us from benefiting from simple business things,
like economies of scale.
Complicated translation process leads to long lead times
and getting a translation turned around and back
into the hands of our business partners
within an acceptable time frame.
And our application from our users' point of view
currently looks like this.
So the goal is that our users request a document or text
to be translated.
They enter metadata for the translation task at hand.
And then they send it over to our API layer, which
governs the interaction between Lilly and the cloud translation
provider.
So if you were to see this diagram three to four months
ago over in the top right there, you
would have seen multiple cloud translation engines.
However, feedback from our users pushed us down the Google
for all translations route.
And we'll see more of that service
in our application demo, which I'm
going to run us through now.
So this is our application UI.
The Translate UI provides a simple method for our users
to interact with our API.
And it's very popular for achieving a quick translation
during day-to-day activities outside of integrating
the system into the API programmatically.
Users can translate text and documents,
and I'll demo both of those services.
For text, I'm just going to paste some publicly available
information taken from one of our press releases
into the text field, select English as our "from" language,
and Greek as our "to" language.
Users can then copy their result to their clipboard.
Our document demo is going to consist of a full press release
in .docx format.
Currently we can translate PowerPoints, .docx files,
.txt files, and spreadsheets in this way.
Note how the application keeps formatting intact,
along with any hyperlinks.
Our API consists of three methods--
one for text, one for uploading documents
that are to be translated, and one for downloading documents
that have been translated.
Our Text API is a simple one-step call
made via a unique API key and can translate up
to 5,000 characters at a time.
Our Download and Upload APIs are both two-step APIs
that work via temporary secure access
URLs that exist for 15 minutes.
And these are each also provisioned
via an initial call that also requires a unique API key.
Some other key points are that the application translates
content in 5,000-character chunks,
meaning a full document is never sent outside
of our environment.
And our data stores are wiped clean on a daily basis,
meaning we never keep or have any access to any data that
has been put through the application.
In earlier releases, our API leveraged various translation
engines based on the translation task at hand.
However, feedback from our users led
me to alter the API to leverage Google for all translation
tasks.
And since implementing this change,
we've seen increased accuracy and a ramp-up
in usage across our enterprise.
Leveraging the Google Engine via our own custom API layer
is key, as it has enabled us to provide
this type of automated machine translation to our users
in a heavily regulated environment.
So that was our application demo.
And now we can talk a little bit about the tech that goes
into creating such a service.
So our front end is a Node.js tech stack
that leverages React, Material UI, and Babel.
Our middleware and environment, again,
leverages a lot of Node.js, Ping Identity, and OAuth
for security across our enterprise and applications
of this type.
We're using PL/SQL as a database solution.
And we've created a lot of Python functions
that monitor and maintain the integrity of our environment,
which is things like preventing data
from being held and ensuring that nobody, not even
the application developers, have access to the data.
Our API and back end is a full, serverless managed stack,
which means it can be quite easily pointed
at different hosted environments.
We're using Docker to house a lot of our .NET and C# text
extraction functions.
Python-- again, a lot of the data integrity
pieces within the API are handled in Python,
and Node.js to actually leverage our cloud translation
engine providers, which currently is Google
for all translation tasks.
So thank you so much for the opportunity to talk about this.
And I'm going to hand it back over to Sarah.
SARAH WELDON: Thank you, Tom, for sharing with us
the great work you've done at Eli Lilly.
For those of you watching, for more information,
please visit our documentation and blog
posts for developer resources on building with our APIs.
Thank you all for joining us today.