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

第24回 再び品質改善へ (2011年3月)

前回は、Mosesを中心に某I社独自のシステム化を行なった際のお話をしました。今回は、意外な発見と3.11のときのお話です。

まさか

システム化は一段落がついたので、1月下旬から保留になっていた品質改善に、再び取り組むことにしました。何から手を付けようかという感じでしたが、そのヒントを探るため、もう一度、2010年末に行なったQA担当者による評価の結果に目を通すことにしました。

何故、こんなことを思い付いたのかは覚えていませんが、ふと、基本的な疑問が湧きました。「Mosesによるチューニング結果は、常に同じなんだろうか?」と。当然、何度チューニングしても結果は同じだろうと決め付けて、疑ったこともなかったので、検証してみようと思ったことすらありませんでした。

早速、実験をしてみましたが、なんと、チューニングをするたびに結果が変わるではないですか! しかも、チューニングの結果次第で、デコード結果がかなり変化します。同じ言語モデルと翻訳モデルを使っているのにです。大きな落とし穴でした。。

例1
原文Moves user configurations (views, mapped attributes, and so on) from one instance to another through an intermediate export file.
機械翻訳
(チューニング#1)
エクスポート・ファイルに移動します。1つのインスタンスを別の中間(ビュー、マップ済属性など)を介してからユーザー構成
機械翻訳
(チューニング#2)
ユーザー構成(ビュー、マップ済属性など)には、中間的なエクスポート・ファイルを使用してインスタンス間で移動します。
例2
原文The Footer page that displays is based upon the page template you selected on the Name and Definition page in Step 7 (either Default Page Template or Custom Page Template).
機械翻訳
(チューニング#1)
手順7で「フッター」ページで選択したページ・テンプレートに基づいています。「名前および定義」ページが表示されたいずれかのデフォルト・ページ・テンプレートまたはカスタム・ページ・テンプレートなど)
機械翻訳
(チューニング#2)
手順7で「名前および定義」ページで選択したページ・テンプレートが表示された「フッター」ページ(デフォルト・ページ・テンプレートまたはカスタム・ページ・テンプレートなど)に基づいています。

このときから、通常は3回、最低でも2回はチューニングを行ない、最もよいチューニング結果を採用するようになりました。筆者の知る限り、こんなことはどこにも書かれていなかったので、本当に気付いてよかったです。

300万センテンスの処理中に

2月にシステム化を行なっている間に、上司のGさんが過去の翻訳資産を更に集めてくださり、ついに300万センテンスものパラレル・コーパスが出来上がりました。今回は、ソフトウェアで使われている画面メッセージやボタン名など、ドキュメント以外のコーパスも多く含めたので、純粋に文章が300万センテンスというわけではありませんが、それでも従来の100万センテンスと比較して、更なる品質向上が期待できます。

そして、この300万センテンスを使って翻訳モデルを作る処理の最中に、東日本大震災が起きました。某I社は神奈川県の内陸部にあるため、被害はほとんどなかったものの、建物はかつてないほど激しく揺れ、普通は動くはずのないラックが大きくずれたり、PCが倒れたりしました。

筆者は、偶然にも午後だけ休暇を取っていたため、都内の自宅そばにいたのですが、生まれて初めて死を意識したほどの揺れとは対照的に、自宅は拍子抜けするくらい何事もなく、帰宅難民になることもなかった上に、家族や会社とも比較的スムーズに連絡が取れたのは、本当にラッキーでした。

週が明けた月曜日、首都圏の交通網がパニック状態の中、普段の倍以上の時間をかけて、何とか出社しました。そこで、初めて気が付きました。あの歴史的な大震災の中、Mosesは動き続け、300万センテンスのパラレル・コーパスから翻訳モデルを作り終えていたのです。これには、ちょっとした感動を覚えました。

しかし、この日から、計画停電との戦いになりました。日替わりで変化する停電の時間帯にあわせて、毎日、サーバー類のシャットダウンと起動の計画を立てる必要がありましたし、Mosesでの処理はまとまった時間が必要になるため、下手に処理を始めることもできません。状況が落ち着くまで、Mosesどころの話ではなくなってしまいました。

次回は長文対策の発見です。


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

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

|

検索

フォトアルバム

コンテンツ

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