前回は、言語モデルや翻訳モデルの基となるパラレル・コーパスのセンテンス数についてのお話をしました。今回は、デコード時のパラメータのチューニングについてのお話です。
わかってしまえば
第1回で初めてMosesに出会ったときのお話をしましたが、その時から、Mosesを使ってデコードをする手順については、長岡技術科学大学の情報を参考にしていました。このページでは、チューニングは「moses.iniのパラメータ調整をもっとまじめにするとき」と紹介されており、かつ、手順を読んでもさっぱり理解できなかったこともあって、2010年秋の時点でも、チューニングというのは相当な上級者のやることだという先入観がありました。
しかし、これまで何回にも渡って書いてきたように、様々な工夫を施すも、ちっともBLEUスコアの向上にはつながりませんでした。おまけに、最も効果的だったのが、言語モデルと翻訳モデルの基となるパラレル・コーパスの量を増やすという、実に原始的なものでした。最初の意気込みはどこへやら、手詰まり感でいっぱいです。
こうなると、チューニングに手を出すしかありません。同僚のFさんに調査をお願いし、どうにかチューニング方法はわかりました。勝手な先入観とは裏腹に、わかってしまえば、手順そのものは簡単なものでした。
- チューニング用のパラレル・コーパスを用意する。
- Mosesに付属のスクリプトを使ってチューニングを行なうと、最適と思われるパラメータ値が入った設定ファイルができる。
- 2.の設定ファイルを使ってデコードする。
Mosesのデコード時に使われるパラメータはいくつもあり、その意味もかなり難解です。実は、未だに細かな意味については、理解できていません。でも、とりあえず手順どおりに実行すれば、最もよさそうなパラメータ値を自動で見繕ってくれるわけですから、何で今まで利用しなかったの? って話です。
後から徐々にわかったことですが、Mosesで行なっているチューニングは、チューニング用のパラレル・コーパスを使って、以下のような方法で最適と思われるパラメータ値を探っていきます。
- 原文コーパスをデコードする。(初回のパラメータ値はデフォルト値を、それ以降は3.の計算結果を使う。)
- 訳文コーパスを手本とした1.のデコード結果のBLEUスコアを算出する。
- あるアルゴリズムで次のデコード時に使うパラメータ値を算出する。
- 2.のBLEUスコアの向上が頭打ちになるまで1.から3.を繰り返す。
これまではずっと、デフォルトのパラメータ値を使ってデコードしていたので、これは期待できそうです。BLEUスコアを使った検証の、7番目のテーマが決まりました。
記録更新
比較する条件は、以下のとおりです。
改善前 | デフォルトのパラメータ値を使ってデコードする。(103,835センテンス) |
---|---|
改善後 | チューニング結果のパラメータ値を使ってデコードする。(103,835センテンス) |
主な共通の条件は、以下のとおりです。
- パラレル・コーパスは、第9回で指摘したおかしなセンテンスも含む。
- デコード対象のセンテンスは、文章の類を手持ちのパラレル・コーパスから抽出。つまり、再現性の確認。
- 分かち書きは素の状態から手を加えない。(明らかにおかしな分かち書きもそのまま。)
そして、デコード結果のBLEUスコアですが、前回をさらに上回り、最もスコアが向上しました。
改善前 | 0.6568 |
---|---|
改善後 | 0.6849 (+4.3%) |
前回はパラレル・コーパスのセンテンス量を3倍に増やしたのですが、チューニングするだけであっさりとそれを上回る効果を手にすることができました。これは、チューニング必須ですね。というか、今まで何やってたんだろ。。
分かち書きの単位に疑問を持ち、おそらく、他人とは違うアプローチで様々な改善を試みてきたものの、結局、効果が大きかったのは、今思えば王道とも思われる2つの手法でした。
- デコード時のパラメータのチューニング
- パラレル・コーパスの増量
ずいぶんと回り道をしてしまったかもしれませんが、何が効果的で、何が効果的ではないか、1つずつきちんと体験することができました。そして、これまで効果的だったものを組み合わせれば、さらに効果的になるはずです。ようやく手詰まり感から脱し、光が射してきた感じになってきました。
次回は最初のブレイクスルーです。
[注] この回顧録は、かつて勤めていた会社で書いた連載を復元したもので、某I社の現在の状況を反映している訳ではありません。