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

第23回 某I社独自のシステム化 (2011年2月頃)

前回は、ようやく解決した課題と難解すぎて挫折してしまった課題に関するお話をしました。今回は、Mosesを中心に某I社独自のシステム化を行なった際のお話です。

まずは処理フローから

前回も簡単に書きましたが、この頃は、Mosesの処理をするために、いくつものコマンドを手動で実行していました。必要なコマンドは、メモ代わりのテキスト・ファイルに書き留めていたので、それをコピー&ペーストして実行すれば済むものもありましたが、某I社独自の処理は手動で行なっていたり、どういう条件のときに何を実行するかを考える必要もあり、なかなか煩雑でした。今でも同じメモに追記し続けていますが、既に1,200行を超えています。

処理が煩雑なのは確かですが、裏を返せば、処理フローをきちんと把握できていないという面もあります。Mosesについて調べ始めた頃、概念を表す図はあっても、全体像を処理フローで表した資料が見付からず、処理の単位で全体の流れをなかなか理解できませんでした。

しかし、処理の自動化のためにシステム化を行なうためには、入力と処理と出力を定義し、全体がどう流れていくのかを明確にしないといけません。また、標準的な処理以外に、某I社独自の工夫としてどの処理を追加するのかを決めないと、処理の流れそのものが決まりません。

そこで、処理フローの作成に取り掛かりましたが、頭の整理ができていなかった上に、某I社独自の処理を反映させるため、それが処理フローにどう影響するかを考えるのに時間がかかり、遅々として進みませんでした。結局、小規模システムにもかかわらず、処理フローの作成だけで1週間もかかってしまいました。その代わり、処理フローが完成したおかげで、全体像が実に明確になりました。プロジェクトの他のメンバーにも説明しやすくなり、当たり前のことだけど、大きな前進でした。

次に、ツールのインストール場所や、成果物の置き場所など、ディレクトリ構成を決めました。これは、決めてしまえば済む話ですが、一度決めてしまうと変更が難しいので、本当にそれで問題がないのか、よく検討する必要があります。

そして、ここまで決まって、ようやく処理の細かな仕様を決めることができます。さらに、処理の自動化を行なう単位にあわせて、処理フローの単位を見直し、やっと筆者の担当分が終了。プログラム内部の設計から先は、同僚のFさんにお任せ。しかし、このとき既に2月中旬。残り2週間で残りの設計、コーディング、テストを行なう必要があり、スケジュール通りとは言え、本当にぎりぎりになってしまいました。

今更ですが

筆者の職種はSEということもあり、某I社に入社して8年も経つのに、実はローカライズ案件の経験はほとんどありません。機械翻訳の対象とするのは、既存訳とのマッチ率が高くないセンテンスというのは確認済みでしたが、当時は自分たちで作り出した機械翻訳の訳文が、翻訳者さんにどのように還元されるか、具体的にイメージできていませんでした。もちろん、翻訳支援ツールの存在は知っていましたし、その概要は理解できていましたが、どこにどう表示され、具体的にどう作業を進めていくのかが見えていなかったのです。

そんな中、上司であるGさんが某I社社内で統計的機械翻訳を利用する場合に、既存の翻訳支援ツールにどうやって取り込むかをまとめてくださり、ようやく具体的なイメージが湧きました。

  1. 原文と機械翻訳の訳文のパラレル・コーパスから、翻訳メモリーの標準規格であるTMX形式のファイルを作成する。
  2. 1.のTMXを翻訳支援ツールで読み込み、翻訳作業時の候補訳として利用する。

当時はTMXの存在すら知りませんでしたから、なるほどぉと、実にすっきりしました。

ようやく完成

何とか当初の予定通り、2月末にFさんの環境でのテストを終えることができました。めでたし、めでたしと、はやる気持ちを抑えつつ、筆者の環境で稼動確認をしたところ、一部が動かないではありませんか。。よく調べてみると、Fさんと筆者のMosesのバージョンが微妙に異なっていて、使うコマンドが異なっていたのが原因でした。より新しいバージョンであるFさんの環境に合わせるのが筋なのですが、このタイミングでMosesのコンパイルからやり直すのは危険なので、該当するプログラムだけ筆者の環境用に書き換え、無事に稼動するようになりました。

Fさんが、簡易的な管理コンソールのようなものを作ってくれたおかげもあり、操作は飛躍的に確実で簡単なものになりました。ちなみに、当時の操作メニューはこんな感じで、番号を選ぶだけで必要な処理ができます。

***** 処理を選択してください. ******
1) [1.1]パラレルコーパスの前処理
2) [1.2]言語モデルと翻訳モデルの作成
3) [1.3]チューニング処理
4) [2.1]パスやURLの抽出と前処理
5) [2.2]パスやURL用の言語モデルと翻訳モデルの作成
6) [2.3]パスやURL用のチューニング処理
7) [2.4]Recase用のトレーニング処理
8) [2.5]デコード用の言語モデルの作成
9) [2.6]デコードの前処理
10) [2.7]デコード処理
11) [2.8]逆分ち書き:デコードの後処理
12) [2.9]タグ追加:デコードの後処理

終了する場合:(N/n)

履歴:
--->

その後も何度か大きな改良を加えましたが、処理フローの変更に伴って操作メニューも変更し、現在も使い続けています。

次回は再び品質改善へです。


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

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

|

検索

フォトアルバム

コンテンツ

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