小規模でも性能が良いと主張するモデルが次々と発表されている（OSS – arXiv最新論文の紹介 (devneko.jp)）。7Bから8BのモデルはGPU 1つでも実行でき使い勝手が良い。一方で過去の検証では十分な機械翻訳性能を出すことが難しそうである [1]
最新モデルで上記制約が解消しているのか機械翻訳性能を検証してみた。性能評価に使用したデータは以前（DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp)）と同じ。検証環境は環境はColab Pro+を用いた。基本的にfp16で扱っている。
本件の検証では手で回答抽出をする代わりにGPT-4 Turboを用いて回答抽出を行った結果を併記した。評価指標はBLEU、使用したツールやtokenizerは以前と同じ（sacrebleu –tokenize ja-mecab）である。
「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能、「出力そのまま」と「GPT-4で回答抽出」の比較で指示のしやすさをザックリとみる事ができる[2]。
| モデル・条件 | param | 0 shot / 出力そのまま | 0 shot / GPT-4で回答抽出 | 1 shot / 出力そのまま | 1 shot / GPT-4で回答抽出 |
| google/gemma-1.1-7b-it · Hugging Face | 8.54B | 17.1 | 17.1 | 32.5 | 32.2 |
| meta-llama/Meta-Llama-3-8B-Instruct · Hugging Face | 8.03B | 11.9 | 16.2 | 20.6 | 30.2 |
| Qwen/Qwen1.5-7B-Chat · Hugging Face | 7.72B | 17.8 | 17.9 | 18.9 | 19.0 |
| microsoft/Phi-3-mini-128k-instruct · Hugging Face | 3.82B | 12.6 | 12.7 | 20.0 | 20.3 |
| google/recurrentgemma-2b-it · Hugging Face | 2.68B | 7.9 | 8.7 | 20.3 | 20.9 |
| （参考）gpt-3.5-turbo | 27.1 | 26.9 | 37.1 | 37.0 |
より大規模なモデルについても検証を行った。こちらはollamaを用いて検証を行っている。
実は上記表のモデルも当初ollamaを用いて検証を行っていたが性能が悪かった。4bit量子化の影響ではないかと考えている[3]が詳細は不明である。下表の結果もfp16で実行した場合、より良い結果になる可能性がある。
| モデル・条件 | param | 0 shot / 出力そのまま | 0 shot / GPT-4で回答抽出 | 1 shot / 出力そのまま | 1 shot / GPT-4で回答抽出 |
| command-r-plus (ollama.com) | 104B | 27.4 | 29.4 | 37.1 | 36.8 |
| llama3:70b-instruct (ollama.com) | 71B | 17.3 | 16.5 | 21.0 | 32.3 |
| （参考）gpt-3.5-turbo | 27.1 | 26.9 | 37.1 | 37.0 |
結果と結論
Llama 3 8B, Gemma 7Bはパラメータ数の割に機械翻訳性能が高い。特にGemmaは日本語対応、命令の理解共に性能が高い。Llama 3 8B Instructは出力に不要な部分（今から翻訳しますなどのリード文）が出る事が多くそれが見た目のBLEUに影響していた。主たる文章のみを抜き出せば性能は悪くない。日本語を継続学習したバージョンや日本語の命令セットでSFTしたバージョンに期待である。
より小型のPhi-3、reccurent gemma 2Bは実用には厳しそうだが期待のできる結果を出しているように思う。特にreccurent gemmaのように新たなアーキテクチャ[4]には期待大である。機械翻訳ではSSMのような状態を扱えるモデルだと利点が多い。例えば「単語対応の辞書」や「訳調」、「定型文」などを状態に押し込んでおくことで、欲しいスタイルの機械翻訳を実行可能になる。FuguMT ver 2はこのような機能で構築する予定である。
より大規模なモデルとしてはCohereのCommand R+はさすがの性能である[5]。Llama 3 70Bについては量子化の影響を受けていそうなのでfp16での性能を試してみたいところ。
FuguMT ver2（辞書・翻訳スタイル指定可能なLLMベースの機械翻訳モデル）公開に合わせて、これら検証データの最新化やベンチマークの公開もしたい[6]。
脚注
[1] 以前の検証では7Bクラスと14Bクラスで大きな差が出ていた。PaLM2 / ELYZA-japanese-Llama-2-7bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp)
[2] モデルに合わせたプロンプトチューニングは行っていないため、特に後者は本当にザックリとである。
[3] Llama3の量子化の影響についての検証は GitHub – Macaronlin/LLaMA3-Quantization が詳しい。
[4] Fugu-MT 論文翻訳(概要): RecurrentGemma: Moving Past Transformers for Efficient Open Language Models (fugumt.com)、GriffinアーキテクチャFugu-MT 論文翻訳(概要): Griffin: Mixing Gated Linear Recurrences with Local Attention for Efficient Language Models (fugumt.com)
[5] Command R+ (cohere.com)、Introducing Command R+: A Scalable LLM Built for Business (cohere.com)、研究目的用にCC-BY-NC-4.0で公開されている商用モデルであるので当たり前かもしれないが。。
[6] だが、時間の余裕がない状況が続く。既存FuguMTの問題修正もいい加減やりたい。。。