Category Archives: 機械翻訳

ニューラル機械翻訳モデルと対訳データの品質

ニューラル機械翻訳モデルやDeepLearningに限らずだがデータ品質とデータ量の関係は良く話題になる。品質の良い少量のデータでモデル構築を行うべきなのか、多少品質が悪くとも大量のデータを用いるべきなのかという議論である。

本記事ではニューラル機械翻訳モデル(Marin-NMTによるTransformer)を対象としてデータ品質を向上させた約1000万対訳ペアのデータと品質向上前(最低限のクレンジングを実施)の約1400万対訳ペアのデータで構築したモデル[1]を比較した。

その結果、品質向上後データではBLEU=28.6、品質向上前データではBLEU=27.5とBLEUで約1.1pointの品質向上の効果が示された。これは乱数で出るような影響ではなく本件で実施した品質向上処理には意味があるものと思われる。

以下、詳細を記載する。

基本的なクリーニングロジック

FuguMTでは様々なデータセット(日英の対訳データ)を用いてモデル構築を行っている。用いているデータセットの品質には大きな差があるため基本的に下記のデータクリーニングを行っている[1]。

  • 日本語文、英語文それぞれをUniversal Sentence Encoder[1]で分散表現に変換、コサイン距離が一定以内のものを採用
  • 日本語文をMeCab[2]で形態素に分割、日本語文の形態素の数と英単語の数の比が一定範囲内のものを採用
  • 日本語文が日本語文字セットの文字で構成されているかを確認(UnicodeのHiragana lettersを含むかなど一定のルールで対応)、英語文も同様に構成文字が妥当かを確認。
  • 対訳ペアが数字を含む場合、双方に同じ数字があるかを確認。無い場合は「数字を表す単語(例:one, two, …)」「月を表す単語(例:Jan~Dec)など数字に変換可能な単語を含んでいるか」と「0の数を変化させる表現(例:hundredやmillionなど)」があるかを確認、加えて、それが正しい対応になっているかを確認[5]

上記処理によって多くの対訳ペアがフィルタリングされる。公開されている対訳データによっては有効な対訳ペアが半分程度になることもある。

wikimatrixなど機械的に対訳アライメントを行ったデータに対しては最後の数字対応によるフィルタリングが特に有効である。(逆に言うとこのようなデータセットは数字が対応していない対訳ペアを多く含んでいる。)機械翻訳モデルでも数値対応は課題になることが多い。数値を含めての自動対訳アライメントは簡単ではないのであろうと思う。一方で数値を対象としたルールベースによるフィルタリングはそれほど困難ではない。このようなデータを用いる場合はぜひ行ったほうが良い処理である。

現在公開されているFuguMTモデルCC Alignedデータを加える際も同様の処理を行った。今回、さらに厳しい基準を用いた場合にどのような変化があったかをメモがてら記載する。

CCAlignedデータ追加時に行った処理

CCAlignedデータの追加にあたり、基本的なクリーニングロジックに加えて3つの処理を追加した。これはCC Alignedのデータを目検したところSPAM的なデータ[6]が多く含まれており品質があまり良くなったためである。残念ながら前述のクリーニングロジックでは品質が低い機械翻訳をフィルタリングすることが難しかった。

  • LaBSE[7]を用いてベクトル化した対訳文ペアのコサイン距離を計算し、一定範囲に入っているか
  • fasttextのLanguage identification[8]の結果がそれぞれの言語(日本語、英語)で判定されているか
  • 記載内容+取得元URLに対してSPAM的なデータではないかを2値分類モデルで判断

最後の処理は一定数のデータをハンドラベリングしたのちにSPAM判定モデルを構築し実施した[9]。SPAM判定ではURL情報が非常に有効であった。(当たり前ではあるが)URLによろしくない単語を含んでいる場合はほぼSPAMサイトであった。

データセットにURL情報がないなど適用不可能な場合を除き、既存データにも追加クリーニングを実施した。

品質向上前は全部で14,023,805対訳ペアのデータ数であったが、クリーニングの結果10,903,035対訳ペアに減少した。

モデル構築と精度評価結果

今までと同様、Marian-NMT (transformer) sentencepiece を用いてニューラル機械翻訳モデルの構築を行った。使用した機材はAWS p3.2xlarge インスタンスである。学習はearly stopping有りで行い、最善の学習を行った結果を用いて評価を行った。学習時間はおおむね同等でありデータ数が少なくなった影響は見られなかった。

機械翻訳モデルの精度評価には学習データに含まれない4,145対訳ペア[10]を用いた。対訳ペアの半数はデータセットの分割により、残りの半数はドメイン外のデータを用いて作成している。評価のメトリクスにはBLEUを用いた。

結果、品質向上後データではBLEU=28.6、品質向上前データではBLEU=27.5と約1.1ポイントBLEUが向上した。

所感

BLEUで+1.1 pointは経験的に[11]乱数の揺れで出る値では無いので、データ品質向上の効果はあったものと思われる。

基本的なクリーニングロジックでも相応の処理を行っていると思っていて、その効果がある事は確認している。そのため追加処理で300万対訳ペアを削ってもBLEUが上がるのは正直驚きであった。削られたデータにも有用そうなものはあるのでデータ品質とデータ量のバランスを良い感じにする取り組みは今後も続ける必要がありそうな気がしている。

作成したモデルの品質確認は現状でも続けている。現実のデータである程度性能確認ができたところでモデルを公開しようと思っている。現状では前回公開したモデルよりも若干性能が向上しているように思う。データ量を660万ペアから1000万対訳ペアに拡張した効果は出ているようである。

脚注

[1] モデル構築手法はこれまでのものと同じでMarian-NMT + sentencepieceを用いている。比較はそれぞれのデータセットに含まれない4,145文で行った。
[2] 問題のある対訳ペアが少ないtatoebaのみ例外的にクリーニングは行っていない。それ以外のデータセットについては対訳データとされていてもクリーニングの対象としている。(実際問題のある対訳ペアを含んでいる)
[3] https://tfhub.dev/google/universal-sentence-encoder/4
[4] https://taku910.github.io/mecab/
[5] 基本的にルールで対応している。
[6] ここでは品質の低い機械翻訳モデルによって機械的作成されたサイトのこと
[7] https://tfhub.dev/google/LaBSE/2
[8] https://fasttext.cc/docs/en/language-identification.html
[9] クリーニング用モデルを作ってデータ品質を高めることは近年の大規模モデル(T5やGPT-3など)でも普通に行われている。
[10] それぞれの英語文に対して、一律小文字に変換、記号(+空白)を除いてキー情報を作成、学習データとテストデータでキー情報が一致するものが無い事を確認している。
[11] 本来は正しく評価したいところだがAWS費用が高額なので十分な検証が難しい。できることならABCIとか使いたい。

Arxiv論文の翻訳サイト

前回公開した機械翻訳モデルのアプリケーションとして、arXivに投稿された人工知能関連の論文のメタデータ(タイトル・アブストラクト)とCreative Commonsライセンス(CC 0, CC BY, CC BY SA)の本文を日本語に翻訳するサイトを作成した。

Fugu-MT: arxivの論文翻訳

トップページでは投稿日別に最新3日の要約を表示している。メタデータ・本文の翻訳は日付別の参照から確認できる。全文翻訳がある場合はそのリンクを貼っている。

アブストラクトを要約・翻訳して一覧化も行っている。

Fugu-MT: arxivの論文翻訳(概要)

スマホなどで最新の論文をざっくり確認したい場合は便利だと思う。arXivのメタデータはCC 0なので要約や翻訳が可能である。

技術的な話

サイトの構成

このサイトはarXivのAPIを用いて人工知能分野の最新論文を取得、Fugu Machine Transratorを用いて日本語に翻訳している。PDF本文を翻訳するエンジンはリンク先のgithubにあるものを若干カスタマイズして使っている。

静的なWEBサイトで構成するため[1]に、翻訳結果などは基本的にHTML化して保存している。PDF情報もBASE64で埋め込んでいて、HTMLファイルをダウンロードすればどの環境でも翻訳文の閲覧が可能である。

CSSやJSはCDN経由としているので、「wgetでダウンロード」「ブラウザでリンク先を名前を付けて保存」などCSSやJSをローカルに保存する動きをしない方がうまく動く[2]。

2週間程度動かしてみてArxivに投稿された論文をライセンス別に集計すると大体1/3くらいは全文翻訳可能なライセンスとなっていた。最近Openなライセンスの論文が増えている印象で非常にありがたい。

作成したサイトでは30ページを超える論文は翻訳対象外としている[1]。30ページを超える論文の和訳が欲しい・Arxiv以外のサイトで翻訳可能な論文の和訳が欲しいなどの場合はFugu Machine Transratorでこのサイトと同じようなことができる(若干不具合があるので、今月中には修正予定)。

arXivへのアクセスはかなりゆっくりやっていて、API Limitやrobots.txtで決められた待機時間より2倍以上長めのwaitを入れているので更新は遅めかもしれない[3]。

要約処理

アブストラクトの要約にはPEGASUS: Pre-training with Extracted Gap-sentences for Abstractive Summarization論文)を用いている。PEGASUSはAbstractive Text Summarizationタスクで優秀なモデル(CNN / Daily MailでPapers with Code 3位[4])として知られている。論文のアブストラクトをさらに要約するにはExtractiveな手法ではイマイチであり、Abstractiveな要約手法を採用した。結果、まずまず良い感じに要約できているように思う。

所感など

arXivの日本語翻訳を行っているサイトはいくつかあり、また、arXiv Vanity を使ってブラウザの翻訳機能経由で日本語翻訳を行うことを紹介しているものもあった。arXiv VanityはPDFではなくそのソースであるTeXをベースにHTML化しているようで品質が高い[5]。正直、実用的にはこのような方法で十分だと思うが、自作ニューラル機械翻訳モデルの性能評価の意味を込めてサイトを作成してみた。

結果、アブストラクトについては大手翻訳サイトと比べても十分に比較可能なレベルで翻訳ができているように思う[6]。論文本体はPDFのテキスト化、英語文のsentence tokenizeに課題を抱えているためそこまで高精度ではないが「流し読みに便利」程度のレベルにはなっている。

Abstractiveな要約いわゆる抽象型と呼ばれる要約手法はExtractiveな要約(抽出型要約)に比べて安定した性能を出しにくいことが多いが、今回は翻訳を通しても文の破綻が少なくまずまずの性能が出せている。(要約部分も翻訳部分も意訳に近い動きをしているため、内容が変わることも少なからずあるが・・・[7])

前回TODOに挙げていた事を無視してarXivの翻訳サイトを作ってしまったが、良い経験にはなった[8]。英語のNLPでできる事は非常に多いのでFuguMTを便利に使ってもらえたら嬉しい[9]。

一応、1400万対訳ペアでのモデリング、1400万対訳→1000万対訳ペアへのフィルタリング(高品質化)なんかもやってはいるので、ぼちぼち翻訳エンジンの強化も再始動したいと思う最近。NLP周りの英語での成果を使うためにはEN→JAだけでなくJA→ENも必要なのでそのモデルも作ろうかなーとも思っている[10]。

脚注

[1] VPSのスペックによるもの・・・。
[2] ブラウザがJSやCSSをダウンロードし、リンクを書き換えるとうまく動作しないことがある。
[3] APIのデータは日本時間午前8時頃に更新されるがアクセス過多になっていることが多い。アクセス過多の時のwaitもかなり長めにとっているので新規論文リストを取得&論文のメタデータを取得完了するのは日本時間11時頃になっていると思う。(大体、次の日には和訳できてる、くらいのイメージ)
[4] 2021/2/14現在。リンク先にはExtractiveな要約が入っていない、PwCのLeader boardに載っていない結果もある、などの理由で実際の順位は不明。とはいえ、SOTAと比べて大幅に性能が低いわけではない。(正解が正解か怪しい世界でROUGEという微妙な指標を用いてベンチマークした結果よりも、要約したいドメインでの目検証の方が重要・・・。本件でも実は様々な手法を試している。)
[5] Robots.txt的にTeXファイルの取得はDisallowな気もしつつ、どう実装しているかは謎。
[6] 論文ドメインでのfine tuning無しの素の結果なので結構優秀ではなかろうかと自画自賛。ただ、語彙の点で負けている感はある。ニューラル機械翻訳モデルのパラメータチューニング&(やや反則だが)論文ドメインでのfine tuningを行えば大手翻訳サイトの性能を越えられるんじゃないかと思わなくはない。(がAWS費用がつらい)
[7] 要約文が破綻していても翻訳側で救っている場合もあった。要約結果があまりに変な文だと翻訳側が壊れる(同じ単語を繰り返す)みたいな事も起きる。
[8] 現実のデータと格闘しないと分からないことは多い。
[9] 日本語版のpre trainedモデルがたくさん公開されるとかNLPは日本語版がSOTAみたいな時代が来ると嬉しいが、現実は厳しい気がしている。マルチリンガル方面は流行なので、それで解決される可能性も感じているが・・・。
[10] GPU買っちゃおうかなーとも。対訳データを1円/wordくらいで買ってくれるとこないかな、、、

フリーのニューラル機械翻訳モデルFuguMT

英文を日本語訳するニューラル機械翻訳モデルをCC BY-SA 4.0で公開した。以前の記事で紹介した手法を用い昨年11月に構築したモデルである

  • FuguMT ver.2020.11.1 (約440MB)のダウンロード
  • shasum: 0cf8a1fc540b4c7b4388b75b71858c0eb32e392a
  • ライセンス: CC BY-SA 4.0  (readmeにも書いた通り、作者(Satoshi Takahashi)は本モデルを使用して発生したあらゆる結果について一切の責任を負いません 。引用等を行う場合はこのBlogのURLを記載するか、リンクを貼ってください。)

性能はそこそこ(後述)。構築手法は本格的(Marian-NMT[1]を用いた Transformer + Sentence Piece[2])である。

研究用途での試用を前提としており、当然ながら動作や出力に関して一切の責任を負えない(重要なので2度目) [3] がCreative Commonsに従って利用可能なモデルは珍しいと思う。

周辺のコードを含めてgithubにuploadしたので、利用する場合はgithubのfugumtリポジトリを参照いただきたい。githubのコードは基本的にテストサイトと同様だがシンプルに使用可能な構成にしている[3]。

翻訳を行う場合は著作権に注意。最近はCC Zeroなど自由なライセンスで公開される論文等も増えてきているとはいえ、通常、著作物を自由に翻訳することはできない。

モデルの詳細

githubに記載の通り FuguMT ver.2020.11.1 は様々なデータセットを組み合わせて作成している。使用したデータ量は約660万対訳ペア(日本語:690MB 英語:610MB、約1億words)である。 AWS p3.2xlarge 上で Marian-NMT + SentencePieceを用い約30時間の学習を行った。

公開するモデルは「model.npz」と「model_uncased.npz」の2つで、前者は英文をそのまま日本語訳するモデル、後者は英文を小文字に統一(sentence pieceの–normalization_rule_name = nmt_nfkc_cf)し日本語訳するモデルである。 fine tuningも可能。詳細な設定はzipファイル中の「model.npz.yml」「model.npz.progress.yml」を確認してほしい。fine tuning時にはreadmeを読みライセンスに従った取扱いをお願いしたい。

このモデルの性能はKFTT テストデータのBLEUで23程度である。技術文書、論文に対してはもう少し性能が高く、BLEUで30程度とオンラインで公開されている翻訳エンジンと同レベルの性能を出すことができる。BLEUは良い指標とはいいがたいため、 テストサイト で試してみると大体の性能が分かると思う。このBlogを書いている時点ではテストサイトの翻訳エンジン1はFuguMT ver.2020.11.1のmodel.npzを使用している[4]。

多くの場合 「model.npz」の方が良い結果を出力するが、翻訳が難しい文の場合「model_uncased.npz」の方が安定した結果を出力する。githubのfugumtライブラリでは複数の翻訳結果候補から良いと思われる出力を選ぶ機能を実装している。

FuguMT ver.2020.11.1 で利用したデータセット

FuguMT ver.2020.11.1 で使用したCreative Commonsライセンスのデータセットは下記の通り。CCで利用可能なデータセットには非常に助けられた。フリーなライセンスで公開された方々に感謝したい。FuguMTの構築には下記以外に独自に収集したデータも利用している[5]。

使い方

fugumtに記載の通り。githubのDockerfileをbuildし、モデルをダウンロード、marian-decoder経由で使う手順がテストを行いやすい。CPU 1コアで実行した場合1文の翻訳に2-3秒は必要である。

fugumtライブラリでは文章の文分割、訳抜け防止モードの実行、翻訳の適切さのスコアリング、複数の翻訳候補から良い翻訳文を選ぶ機能などを実装している。

pdf_server.pyを使うとpdfminerを用いてPDF文書をそのまま翻訳できる。pdf_server.pyはpickleを出力する。server.pyの機能でPDFと訳文を対比しながら内容を確認できる。 計算時間は1ページあたり1分程度である。

今後の予定

githubにも書いている通り、TatoebaとCCAlignedを用いたモデルは構築済みで性能評価中である。対訳ペア数は1400万に達しているものの、CCAlignedのデータに機械翻訳されたものが多数混在しており総合的な性能が向上するかは検証できていない。これを含め、今後下記のようなことをやりたいと思っている[7]。

  • 対訳ペアを1400万ペアに拡張したモデルの性能評価・公開
  • FastAPI等を利用したAPI化
    • bottleの実装を改善したい
  • 英語→日本語だけではなく日本語→英語のエンジン作成
    • 基本的にはデータを反転させれば作れる
  • Back Translation、BARTやmT5など事前学習モデルの活用、文脈を使った翻訳などモデルの高度化
    • Back Translationの活用はマシンパワーがあれば可能
    • BARTは試行したが性能が向上しなかった。とりあえず中断した検証を再開したい。
    • 1400万対訳ペアのうち7割程度は文脈を考慮可能[8]で文脈を考慮するモデルは構築したい(構築できる)。
  • 英語・日本語以外への対応
    • フランス語、ドイツ語、イタリア語、スペイン語、ロシア語、ポルトガル語は一定程度の対訳をコレクションしている。

その他

とりあえず夏休みの宿題で作ったものを形にして冬休み(+1週間)に公開できたのは良かった。 FuguMTは気軽に使えるがモデル性能はそこまで高くない。何らかのサービスで利用する場合は大手翻訳サイトのAPIと比較してみてほしい。

元々のモチベーションはSuperGLUEのような標準データセットの日本語版を作りたいというものだった。SuperGLUEは昨年末に「解決」されてしまい、xtremeといったマルチリンガルなベンチマークも流行っているのでやや時代遅れ感もある。。。が、勉強にはなった。

次に何をやるかは考え中。今後の予定にあることを地道にやっていくか、全然違うことをやるかも正直決めていない。

対訳ペアのデータの公開は今のところ考えていない。商業的価値のあるデータだと思いつつ、リーガルチェックや税金の問題など様々な課題があるので相当の金額でないと有償提供もしないと思う。

脚注

[1] Marian-NMT: https://github.com/marian-nmt/marian
[2] SentencePiece: https://github.com/google/sentencepiece
[3] 特に差別的な翻訳を行う可能性など十分な検証はできていない。
[4] 安定性は若干劣る。テストサイトはuwsgi+nginxで動作させる構成としている。もっとも、Marian-NMT自体が非常に良くできたソフトウェアなので、npzファイルさえあれば他はいらないかもしれないが・・・。
[5] これらデータを機械翻訳モデル構築に用いた場合、機械翻訳モデル(npzファイル)のライセンスがどうなるかは多くの議論がある。ここでは出所・ライセンスを明確にし、引用条件は配布サイトの表記に従っている。
[6] データはフィルタリングして使用。660万対訳ペアのうち300万対訳ペア程度は自力で収集したデータである。
[7] 趣味でやっているので時間が足りない。加えてAWS費用が重い。
[8] ただの文ではなく、ドキュメントとしてデータを保持している。

機械翻訳と訳抜けとConstituency parsing

翻訳エンジンのお試しサイト(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)は、コンピュータと人間の言語間の相互作用に関する言語学、コンピュータ科学、人工知能のサブフィールドである。 特に、コンピュータが大量の自然言語データを処理および分析するためのプログラム方法。」と翻訳した。意味としては良くなっている一方で流暢さは損なわれている。 実装した訳抜け防止モードは文を分割して翻訳しているだけであり、現状の機械翻訳エンジンは文脈の考慮もできていない。訳抜け防止モードの翻訳品質は通常モードに比べて低くなる。

翻訳エンジンのお試しサイトでは通常の翻訳×2[4]と訳抜け防止モード×2の結果を文毎に比較し、最も良い結果(スコア算出方法は後述)を採用している。

スコア表示

お試しサイトでは英語文と対応する翻訳文それぞれについてスコアが付与されている。スコアは翻訳文が良いかどうかを表す指標であり、0.0 – 1.0で評価される。概ね0.7以上であればそれなりの訳文になっていることが多く、0.5以下の場合は何かしらの問題が起きていることが多い。特に0.3以下の場合はほぼ確実に訳抜けが発生している。

スコアは「①文の類似度」×「②単語/形態素数の類似度」で計算している。「①文の類似度」はUniversal Sentence Encoder[5] + cos類似度である。LaBSE[6]も試行したがこのタスクではメモリ・計算時間の増加[7]に比べて効果が薄かった。「② 単語/形態素数の類似度 」は英文の単語数と日本語文の形態素数の比率が対訳データの平均(0.85)に近いかを計算している。形態素解析はMeCabを用いた。

所感・その他

お試しサイトの処理フローは以下の通りで機械翻訳エンジンを使う際の対応は大体実施できた気がしている。

  1. 改行が連続した場合は別の文とみなし、処理ブロックを分ける。(途中改行が1つの場合、文は連続しているとみなす。arxivの論文やPPT資料でありがちな改行の入り方に対応している。)
  2. 処理ブロック内の文章をNLTKのsent_tokenizeで文に分割する。
  3. 文に分割されたデータそれぞれに対してconstituency parsingを行い、意味が成立すると思われる一定の長さで文を分割する。
  4. 上記、2.、3.で作成した文のリストを機械翻訳エンジンで和訳する。和訳はハイパーパラメータを変えた2つのエンジンで行う。
  5. 翻訳対象の英語文それぞれについて4つの和訳結果(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)構築時点でタグを特殊記号扱いし、対訳ペアに正しくタグを扱っている文を追加して学習させる予定である。このあたりは翻訳エンジンそのものに手を入れないと実現しにくく、メジャーな翻訳エンジンで同様の事をやるのは簡単ではないと思っている。