• [まろぐ]
  • [簡単で正しいHTMLの書き方]
  • [Moses奮闘記]
[まろぐ] [簡単で正しいHTMLの書き方] [Moses奮闘記]

第8回 BLEUスコア導入 (2010年11月)

前回は、Mosesを使い始めて真っ先に感じた疑問を晴らすために日本語と格闘したお話をしました。今回は、その結果についてのお話です。

確かに変化したけれど

日本語コーパスを形態素解析を用いて分かち書きすると、統計的機械翻訳にとっては細かく分けすぎなんじゃないだろうかという仮説を検証するため、日本語の動詞の活用部分を中心にくっつけたコーパスを使って言語モデルと翻訳モデルを作成し、デコード結果にどのような変化が現れるか、調べてみました。

当然、よくなるはずだと思っていましたが、正直、改善したのかしなかったのか、判断がつきませんでした。でも、結果が変化したことだけは確かです。以下、いくつか例をご紹介します。(ちなみに、「日本語がブランクで区切られたまま」なのは、当時は解決方法を知らなかったからなので、気にしないでください。)

例1
原文A vertical bar represents a choice of two or more options within brackets or braces.
人間翻訳(手本)縦線は、大カッコまたは中カッコ内の複数の選択項目の区切りに使用します。
機械翻訳(基準)、 縦 線 は 、 2 つ 以上 の 大 カッコ または 中 カッコ 内 の です 。
機械翻訳(仮説)縦 線 は 、 2 つ の 選択 以上 の オプション は 、 大 カッコ または 中 カッコ 内 に あります 。
例2
原文A one-client server can be reused after its (single) client has disconnected.
人間翻訳(手本)1クライアントのサーバーは、その(単一の)クライアントの切断後に再利用できます。
機械翻訳(基準)クライアント が サーバー の 後 に 再 利用 でき 、 その 単一 の クライアント が 切断 さ れ た こと を 示し て い ます 。
機械翻訳(仮説)クライアント が サーバー を 再利用 できる 後 、 その 単一 の クライアント が 切断 された こと を 示して います 。
例3
原文A connection is defined as a connection to a server process or daemon.
人間翻訳(手本)接続は、サーバー・プロセスまたはデーモンへの接続として定義されます。
機械翻訳(基準)接続 へ の 接続 として 定義 さ れ 、 サーバー ・ プロセス または デーモン を 示し て い ます 。
機械翻訳(仮説)接続 は 、 接続 として 定義 に 、 サーバー ・ プロセス または デーモン 。

ご覧の通り、基準となるデコード結果の品質もそれほどよくありませんが、筆者の仮説を検証できるほどのデコード結果も出ていません。どちらも特別いいというわけではないので、判断がつかなかったのです。もちろん、何かの基準に基づいて1センテンスずつきっちり比較していけば全体的な傾向は出せるかもしれませんが、筆者の英語力ではそこまでのことはできませんし、この程度の品質では社内のQA担当者に評価を依頼するわけにもいきません。しかも、こんな感じで1万センテンスもあります。困りました。。

やっぱり数値化かぁ

機械翻訳の結果をどう評価するかという課題は世界共通で、一般的にはBLEUスコアというものが使われています。しかも、実にいいタイミングで同僚のFさんがBLEUスコアを出す方法を調べてくれていました。ただ、まだBLEUスコアの意味を理解していなかったので、出てきた数字の意味がわからなかった上に、想像していたものとちょっと違っていました。

そこで、BLEUスコアについて調べてみましたが、簡単に言うと、お手本の訳文と比較して、どれくらいワードの並びが一致しているかという割合を数値化したもので、最低0から最高1までの数字で表されます。そもそも、お手本の訳文が適切なのかとか、並び順だけで判断していいのかとか、いくつかの問題が指摘されていますが、一般的には人間の評価と相関関係があることが知られています。要するに、BLEUスコアが高ければ、お手本の訳文に近いということであり、人間の評価も高くなる傾向があるということです。

また、BLEUスコア自体は、各センテンスごとに付けられるものではなく、コーパス全体に対して付けられます。なので、特定の文章がいいか悪いかはわからない代わりに、文書全体の評価を数値化して把握することができます。もちろん、BLEUスコアがすべてというわけではありませんが、筆者のような翻訳の門外漢が結果の良し悪しを判断するには、非常に役に立ちます。

実は、今回の仮説を検証するために、筆者なりによいと思った対策を追加しながら、同じコーパスを計3回デコードしたのですが、これらのBLEUスコアを出したところ、想像と違う結果が出ました。(いずれも、デコード対象のセンテンスが翻訳モデルに入っているため、再現性のテストであり、BLEUスコアは高めです。)

1回目0.6633
2回目0.7107
3回目0.7010

最も対策が多く施された3回目が最高スコアのつもりでしたが、実際には2回目が最高スコアでした。しかし、複数の対策を一度に盛り込んだため、何がよくて何が悪かったのか、切り分けができない状態でした。また、今回は未確認のものも含め、変更したい条件は他にもいくつかありました。

ちょっとしんどい作業になりますが、素の状態から1つずつ条件を変更して、結果がどのように変化していくかを順番に調べていかないと、どれが効果的なのか判断ができません。何だか、卒論研究をしてるみたいだなぁと思いつつ、検証に没頭する日が続きました。

次回はおかしなセンテンスを取り除くとです。


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

投稿情報: 19:09 | 個別ページ

|

検索

フォトアルバム

コンテンツ

  • [まろぐ]
  • [簡単で正しいHTMLの書き方]
  • [Moses奮闘記]

出会い編

  • 第1回 Moses? (2010年3月)
  • 第2回 夜明け前の出来事 (2010年4月頃)
  • 第3回 機械翻訳で行くぞ (2010年8月頃)
  • 第4回 異動 (2010年9月頃)

手探り編

  • 第5回 Linuxの壁 (2010年10月)
  • 第6回 最初の疑問 (2010年11月)
  • 第7回 日本語との格闘 (2010年11月)
  • 第8回 BLEUスコア導入 (2010年11月)
  • 第9回 おかしなセンテンスを取り除くと (2010年11月)
  • 第10回 ユーザー辞書を使うと (2010年11月)
  • 第11回 押してダメなら引いてみろ (2010年11月)
  • 第12回 英ママは善か悪か (2010年11月)
  • 第13回 言語モデルは偉大なり (2010年11月)
  • 第14回 ある程度の数は必要 (2010年11月)
  • 第15回 チューニングは必須 (2010年12月)
  • 第16回 最初のブレイクスルー (2010年12月)

独自の工夫編

  • 第17回 ついに100万センテンスへ (2010年12月)
  • 第18回 メモリ不足を解消せよ (2010年12月)
  • 第19回 処理速度を改善せよ (2010年12月)
  • 第20回 品詞情報を活かせるか (2010年12月)
  • 第21回 カンニングは効果あり (2010年12月)
  • 第22回 前進と挫折で始まった2011年 (2011年1月)
  • 第23回 某I社独自のシステム化 (2011年2月頃)
  • 第24回 再び品質改善へ (2011年3月)
  • 第25回 長文対策の発見 (2011年3月)
  • 第26回 都合のいいコーパス (2011年3月)
  • 第27回 パラレル・コーパスの加工 (2011年4月)
  • 第28回 評価結果に潜むヒント (2011年5月)
  • 第29回 現在も続く改良 (2011年6月以降)

著作権

  • © 1995-2021, "Toda, Masalu", All Rights Reserved.
Powered by Typepad
  • Moses奮闘記 •
  • Powered by Typepad
上