前回は、デコード時に品詞情報も活用することで品質が向上するかというお話をしました。今回は、英語のままでいい箇所の対応方法についてのお話です。

その前に

第18回と第19回で抱えていた2つの課題も、とりあえずは支障がない程度に解消し、再び、品質向上に取り組むことにしました。何か使えそうな機能はないものかと、Mosesのマニュアルを読み漁っていたところ、品質向上とは無関係ですが、こんな機能があったのかというのを1つ発見。

第6回で簡単に触れましたが、Mosesではデコード対象のアルファベットを「すべて小文字」にし、デコードを終えた後、「すべて小文字」なのを「大文字小文字交じり」に戻す必要があります。ずっと、「大文字小文字交じり」に戻す方法がわからなかったのですが、実は、Mosesが機能として持っていました。

それが、なるほどぉと唸ったのが、この機能は通常のデコードの応用で、「すべて小文字」と「大文字小文字交じり」のパラレル・コーパスから言語モデルと翻訳モデルを作成し、「すべて小文字」から「大文字小文字交じり」にデコードするというものでした。統計的な処理なので、100%きれいに元に戻るわけではないですが、かなり高い確率で元に戻ります。

つまり、デコードというのは、必ずしも異なる言語間で行なう必要はなく、広島弁と東京弁とか、直訳の日本語訳と修正後の日本語訳とか、いろんな応用が考えられるということです。近い将来、何かに活かせそうです。

評価方法を変更

さて、これまでは翻訳モデルの中に含まれているセンテンスをデコードし、その再現性の度合いから品質向上に効果があるかどうかを判断していました。しかし、翻訳モデルの中に含まれているセンテンスは、既存の仕組み(翻訳支援ツールの翻訳メモリ)を使って再利用することができるため、わざわざ機械翻訳を使う必要はありません。

じゃあ、どこで機械翻訳を使うの? って話ですが、翻訳モデルの中に含まれているセンテンスと重複箇所が少ないセンテンスに対して、機械翻訳で下訳を作りたいのです。ということは、品質向上の効果を測定するには、翻訳モデルの中に含まれていないセンテンスをデコードする必要があります。これまでより、厳しい条件で効果測定を行なうことにしました。

答えを先に教えとけばいいんだ

早速、翻訳モデルの中に含まれていなくて、かつ、同じような分野のセンテンスをデコードしてみました。BLEUスコアは0.4程度という低い値だったので、中身を見たところ、パスとURLを中心に英語のままでいい箇所(英ママ)がバラバラに分離されているのが目に付きました。

英ママ箇所は翻訳する必要がないため、デコード対象の英語コーパスから機械的に抽出することができれば、簡単にパラレル・コーパス化できます。それを追加した翻訳モデルを作れば、上記の例のように英ママ箇所がバラバラになるようなことがなくなるんじゃないかと思い実験したところ、効果覿面。ご覧のように、かなり塊が維持されるようになり、BLEUスコアも0.3893から0.4397(+12.9%)に改善されました。

しかし、デコードする度に翻訳モデルの再作成と再チューニングが必要になるため、デコード対象を入手してから丸1日経たないとデコードを開始できません。。それだと実用的じゃないので、再び、Mosesのマニュアルとにらめっこ。そしたら、あったんです。複数の翻訳モデルを同時に使用する方法が。

母体となる大きな翻訳モデル(当時は90万センテンス)とは別に、デコードの度に英ママ箇所だけ入った小さな翻訳モデル(せいぜい数百センテンス)を作成し、それら2つを同時に使用してデコードすれば解決です。デコード結果はやや異なっていましたが、英ママ部分がかなり塊で維持されることに変わりはありませんでした。(ちなみに、現在は別の方法を使って英ママの対応を行なっています。)

今回は、追加したセンテンスがたまたまパスやURLの類でしたが、デコード対象に含まれるフレーズを如何に翻訳モデルに入れておけるかが重要だという証になりました。この考え方は、今でも品質改良を行なう際の大切な指針の1つです。

さて、この頃は年の瀬が迫り、2010年が終わろうとしていました。3月にわけもわからぬまま初めてMosesに触れただけで、9月にMosesの担当者に指名されたときはどうなることかと思いましたが、12月になって、ようやく使い物になりそうな日本語が出てくるようになりました。一区切りついたので、一旦Mosesのことはきれいさっぱりと忘れ、冬休みに突入したのでした。

次回は前進と挫折で始まった2011年です。

[注] この回顧録は、かつて勤めていた会社で書いた連載を復元したもので、某I社の現在の状況を反映している訳ではありません。