機械翻訳の低リソース言語問題
1,600言語以上の翻訳が英語中心のMTより本質的に難しい理由と、新しい手法がそのギャップをどう埋めつつあるかを解説。
Sarah Chen
世界には約7,000の言語が話されています。Google翻訳は約130言語に対応していますが、商用のMTシステムでまともに扱えるのは30言語未満がほとんどです。ヨルバ語、ケチュア語、クメール語を話す人にとって、機械翻訳の体験は「ほとんど使えない」か「笑えるほど間違っている」かのどちらかでしょう。不都合な真実として、この10年のNLPの進歩の多くは英語を最優先にしたものであり、高リソース言語と低リソース言語の差は縮まるどころか広がり続けています。
Metaが進める1,600言語以上を対象とした「オムニリンガル機械翻訳」は、この状況を変えようとする最も野心的な試みの一つです。しかし、そこに含まれる技術的な課題は、言語モデルの構築方法に深く埋め込まれた前提を浮き彫りにしており、単にスケールさせるだけでは問題が解決しない理由を示しています。
「低リソース言語」とは何か
MT研究において「高リソース」な言語ペアとは、何百万文もの対訳データ、つまり2言語間でプロによって翻訳された文章が存在するペアを指します。英仏、英中、英西などのペアには、EU議会、国連、ニュース機関、そして数十年にわたるプロの翻訳から生まれた膨大な対訳コーパスがあります。こうしたペアで学習したモデルは驚くほどうまく機能します。
「低リソース」の言語は、数千文程度の対訳データしかないか、まったくない場合もあります。フォン語（ベナンで約200万人が話す）は英語との対訳データがほぼ存在しません。バンバラ語（マリで約1,400万人が話す）はそれより多少ありますが、従来のMTシステムが必要とする量と比べると桁違いに少ないのが現状です。多くの言語では、利用可能な最大のテキストコーパスが聖書の翻訳と、いくつかのWikipedia記事程度しかありません。
リソースの差はデータ量だけの問題ではなく、データの多様性の問題でもあります。低リソース言語に対訳テキストがあったとしても、宗教文書や行政文書に偏っていることが多いのです。その結果、モデルは堅苦しく反復的な文章の翻訳は覚えても、日常会話や専門用語、学習した狭い領域から外れる内容には対応できず、すぐに崩れてしまいます。
スケールだけでは解決しない理由
現代の機械学習の発想は「データを増やし、モデルを大きくすれば、結果は良くなる」というものです。英語中心のタスクではこれが劇的にうまくいってきました。数兆トークンの英語で学習したGPT系モデルは、驚くほど流暢な文章を生成します。しかし、このアプローチは低リソースのMTにおいて三つの致命的な失敗パターンを抱えています。
- そもそもデータが存在しない。 誰もこれまでに大量のフォン語・英語の対訳テキストを公開していなければ、インターネットからスクレイピングで集めることはできません。大規模なMT学習データの多くを支えるWebスクレイピングは、もともとインターネット上での存在感が大きい言語に偏る構造を持っています。
- トークナイズが破綻する。 多くの言語モデルは、英語（または少数の高リソース言語）を中心に学習したトークナイザを使っています。英語で学習したBPEトークナイザにアムハラ文字やビルマ語を通すと、文字が細かく分断され、極端に長いトークン列になります。アムハラ語の1単語が8〜12トークンを消費することもあります。その結果、モデルは入力の符号化だけでコンテキストウィンドウの大部分を使い切り、実際の理解に回す余力がほとんど残りません。
- 転移学習には限界がある。 mBERTやXLM-Rのような多言語モデルは、多くの言語で学習させることで低リソース言語にも効果があることを示しました。モデルは言語間の構造的な類似性を捉えるのです。ただし、この転移が最も強く働くのは近縁の言語どうしです。フランス語によく通じたモデルは、そこで得た知識の一部をハイチ・クレオール語に転移できます。しかし中国語やナバホ語にはほとんど転移しません。
ピボット言語の問題
数百言語を扱うと主張するMTシステムの多くは、実際には全てを英語経由で処理しています。スワヒリ語からタイ語に翻訳したい場合、システムはスワヒリ語→英語→タイ語と変換します。この「ピボット」方式は実用的です。英語との間の翻訳モデルさえ作ればよいからです。しかし、誤りが積み重なるうえ、文化的な特徴が平板化されるという見えにくい問題も生じます。
ピボットで英語を経由すると、英語にうまく対応しない概念は失われます。日本語には動詞の活用形に丁寧さのレベルが埋め込まれています。ヨルバ語には声調によって意味が変わる区別があります。タミル語には包括的な「私たち」と排他的な「私たち」（聞き手を含むかどうか）の区別があります。これらが英語というボトルネックを通ると情報が失われます。英語にはその区別がないため、モデルはそれを保持する手段を持たないのです。
英語を経由せず、スワヒリ語から直接タイ語へ翻訳すれば、より多くの情報が保たれます。しかし、考えうる全ての言語ペアに対して直接翻訳モデルを作ることは、組み合わせ的に不可能です。1,600言語であれば、有向の翻訳ペアは256万通りになります。最も話者の多い100言語だけを直接扱うとしても、なお9,900ペアが必要です。
現在の多言語MTの仕組み
現在の大規模多言語MTモデルは、ピボット戦略とは根本的に異なるアプローチを取っています。言語ペアごとに別々のモデルを作る代わりに、全言語を同時に学習し、共有された表現を獲得する単一のモデルを訓練します。主要な技術革新はいくつかのカテゴリに分けられます。
言語非依存のトークナイズ
トークナイザの問題は、英語に偏らないバランスの取れた多言語コーパスでトークナイザを学習させることで解決が進んでいます。Metaのアプローチでは、文字単位のフォールバックを使い、どの言語も極端に長いトークン列にならないようにしています。言語のバランスを明示的に取りながら学習したSentencePieceモデルは、はるかに公平なトークナイズを実現します。意味の近いヨルバ語の文と英語の文は、ほぼ同程度のトークン数になります。
これは見た目以上に重要です。あるトークナイザが言語Xに対して4倍非効率であれば、モデルはその言語を処理する能力が実質的に4分の1しかないことになります。低リソース言語の性能を向上させるうえで、トークナイズの改善は最もレバレッジの大きい施策なのです。
野生のデータから対訳を抽出する
最も優れた技術的貢献の一つが、対訳データの自動マイニングです。考え方はこうです。どの言語の文も共通の埋め込み空間に写像する多言語文エンコーダを学習させます。次にWebをクロールし、異なる言語の中から似たベクトルに写る文を探します。それらは互いの翻訳である可能性が高いのです。
LASERのようなツールで先駆けとなり、最近の研究で拡張されたこの手法は、CCNetやOSCARといったWebクロールから数億文の対訳を抽出してきました。ノイズは多く、抽出されたペアのうち20〜30%程度しか本当の対訳ではありません。それでもフィルタリングのヒューリスティクスで精度は上がり、量の多さがノイズを補います。一部の言語では、この自動マイニングによって、それまでの人手で整備されたデータセットをすべて合わせたよりも多くの対訳データが得られています。
バックトランスレーションと自己学習
バックトランスレーションとは、既存の（不完全な）MTモデルを使って単言語テキストを対象言語に翻訳し、その合成された対訳ペアでより良いモデルを学習させる手法です。ブートストラップ的な手法ですが、驚くほどうまく機能します。
サイクルは次のとおりです。手元にある対訳データで初期モデルを学習する → それで単言語データを翻訳する → 質の悪い翻訳を除外する → 実データと合成データを合わせて再学習する → これを繰り返す。反復のたびにモデルが良くなり、より良い合成データが生まれ、それが次の反復をさらに改善します。最初の対訳データが数千文しかない言語でも、バックトランスレーションによって学習データを10〜50倍に増やせることがあります。
# Simplified back-translation loop
def back_translate_cycle(model, parallel_data, monolingual_target, rounds=3):
for round in range(rounds):
# Generate synthetic source from monolingual target text
synthetic_pairs = []
for target_sent in monolingual_target:
source_sent = model.translate(target_sent, direction='reverse')
score = model.score_pair(source_sent, target_sent)
if score > QUALITY_THRESHOLD:
synthetic_pairs.append((source_sent, target_sent))
# Combine real and synthetic data
combined = parallel_data + synthetic_pairs
# Retrain model on combined data
model = train_mt_model(combined)
print(f'Round {round+1}: {len(synthetic_pairs)} synthetic pairs added')
print(f'BLEU score: {evaluate(model, test_set)}')
return model評価は思ったより難しい
BLEUスコアはMTの品質を測る標準的な指標ですが、低リソース言語に対しては深刻な問題があります。BLEUはモデルの出力と参照訳との間のn-gramの一致を測ります。英語は語順が比較的固定され、形態変化も少ないため、この指標はそれなりに機能します。しかしトルコ語やフィンランド語のような膠着語では、1語で英語の句全体に相当する意味を表すことがあります。そのため、異なる形態を使った正しい翻訳がBLEUでは減点されてしまうのです。
参照訳の問題もあります。評価に使う参照訳を誰が書いたのかという問題です。高リソース言語にはプロの翻訳者がいます。しかし多くの低リソース言語では、「ゴールドスタンダード」の参照訳は宣教師や、堅い文体で作業する行政の翻訳者、あるいは大学院生によって作られています。これらの参照訳は文法的には正しくても文体が不自然なことがあり、より自然な翻訳を生成するモデルほど、実際にはスコアが低く出てしまうのです。
COMETやBLEURTといった新しい指標は、ニューラルモデルを使って翻訳品質を推定し、人間の判断とより高い相関を示します。しかし、これらも主に高リソース言語のデータで学習されているため、構造が大きく異なる言語にはうまく汎化しないかもしれません。重要な言語ペアについて、ネイティブ話者による人手評価を始めたチームもありますが、それでは1,600言語へのスケールは不可能です。
文化的・倫理的な側面
1,600言語のためのMTを構築することは、単なるエンジニアリングの課題ではありません。誰が恩恵を受けるのか、言語をどう表現するかを誰が決めるのか、そしてモデルが不正確または偏った翻訳を学習してしまったときに何が起きるのか、という問いを投げかけます。
絶滅危惧言語の多くでは、主な話者は地方に住む高齢のコミュニティメンバーです。彼らは機械翻訳APIを使う人たちではありません。直接の恩恵を受けるのは研究者、NGO、政府である可能性が高く、それは文脈によって良くも（情報へのアクセスの改善）悪くも（監視や強制的な同化）なります。コミュニティの意見を聞かずに開発された先住民言語のMTには、苦い歴史があります。
また、言語の標準化という問題もあります。多くの低リソース言語には大きな方言差があり、単一の「標準形」が存在しないことがほとんどです。MTモデルが一つの方言を標準として選ぶと（通常は学習データに最も多く含まれていたもの）、他の方言の話者は暗黙のうちに周縁化されます。これは仮説の話ではなく、より多くのリソースがある言語ですでに起きています。アラビア語のMTモデルは現代標準アラビア語をうまく扱える一方で、実際に数億人が話すエジプト方言、レバント方言、湾岸方言には苦戦しています。
開発者にとっての意味
グローバルなユーザーを対象とするソフトウェアを作っているなら、MTの現状はアーキテクチャやプロダクトの判断に実務的な影響を与えます。
- MTの品質が均一だと思い込まない。 アプリがローカライズにGoogle翻訳などのAPIを使っているかもしれません。フランス語の品質は優れていますが、アムハラ語では実用に耐えないほど低いこともあります。上位10言語だけでなく、サポートすると宣言したすべての言語についてネイティブ話者でテストしましょう。
- MTの失敗を優雅に扱う設計にする。 元の文を翻訳と並べて表示しましょう。ユーザーが不適切な翻訳をフラグできるようにしてください。コンテンツが機械翻訳であることを隠してはいけません。ユーザーはどうせ気づきますし、人間の品質であるふりをしていたと分かれば、信頼はむしろ下がります。
- トークナイズのコストを考慮する。 多言語環境で（MTだけでなく）言語モデルを使う場合、英語以外の言語はより多くのトークンを消費することを意識してください。4Kのコンテキストウィンドウに入る量は、英語と比べてタイ語やアラビア語では大幅に少なくなります。それを前提に予算を組みましょう。
- 多言語のテストデータに投資する。 低リソース言語をサポートする際に最も難しいのは、モデルそのものではなく、出力が正しいかどうかを判断することです。出力を検証してくれるネイティブ話者との関係を築きましょう。自動評価指標は、あなたを誤った方向へ導くことがあります。
今後の展望
たとえ課題が多くても、オムニリンガルMTへの動きは本当にエキサイティングです。5年前であれば、1万文の対訳データがある言語向けの翻訳モデルを作ることは研究上の好奇心に過ぎませんでした。今では、バックトランスレーション、多言語転移、自動的な対訳マイニングといった技術によって、完璧ではないにせよ使える水準のものが実現可能になっています。
残された課題は、技術と同じくらい社会的なものです。絶滅危惧言語の学習データを得るには、Webスクレイピングではなくコミュニティとの連携が必要です。大規模に品質を評価するには、新しい指標とネイティブ話者の関与が求められます。MTツールが、カバレッジの項目を埋めるためだけでなく、実際にその言語を話すコミュニティの役に立つことを確かなものにするには、継続的な関わりが必要です。
それでも方向性は正しいと思います。言語が情報へアクセスする障壁になるべきではありません。そして、同じ30言語を何度も最適化するのではなく、1,600言語のための翻訳システムを作ろうとしていること自体が、優先順位の意味ある転換を示しています。エンジニアリングは困難です。トークナイズの問題を正しく特定して解決するだけでも、何年もかかりました。しかし、テック業界に無視されてきた言語を話す何十億もの人々にとって、この取り組みは英仏間のBLEUスコアをあと0.1%改善することよりも、はるかに重要なのです。
