• [まろぐ]
  • [簡単で正しいHTMLの書き方]
  • [Moses奮闘記]
  • [プレゼンは引き算の美学です]
[まろぐ] [簡単で正しいHTMLの書き方] [Moses奮闘記] [プレゼンは引き算の美学です]

第16回 最初のブレイクスルー (2010年12月)

前回は、デコード時のパラメータのチューニングについてのお話をしました。今回は、初めてデコード結果が劇的によくなったときのお話です。

よく調べてみれば

前回のお話の時点で、ようやくデコード時のパラメータのチューニング方法がわかり、初めてパラメータ値をデフォルトとは違うものにしてデコードしてみましたが、それまでの苦労をあざ笑うかのように、最もBLEUスコアが向上しました。正直、パラメータ値を変えることで、こんなに変化があるとは思ってもいなかったし、それまではMosesを使うことで精一杯だったこともあり、どんなパラメータがあるとか、デフォルト値は何かとか、ほとんど意識したことがありませんでした。しかし、前回の結果を経験してしまうと、意識せざるを得ません。

気持ちを改め、デコード時のパラメータについて調べ始めたところ、「あれ?」というパラメータ値があることに気が付きました。原文と訳文の語順の移動を何ワードまで許すかというパラメータで、チューニングの有無にかかわらず、設定ファイルには6ワードまでと指定されていました。

実は、同僚のFさんがかなり早いタイミングで、「日本語にデコードする際は、語順の制限(Reordering Limits)をなくした方がいい」という情報をどこかの大学の論文から得ていました。いつも教科書にしているStatistical Machine Translationには、「経験則では、語順の制限が5-8ワードを超えると、性能は改善せず、むしろ悪化する」(P.167)と書かれていますが、そりゃ欧米言語間の話で日本語は違うんだよ、という類の一例でもあります。このこと自体はすごく頭に焼き付いてて、普段の会話でも何度か取り上げられていたのですが、それがデコード時にどう指定されているかなんて、確認したこともありませんでした。

灯台下暗しとは、まさにこのこと。いくら余裕がなかったとは言え、肝心なことを確認できていませんでした。語順の制限を解除してデコードすれば、更なる改善が見込めます。これまでに少しでも効果があった対策をすべて盛り込み、かつ、語順の制限を解除してデコードしてみました。

キターーーーーー!

比較する条件は、以下のとおりです。

改善前特に工夫せずデコードする。(317,149センテンス)
改善後 #1これまでに効果があったことをすべて盛り込んでデコードする。(285,199センテンス)
  • デコード時のパラメータのチューニングを行なう。(第15回)
  • 原文も訳文も英語のままのセンテンスをコーパスから外して言語モデルと翻訳モデルを作る。(第12回)
  • おかしなセンテンスをコーパスから外して言語モデルと翻訳モデルを作る。(第9回)
改善後 #2#1に加えて語順の制限を解除してデコードする。(285,199センテンス)

主な共通の条件は、以下のとおりです。

  • デコード対象のセンテンスは、文章の類を手持ちのパラレル・コーパスから抽出。つまり、再現性の確認。
  • 分かち書きは素の状態から手を加えない。(明らかにおかしな分かち書きもそのまま。)

そして、デコード結果のBLEUスコアですが、ついにブレイクスルーとも言える、劇的な変化が現れました。語順の制限を外したことが、予想以上に大きな変化をもたらし、実に自然な日本語が出力されるようになりました。

改善前0.6780
改善後 #10.6992 (+3.1%)
改善後 #20.9210 (+35.8%)

その代償として、デコード時間は倍以上に増えました。Mosesを稼動させ始めた頃は、パラレル・コーパスのセンテンス数も少なく、各種処理時間も気にするほどではありませんでしたが、この頃はセンテンス数を3倍に増やしたり、デコード時の語順の制限を外したりしたため、処理時間もメモリの消費量も増える一方でした。これについては、後日、触れたいと思います。

デコード時の語順の制限を外したことは、デコード結果の大幅な品質向上をもたらしただけではなく、欧米語圏の常識に囚われるなという、非常にいい教訓にもなりました。日本語だけが特殊だとは言いませんが、やはり欧米語圏とは異なる日本語独自の対策やノウハウが必要だということだと思います。

次回はついに100万センテンスへです。


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

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

|

検索

フォトアルバム

コンテンツ

  • [まろぐ]
  • [簡単で正しい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-2023, "Toda, Masalu", All Rights Reserved.
Powered by Typepad
  • Moses奮闘記 •
  • Powered by Typepad
上