株式会社アイタス

厳しいなぁ

2010年12月の第1回目に続き、2011年4月にアイタスのQA担当者によるMosesのデコード結果の評価を行ないました。GWが明けた5月上旬に評価結果がまとめられたので、恐る恐る目を通してみました。以前よりはよくなったと言われたものの、なかなか厳しいコメントの連続です。今回は3名が評価したのですが、要約すると以下のような課題にまとめられました。

• 括弧が対になっていない。(過不足あり。)
• 括弧内が塊として維持されていない。
• 訳文の語順がバラバラ。(重文と複文、andとor、未知語に弱い。)
• 英ママであるべき箇所が英ママになっていない。
• 定型文が違う表現になっている。
• 項番号を中心に最後の数字が抜ける。
• 用語とUIが不確実。(お客様指定の言葉になっていない。)
• 逆分かち書きが完璧じゃないので余計なブランクあり。

いずれもBLEUスコアを見ているだけでは見えてこない課題なので、非常に貴重なコメントばかりです。しかし、どうやって解決しようか、実に悩ましいものばかりです。最後の逆分かち書きを除けば、いずれも統計的な処理が苦手とする類で、確率に頼って訳文を生成している限り、改善が難しいです。パラレル・コーパスを文字通り桁違いにかき集めれば、それなりに改善するのかもしれませんが、統計的な処理では結果が100%保証されないことが問題なのであり、根本的な解決にはなりません。

しかし、

• 括弧内が塊として維持されていない。
• 項番号を中心に最後の数字が抜ける。

の2つだけは、ほぼ改善が見込めていました。以下は、改善前の例です。

統計的な手法だけに頼らない

実は、2011年1月の時点で、既にヒントを発見していました。MosesはXMLをデコード対象として扱えるのかという観点で調べていたところ、偶然に、デコード対象にXMLを使って付加情報を加えられる機能があることを発見していたのです。この機能を使えば、訳語の語順に制限を加えたり(Specifying Reordering Constraints)、訳語の指定をしたり(XML Markup)、統計的ではない外部情報を与えることができ、上手に使えばデコード結果の品質を上げることができます。

ただ、やはり上手に使わないと、逆にもっとおかしな訳文が生成されてしまうため、手段として使えそうだというところで止まっていました。また、アイタス独自のシステムに組み込むにも、それなりの改良が必要でした。でも、次の改善の方向性が見えてきました。

次回は現在も続く改良です。