前回は、いきなり遭遇した最初の壁であるLinuxのセットアップのお話をしました。今回は、Mosesを使い始めて真っ先に感じた疑問のお話です。

動いた!

2週間かけて何とかセットアップを終え、どうにかMosesが動く環境を用意できました。しかし、統計的機械翻訳を使って翻訳(デコード)するには、これだけでは足りなくて、膨大な量の対訳集(パラレル・コーパス)が必要になります。(統計的機械翻訳の概要については、「初心者にもわかる機械翻訳入門」をご覧ください。)

まずは、品質度外視で一通りの処理を経験するために、とりあえず1万センテンスのパラレル・コーパスを用意してもらい、以下のような手順で処理を行ないました。

1. 英語と日本語のパラレル・コーパスに対して、前処理(分かち書き、小文字化、クリーニング)を行なう。
2. 日本語のコーパスから、言語モデルを作成する。
3. 英語と日本語のパラレル・コーパスから、翻訳モデルを作成する。
4. 言語モデルと翻訳モデルを使って、英語のコーパスを日本語にデコードする。

最初は、量の加減というものすらわからなくて、とりあえず1万センテンスをそのまますべてデコードしてみました。Mosesに付属のサンプルではなく、自分たちのパラレル・コーパスを使ってデコードできたということに、ちょっとした感動すら覚えました。

これでいいのか?

でも、最初の第一歩を踏み出したばかりで、浮かれてる場合じゃありません。デコード結果がどの程度の品質なのだろうかと眺めてみましたが、明らかにおかしな日本語が散見されます。わかりやすいものだと、いきなり「を」「の」「と」で始まったり、中には「、(読点)」で始まるものもあります。例えば、こんな感じです。

デコード対象と同じ英語の文章は、すべて翻訳モデルの中に入っているので、答えはわかりそうなものですが、統計的な処理を施すので、100%再現されるわけではないという具体例でもあります。この手のおかしな日本語が出るというのは、事前の情報として持っていたものの、実際におかしな日本語を目の当たりにすると、どうしようかと立ちすくんでしまいます。

ちなみに、「英語がすべて小文字のまま」なのと「日本語がブランクで区切られたまま」なのは、当時は解決方法を知らなかったからです。

ちょっと解説しますと、Mosesではデコード対象のアルファベットをすべて小文字にしなければいけません。なので、デコードを終えた後、「すべて小文字」なのを「大文字小文字交じり」に戻す処理が必要になります。

また、日本語には英語のような単語と単語の区切りがないので、分かち書きという処理によって、単語と単語の間をブランクで区切ってしまいます。そして、言語モデルや翻訳モデルの中も、単語に分解された日本語が入っており、Mosesがデコードする際は、バラバラに区切られた日本語の単語を組み合わせて日本語の文章を出してくれます。

そして、これらのおかしな日本語を眺めながら、最初の疑問がふと湧いてきました。

「分かち書きの単位って、これでいいの?」

日本語の分かち書きをする際、一般的には形態素解析というものを用いるのですが、これだと日本語を構成する最小単位にまで細かく分けてしまいます。例えば、

• 指定されたプロパティを編集します。

という文章は、

• 指定 さ れ た プロパティ を 編集 し ます 。

と10ワードに分解されます。もちろん、形態素解析としては正しいのですが、この分け方が果たして統計的機械翻訳にも最適なのだろうかと疑問を持ったのです。特に、動詞の活用部分がやたらと細かく分かれているのが気になりました。例えば、言語モデルには5ワード分の並び順の確率が入るようにしていたのですが、もう少し大きな単位で区切った方が、5ワードでカバーできる文章が長くなり、おかしな日本語を減らせるのではないかと考えたのです。

統計的機械翻訳に関する日本語の情報は、そもそも多くはないのですが、分かち書きの単位について言及したものを見たことがありませんでした。これは、きっと誰も注目していない領域だと思い、この日から仮説を検証するための実験が始まったのでした。

次回は日本語との格闘です。

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