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

第14回 ある程度の数は必要 (2010年11月)

前回は、言語モデルがデコード結果に与える影響についてのお話をしました。今回は、言語モデルや翻訳モデルの基となるパラレル・コーパスのセンテンス数についてのお話です。

増やしてみるか

第4回で書いたように、2010年10月の時点では「2010年11月末(翌月末)までにMosesの仕組みの理解とパフォーマンス測定を行なう」という目標を掲げていたため、言語モデルや翻訳モデルの基となるパラレル・コーパスは、決して多くはないとわかった上で、当時すぐに用意できた10万センテンスのものを使っていました。

パラレル・コーパスのセンテンス数は、一般的に多ければ多い方がよいと言われていますが、最低どれくらい必要で、適量がどれくらいなのか、目安すら目にしたことがないので、まだ誰も把握できていないのかもしれません。なので、10万センテンスという量が、どのくらい足りていないのか、もしくは、どのくらい足りているのか、見当も付かないという状態でした。

唯一、手がかりとなる数字は、先輩Kさんが2010年5月に参加したAAMT主催の「Google翻訳についてのFranz Och博士講演会」で紹介されていました。別の資料(Machine Translation at Google)に同じ図(P48)がありましたが、100万ワード(単位に注意)より1,000万ワード、1,000万ワードより1億ワード、1億ワードより10億ワードと、ワード数を増やせば増やすほど、確実にBLEUスコアが上がる実験結果となっています。

手持ちの10万センテンスですが、単純に10ワード/センテンスとすれば100万ワード、多めに見積もって20ワード/センテンスとしても200万ワードでしかありません。前述の図で言うと、一番左端の量に過ぎません。わかっていたとは言え、やはり少ないということを再認識しました。

何となくですが、10万センテンスの次は30万センテンス、さらにその次は100万センテンスという目安が浮かんできたので、上司であるGさんにお願いして過去の翻訳資産をかき集めてもらい、30万センテンスのパラレル・コーパスを用意していただきました。

これまで、いくつかの条件を変えてデコード結果の変化を確認してきましたが、どれもこれもBLEUスコアには大した影響を与えなかったということは、単純にパラレル・コーパスの量を増やす方が効果的なのかもしれません。BLEUスコアを使った検証の、6番目のテーマが決まりました。

ようやく変化あり

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

改善前10万センテンスのパラレル・コーパスを、そのまま使う。(103,835センテンス)
改善後30万センテンスのパラレル・コーパスを、そのまま使う。(317,149センテンス)

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

  • パラレル・コーパスは、第9回で指摘したおかしなセンテンスも含む。
  • デコード対象のセンテンスは、文章の類を手持ちのパラレル・コーパスから抽出。つまり、再現性の確認。
  • 分かち書きは素の状態から手を加えない。(明らかにおかしな分かち書きもそのまま。)
  • デコード時のパラメータのチューニングはしない。(当時はチューニング方法がわからなかったため。)

そして、デコード結果のBLEUスコアですが、これまでで最も大きな変化が現れました。

改善前0.6568
改善後0.6780 (+3.2%)

センテンス数を3倍にした(200%増やした)のに、BLEUスコアはたったの3%しか改善しなかったとも取れますが、それでも、これまでの苦労は何だったんだというくらい、あっさりと記録を更新しました。ただ、改善したという意味ではうれしかったのですが、第12回でも書いたように、「結局、所有するパラレル・コーパスの量だけで勝負が決まってしまうという、一次元的でつまらない話なのかも」ということであれば、悲しい結果でもありました。

しかし、やはり3%しか改善していないわけで、劇的な改善ではありません。まだ、デコード時のパラメータのチューニングをしたことがなかったので、そこに一縷の望みを託すことにしました。

次回はチューニングは必須です。


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

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

|

検索

フォトアルバム

コンテンツ

  • [まろぐ]
  • [簡単で正しい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
上