翻訳エンジンのお試しサイト（https://devneko.jp/demo/）を更新した。主に下記の機能を追加している。
- 最大3000文字までの長文対応
- 訳抜け防止モードの高度化
- 翻訳結果に対するスコア表示
長文対応は文字数制限を外してnltkのsent_tokenize[1]を使用しているだけである。翻訳結果に対するスコア表示、訳抜け防止モードは以下のように多少工夫した。
訳抜け防止モード
Deep Learningな機械翻訳では訳抜けという現象が発生する。これは訳すべき英文を省略してしまうという現象である。結果、流暢であるが情報が欠けた文章が出力される。Google翻訳やDeepL翻訳などメジャーな翻訳エンジンでも起きることがあり（当然ながら）個人開発の翻訳エンジンではよく発生する。
例えば、下記の英語文を翻訳する例を示す。
Natural language processing (NLP) is a subfield of linguistics, computer science, and artificial intelligence concerned with the interactions between computers and human language, in particular how to program computers to process and analyze large amounts of natural language data.
https://en.wikipedia.org/wiki/Natural_language_processing 11 October 2020, at 18:45 (UTC) の版、Wikipediaより引用
現在の私の翻訳エンジンは上記文章を「 自然言語処理(nlp)は、コンピュータと人間の言語間のインタラクションに関する言語学、コンピュータ科学、人工知能のサブフィールドである。 」と翻訳し、「in particular」以後の情報が抜けている[2]。
訳抜けには様々な理由が考えられるが長い文だと発生しやすい。そこで訳抜け防止モードではconstituency parsing[3]を行ったうえで意味が成立しそうなブロックに分割し翻訳エンジンを適用するフローを採用している。ブロック分割した結果はお試しサイトの一番下に表示される。本件では翻訳対象の文が
Natural language processing ( NLP ) is a subfield of linguistics, computer science, and artificial intelligence concerned with the interactions between computers and human language,
https://en.wikipedia.org/wiki/Natural_language_processing 11 October 2020, at 18:45 (UTC) の版、Wikipediaより引用
in particular how to program computers to process and analyze large amounts of natural language data.
https://en.wikipedia.org/wiki/Natural_language_processing 11 October 2020, at 18:45 (UTC) の版、Wikipediaより引用
に分割された。結果、訳抜け防止モードでは上記の英文を「自然言語処理(nlp)は、コンピュータと人間の言語間の相互作用に関する言語学、コンピュータ科学、人工知能のサブフィールドである。 特に、コンピュータが大量の自然言語データを処理および分析するためのプログラム方法。」と翻訳した。意味としては良くなっている一方で流暢さは損なわれている。 実装した訳抜け防止モードは文を分割して翻訳しているだけであり、現状の機械翻訳エンジンは文脈の考慮もできていない。訳抜け防止モードの翻訳品質は通常モードに比べて低くなる。
翻訳エンジンのお試しサイトでは通常の翻訳×２[4]と訳抜け防止モード×２の結果を文毎に比較し、最も良い結果（スコア算出方法は後述）を採用している。
スコア表示
お試しサイトでは英語文と対応する翻訳文それぞれについてスコアが付与されている。スコアは翻訳文が良いかどうかを表す指標であり、0.0 – 1.0で評価される。概ね0.7以上であればそれなりの訳文になっていることが多く、0.5以下の場合は何かしらの問題が起きていることが多い。特に0.3以下の場合はほぼ確実に訳抜けが発生している。
スコアは「①文の類似度」×「②単語/形態素数の類似度」で計算している。「①文の類似度」はUniversal Sentence Encoder[5] + cos類似度である。LaBSE[6]も試行したがこのタスクではメモリ・計算時間の増加[7]に比べて効果が薄かった。「② 単語/形態素数の類似度 」は英文の単語数と日本語文の形態素数の比率が対訳データの平均（0.85）に近いかを計算している。形態素解析はMeCabを用いた。
所感・その他
お試しサイトの処理フローは以下の通りで機械翻訳エンジンを使う際の対応は大体実施できた気がしている。
- 改行が連続した場合は別の文とみなし、処理ブロックを分ける。（途中改行が1つの場合、文は連続しているとみなす。arxivの論文やPPT資料でありがちな改行の入り方に対応している。）
- 処理ブロック内の文章をNLTKのsent_tokenizeで文に分割する。
- 文に分割されたデータそれぞれに対してconstituency parsingを行い、意味が成立すると思われる一定の長さで文を分割する。
- 上記、2.、3.で作成した文のリストを機械翻訳エンジンで和訳する。和訳はハイパーパラメータを変えた2つのエンジンで行う。
- 翻訳対象の英語文それぞれについて４つの和訳結果（3.の有無×4.の2つの結果）のスコア（USEのcos類似度×単語/形態素数の平均比）を計算し、一番良いものを採用する。
それなりに複雑な処理になっているがOSSのソフトフェア・モデルをフル活用しているためコードの記述量はそこまで多くない。上記処理もそのうちgithubとかで公開しようと思っている。
（今のところ情熱が残っているので）今後は翻訳エンジン自体の強化を行っていく予定である。
現時点で前回使ったデータに加えて約200万対訳ペアの作成が完了している。加えて50万対訳ペア程度は追加できそうなのでデータ量は1.5倍程度にはなる見込みである。ぼちぼち小文字統一をしなくても良さそうなデータ量になっていることもあり、条件を変えながら深層学習モデルを作って比較するような事もやっていきたい[8]。
文脈が計算可能なデータ（対訳ペアの元となったドキュメント情報が残っているデータ）もそれなりにあるので、文脈パラメータを入れた機械翻訳エンジンの作りたいなーとも思っている。
構築したモデルはCC BY SAくらいのライセンスで公開する予定で自然言語処理分野の英語データセットを和訳する利用方法を想定している。アノテーション構造を保持したい場合の支援機能[9]組み入れも予定しつつ、時間があまりないなーと思っている今日この頃。
脚注
[1] https://www.nltk.org/api/nltk.tokenize.html?highlight=sent_tokenize#nltk.tokenize.sent_tokenize
[2] メジャーな翻訳エンジンは正しく処理する。流石である。
[3] 今回はAllen NLPのhttps://demo.allennlp.org/constituency-parsingを用いた。
[4] 翻訳はハイパーパラメータを変えて2回実行している。複数候補を出して選ぶというのもよく見られる構成だが、本件では行っていない。
[5] https://tfhub.dev/google/universal-sentence-encoder/4 対訳データ作成でもお世話になったモデルである。
[6] https://tfhub.dev/google/LaBSE/1 BERT系のモデルであり、多言語対応のText Embedding用途では最新・最高性能に近いと思われる。
[7] 類似度の妥当性ではUSEに比べてLaBSEがやや良いが、計算時間が数十倍（50倍以上）でありメモリ使用量も増加する。お試しサイトで使っているVPSで動かすのは厳しかった。
[8] AWS課金が凄いことになりそう。。。本当はBack Translationもやりたい・・・。
[9] 英語文→日本語文でタグ構造を維持する程度の機能は入れたい。tokenizer（sentence piece）構築時点でタグを特殊記号扱いし、対訳ペアに正しくタグを扱っている文を追加して学習させる予定である。このあたりは翻訳エンジンそのものに手を入れないと実現しにくく、メジャーな翻訳エンジンで同様の事をやるのは簡単ではないと思っている。