Category Archives: 人工知能

Qwen2-7B, GLM-4-9Bの機械翻訳性能

Posted by on 2024年6月8日 No comments

中国からもWeightを公開している or オープンなモデルの発表が続いている。いつもの通り機械翻訳性能を検証してみた。性能評価に使用したデータは以前（DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp)）と同じ。検証環境は環境はColab Pro+を用いた。基本的にfp16で扱っている。

本件の検証でもGPT-4oを用いて回答抽出を行った結果を併記しているが、基本的に指示への対応は安定していた。評価指標はBLEU、使用したツールやtokenizerは以前と同じ（sacrebleu –tokenize ja-mecab）である。「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能、「出力そのまま」と「GPT-4で回答抽出」の比較で指示のしやすさをザックリとみる事ができる。いつもの通り非常に限定された機械翻訳ベンチマークである[1]ことに注意が必要である。

モデル0 shot /
出力そのまま		0 shot /
GPT-4oで回答抽出		1 shot /
出力そのまま		1 shot /
GPT-4oで回答抽出
Qwen/Qwen2-7B-Instruct · Hugging Face20.520.429.730.0
THUDM/glm-4-9b · Hugging Face25.525.530.430.6
Qwen2, GLM4の機械翻訳性能

結果と所感

Qwen2 7B、GLM 4 9Bとも機械翻訳性能は高い。さすがマルチリンガル利用を想定され構築されたモデルである。Qwen2とGLM4の性能差はパラメータサイズによるものに見える。

今までの検証結果を振り返ると、同様に構築されたAya-23 8B [2]と比べると出力の安定性（使いやすさ）はQwen, GLMが優れ、絶対性能は競合的またはややAya-23が優位といえそう [3]。

サイズが近く有名なモデルにはMistral 7B v0.3やGemma 7B、Llama 3 8Bがある。これらと比べると0 shot性能ではQwen, GLMが優れ、1 shot性能はほぼ互角である。0 shot性能はLLM内の知識に依存し、日本語での継続学習・SFTを行うと性能拡張の余地も大きそう。

Qwen2 7BはApache-2ライセンスと完全なOSSであることも重要。絶対性能が高く、命令追従性が良い、かつ、周辺ツールもよく整備されている強力で使いやすいモデルであるように思う。

脚注

[1] このあたりのザックリ感はいつもと同じ。
[2] Aya-23はCC-BY-NCと商業利用が禁止されているため使いどころは限られる。
[3] BLEUで測れるのかという話はあるが…

The Pileの構成（なぜCerebras-GPTで日本語が使えるのか？）

Posted by on 2023年4月9日 No comments

ChatGPTが盛り上がる中、オープンライセンスなLLM（大規模言語モデル）開発も行われている。その中でCerebras-GPT（Cerebras Systems Releases Seven New GPT Models Trained on CS-2 Wafer-Scale Systems – Cerebras）が日本語を使えると聞いて試してみた。

Colab Pro +でA100 GPUを使うと、cerebras/Cerebras-GPT-6.7B · Hugging Faceにそって6.7Bのモデルを動作させることができる[1]。

import torch
device = torch.device('cuda:0' if torch.cuda.is_available() else 'cpu')

from transformers import AutoTokenizer, AutoModelForCausalLM
from transformers import pipeline

tokenizer = AutoTokenizer.from_pretrained("cerebras/Cerebras-GPT-6.7B")
model = AutoModelForCausalLM.from_pretrained("cerebras/Cerebras-GPT-6.7B")

pipe = pipeline("text-generation", model=model, tokenizer=tokenizer, device=device)

text = "猫と暮らして10年になる人に聞いた、猫と一緒に暮らすときに必要なもの第1位は"
generated_text = pipe(text, max_length=500, do_sample=False, no_repeat_ngram_size=2)[0]
print(generated_text['generated_text'])

上記の出力は「猫と暮らして10年になる人に聞いた、猫と一緒に暮らすときに必要なもの第1位は「笑顔」。続いて「恋愛」、「自分のことを知っている」という結果に。」[2]、なお、2.7Bパラメータの場合は「猫と暮らして10年になる人に聞いた、猫と一緒に暮らすときに必要なもの第1位は、それぞれの人間が笑っているということです。」[2]だった。

model = AutoModelForCausalLM.from_pretrained("cerebras/Cerebras-GPT-13B", torch_dtype=torch.float16)

としてCerebras-GPT-13Bを使った時の結果は「猫と暮らして10年になる人に聞いた、猫と一緒に暮らすときに必要なもの第1位は、「笑顔」。結果、それは私の言葉ではなく、自分のものである。」[2]だった。

日本語を使えると言っても性能はかなり微妙な感じ。
※以降、理由を探っていくが本来使えないはずの日本語っぽい文字列が表示されるのは結構すごいというのが全体的な感想。

The Pile

Cerebras-GPTシリーズはデータセットとしてThe Pile[3]を用いている。論文に書かれている通りThe Pileは英語のデータセットである。そのため基本的には日本語を使えないはずなのだが、The Pileを用いて学習されたLLMは日本語をある程度解釈しているのでは？と思う動作をする。これはThe Pile構築で使われたデータセットに意図せず日本語が含まれているためと言われている。前置きが長くなったが、本記事ではこれが本当なのか検証する。

検証方法

The Pileをダウンロードし含まれる文字を文字別にカウントし、下記条件の文字を日本語と考えて日本語の構成比率を算出した。CJKの名の通り日本語ではない用例の漢字を含めて数えており明らかに日本語分を多くカウントしているという問題があるのだが、ここではいったん無視することにする[4]。

  • UnicodeのBlock=Hiragana
  • UnicodeのBlock=Katakana
  • UnicodeのBlock=CJK Unified Ideographs

The Pileのデータを展開しながら文字別カウントし、その後、上記条件をregexでチェックし日本語と全体の文字数を集計した。Pythonで適当に書いた感じc6a.xlargeで1プロセス辺り9Mバイト/秒程度の速度で処理ができた。2プロセス並列させると1日以内に処理が終わるイメージである。

検証結果

検証結果は次表の通り。The Pileにおける日本語の構成比率はわずか0.07%（約900 M文字）だった。日本語に貢献しているデータセットは「OpenWebText2」「Github」が大きく、続いて「YoutubeSubtitles」だった。

データ名全体の文字数うち日本語日本語構成比率
■全体1,297,182,716,948889,523,7340.07%
Pile-CC230,770,471,68714,799,6330.01%
PubMed Central181,751,973,64018,441,2010.01%
Books3153,023,754,59930,846,0520.02%
OpenWebText2124,271,071,981390,955,6250.31%
ArXiv113,558,856,961307,7740.00%
Github96,487,741,975314,200,4230.33%
FreeLaw79,956,003,3662,8320.00%
StackExchange64,805,917,11319,770,0980.03%
Wikipedia (en)50,611,222,0865,979,9760.01%
USPTO Backgrounds47,025,652,53400.00%
PubMed Abstracts39,086,727,4677300.00%
Gutenberg (PG-19)26,723,093,69917,8450.00%
OpenSubtitles19,750,201,47835,0700.00%
DM Mathematics15,719,095,09600.00%
Ubuntu IRC11,184,940,47100.00%
BookCorpus29,378,252,620833,3340.01%
EuroParl8,516,900,087200.00%
HackerNews7,872,312,50577,7930.00%
YoutubeSubtitles6,431,579,29193,060,4371.45%
PhilPapers4,745,004,923194,8910.00%
NIH ExPorter3,814,590,93000.00%
Enron Emails1,697,352,43900.00%
The Pileの日本語構成比率

なお、日本語として含まれる文字のトップ5は次の通りだった[5]。ひらがなの出現頻度が通常と同じなのかは疑問ではある。

  1. 「の」約20M文字
  2. 「い」約14M文字
  3. 「的」約13M文字
  4. 「に」約13M文字
  5. 「る」約12M文字

結果とまとめ

オープンなLLM開発でよく使われるデータセット、The Pileの構成文字から日本語の比率を考えてみた。結果、多めに見積もって900M文字、構成比率0.07%と非常に少ない。この程度しか入っていないにもかかわらず日本語文として一定程度成立した文が返ってくるCerebras-GPT-6.7Bは凄い。

脚注

[1] GPUで動作させる部分だけ若干コードを追加している。cerebras/Cerebras-GPT-13B · Hugging Faceは書かれた手順ではメモリ不足になる。float16にすれば動作する。
[2] この後改行して「私は、それぞれの言葉についちゃった。「お父さん、こんなに美しい犬がいますか?」「この人、あなたのほうが素敵ですよ」」・・・と謎の文字列が続く。
[3] Gao, L., Biderman, S., Black, S., Golding, L., Hoppe, T., Foster, C., Phang, J., He, H., Thite, A., Nabeshima, N., Presser, S., and Leahy, C. 2020. The Pile: An 800GB Dataset of Diverse Text for Language Modeling. arXiv preprint arXiv:2101.00027.
[4]とても雑なことは承知しつつ、日本語判定は結構難しく判定に凝ると処理時間の問題が出るため今回はこの条件で検証した。日本語分を多めにカウントしていて出た結果で結論には影響しない。
[5] 「的」が入っているのは中国語も入っているからかな？と思う。

その他

The Pileを使って構築した大規模言語モデルで何故か日本語が使えるのは知られていた。その理由としてGithubデータセットの日本語コメントによるものなどの理由を聞いたこともあったが、本当か確証がなかったので調べてみた。結果当たらずも遠からずという感じだった（構成要素としてはそれなりに多いが半分は超えていない）。

個人的には1G文字いかないレベルのデータで日本語能力を学習していることに驚きだった。疑問に思ったことは調べてみると面白い。The Pileにwikipedia-jaのデータを混ぜるだけでも日本語能力はかなり上がるんじゃないだろうか。BlinkDL/rwkv-4-raven · Hugging Faceのように1%程度でも日本語が入っていると結構な効果がありそうに思う。

機械翻訳でのIn-Context Learning（GPT-4 + OpenICL）

Posted by on 2023年4月5日 No comments

GPT-4とGPT-3.5 + OpenICL[1]を用いて機械翻訳におけるICL（In-Context Learning）を検証してみた。結果は下表の通りでプロンプトの動的生成には大きな効果があった。

プロンプトの条件GPT-3.5[2]GPT-4[3]FuguMT[4]
ゼロショット、事例無し27.230.231.3
対応するページのタイトル（英語・日本語の両方）29.631.8–
OpenICL / RandomRetriever
※ gpt-3.5のトークン数に沿って1-2 shot
※ 翻訳例をランダムに参照しているイメージ		28.030.6–
OpenICL / TopkRetriever①
※ gpt-3.5のトークン数に沿って1-2 shot
※ 翻訳例から対象に近い事例を参照しているイメージ		34.734.5–
OpenICL / TopkRetriever②
※ 全ての試行で3-shot
※ 翻訳例から対象に近い事例を参照しているイメージ		–35.3–
GPT-3.5, GPT-4でプロンプトを変えた場合及びOpenICL利用時のBLEU

性能評価の方法

性能評価に使用したデータは前回（GPT-4を用いた翻訳の検証（vs GPT-3.5 vs FuguMT） | ぷるーふおぶこんせぷと (staka.jp)）と同様としOpenICLの効果を検証した。

  • ChatGPT API（gpt-3.5-turbo-0301）、GPT-4 API（gpt-4-0314）、FuguMT（staka/fugumt-en-ja · Hugging Face）を比較。英語文を日本語文に翻訳し、その性能を評価した。評価指標はBLEUで、使用したツールやtokenizerは前回と同じ（sacrebleu –tokenize ja-mecab）である。
  • データセットは外務省WEBサイトのプレスリリース（CC BY互換で利用可）のうち日本語、英語が対応しているページを利用した。評価に使用した対訳ペアは前回と全く同じ。2020年1月～2023年3月で月ごとに5件のプレスリリースを選択し全195件。
  • ベースのプロンプトも前回と同じだがOpenICLを用いて事例部分を変更した。各Retrieverが用いる対訳ペアは評価データとは分けている。
    • RandomRetriever: 対訳事例をランダムに選択、gpt-3.5-turboの最大トークン数に合わせて事例数を変更、結果1-2shot設定となっている。（0-shotにはなっていない）
      直感的には過去の翻訳例をランダムに選んで参考にしている状況に相当する。
    • TopkRetriever①: 対訳事例をTopK「[2101.06804] What Makes Good In-Context Examples for GPT-$3$? (arxiv.org)[6]」に沿って選択。gpt-3.5-turboの最大トークン数に合わせて事例数を変更、結果1-2shot設定となっている。（0-shotにはなっていない）
      直感的には過去の翻訳例から今翻訳しようとしている内容に近いものを選び参考にしている状況に相当する。
    • TopkRetriever②: TopkRetriever①を3-shotに固定して実行。GPT-4で最大トークン数が拡張されているから可能[5]。

結果とまとめ

結果はページ最初の表の通りでTopkRetrieverは高い効果を示した。近い内容の翻訳結果を参照することで単語の対訳や文章スタイルなどを合わせることができBLEUが高くなったものと思われる。

某有償APIを用いた時はBLEU=32.6であった。GPT-3.5 + TopkRetrieverとGPT-4 + TopkRetrieverはこのスコアを超えておりOpenICLの有効性が伺える。有償APIによっては単語登録が可能なものもあり一概には言えないものの、うまくICLを行ったときの翻訳性能は非常に高いと言える。

GPT-3.5の最大トークン数（約4K）に比べGPT-4の最大トークン数は32Kと大幅に拡張されている。本件では最大3-shotの設定[7]で試行しshot数が増えたことによる性能向上も確認できた。

翻訳時に過去の翻訳結果を参照することは一般的に行われており、本検証の設定は無理なものではない（厳密には微妙な部分はあるけど）。LLMを利用した機械翻訳では辞書を参照することが有効という報告もある[8]。プロンプトの工夫や自動作成によってLLMを用いた機械翻訳性能は向上し使い勝手の良いシステムになる事が見込まれる。

脚注

[1] GitHub – Shark-NLP/OpenICL: OpenICL is an open-source framework to facilitate research, development, and prototyping of in-context learning. Zhenyu Wu, Yaoxiang Wang, Jiacheng Ye, Jiangtao Feng, Jingjing Xu, Yu Qiao, and Zhiyong Wu 2023. OpenICL: An Open-Source Framework for In-context Learning. arXiv preprint arXiv:2303.02913.
※sentence_transformerのモデル名を与えることができ日本語も使用可能（例えば↓）
TopkRetriever(data, ice_num=5, sentence_transformers_model_name='paraphrase-multilingual-mpnet-base-v2')
[2] gpt-3.5-turbo-0301
[3] gpt-4-0314
[4] GitHub – nipunsadvilkar/pySBDにより行に分割し、FuguMT(staka/fugumt-en-ja · Hugging Face)で翻訳
[5] GPT-3.5では実行不可の設定
[6] Jiachang Liu, Dinghan Shen, Yizhe Zhang, Bill Dolan, Lawrence Carin, and Weizhu Chen. (2021). What Makes Good In-Context Examples for GPT-$3$?. arXiv preprint arXiv:2101.06804.
[7] 4Kだと1 shotしか無理な場合もあったので、3 shotでも大きな拡張
[8] [2302.07856v1] Dictionary-based Phrase-level Prompting of Large Language Models for Machine Translation (arxiv.org)、Marjan Ghazvininejad, Hila Gonen, Luke Zettlemoyer. Dictionary-based Phrase-level Prompting of Large Language Models for Machine Translation. arXiv preprint arXiv:2302.07856.
[9] 正直、ベンチマークデータの品質がイマイチだったりする…。

その他

OpenICLを試してみたいと思って機械翻訳を題材に検証してみた。結果として商用の機械翻訳システムを超える性能となってびっくり。過去の訳を参照できる条件だと翻訳が容易になるのは当たり前ではあるが、それを自然に自動化できるのはすごい。

LLMの流行やGPT-4の登場によってNLP界隈は激変している。LLMをうまく使う上でICLは一つのキーワードであると思う。なかなか検証が難しい[9]分野であるが今後も定量的評価を行いたい。本件だとICLは「英語→日本語での単語選択への貢献」「日本語のスタイル（常体・敬体など）への貢献」など様々な側面があるはずでその辺りも分けて検証したいところ。

GPT-4を用いた翻訳の検証（vs GPT-3.5 vs FuguMT）

Posted by on 2023年3月22日 No comments

GPT-4の翻訳性能を外務省WEBサイトのテキスト（日本語/英語）を用いて定量的[1]に測ってみた。

検証結果からGPT-4の翻訳性能はGPT-3.5より優れていると言えそう（FuguMTより若干上）。期間別の比較（後述）も行っているが発表されているGPT-4の学習データ期間前後では大きな性能変化はなかった。一方で詳細検討が必要な気がしている[2]。

モデル概要BLEU
GPT-4gpt-4-0314を利用（ゼロショット）30.19
GPT-4 + タイトルgpt-4-0314を利用し対応するページのタイトル（英語・日本語の両方）を与えたもの31.82
GPT-3.5gpt-3.5-turbo-0301を利用（ゼロショット）27.16
GPT-3.5 + タイトルgpt-3.5-turbo-0301を利用し対応するページのタイトル（英語・日本語の両方）を与えたもの29.58
FuguMT英語文書をGitHub – nipunsadvilkar/pySBDにより行に分割し、FuguMTで翻訳31.30
GPT-4、GPT-3.5、FuguMTの性能（概要）、データの詳細は後述

性能評価の方法

性能評価は下記の条件で実施した。

  • ChatGPT API（gpt-3.5-turbo-0301）、GPT-4 API（gpt-4-0314）、FuguMT（staka/fugumt-en-ja · Hugging Face）を比較。英語文を日本語文に翻訳し、その性能を評価した。
    • 評価指標はBLEUで、使用したツールやtokenizerは前回と同じ（sacrebleu –tokenize ja-mecab）である
  • データセットは外務省WEBサイトのプレスリリースのうち日本語、英語が対応しているページを利用した。詳細はデータセットの作成に記載する。
    • 期間は2020年1月～2023年3月、月ごとに5件のプレスリリースを選択[3]、全195件
    • 既存のデータセットはGPT-4、GPT-3.5の学習データとして使われている可能性があり利用を避けた。（加えて性能評価のために適した品質と言えないものも少なくない。）
  • プロンプトは前回のもの（機械翻訳でのChatGPT vs GPT-3.5 vs FuguMT | ぷるーふおぶこんせぷと (staka.jp)）を使用、プレスリリースのタイトル（日・英）の対応を参照用として与えたパターンも比較対象とした
    • タイトルを与えることで、参考訳として使用する事及び訳のスタイルを官公庁っぽくすることを狙っている [4]
    • 学習データに外務省のサイトが入っている場合（おそらく入っていると思うが）そのデータを色濃く反映する効果も狙っている
  • 性能評価は全体、2021年9月[2]前後での検証、月別（ある月以降3ヶ月間分のプレスリリースを使用）で評価した。月別の評価と言いつつ3ヶ月移動平均のような処理になっている。（データが少ないことによる苦肉の策）

データセットの作成

データセットは外務省ホームページのPress Releases | Ministry of Foreign Affairs of Japan (mofa.go.jp)を用いて下記手順で作成した。使用したデータは整理後に公開予定[5]。

  1. プレスリリースのうち、日本語と英語の対応が取れるものを取得
  2. 日本語のページと英語のページから本文とタイトルを抽出
  3. 英語のページから日付を抽出
  4. 日本語のページと英語のページを目で比較し、どちらか一方のみにある部分を削除
    • 日本語だけに補足や経緯がある、参考リンクが日本語と英語のページで異なるなど微妙な差異があるため、その部分は対応が必要である。[6]
  5. 2020年1月～2023年3月の記事について長さがちょうどよいものを5件/月を選択した
    • 月内の全記事の中から一定期間ごとになるように5件選択
    • 300文字～1600文字の記事を選択

検証結果

検証結果は下表・下図の通り。　

モデル期間BLEU
GPT-4全期間30.19
GPT-42021/09/01以前29.66
GPT-42021/10/01以降30.82
GPT-4 + タイトル全期間31.82
GPT-4 + タイトル2021/09/01以前31.30
GPT-4 + タイトル2021/10/01以降32.15
GPT-3.5全期間27.16
GPT-3.52021/09/01以前27.04
GPT-3.52021/10/01以降26.87
GPT-3.5 + タイトル全期間29.58
GPT-3.5 + タイトル2021/09/01以前29.34
GPT-3.5 + タイトル2021/10/01以降29.59
FuguMT全期間31.30
FuguMT2021/09/01以前31.65
FuguMT2021/10/01以降30.70
2021年9月を境にした性能変化
BLEUの時系列変化
BLEUの時系列変化、BLEU≧20のエリアを拡大表示

まとめ

GPT-4の翻訳性能を外務省WEBサイトの日本語-英語対応を使って検証した。結果としてGPT-4は翻訳性能においてGPT-3.5よりも大幅に優れていた。タイトルを参考訳として使用可能な状況ではFuguMTのような翻訳特化モデルを超える性能を発揮している[7]。

GPT-4の学習データ期間は2021年9月までとのことだが、翻訳性能の変化からはその時期を境にした性能変化は見られなかった。2022年3月～4月ごろに性能の変化がみられるが、FuguMTでも同傾向であり単純に訳が難しいデータになっているだけの可能性がある[8]。

BLEUの経年変化はタイトル行を入れてもFuguMTと概ね同じである。（おそらく学習データに含まれているであろう）ページの日本語訳のコピーを出している場合はFuguMTと動きが異なるはずで、そのような不適切な動作はしていないものと思われる。BLEUの変化のブレが激しくデータを増やす、比較するモデルを変えるなどしての再検証が必要と思われる[9]。

現在のGPT-4 APIでは画像入力ができないが、できるようになったらそれを含めて検証を行いたい。官公庁のサイトでは画像付きの記事も多く、画像＋機械翻訳の性能検証は可能だと考えている。

脚注

[1] といってもデータ数は微妙で評価指標はBLEU。。。sacrebleu.corpus_bleu( sys, [ref], tokenize=’ja-mecab’)を使用。
[2] GPT-4 (openai.com)によると「GPT-4 generally lacks knowledge of events that have occurred after the vast majority of its data cuts off (September 2021)」とのこと。データ数も少ないので何とも言えないというところではあるが、特に「Webページの内容を記憶しているだけ」な場合はタイトルをプロンプトに入れることで2021/9を境に大幅な性能変化があるかと期待していたが、そのような結果とはなっていない。
[3] 過負荷のためかOpenAI APIのエラー（’openai.error.RateLimitError’）が多発、検証に用いたデータは少なめである。負荷が落ち着いたら全データを使って検証したいと思っている。
[4] 本当はURLを与えるなどより学習データを濃く反映できそうなパターンも実施したかったが時間の関係上断念した
[5] 2017年1月～現在までで2700件程度のデータが取得可能、本件に使ったもの以外を含め1/3くらいは目検証済みで残りを検証した後に公開する予定である。翻訳の品質が高く、オープンなライセンスで、検証しやすい長さのドキュメント単位、発表日が明確に記載されている貴重なデータである。機械翻訳モデルの時系列での性能劣化を測るために有用だと思っている。
[6] 自分で目検した。結構大変だが何とかなる量ではある。
[7] FuguMTと僅差だと商用の翻訳サービスの性能よりは低めな気がする。ただ、プロンプトで改善できる、訳のスタイル変更が可能、間違いを指摘してくれるなど単純な性能以外の利点は多くあり、それがチャット形式で可能なのは大きな利点。
[8] 実はFuguMTのクローリングデータはちょうどこの時期に追加したのが最後になっている（OCR用翻訳モデルとVR対応論文翻訳 | ぷるーふおぶこんせぷと (staka.jp)）。翻訳が難しいデータなのか、たまたまGPTのデータ期間とFuguMTのデータ期間が近いのか、結論を出すのがとても難しい。Google翻訳やDeepLなどの他のエンジンで試すか、FuguMTの過去バージョンで検証する必要がありそうに思っている。
[9] データはあるが、APIの動作が重く検証できる気がしない…参考までに本検証にかかったコストは15USD程度であった。

その他

色々なところで指摘されている事でもあるが、試行しているとGPT-3.5までと比べてGPT-4は日本語性能が大きく向上している。機械翻訳でのBLEUの向上はそれを裏付けている。GPT-3.5までであれば特化型モデル > GPT(LLM+prompt)だったがGPT-4ではそうでもなさそう。おそらく数か月すれば検証結果がそろうはずで興味津々。

本件の検証の目的の一つは2021年9月を境に性能が劣化するか？だったが残念ながら裏付けが取れなかった…全データを使っているわけではなく変化点っぽいものも見えなくはないのでより詳細な検討を行いたいところ。メンバシップ攻撃のようなことをやっている人達もいるかもだが、個人的にはデータの期間をはっきりさせるというよりはleakっぽい理由で性能が高く見えるのかそうでないのか？をはっきりさせたいと思っている。Home | RealTime QAのような取り組みも参考になりそう。

日本語性能の向上やプロンプトの探索などを見るに結構な社会的インパクトを与えるのは間違いなく、どう使っていくか？を考えていく必要がある。初期のインターネットと同じワクワク感がありとても楽しいと思う一方でディスラプトの怖さもある。OpenAIは結構な影響を予測しているFugu-MT 論文翻訳(概要): GPTs are GPTs: An Early Look at the Labor Market Impact Potential of Large Language Models (fugumt.com)が、実際どうなるかはここ数ヶ月で決まるんだろうなーと思う。

社会的なインパクトにも興味があるが、LLMの内部動作の理解、特にマルチリンガルな能力の獲得やIn-Context Learningが可能な理由にも興味がある。マルチモーダルさが入った時の動きも知りたいところ。この手の検証はAPIだととてもやりにくいのでオープンなChatGPT likeモデルに期待大。色々理由はあるのだろうが詳細が非公開というのはやはり辛い。

GPT-4の翻訳性能

Posted by on 2023年3月15日 No comments

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周りが急速に発展する中での日本語の立ち位置にも興味津々で実験時間が足りないというのが正直なところ。