Category Archives: 機械翻訳 - Page 4

GPT-4の翻訳性能

GPT-4が発表された(GPT-4 (openai.com))。マルチモーダル化や長い入力への対応など非常に面白い拡張がされている。テキスト部分も性能向上があったとのことで機械翻訳でのChatGPT vs GPT-3.5 vs FuguMT | ぷるーふおぶこんせぷと (staka.jp)の後半の文例で翻訳させてみた。

現在はAPI提供はされておらず画面から「あなたは翻訳者です」と役割を入力し、その後「次の文章を英語から日本語に翻訳してください。」と指示している。入力方法は異なるが前回と条件はほぼ同じのはずである。

APIが提供されれば何らかのデータセットを用いたベンチマークもやってみたいと思っている。ただ下記の結果を見るに、ベンチマークデータの品質が問われるレベルで高い性能だなという印象。

最初に、林大臣は、G20外相会合と日本・オーストラリア・インド・米国外相会合の議長を務めるジャイシャンカル外相のリーダーシップに敬意を表しました。彼は、国際社会が一連の大きな危機に直面している中で、日本は5月のG7広島サミットと9月のG20ニューデリーサミットに向けて取り組み、G20議長国を務めるインドと引き続き緊密に連携していくと述べました。これに対し、ジャイシャンカル外相は、林大臣のインド訪問を歓迎し、G20議長国として、G7議長国である日本と協力したいとの意向を示しました。

出典:外務省ホームページ (https://www.mofa.go.jp/s_sa/sw/in/page3e_001319.html、機械翻訳を行った結果)
金融庁は、資金移動業者に関する「行政手続きガイドライン」の改正案を公開コメントのために提案しました。この提案は主に、厚生労働大臣が指定する資金移動業者の口座への賃金支払いを認める労働基準法施行規則の改正に関する省令(仮称英語名)[2022年11月28日公布]を受けて、資金移動業者に対する監督措置を定めたガイドラインの改正を提供することを主な目的としています。

出典:金融庁ウェブサイトhttps://www.fsa.go.jp/en/newsletter/weekly2023/527.html)、機械翻訳を行った結果
デジタル庁は、政府の非効率的な技術を排除するために最善を尽くし、人々の日常生活を支援するシステムのデジタル化に注力しています。データとシステムのセキュリティを保証することで、ユーザー主導のデジタル化を加速させることを目指しています。私たちは、「政府がサービスとして」、「政府がスタートアップとして」のビジョンを基盤に、「人にやさしいデジタル化:誰も取り残さない」というコミットメントを果たします。

出典:デジタル庁(https://www.digital.go.jp/en/creation-en/)、機械翻訳を行った結果
GPT-4を用いた翻訳結果

GPT-4は全体的に正確かつ流暢に訳せており、前回結果(GPT-3.5、ChatGPT、FuguMT)より優れているように見える。特に3つ目で「デジタル庁」を正しく訳せているのはすごい。「Government as a service」「Government as a startup」「Human-friendly digitalization: No one left behind」の翻訳も良い感じである。

マルチモーダルな入力が可能になったら画像+テキストでの翻訳もぜひ試してみたい。(既存研究はあるものの)マルチモーダルなデータを用いた翻訳&テキスト指示による文のスタイル指定が手軽に実行可能だとするとすごいことだと思う。

その他

この分野はGoogleがPaLM APIを発表(Google Developers Blog: PaLM API & MakerSuite: an approachable way to start prototyping and building generative AI applications (googleblog.com))するなど競争が激化している。LLMの挙動は非常に面白いので色々試していく予定。

現在、GitHub – Shark-NLP/OpenICL: OpenICL is an open-source framework to facilitate research, development, and prototyping of in-context learning.のようなIn-Context Learningもテスト中でその結果も早めに記事にしたいなーと思っている。in-context Learningの挙動も謎が多く(Larger language models do in-context learning differently – arXiv最新論文の紹介 (devneko.jp))非常に興味深い。

GitHub – dair-ai/Prompt-Engineering-Guide: Guides, papers, lecture, and resources for prompt engineeringのようなPrompt作成のテクニックが日本語でも同じなのか?など、LLM周りが急速に発展する中での日本語の立ち位置にも興味津々で実験時間が足りないというのが正直なところ。

機械翻訳でのChatGPT vs GPT-3.5 vs FuguMT

ChatGPTがAPI提供されるようになったこともあり、機械翻訳性能がどの程度変わっているか試してみた。比較条件は下記の通り。

評価結果

結果は下表の通りであり、FuguMT > GPT-3.5 > ChatGPTの結果だった。

パターンBLEU補足
ChatGPT(Excellent)22.850.4/29.0/16.9/10.9 (BP = 1.000 ratio = 1.228 hyp_len = 6920 ref_len = 5633)
ChatGPT(Good)23.251.0/29.3/17.4/11.2 (BP = 1.000 ratio = 1.196 hyp_len = 6735 ref_len = 5633)
GPT-3.524.956.0/31.7/18.5/11.7 (BP = 1.000 ratio = 1.068 hyp_len = 6014 ref_len = 5633)
FuguMT32.763.5/40.2/26.0/18.6 (BP = 0.982 ratio = 0.982 hyp_len = 5531 ref_len = 5633)
Tatoebaを用いたBLEUの比較(ChatGPT vs GPT-3 vs FuguMT)

ChatGPTの出力には()書きでローマ字の読みが補足されている場合(「Hello」の翻訳として「こんにちは(Konnichiwa)」となっているような場合)があり、それを修正すると下表の結果となった。

パターンBLEU補足
ChatGPT(Excellent)26.557.6/33.5/19.8/13.0 (BP = 1.000 ratio = 1.077 hyp_len = 6064 ref_len = 5633)
ChatGPT(Good)26.056.3/32.6/19.5/12.8 (BP = 1.000 ratio = 1.084 hyp_len = 6104 ref_len = 5633)
Tatoebaを用いたBLEU、ChatGPTの出力を修正した場合

若干修正しても単文(かつ短め)翻訳においてはFuguMTはChatGPT・GPT-3よりも性能が高いという結果になった。ただし、Tatoebaの結果で正しい性能を測ることはそもそも困難であること、BLEUが良い指標とは言い難いこと、ChatGPTの出力は機械的な評価以上に人間に好まれること[2][3]に注意が必要である。実際に目検証を行った限りではChatGPTとFuguMTの性能はほぼ同じレベルに見えた(GPT-3.5はイマイチな訳が含まれていた)。そして、そもそもゼロショットで機械翻訳特化のモデルに相当しているというのも凄いことである。

追加検証

追加検証として外務省、金融庁、デジタル庁のWEBサイトにある英語文を用いて比較を行った。

外務省のデータ

まずはJapan-India Foreign Ministers’ Meeting | Ministry of Foreign Affairs of Japan (mofa.go.jp)から下記文章を抜き出し検証した。

At the outset, Minister Hayashi expressed his respect for Foreign Minister Jaishankar’s leadership in chairing the G20 Foreign Ministers’ Meeting and the Japan-Australia-India-US Foreign Ministers’ Meeting. He stated that as the international community faces a series of major crises, Japan is looking ahead to the G7 Hiroshima Summit in May and the G20 New Delhi Summit in September, and expressed that Japan will continue to work closely with India, which holds the G20 Presidency. In response, Foreign Minister Jaishankar welcomed Minister Hayashi’s visit to India and stated that as G20 Presidency, India would like to cooperate with Japan, which holds the G7 Presidency.

出典:外務省ホームページ (https://www.mofa.go.jp/s_sa/sw/in/page3e_001319.html、機械翻訳を行った結果を下表に表示)

この程度の長さであれば一文が入力されることを想定したFuguMTでも対応可能だが、テキスト中の行を分割後に翻訳したバージョンも記載している。なお、「外務省」「金融庁」「デジタル庁」など省庁のテキストの多くはクリエイティブ・コモンズ (Creative Commons) — 表示 4.0 国際 — CC BY 4.0と互換性のある利用規約で使うことができる。

パターン日本語訳
ChatGPT(Excellent)冒頭、林大臣は、ジャイシャンカル外相がG20外相会議と日豪印米外相会議の議長を務めたことへの尊敬を表明しました。彼は、国際社会が一連の大危機に直面する中、日本は5月のG7広島サミットと9月のG20ニューデリーサミットに注目し、G20大統領国のインドと引き続き緊密に連携していくと述べました。これに対し、ジャイシャンカル外相は、林大臣のインド訪問を歓迎し、G20大統領国であるインドは、G7大統領国である日本と協力したいと述べました。
ChatGPT(Good)最初に、林大臣は、ジャイシャンカル外務大臣がG20外相会議や日豪印米外相会議で議長を務めたことについて、彼の指導力に対する敬意を表明しました。彼は、国際社会が一連の重大な危機に直面している中、日本は5月のG7広島サミットと9月のG20ニューデリーサミットを見据えており、G20の議長国であるインドと緊密に連携していくと表明しました。これに対し、ジャイシャンカル外務大臣は、林大臣のインド訪問を歓迎し、G20議長国であるインドはG7議長国である日本と協力したいと述べました。
GPT-3.5最初に、林大臣はG20外務大臣会議と日豪印米外務大臣会議を主席としたジャイシャンカール外務大臣の領導力を尊敬した。彼は、国際社会が一連の重大な危機に直面していると述べ、5月にはG7広島サミット、9月にはG20ニューデリーサミットがあると述べ、G20議長国であるインドと緊密に協力していくと表明した。それに対し、ジャイシャンカール外務大臣は林大臣のインド訪問を歓迎し、G20議長国として日本、G7議長国として日本と協力したいと述べた。
FuguMT冒頭,林大臣から,ジャイシャンカル外相のG20外相会合及び日米豪印外相会談の議長に対する敬意を表明しました。国際社会が一連の大きな危機に直面する中で,5月のG7広島サミット,9月のG20ニューデリーサミットを先取りし,引き続きG20議長国であるインドと緊密に連携していく旨述べました。これに対し,ジャイシャンカル外務大臣から,ハヤシ外相の訪印を歓迎し,G20議長国として,G7議長国である日本と協力していきたい旨述べました。
FuguMT(行分割)冒頭,林大臣から,G20外相会合及び日米豪印外相会談の議長として,ジャイシャンカル外務大臣のリーダーシップを尊重する旨述べました。 5月のG7広島サミット、9月のG20ニューデリーサミットに向けて、国際社会が一連の大きな危機に直面する中、日本は引き続きG20議長国であるインドと緊密に連携していく旨述べました。 これに対し,ジャイシャンカル外務大臣から,林大臣のインド訪問を歓迎し,G20議長国として,G7議長国である日本と協力していきたい旨述べました。
外務省のページに対する各パターンの翻訳結果

外務省の日本語記載は下記の通りである。

冒頭、林大臣から、今般のG20外相会合及び日米豪印外相会合の議長としてのジャイシャンカル外相のリーダーシップに敬意を表明するとともに、国際社会が大きな危機に立て続けに直面する中、日本は、5月のG7広島サミット及び9月のG20ニューデリー・サミットを見据え、G20議長国であるインドと、引き続きしっかり連携していきたい旨述べました。これに対し、ジャイシャンカル外相より、林大臣の訪印を歓迎した上で、G20議長国としてG7議長国である日本と協力していきたい旨述べました。

出典:外務省ホームページ (https://www.mofa.go.jp/mofaj/s_sa/sw/in/page6_000819.html

全般的に甲乙をつけるのが難しいが、GPT-3.5は若干微妙な訳になっているように見える。FuguMTも誤訳のように思えなくもない(解釈が悩ましい文章になっている)。このように小さな単位で測っても…と思いつつBLEUを計算すると FuguMT(行分割) > FuguMT > ChatGPT(Excellent) > ChatGPT(Good) > GPT-3.5だった。

金融庁のデータ

金融庁の下記テキストを翻訳した結果は下表の通り。

The FSA proposed the draft amendments to the “Guidelines for Administrative Processes” regarding funds transfer service providers for public consultation.The proposal is mainly aimed at providing amendments to the said Guidelines by setting forth supervisory measures to be taken for funds transfer service providers, in response to the “Ministerial Order to Amend the Regulation for Enforcement of the Labor Standards Act to Allow Wage Payment to the Accounts of Funds Transfer Service Providers Designated by the Minister of Health, Labor and Welfare” (provisional English title) [promulgated on November 28, 2022].

出典:金融庁ウェブサイトhttps://www.fsa.go.jp/en/newsletter/weekly2023/527.html)、機械翻訳を行った結果を下表に表示
パターン日本語訳
ChatGPT(Excellent)FSAは、公共の意見募集のために、資金移転サービスプロバイダーに関する「行政手続指針」の草案改正案を提案しました。この提案は、主に「労働基準法施行規則の改正により、厚生労働大臣が指定した資金移転サービスプロバイダーの口座への賃金支払いを認める」という大命令に対応して、資金移転サービスプロバイダーに対する監督措置を定めることにより、当該指針の改正案を提供することを目的としています。
ChatGPT(Good)FSAは、公開の意見募集のために、資金移転サービスプロバイダに関する「行政手続に関する指針」の草案を提案しました。この提案は、主に、厚生労働大臣が指定した資金移転サービスプロバイダの口座への賃金支払いを許可するための「労働基準法施行規則の改正に関する省令案」(暫定英語タイトル)(2022年11月28日公布)に対応して、資金移転サービスプロバイダに対して取られるべき監督措置を明示することで、該指針の改正案を提供することを目的としています。
GPT-3.5「厚生労働大臣令による労働基準法施行規則の改正(仮英語表記)(2022年11月28日公布)に対応して、資金振込サービス提供者に対する監督措置を定めることを目的として、「行政処理のガイドライン」に関する案を公開諮問することを金融庁が提案しました。
FuguMTFSAは、公共相談のための資金移転サービス提供者に関する「行政プロセスガイドライン」の改正案を提案しました。この提案は、主に、「厚生労働大臣が指定する資金移転サービス事業者の口座への賃金支払いを許可する労働基準法施行規則の改正に関する閣僚令」(仮称)に対応して、資金移転サービス事業者に対して取るべき監督措置を設定することにより、当該ガイドラインの改正案を提供することを目的としています(仮称) [2022年11月28日に公布]。
FuguMT(行分割)FSAは、公的協議のための資金移転サービスプロバイダーに関する「行政プロセスガイドライン」の修正案を提案した。 この提案は、主に「厚生労働大臣が指定する資金移転サービス事業者の口座への賃金支払いを許可する労働基準法施行規則の改正に関する閣僚令」(仮称)(2022年11月28日公布)に対応し、資金移転サービス事業者に対して取るべき監督措置を定めることにより、当該ガイドラインの改正を行うことを目的とするものです。
金融庁のページに対する各パターンの翻訳結果

GPT-3.5以外は甲乙つけがたし、という印象。GPT-3.5は一部を飛ばしてしまっている。もっとも大意があっていればOKという感想はなくはない。

デジタル庁のデータ

最後にデジタル庁のテキストを翻訳した結果は下表の通り。

The Digital Agency makes best effort to eliminate inefficient technology of the government and focuses on the digitalization of improving systems to support daily lives of people. By guaranteeing the security of data and systems, we aim to accelerate digitalization in a user-driven manner. We commit to “Human-friendly digitalization: No one left behind”, underpinned by the vision of “Government as a service” and “Government as a startup.”

出典:デジタル庁(https://www.digital.go.jp/en/creation-en/)、機械翻訳を行った結果を下表に表示
パターン日本語訳
ChatGPT(Excellent)デジタル・エージェンシーは、政府の非効率な技術を排除し、人々の日常生活をサポートするシステムの改善のデジタル化に注力しています。データとシステムのセキュリティを保証することで、ユーザー中心のデジタル化を加速することを目指しています。「誰も後れを取らない」人間にやさしいデジタル化を実現することを約束し、「サービスとしての政府」と「スタートアップとしての政府」というビジョンを土台にしています。
ChatGPT(Good)デジタルエージェンシーは、政府の非効率的な技術を取り除き、人々の日常生活を支援するシステムの改善に重点を置くことでデジタル化に取り組んでいます。また、データやシステムのセキュリティーを保証することで、ユーザー主導のデジタル化を加速することを目指しています。私たちは、「誰一人取り残さない人間中心のデジタル化」というビジョンのもと、「政府サービス」と「政府スタートアップ」という考え方を基盤として、取り組んでいきます。
GPT-3.5デジタルエージェンシーは、政府の不効率な技術を排除し、人々の日常生活を支援するシステムのデジタル化に焦点を当てるための最善の努力をしています。データとシステムのセキュリティを保証することにより、ユーザー主導のデジタル化を加速します。私たちは「人間中心のデジタル化:誰も残さない」を掲げ、「政府をサービスとして」および「政府をスタートアップとして」というビジョンに基づいています。
FuguMTデジタルエージェンシーは、政府の非効率な技術を排除するために最善を尽くし、人々の日常生活を支えるシステム改善のデジタル化に重点を置いています。データとシステムのセキュリティを保証することで、ユーザー主導のデジタル化を加速することを目指しています。私たちは、「Government as a service」と「Government as a startup」のビジョンに裏付けられた「Human-friendly digitalization: No one left back」にコミットします。
FuguMT(行分割)デジタルエージェンシーは、政府の非効率な技術を排除するために最善を尽くし、人々の日常生活を支援するためのシステムの改善のデジタル化に焦点を当てています。 データとシステムのセキュリティを保証することで、ユーザ主導のデジタル化を加速することを目指しています。 私たちは、「サービスとしての政府」と「スタートアップとしての政府」のビジョンに裏付けられた「人間に優しいデジタル化:誰も残っていない」ことを約束します。
デジタル庁のページに対する各パターンの翻訳結果

こちらは全般的に近い翻訳で評価が難しい。GPT-3.5の「不効率」という表記は気になるが、それ以外はまぁ機械翻訳だしこんなもんか、という結果に思える。

まとめ

ChatGPT vs GPT-3.5 vs FuguMTということで翻訳性能を比較してみた。機械的な評価ではFuguMTが上回るが、個別にみていくと甲乙つけがたい結果であることが確認できた(ただ、おそらくChatGPTはGPT-3.5よりも和訳性能が高い)。

LLMを用いた翻訳はPromptの入れ方に依存して性能が変わることがある。実際にChatGPTではSystem Roleに与えたテキストによって訳文が変化している(スコア的にはそこまで変わらずExcellent > Goodということはなさそう)。他論文でも指摘されているが、Promptの工夫や今後のSoft Prompt[4][5]のような技術を適用することで性能はさらに上がっていくものと思われる。

ゼロショットで良い翻訳性能を出したLLMは驚異的とも言え、また、その性質上文単位ではなくドキュメント単位で情報を捉える事も可能、翻訳文のスタイルもコントロール可能と利点が多い。ChatGPTの会話の中で出力させていくUXも素晴らしく、使っていて楽しい。[2]にも書かかれていたように(裏側では)翻訳特化モデルと大規模言語モデル(LLM)+PromptのHybridで使っていくことになるのかなと思う。

FuguMTとしては「ChatGPTに勝ったぜ」と宣伝するのではなく、文書単位(文単位を超える)機械翻訳モデルへ性能強化するとか、英語OnlyなLLMを使うときに役立つ機能(<t1></t1>で挟まれた部分は訳文でも同じタグで挟まれているようタグ構造を保存して翻訳するなど)を入れるとかそういう方向で強化を行っていきたい。

その他

流行りのChatGPT API(gpt-3.5-turbo)、GPT-3.5 API(text-davinci-003)をFuguMTと比較してみたが、ぶっちぎりで負けているようなことが無くて安心した。OpenAIが使っているデータに日本語が少ないという理由だと悲しいが…

LLM (Large Language Model / 大規模言語モデル)の良さはzero / few shotで動くモデルが作れることにあり、No Data, No Codeで特化型モデルであるFuguMTと遜色ない性能を出しているのは正直凄い。[6]によるとGLUEにおけるChatGPTの性能は(得意不得意の差が大きいが平均的には)BERT-baseでfine tuningした結果と同等、BERT-largeやRoBERTaには及ばないとのこと。FuguMTはTransformer世代で約60Mパラメータ(BERT-baseは約110Mパラメータ)であることを考えるとだいたい想定通りの結果ともいえる。

上記結果を「あらゆるユーザが自分の欲しい”AI”をNo Code, No Dataで生み出せ、その性能はBERT-baseを用いてそこそこのデータでfine tuningした結果と同等」と捉えると世の中にかなりのインパクトがあってもおかしくない。Twitterを見ていると様々なタスクにChatGPTを使うユーザがいて、そのタスクには今まで想定されていなかったものが含まれている。データがいらないという点も重要でまさに「AIの民主化」と言えそう。今まで研究者やエンジニアが想像もしなかった用途で有用な”AI”が出てくる可能性は高い。とっても楽しみ。

NLP業界に与える影響としては、現時点では特化型モデルの方が性能が高い(上記、有用な”AI”のアイデアについてLLMの性能を超えることは可能)とかFATE(Fairness, Accountability, Transparency, Ethics)やRobustness[7]といったモデル性能以外に重要な要素も多数ある[8]ので、分野としての仕事は減らないかむしろ増える気がする。

ChatGPTが嘘を言う、いわゆるHallucinationの問題は機械翻訳やAbstractiveな要約といったテキスト生成でも生じる(生じてきた)問題で応用によっては解決可能。もちろん用途によっては対策が難しいかもしれないし、あまり考えずにChatGPTに頼る場合は問題になるが、現実的には何とかできる感がある。

少し未来のことを考えると今後もLLMの進化は止まらなさそう。上で挙げたfew-shot以上の事例をPromptに埋め込むSoft PromptやCoT(Chain of Thought)[9][10]、PAL(Program-Aided Language models)[11]のようにPromptを工夫する方向性の他、LLM自体の高度化としてマルチモーダル化や外部知識の利用、APIの活用など様々な方向性[12]が研究されている。

個人的にはマルチモーダル化に期待したいところ。自然言語+画像の大規模モデル構築の試みは非常に多く行われていてかつ成果も上がっている。視覚+言語理解を得たChatGPTが登場するのはそう遠くないと思う。その後、テーブルデータの理解(またはAutoMLとの統合)や計画・手順の理解がなされると”AIエンジニアGPT”のようなレベルに達する。それぞれについて研究成果が複数あるので意外と早く実現してしまうかもしれない。

この方向でAGIに達するかは不明だが、社会にインパクトを与えうる動きとして注目していきたい。

注釈・参考文献

[1] 単純に学習データに入れないだけではなく、英文側から数字記号を削除し小文字に直したデータをキーとして一致するものが学習データに含まれていないことを確認している。(複文の一部に含まれている場合は検出できないが…)
[2] [2302.09210v1] How Good Are GPT Models at Machine Translation? A Comprehensive Evaluation (arxiv.org)ではもっと詳細に検証されている。
[3] 要約だと[2302.08081] Exploring the Limits of ChatGPT for Query or Aspect-based Text Summarization (arxiv.org)には「we can tell the ChatGPT-generated summaries are surprisingly good and even better than the given references」との記載がある。
[4] The Power of Scale for Parameter-Efficient Prompt Tuning – ACL Anthology
[5] [2302.06541v1] Towards Agile Text Classifiers for Everyone (arxiv.org)
[6] [2302.10198v1] Can ChatGPT Understand Too? A Comparative Study on ChatGPT and Fine-tuned BERT (arxiv.org)
[7] RobustnessはLLMの方が良いかも?と言われていたりもする。[2302.12095v1] On the Robustness of ChatGPT: An Adversarial and Out-of-distribution Perspective (arxiv.org)
[8] [2110.01167] Trustworthy AI: From Principles to Practices (arxiv.org)
[9] [2201.11903] Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (arxiv.org).
[10] その後も非常に多くの報告が出ている Chain of Thought – arXiv最新論文の紹介 (devneko.jp)
[11] [2211.10435v1] PAL: Program-aided Language Models (arxiv.org)
[12] [2302.07842] Augmented Language Models: a Survey (arxiv.org)

OCR用翻訳モデルとVR対応論文翻訳

NLP Hacks vol.2で話した内容でもあるがPDFからのテキスト抽出やOCR時の問題に対応可能なニューラル機械翻訳モデルを構築した。ここで言う問題は単語境界判定を間違いスペースが削除される現象やOCR特有の認識間違い[1]を指す。

具体的には下記のようなデータを正しく翻訳することを目指す[2]。

Tounifythecurrentfragmentedapproachestowardstrustworthy
AI,weproposeasystematicapproachthatconsiderstheentirelife
cycleofAIsystems,rangingfromdataacquisitiontomodeldevelop
ment,todevelopmentanddeployment,finallytocontinuousmoni
toringandgovernance.

Bo Li, Peng Qi, Bo Liu, Shuai Di, Jingen Liu, Jiquan Pei, Jinfeng Yi, & Bowen Zhou. (2021).
Trustworthy AI: From Principles to Practices.(https://arxiv.org/abs/2110.01167)
ライセンス:Creative Commons — Attribution 4.0 International — CC BY 4.0
※当該PDFからpdfminerによるテキスト抽出を実施、Blogで表示するため改行を追加。

このデータをFuguMTモデルで翻訳すると下記のようにイマイチな訳となる。

信頼に値するAI、AIシステムの再ライフサイクルを考察するweproposeasystematicapproach、dataacquisitiontomodel Modeling、Development and Deployment、finallytocontinuousmonitoringandgovernanceに現在のフラグメンテーションされたapproachestounify。

Bo Li, Peng Qi, Bo Liu, Shuai Di, Jingen Liu, Jiquan Pei, Jinfeng Yi, & Bowen Zhou. (2021).
Trustworthy AI: From Principles to Practices.(https://arxiv.org/abs/2110.01167)
ライセンス:Creative Commons — Attribution 4.0 International — CC BY 4.0
※当該PDFからpdfminerによるテキスト抽出を実施し機械翻訳。

モデル概要

通常「スペースが削除される現象やOCR特有の認識間違い」への対策は認識した文章の修正である。その上で機械翻訳モデルに投入するパイプライン構成をとるのが第一感である。

しかしながら、今回はそれらをend-to-endで対応することを目指す[3]。モデル構築手順は下記の通り。

  1. FuguMTモデル用に構築したテキストデータを準備する。
  2. 上記テキストデータを目的に沿ってデータ拡張する。
    • スペースを除去したテキストを加える。
    • nlpaugを用いてOCRエラーをシミュレーションしたデータを加える。
  3. FuguMTモデルと同様の手順でモデルを構築する。

構築したモデルは前述のテキストを下記のように翻訳する。まずまずの品質である。

信頼できるAIに対する現在の断片化されたアプローチを統一するために、データ取得からモデル開発、開発とデプロイ、さらには継続的な監視とガバナンスまで、AIシステムのライフサイクル全体を考慮した体系的なアプローチを提案する。

Bo Li, Peng Qi, Bo Liu, Shuai Di, Jingen Liu, Jiquan Pei, Jinfeng Yi, & Bowen Zhou. (2021).
Trustworthy AI: From Principles to Practices.(https://arxiv.org/abs/2110.01167)
ライセンス:Creative Commons — Attribution 4.0 International — CC BY 4.0
※当該PDFからpdfminerによるテキスト抽出を実施し機械翻訳。

構築したモデルはhttps://fugumt.com/pdf_ocr_model.zipからダウンロード可能。加えてHugging face対応バージョンをhttps://huggingface.co/staka/fugumt-en-jaから利用できる。ライセンスはCC BY-SA 4.0、研究用目的の公開である。多くのOSS同様、「作者は本モデルの動作を保証しないし、本モデルを使用して発生したあらゆる結果について一切の責任を負わない。」事に注意してほしい。

下記のようにHugging Faceバージョンは3行で利用でき便利である。

from transformers import pipeline
fugu_translator = pipeline('translation', model='staka/fugumt-en-ja')
fugu_translator('This is a cat.')

意外なことにOCR対応モデルはデータ拡張を行わなかったモデルよりもBLEUが高かった。英語と日本語のtokenizeが同条件(両方ともスペースが無い)だったから性能が上がったとかだったら面白いなと思いつつ時間があったら詳細検証を行うかもしれない[4]。

なお、日→英翻訳モデルも(OCR対応ではないが)https://huggingface.co/staka/fugumt-ja-enで公開している。こちらも先ほど同様3行で利用できるので興味のある方は試してみてほしい。

from transformers import pipeline
fugu_translator = pipeline('translation', model='staka/fugumt-ja-en')
fugu_translator('猫はかわいいです。')

VR対応論文翻訳

FuguMTのPDF翻訳を改善すべく下記のフローで翻訳を行うシステムを開発、VR対応を行った[5]。

  1. PDFを画像に変換する。
  2. Layout Parserを用いてドキュメントを解析、tesseractでOCRを行う。
  3. 前述のFuguMT OCR対応バージョンで機械翻訳する。
  4. A-Frameを用いてVRモードで確認可能とする。

テストのためCC-ZEROで公開されていた[2201.13309] Accelerating Laue Depth Reconstruction Algorithm with CUDA (arxiv.org)を対象に翻訳→VR化を行った。変換後のHTMLはhttps://fugumt.com/fugumt/paper/tmp/vr-demo_20220508.htmlである。動作確認はOculus Quest 2で行っており、次の動画のように論文のテキスト領域を選択すると翻訳結果が表示される。
(テキスト領域以外を選択すると手元に選択したページが表示される。両手に論文のページと翻訳結果を持って見比べることが可能。)
※ ソフトウェア一式は近日公開予定。

Oculus Quest2で表示した結果

その他

GWということで趣味の開発を進めてみた。ニューラル機械翻訳を自作しているとモデルレベルで様々な対応が可能でとても良い。加えてVRの可能性を感じた。便利なのでソースコードの公開とともに利用しやすいサービスとしての提供を検討中である[6]。

GWには英語、ドイツ語、イタリア語、フランス語、スペイン語、ロシア語、ウクライナ語を日本語に変更する7+1か国語対応したTakoMT [7](https://huggingface.co/staka/takomt)の開発も進めていた。一応使えるようにはなっているがたまに日本語訳せずに出力を返すことがあるので改善予定[8]。こちらもモデル構築過程などをBlogに整理したいと思っている(が時間がない・・・)。

脚注

[1] 1をlと間違うなど。tesseractはじめDeep Learningを活用したOCRだとエラー発生の雰囲気が異なるが、それには対応できていない。
[2] メジャーな機械翻訳モデルでは正しく翻訳できる。さすがである。
[3] 無駄と思われることをやってみるのは趣味の楽しみ。
[4] OCRの誤認識に対するデータ拡張が良く機能している可能性の方が高いとは思う。
[5] 正直VR対応は流行りに従っただけ(上記同様)。ただ、大画面で論文を読めるのは意外と便利だった。
[6] メールでPDFを送ると翻訳して送り返してくる的なシンプルなサイトを作ろうかと思っている。計算リソースに限りがあるので、どのようなサービスにするか詳細を検討中。
[7] たこは足が8本。
[8] 計算リソース不足から対訳ペアのフィルタリングが甘くなっているのが原因である。過去の経験からも時間をかけてフィルタリングすれば性能は大幅に改善するはず。

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

ニューラル機械翻訳モデルや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くらいで買ってくれるとこないかな、、、