DAMO PolyLM-13Bの機械翻訳性能

Alibaba、DAMO ACADEMYよりApache-2ライセンスでマルチリンガルなLLM、[2307.06018v1] PolyLM: An Open Source Polyglot Large Language Model (arxiv.org)が出ており、機械翻訳性能を評価してみた。

HuggingFaceから利用可能でDAMO-NLP-MT/polylm-13b · Hugging Faceの他、DAMO-NLP-MT/polylm-multialpaca-13b · Hugging Faceも提供されている。

論文にデータセットや構築方法の詳細な情報があるのが非常にありがたい。13Bモデル構築に要した計算リソースは32 A100 GPU (8×80G) serversで29 daysとのこと。今後の拡張として下記が予定されているとのことで非常に楽しみである。

We are continuously enhancing the capabilities of PolyLM by focusing on the following aspects:

  1. Replacement of absolute position embeddings with RoPE, as outlined in the research paper here.
  2. Expansion of window size to more than 10,000.
  3. Verification of lightweight techniques to quickly enhance multilingual quality, especially for low-resource languages.
https://huggingface.co/DAMO-NLP-MT/polylm-13b

論文ではpolylm-multialpaca-13bの方が機械翻訳性能が高そうであったが制御が難しく[1]本件試行はpolylm-13bで行っている。環境はColab Pro+を用いた。bfloat16で読み込むこととGPU側で計算[2]させないとエラーになる点に注意が必要。また、A100 VRAM 40GBではメモリ制約が厳しいため特に長いコンテキストではエラーが発生する事がある[3]。本件でもOut of memory発生時はnum_beamsなどのパラメータを調整している。

性能評価に使用したデータは前回(MPT-30B-Chat + In-Context Learningの性能 | ぷるーふおぶこんせぷと (staka.jp))と同じであり50件をサンプリングして使っている。MPT-30B同様、回答部分の抽出が難しいことがありルールベースで回答部分を抽出した結果と手動抽出した結果の2通りでBLEUを算出している。

結果は下表の通り。OSSなマルチリンガルモデルとしてはかなり性能が高い。

モデル・条件zero shot1 shot [4]
GPT-3.5 [5]26.737.0
PolyLM-13B10.621.5
PolyLM-13B
※回答部を手動抽出
14.125.8
PolyLM-13B, GPT-3.5-TURBO-16KのBLEU

BLEU的には1 shotで回答をうまく抽出できればGPT-3.5のゼロショットと同レベルの品質となっている。目検すると重要部分での訳ミスが多くGPT-3.5と比較してもBLEU以上に差が大きい印象。

パラメータ数13Bと1 GPUで動作可能&マルチリンガル&日本語対応のモデルがApache-2で利用可能というのはとてもありがたい。LLaMA v2の噂も出ていてオープンなLLM開発は盛り上がっている。この状況が続き良いものが出てほしいと強く思う。

脚注

[1] プロンプトをうまく調整できれば良いのかもだが、中国語の出力がされる、hallucinationが凄いなど正しい翻訳への誘導が難しいことが多かった。。
[2] 本件ではset_default_tensor_typeを使用したが、to.(‘cuda’)みたく明示的に飛ばしてもよいはず。
[3] torch.cuda.empty_cache()も呼びまくっている。
[4] OpenICL、TopkRetrieverにより取得
[5] gpt-3.5-turbo-16k-0613

MPT-30B-Chat + In-Context Learningの性能

MPT-30Bの性能が高いと聞いてそのChat版であるmosaicml/mpt-30b-chat · Hugging Faceの性能を検証してみた。過去の事例通り機械翻訳(英文和訳)でGPT-3.5、GPT-4と性能を比較した。結果、パラメータ数の割に高い性能を持っていることが分かった[1]。

MPT-30B-ChatのライセンスはCC-By-NC-SA-4.0 (non-commercial use only)であることに注意が必要である。Apache-2.0のMPT-30BやCC-By-SA-3.0のMPT-30B-Instructとはライセンスが異なる。

モデル / shot数 / 備考BLEU
MPT-30B-Chat / 0 shot / モデル出力のまま7.7
MPT-30B-Chat / 0 shot / ルールで回答抽出13.0
MPT-30B-Chat / 0 shot / 手で回答抽出13.8
MPT-30B-Chat / 3 shot / モデル出力のまま16.1
MPT-30B-Chat / 3 shot / ルールで回答抽出29.2
MPT-30B-Chat / 3 shot / 手で回答抽出30.9
gpt-3.5-turbo-16k-0613 / 3 shot35.3
gpt-4-0613 / 3 shot32.1
gpt-4-0314 / 3 shot36.5
MPT-30B-Chat, GPT-3.5, GPT-4+OpenICL利用時のBLEU

性能評価の方法

性能評価に使用したデータは以前(GPT-4を用いた翻訳の検証(vs GPT-3.5 vs FuguMT) | ぷるーふおぶこんせぷと (staka.jp))と同様であるが、処理時間の関係上[2]、50件をサンプリングした。

  • 英語文を日本語文に翻訳し、その性能を評価した。評価指標はBLEUで、使用したツールやtokenizerは前回と同じ(sacrebleu –tokenize ja-mecab)である。
  • データセットは外務省WEBサイトのプレスリリース(CC BY互換で利用可)のうち日本語、英語が対応しているページを利用した。評価に使用した対訳ペアは前回と同じ。2020年1月~2023年3月で月ごとに5件のプレスリリースを選択し全195件を取得、その上でさらに50件サンプリングした[3]。
  • OpenICLを用いて事例部分を取得した。RetrieverにはTopkRetriever[2101.06804] What Makes Good In-Context Examples for GPT-$3$? (arxiv.org)」を用いた。3 shotと書かれた行については全く同じデータを使っている。
  • 入力データは前回GPT-3.5/4の比較で使用したものと可能な限り合わせて作成した。プロンプトの作成はMPT-30B-Chat – a Hugging Face Space by mosaicmlを参考にしている[4]。
  • 処理時間削減のためMPT-30B-Chatは「load_in_8bit=True」で読み込んでいる。
  • MPT-30B-Chatの出力は回答部分の特定が一筋縄ではいかないことがある。複数の方法で回答部分の特定を行った。[4][5]
    • モデル出力のまま:出力をそのまま利用
    • ルールで回答抽出:正規表現を用い<|im_start|>や<|im_end|>をいくつかのパターンで指定して回答部分を取得
    • 手で回答抽出:目で見て回答部分を特定

結果とまとめ

MPT-30B-Chatは長いコンテキストに対応していることからIn-Context Learningが有効に機能する。出力から回答部分を特定することは簡単ではないが、うまくルール化することでGPT-3.5に近い性能を出すことができる。これらの処理はライブラリが対応すればよく、単純なルールでも比較的良いスコアが出せる[4]。

スコア上はMPT-30B-Chat+3 shotのICLでzero shotのGPT-3.5以上の性能が出せている。日本語に対応していてローカル環境で動くLLMとしては非常に優秀である[6]。オープンなライセンスのLLMであることから日本語能力の強化も有望そうで今後が非常に楽しみ。

脚注

[1] (最近色々言われている)GPT-3.5やGPT-4のサイズと比べるとかなり小規模。
[2] 「その他」にも書いている通り、検証するのも結構な計算リソースが必要。ICLを使ってコンテキストが長いのでしょうがない面はあるが…(3 shotではなくzero shotだとかなり速い)
[3] 一定期間ごとにサンプリングしている。
[4] 簡単に使えるライブラリが欲しい。誰か作っていそうではあるし既存の何かのライブラリでサポートされそうな気もする。
[5] ルールを追加するなどして自動化したかったが時間の関係上断念した。これらの処理は回答の特定を目的としており回答中のおかしな出力を除去したりはしていない。「手で回答抽出」は頑張ってルール化したときの最善の結果として記載している。
[6] これは本当にそう思う。
[7] 中国語など他の言語が混ざることがある、日本語としておかしな表現が出力されることがある、など印象の悪い出力が混ざることがある。これらが悪い方向に目立つのは事実。

その他

MPT-30B-Chatを検証したところGPT-4や3.5にかなり迫っている感じがあり驚いた。とはいえ、目検証をしてみるとBLEU以上の差は感じなくもなく日本語能力は十分とは言い難い[7]。機械翻訳能力だけでなく総合的なベンチマークもしてみたいところ。

検証はCloab Pro+のA100 GPU、load_in_8bit=Trueで実施した。この環境でもコンテキストが長い(7000文字)場合は5-10分の処理時間が必要だった。公式の説明通りbfloat16+triton構成では20-30分かかる。高速化手法は色々あるとはいえ実利用で安定動作させるのはかなり大変そうではある。

OpenAI APIのアップデート(gpt-3.5-turbo-16k, gpt-4-0613)と機械翻訳

OpenAI APIがアップデート(Function calling and other API updates (openai.com))されたため機械翻訳を対象に性能を評価してみた。GPT-3.5 16Kは性能向上に有効、GPT-4 0613は機械翻訳においては性能が落ちているように見える結果となった[1]。

プロンプトの条件GPT-3.5 16K[2]GPT-4 0613[3]GPT-4 0314[4]
OpenICL / RandomRetriever / 3 shot29.029.4
OpenICL / TopkRetriever / 3 shot34.933.334.9
OpenICL / TopkRetriever / 3 shot(日本語のみ)
※ 訳文のみを例示
31.3
OpenICL / TopkRetriever / 5 shot(日本語のみ)
※ 上記同様
31.6
GPT-3.5 16K、GPT-4 0613、GPT-4-0314のBLEU

※ 前回結果は「GPT-3.5で1-2 shotの場合、BLEU=34.7」「GPT-4で3shotの場合、BLEU=35.3」だった。ランダム性があるため前回結果と厳密には一致はしない。

性能評価の方法

性能評価に使用したデータは以前(GPT-4を用いた翻訳の検証(vs GPT-3.5 vs FuguMT) | ぷるーふおぶこんせぷと (staka.jp))と同様である。繰り返しになるがランダム性があるため前回結果とは完全一致はしない。

  • OpenAI APIでの比較。英語文を日本語文に翻訳し、その性能を評価した。評価指標はBLEUで、評価指標はBLEUで、使用したツールやtokenizerは前回と同じ(sacrebleu –tokenize ja-mecab)である。
  • データセットは外務省WEBサイトのプレスリリース(CC BY互換で利用可)のうち日本語、英語が対応しているページを利用した。評価に使用した対訳ペアは前回と同じ。2020年1月~2023年3月で月ごとに5件のプレスリリースを選択し全195件。
  • ベースのプロンプトも前回と同じでOpenICLを用いて事例部分を変更した。各Retrieverが用いる対訳ペアは評価データとは分けている。
    • RandomRetriever / 3 shot: 対訳事例を3件ランダムに選択。
    • TopkRetriever / 3 shot: 対訳事例を3件 TopK「[2101.06804] What Makes Good In-Context Examples for GPT-$3$? (arxiv.org)[6]」に沿って選択。
    • TopkRetriever / 3 shot(日本語のみ): 対訳事例の選択は上記同様。プロンプトとして英語-日本語の対訳ペアではなく日本語文章のみを与えたもの。対訳事例が無く文体のみを参照可能な状況に相当する。
    • TopkRetriever / 5 shot(日本語のみ): 条件は上記同様で事例を5件選択したもの。
  • 表中、同じ行であれば全く同じデータがプロンプトとして与えられている。

結果とまとめ

以前の検証の通りTopkRetrieverは高い性能を示す。本件ではコンテキストが広がったGPT-3.5 16Kを検証し、トークン数の増加がIn-Context Learningを活用するため有効そうという結果が得られた[5]。

類似する日本語の翻訳文章のみを与える手法にも効果がみられ(同一ドメイン内で)ランダムな対訳事例を与えるより性能が高かった。ビジネスで何らかの翻訳を行っている場合、対訳データを整備している事例は多くない[6]。翻訳結果のみが残っている状況でもそのデータで性能向上が目指せる事は興味深いと言える[7][8]。

データ数に限りがありBLEUというイマイチな指標で評価している事もあり確定したことは言えないが、GPT-4の6/13版は3/14版より性能が落ちているように見える。API性能を正しく把握するため日本語や日本語を含むマルチリンガルな評価用データ・ベンチマークが必要である[9]。

脚注

[1] 評価指標が微妙ではあるがスコアはGPT-4-0314 > GPT-4-0613
[2] gpt-3.5-turbo-16k-0613
[3] gpt-4-0613
[4] gpt-4-0314
[5] 評価の揺れも大きいので断言は難しいが。。
[6] ビジネスでは単語単位で訳し方を決めている例は結構ある。単語単位の対訳がある場合、Fugu-MT 論文翻訳(概要): Dictionary-based Phrase-level Prompting of Large Language Models for Machine Translation (fugumt.com)Fugu-MT 論文翻訳(概要): Chain-of-Dictionary Prompting Elicits Translation in Large Language Models (fugumt.com)のような形でLLMに情報を入れる手法が提案されている。
[7] Fugu-MT 論文翻訳(概要): WangLab at MEDIQA-Chat 2023: Clinical Note Generation from Doctor-Patient Conversations using Large Language Models (fugumt.com)をみると入力/出力のペアを与えなくてもICLが有効っぽいので試してみたが、翻訳においては対訳データを与えた方が効果的であった。。
[8] モノリンガルデータでのドメインフィッティングのような動きかなーという気はしないでもない。なお、訳文のみでは微妙に商用APIのスコアに及ばないのでゼロショット設定では特化型の翻訳モデル、文体を変えたい場合はLLM+訳文のみのICLと使い分けるのが良いのではないかと思う。
[9] と思っている人はとても多いと思うが、作るのは大変。。。
[10] 問題が無いとは言っていない

その他

OpenAI APIがアップデートされたので性能を評価してみた。GPT-4について性能が落ちていそうに見えるのはとても意外だった(検証に色々雑な部分があり詳細検討は必須、結論ではない)

翻訳結果のみの参照でも機械翻訳性能が向上したことも興味深かった。文体の参照が効いているのではないかと思っているが詳細を分析してみたいところ。ビジネスの場では重要な性質のように思える[8]。

色々見ていて思うが機械翻訳以外を含めて標準的な日本語ベンチマークが欲しい。英語・中国語ではデータセットやベンチマークの整備が進んでいて多様な評価軸でオープンなLLMを含め様々なモデルを評価できるようになっている[10]。完璧でなかったとしても性能評価は重要で日本語(とクロスリンガルで日本語を含むもの)についてもベンチマークの整備が必要だと思う[9]。

The Pileの構成(なぜCerebras-GPTで日本語が使えるのか?)

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)

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は「英語→日本語での単語選択への貢献」「日本語のスタイル(常体・敬体など)への貢献」など様々な側面があるはずでその辺りも分けて検証したいところ。