前回は、英語のままでいい箇所の対応方法についてのお話をしました。今回は、ようやく解決した課題と難解すぎて挫折してしまった課題に関するお話です。
メモリ不足からの解放
年が明けて、世は2011年に。21世紀になって、もう10年目だなんて、早過ぎる。。なんてことを考えながら、連休ボケの頭を徐々に戻していきます。
さて、何を調べていて閃いたのか、まったく覚えていないのですが、第18回で書いた翻訳モデルのバイナリ化によって、本来やりたかったオンデマンド・ローディングが、ようやく出来るようになりました。デフォルトの設定だと、デコード時に翻訳モデルをすべてメモリに読み込んでしまうため、メモリの消費量がGB単位になってしまうところを、翻訳モデルの必要な部分だけをファイルから読み込むという機能がオンデマンド・ローディングです。それをデフォルトにしろよとツッコミたくなるような機能なのですが、Mosesのマニュアルどおりに設定しても、ずっと機能しなくて、保留にしていたんです。
当時は、Googleでオンデマンド・ローディングについて検索しても、「翻訳モデルをバイナリ化するだけで、あとはMosesが自動判断します」という回答しかなく、困り果てていたのですが、設定ファイルであるmoses.iniの注釈を読むうちに、その回答の頃とは書式が変わっているようだということに気が付きました。確かに、古い書式だと最初からバイナリも想定しているようなことが書かれていて、かつ、moses.iniは古い書式でも認識すると書かれています。
ということは、古い書式に書き換えてあげればうまくいくかもと思って試したら、ようやくオンデマンド・ローディングで動くようになりました。今になって気付いたんですが、当時のMosesのマニュアル(2010/11/15版)には書かれていなかった新しい書式での修正手順が、今のマニュアルには追加されているではありませんかっ!
しかし、そんな愚痴はどうでもよくなるくらい、その効果たるや絶大。翻訳モデルをメモリに読み込まなくなったので、メモリの消費量が1GB強に激減しました。これなら、メモリが2GBのPCでも稼動しますし、4GBのPCなら余裕で処理できます。
しかも、デコードを始めるまでの時間も大幅に短縮され、1センテンスだけデコードしてすぐに結果を見たいときも、気軽に使えるようになりました。デコード結果に変化がないことも確認でき、年初から幸先のよいスタートです。
一方で挫折も
それなりの品質のデコード結果を出せるようになってきたということもあり、徐々に実用化した後の使い方も意識するようになってきていました。実は、2010年末にQA担当者がMosesのデコード結果を評価したのですが、そのままの状態で問題ないものから、ほとんど使い物にならないものまで、センテンスによって品質の差があり、修正に要する作業量を事前に算出しづらいという感想をもらっていました。例えば、デコード結果と共に松竹梅のような格付けがされていれば、「松なら最小限の修正、竹なら通常の修正、梅なら新規に人間翻訳」のような切り分けが可能で、事前に作業量を把握することもできます。
問題は、デコードの時点で、そのような格付けが自動的にできるかどうかです。そこで、Mosesが内部的に使っている情報で、何か使えそうなものがないかを調べ始めました。教科書的存在であるStatistical Machine Translationを開き、Mosesがどうやってデコードしているのか、そのアルゴリズムを勉強し、概要を理解するところまではできました。デコード途中で発生するいくつもの候補訳に対し、それぞれスコアを付け、最もよいスコアがデコード結果として採用されるのですが、筆者の理解ではスコアは絶対評価ではないため、複数のセンテンス同士のスコアを比較しても意味がなさそうでした。
また、スコアは「ある確率値(0から1まで)の対数(-∞から0まで)」だと理解していたのですが、実際のデコード結果では稀にプラスのスコア(確率100%以上?!)が存在し、この時点で筆者の脳みそが融け始めました。。もう少し時間をかけて勉強し、デコード結果の自動格付けを実現したかったのですが、見通しが立たなかったため、この時点で諦めました。
方針転換
また、この頃は、Mosesの処理をするために、いくつものコマンドを手動で実行していたため、実際に案件が発生しても、ミスなく効率よく処理できるような状態ではありませんでした。まさに、実験段階の域に留まっていました。実用化のためには、某I社独自の処理も含め、メニューから番号を選ぶだけで必要な処理を行なえるように、システム化する必要があります。元々、2010年秋の時点での目標は、2011年春にシステム化が完了だったので、品質改善は一旦中断し、以下のような方針を立てました。
- 2月(翌月)末までに、プレーン・テキストを対象に社内に対して統計的機械翻訳サービスを開始できるよう、作業フローを確立し、体制を整える。
- 1.が終了後、タグ付きテキストを対象に処理を行なうための具体的な手段を検討する。
- 2.と並行して、品質改善に関する実験を再開する。
5週間で、要件定義、設計、コーディング、テストを終えなければならず、それなりにタイトなスケジュールです。それまでは、Mosesに対する理解を深めるための研究や実験が中心でしたが、ついに、実用化へ向けて最初の一歩を踏み出しました。
次回は某I社独自のシステム化です。
[注] この回顧録は、かつて勤めていた会社で書いた連載を復元したもので、某I社の現在の状況を反映している訳ではありません。