第25回 長文対策の発見 (2011年3月)前回は、意外な発見と3.11のときのお話をしました。今回は、3.11のその後と長文のデコード結果の品質を上げる案のお話です。
3.11の翌週、東京電力による計画停電が始まりました。1日に何度も東京電力のプレスリリースを確認し、日替わりで変化する停電の時間帯にあわせて、毎日、サーバー類のシャットダウンと起動を繰り返しました。在宅勤務の社員からは、「本当に停電しました」という報告が何件も寄せられましたが、結局、アイタスでは一度も停電しないまま、最初の週が終わりました。
その翌週、東京電力から、より詳細な情報が公開された段階で、実はアイタスが入居しているビルは、計画停電の対象外だということが判明しました。念のため、東京電力にも問合せをしたところ、確かに対象外だと確認でき、世間よりかなり早い段階で計画停電から解放されました。電車の間引き運転は続いていたので、通勤の不便さは残っていましたが、あの歴史的大震災から10日程度で普段どおりの状態に戻ることができ、非常に助かりました。
さて、300万センテンスのパラレル・コーパスを用意し、新たに言語モデルと翻訳モデルを作成しましたが、デコード結果に目を見張るような品質向上は見られませんでした。ある程度のコーパスを確保できたら、そこから先の品質向上は鈍化するのでしょう。単にコーパスの量を追い求めるだけだと、この頭打ちに近い状態から抜け出せそうにありませんでした。何か改善策はないかと、デコード結果とにらめっこが続きました。
一般的に機械翻訳の訳文は、短文だと比較的うまくいくのに、長文だと使い物にならないことが多いです。アイタスの統計的機械翻訳も同じような傾向にありましたが、同じ長文でも、文法的には非常に簡単なのに、デコード結果がかなりおかしなものがあった反面、文法的には難しいはずなのに、デコード結果は良好なものもありました。
この差は、一体何なんだろう。。長文でも安定的に良質な訳文を生成できるようになれば、ポストエディットの作業効率は格段に上がるので、何とかして理屈を解明し、解決したい課題でした。そして、いくつもの原文と訳文を眺めているうちに、ある仮説を思い付きました。
すべての長文に対して効果があったわけではありませんが、全体的には確実に効果がありました。以下は、うまくいった例です。
例1 原文Also, unstructured data such as text, graphic images, still video clips, full motion video, and sound waveforms tends to be large in size. 機械翻訳(改善前)waveformsもなる傾向があります。テキスト、グラフィック・イメージ、サウンド、ビデオおよび、フル・モーション静止ビデオ・クリップなどの大型で非構造化データ 機械翻訳(改善後)また、テキスト、図形イメージ、静止ビデオ・クリップ、フル・モーション・ビデオおよびサウンド・ウェーブフォームなどの非構造化データは、サイズが大きくなる傾向があります。 人間翻訳(手本)また、テキスト、図形イメージ、静止ビデオ・クリップ、フル・モーション・ビデオおよびサウンド・ウェーブフォームなどの非構造化データは、サイズが大きくなる傾向があります。 例2