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 shot | 29.0 | 29.4 | – |
| OpenICL / TopkRetriever / 3 shot | 34.9 | 33.3 | 34.9 |
| OpenICL / TopkRetriever / 3 shot（日本語のみ） ※ 訳文のみを例示 | 31.3 | – | – |
| OpenICL / TopkRetriever / 5 shot（日本語のみ） ※ 上記同様 | 31.6 | – | – |
※ 前回結果は「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]。
0 Comments.