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

第25回 長文対策の発見 (2011年3月)

前回は、意外な発見と3.11のときのお話をしました。今回は、3.11のその後と長文のデコード結果の品質を上げる案のお話です。

計画停電からの解放

3.11の翌週、東京電力による計画停電が始まりました。1日に何度も東京電力のプレスリリースを確認し、日替わりで変化する停電の時間帯にあわせて、毎日、サーバー類のシャットダウンと起動を繰り返しました。在宅勤務の社員からは、「本当に停電しました」という報告が何件も寄せられましたが、結局、某I社では一度も停電しないまま、最初の週が終わりました。

その翌週、東京電力から、より詳細な情報が公開された段階で、実は某I社が入居しているビルは、計画停電の対象外だということが判明しました。念のため、東京電力にも問合せをしたところ、確かに対象外だと確認でき、世間よりかなり早い段階で計画停電から解放されました。電車の間引き運転は続いていたので、通勤の不便さは残っていましたが、あの歴史的大震災から10日程度で普段どおりの状態に戻ることができ、非常に助かりました。

ひらめいた

さて、300万センテンスのパラレル・コーパスを用意し、新たに言語モデルと翻訳モデルを作成しましたが、デコード結果に目を見張るような品質向上は見られませんでした。ある程度のコーパスを確保できたら、そこから先の品質向上は鈍化するのでしょう。単にコーパスの量を追い求めるだけだと、この頭打ちに近い状態から抜け出せそうにありませんでした。何か改善策はないかと、デコード結果とにらめっこが続きました。

一般的に機械翻訳の訳文は、短文だと比較的うまくいくのに、長文だと使い物にならないことが多いです。某I社の統計的機械翻訳も同じような傾向にありましたが、同じ長文でも、文法的には非常に簡単なのに、デコード結果がかなりおかしなものがあった反面、文法的には難しいはずなのに、デコード結果は良好なものもありました。

この差は、一体何なんだろう。。長文でも安定的に良質な訳文を生成できるようになれば、ポストエディットの作業効率は格段に上がるので、何とかして理屈を解明し、解決したい課題でした。そして、いくつもの原文と訳文を眺めているうちに、ある仮説を思い付きました。

  • 要するに、デコードの基となる「フレーズ対」が正しくないと品質は上がらないので、正しいフレーズ対を作ってくれるようなコーパスを人為的に作ってあげれば、デコード結果の品質は上がるのではないだろうか。
  • 特に長文では、英語と日本語のフレーズの組合せが無限に広がってしまい、正しいフレーズ対になる確率が大幅に下がってしまうので、ある手法でコーパスを作ってしまおう。

すべての長文に対して効果があったわけではありませんが、全体的には確実に効果がありました。以下は、うまくいった例です。

例1
原文Also, unstructured data such as text, graphic images, still video clips, full motion video, and sound waveforms tends to be large in size.
機械翻訳(改善前)waveformsもなる傾向があります。テキスト、グラフィック・イメージ、サウンド、ビデオおよび、フル・モーション静止ビデオ・クリップなどの大型で非構造化データ
機械翻訳(改善後)また、テキスト、図形イメージ、静止ビデオ・クリップ、フル・モーション・ビデオおよびサウンド・ウェーブフォームなどの非構造化データは、サイズが大きくなる傾向があります。
人間翻訳(手本)また、テキスト、図形イメージ、静止ビデオ・クリップ、フル・モーション・ビデオおよびサウンド・ウェーブフォームなどの非構造化データは、サイズが大きくなる傾向があります。
例2
原文For example, emphasized text can be rendered as italics on a desktop, or as underlined text in handheld devices.
機械翻訳(改善前)たとえば、強調テキストか、携帯情報端末では下線として、デスクトップではイタリックとしてレンダリングできます。
機械翻訳(改善後)たとえば、強調テキストは、デスクトップではイタリックとしてレンダリングし、携帯情報端末では下線としてレンダリングできます。
人間翻訳(手本)たとえば、強調テキストは、デスクトップではイタリックとしてレンダリングし、携帯情報端末では下線としてレンダリングできます。

実験は99センテンスで行ないましたが、ご覧のように改善効果はBLEUスコアにも反映されています。

改善前0.7024
改善後0.8458

肝心な「ある手法」の中身が気になるかもしれませんが、今はまだ明かせません。。また、「ある手法」を忠実に実行するためには、かなり人手がかかってしまうため、どうやって効率化を図るかが課題でした。しかし、どういうコーパスを用意すれば、より正しいフレーズ対ができるのかがわかったのは、非常に大きな収穫でした。

次回は都合のいいコーパスです。


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

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

|

検索

フォトアルバム

コンテンツ

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