前回は、3.11のその後と長文のデコード結果の品質を上げる案のお話をしました。今回は、既存のパラレル・コーパスを加工することに舵を切ったときのお話です。
やはりコーパス勝負なのか?
前回、300万センテンスのパラレル・コーパスで言語モデルと翻訳モデルを作成したのに、デコード結果は目を見張るような品質向上が見られず、「ある手法」でコーパスを作り出して追加したところ、長文のデコード結果の品質が向上したというお話をしました。
思い起こすと、「適切なフレーズ対」を作るという目的は同じだったものの、それまでの手段は、一般的に言われている以下の2つしか追いかけていませんでした。
- とにかくパラレル・コーパスを増やす。
- ひたすら既存の翻訳メモリを掻き集める。
- ドメインを適度に限定する。
- お客様単位で分ける。
- ある程度の製品群単位で分ける。
つまり「過去の翻訳資産をそのまま使う」という範囲に留まっていたのですが、前回の結果も踏まえ、「統計的機械翻訳にとって都合のよいパラレル・コーパスに加工していく」という発想に切換えることで、さらに品質を上げられるということがわかってきました。
パラレル・コーパスの加工とは、以下の2種類に大別されます。
追加 | 新たに必要なパラレル・コーパスを人為的に作り出して追加する。 |
---|---|
修正 | 既存のパラレル・コーパスのうち、都合の悪いものを修正して、都合のいいものと置き換える。
|
「追加」に関しては、既に効果が確認できていたものが2つありましたが、「修正」に関しては、既存のパラレル・コーパスをよく観察して特徴を掴み、改善案を検証する必要がありました。
なんだこりゃ
そして、既存のパラレル・コーパスを観察しているとき、実に偶然ですがおかしな文章を大量に発見してしまいました。英語コーパスはまったく問題ないのですが、日本語コーパスだけこんな状態です。
- 「事前定義のコンシューマ・クルーフ・マッヒンク・ルール」を参照してくたさい。
- 「単一サーハーにおける複数のテータヘース・インスタンスの管理」を参照してくたさい。
- これにより、応答時間およひスルーフット全体を改善てきます。
- 自分のスキーマにあるヒューはすへて削除てきます。
- また、リモート・オフシェクトか存在するテータヘースに、ローカル・ハフリック・シノニムを作成てきます。この場合は、フロシーシャまたはファンクションへの後続のすへてのコールに、そのテータヘース・リンクを含める必要かあります。
- テータファイルのオーフン状態のハックアッフの開始または終了
どういうわけか、濁音(ばびぶべぼの類)と半濁音(ぱぴぷぺぽの類)が抜けた状態(はひふへほの状態)になっています。わざわざこんな文章に変換する方が難しいと思うんですが、何故かこんな状態の文章がいくつもあります。ほっといても統計的な処理の過程で自然に淘汰されるのかもしれませんが、悪影響の素なので削除することにしました。ところが、出るわ出るわ、どんだけあるのってくらいあります。300万センテンスを対象に調べたところ、結局、2万4千センテンスもありました。。
そもそも、おかしなセンテンスはないくらいに思っていたので、ここまでおかしなセンテンスをこんなに大量に発見してしまうと、勝手な思い込みも見事に打ち砕かれてしまいます。逆に、こんなにおかしなセンテンスを含んでいたのなら、これらを削除したり修正することで、まだまだデコード結果の品質は上げられるんじゃないだろうかとも思いました。そして、この日を境に、300万センテンスのパラレル・コーパスを加工する日々が続きました。
次はパラレル・コーパスの加工です。
[注] この回顧録は、かつて勤めていた会社で書いた連載を復元したもので、某I社の現在の状況を反映している訳ではありません。