私たちは今、見たり、聞いたり、読んだりすることがたくさんあるコンテンツビッグバンの時代に生きています。特に、かつてコンテンツは制作された地域で主に消費されていましたが、今ではコンテンツを楽しむときに境界線があまり意味を持ちません。今では、ヨーロッパでKドラマ「奇妙な弁護士ウー・ヨンウ」を見たり、韓国でスペインのドラマ「ハウス・オブ・ペーパー」を見たりするのが当たり前のように感じます。
もちろん、このような世界はどこからともなく魔法のように生まれたわけではありません。機械翻訳テクノロジーは、以前は想像しかできなかったことが現実になるまで、進化を続けてきました。これにより、大量のコンテンツを高速で (かつ低コストで) 翻訳できるようになりました。このような強力な利点を持つ機械翻訳の導入は、世界のコンテンツ産業の全盛期を迎える上で決定的な役割を果たしました。
また、数年前からこの大きなトレンドに注目してきました。その結果、私たちが開発してきたのは コンテンツローカリゼーションツール「レターワークス」穏やか。今、公式開幕を前にして、もう少し詳しく見てみようと、土壇場で急いでいるんだ。あまりプロモーションをしなくても、多くの人が関心を示し、オープニング通知の申し込みを待っていたことを考えると当然です。
この記事はこのような人のためのものです レターワークスのコアテクノロジー ハイブリッド翻訳エンジンまた、これがコンテンツのローカリゼーションプロセスにどのように役立つかを事前に紹介したいと思います。
従来の翻訳者の限界と翻訳エンジンの重要性
最近、GoogleやPapagoなどの機械翻訳エンジンが急速に発展しています。翻訳結果を以前と同じように間違って見て、ばかげたものにすることがますます難しくなっています。多くのユーザーから集められた膨大なデータに基づいた学習のおかげで、今では一般的な文章でも正確に翻訳できることが確認できるようになりました。
しかし、機械翻訳の開発ペースは驚異的ですが、残念なことがまだいくつかあります。また、機械が生成した結果をまだ見ていると、うまく翻訳されていない文やぎこちない文章が簡単に読めるのも事実です。機械翻訳には明らかな利点がありますが、結果の限界も明らかであるため、やはり人間による修正が必要というのが現実です。
そしてこのような状況で重要になったのは、翻訳エンジンのパフォーマンスでした。これは、機械翻訳の品質が低下すると、後で修正しなければならないことが増え、時間とコストが増加するためです。一方、高品質でエラーが少ないことを保証する高性能翻訳エンジンは、自動翻訳と人間による翻訳の相乗効果を最大化することで、優れたパフォーマンスを期待できます。
ユーザーデータに基づいてカスタマイズされた翻訳者の登場
まず、一般的な機械翻訳フローを見てみると、理解しやすくなります。下の図を見れば、機械翻訳者が原文を翻訳し、ユーザーが原文を入力すると翻訳結果を提供するという、機械翻訳者の通常の使用フローを確認することができます。
その間に機械翻訳者はずいぶん進歩したと言われていますが、完全に特定の翻訳者のパフォーマンスに頼るには限界があります。そのため、一般的な文章は正確に翻訳されることが多いですが、重要な用語が間違って解釈されたり、翻訳がぎこちなくて理解しづらくなることがあります。
このため、ユーザーデータに基づいて翻訳者をより専門的にする取り組みが数年前に始まりました。一例として、Google は AutoML 翻訳というサービスの提供も開始しました。ユーザーがデータ、つまり翻訳された言語ペアをアップロードする際のカスタム翻訳モデルの使用をサポートします。ただし、Google の AutoML 翻訳には、残念ながら使用できない欠点がいくつかあります。
まず、Google翻訳モデルに基づいてのみ機能します。 つまり、ユーザーデータや用語を入れたとしても、結局Google翻訳しか使えません。最近、Papagoを含む他の翻訳者のパフォーマンスが大幅に向上し、言語や分野によってはGoogleよりも他の翻訳者の方が適しているケースが多いことを考えると、これは残念なことです。
第二に、主に英語で動作します。 当初から英語を中心に発展してきたことを考えると、当たり前のことだと思われるかもしれません。例えば、韓国語-英語または英語-韓国語を学ぶことは可能ですが、韓国語-日本語の学習は不可能であることが知られています。
第三に、大量のデータが必要です。 優れたカスタム翻訳者を作るには、大量のデータでトレーニングする必要があり、ほとんどの場合、ユーザーが持っているデータ数では十分ではありません。一般に、優れた機械翻訳者を作るには数百万文以上必要で、ほとんどのユーザーは数万文のデータしか持っていないことがよくあります。
ハイブリッド翻訳エンジン「LETR WORKS」の心臓部
いずれにせよ、GoogleやPapagoなどの大手テクノロジー企業を中心に、機械翻訳が急速に発展していることは事実です。もしそうなら、このような競争の激しい分野で生き残るためには、どのような武器が必要なのでしょうか。この時に思いついたアイデアは ハイブリッド (ハイブリッド)これです。通常、ハイブリッドと言えばクルマを思い浮かべるが、もともとはハイブリッドかハイブリッドを意味し、「特定の目標を達成するために2つ以上の要素を組み合わせること」を意味していた。* Twigfarmは、このハイブリッドコンセプトを機械翻訳に導入してテクノロジーを研究しました。実際、これに基づいて開発されたハイブリッド翻訳者には、既存の翻訳者とは異なる技術やノウハウが含まれています。
まず、ハイブリッド翻訳の操作フローを簡単にまとめた下図を見てください。
上記で見た通常の機械翻訳プロセスとは大きく異なりませんか?それでは、従来の方法とは異なる、ハイブリッド翻訳のユニークな特徴を本格的に紹介しましょう。
まず、用語集を使用してください。 標準翻訳メモリ (TM)**という元のテキストをベースに、既存の翻訳データをインポートして使用することです。特に、プロの翻訳やコンテンツ翻訳の場合、その分野で使われている用語が適切に適用されていることが重要で、ハイブリッド翻訳は用語集の認知率と応用率が高いです。これにより、原文を入力すると、正確に一致する用語が翻訳結果に表示されます。
第二に、さまざまな翻訳者を使用しています。 用語集を適用するだけでなく、これらの用語に基づいてGoogleやPapagoなどのさまざまな翻訳者を使用できます。もちろん、独自のニューラルネットワークベースのトランスレータを使用することもできます。翻訳者ごとに特性が異なり、異なる言語や分野でうまく翻訳できるという事実を利用することで、翻訳の質をさらに向上させることができます。
第三に、主に英語ではありません。 機械に新しい言語を教えるとき、途中で英語を勉強する必要はありません。つまり、韓国語-日本語、韓国語-中国語、中国語-日本語など、英語をスキップする方法をサポートしています。これらの違いから、ハイブリッド翻訳はすでに国内特許登録を完了しており、海外では特許出願も出願されています。
最後に、これらの手法を使用して正確で自然な翻訳を可能にするハイブリッド翻訳の例を示すことで締めくくります。以下の表を見ると、GoogleやPapagoなどの既存の翻訳者に用語集を適用することで翻訳品質を向上させることができることがわかります。
ハイブリッド翻訳は今後どこまで進歩できるでしょうか?この技術を応用して立ち上げようとしている「LETR WORKS」が、この分野でどのように引き出されるのか、とても楽しみです。
残念なことに、自己賞賛が長すぎたようです。しかし、機械翻訳はまだ速いペースで発展しているので、今後研究や開発すべきことはまだたくさんあります。ハイブリッド翻訳を進め続けることに加えて、より正確で自然で高品質な翻訳を可能にする技術と製品の開発にも引き続き取り組んでいきます。
* https://ko.wikipedia.org/wiki/하이브리드
** https://ko.wikipedia.org/wiki/번역_메모리
参考文献
[1] https://www.bloter.net/newsView/blt202006250040
[2] https://youtu.be/TvQP7Eu9XVg
[3] https://translate.google.com/intl/ko/about/forbusiness/
[4] https://cloud.google.com/translate/automl/docs/
[5] https://cloud.google.com/translate/docs/advanced/glossary
[6] https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-ai-translation-services-works-for-documents?hl=en
[7] https://www.ncloud.com/product/aiService/papagoTranslation
[8] https://guide.ncloud-docs.com/docs/papagotranslation-overview
一緒に見るのに良いコンテンツ
Googleの代わりにLETRハイブリッドトランスレータを使うべき理由[AI Story] 人間に似た機械翻訳 (機械翻訳)LETR API (2) ソリューションとサービスの紹介LETR API の紹介 (3) ユースケースとサンプル