日本語LLMの"1トークン"は何文字相当なのか?
TR:TL
- 最近、日本語のLLMが続々公開されているが、各LLMが何文字まで生成可能なのかを知りたい。
- Rakudaのデータで各LLMのトークナイザーの「1トークンあたりの文字数」を調べた。
- 標準的な日本語特化のLLMでは2.0~2.6文字/トークン程度、一方で、GPT-4/3.50.96文字/トークン程度。
背景
最近、日本語でも使えるLLMが続々と公開されています。特に、GPT-3.5-turboやGPT-4は、8192トークンという大きい最大トークン長を誇っています。一方で、LINEのjapanese-large-lmなどの2023年時点で公開されている公開されている日本語LLMの多くは、2048トークンが最大トークン数になっている場合が多いです。額面上、LINEのLLMは、OpenAI GPT-3.5の1/4の長さのテキスしか生成できないように見えますが、それぞれのトークナイザーは異なる語彙を持っているので、実際に生成できるテキストはもっと長いはずです。では、公開されている日本語LLMは実際何文字のテキストを生成できるのでしょうか？
この記事では、RakudaというLLMのリーダーボードデータを用いて日本語LLMのトークナイザーの1トークンが平均何文字に相当するのかを調べてました。
実験
大まかにな流れはかなりシンプルです。
- 評価対象のLLMのトークナイザーをHugging Facse Hubからダウンロード
- Rukuda-questionsの40件のテキストをトークナイズ
- 各テキストのトークン数と文字数の比を計算する
詳しくはこのgistをご覧ください。
データセット: Rakuda-question
この実験では、jrank: Ranking Japanese LLMsで使われているyuzuai/rakuda-questionsの質問文をトークナイズの対象としています。件数として40件とかなりコンパクトなデータセットです。LLMを実際に使うユースケースに比較的近いと想定されるので、このデータを評価データに選びました。
評価対象のLLM
下記のLLMのトークナイザーを使用しました。
Open AI (tiktokenを使用)
- cl100k_base: gpt-4, gpt-3.5-turbo, text-embedding-ada-002
- p50k_base: Codex models, text-davinci-002, text-davinci-003
- r50k_base: GPT-3 models like davinci, GPT2
Hugging Facaで公開さているLLM
decoder-onlyモデル以外にもencoder, encoder-decoder, テキスト埋め込みモデルのトークナイザーを評価しています。
- line-corporation/japanese-large-lm-3.6b
- rinna/japanese-gpt-neox-3.6b
- rinna/bilingual-gpt-neox-4b
- cyberagent/open-calm-7b
- stockmark/gpt-neox-japanese-1.4b
- abeja/gpt-neox-japanese-2.7b
- matsuo-lab/weblab-10b
- retrieva-jp/t5-large-long
- elyza/ELYZA-japanese-Llama-2-7b
- elyza/ELYZA-japanese-Llama-2-7b-fast
- cl-tohoku/bert-base-japanese-v3
- pkshatech/GLuCoSE-base-ja : 日本語文埋め込みモデル. トークナイザーはstudio-ousia/luke-japanese-base-lite
- [intfloat/multilingual-e5-large].(https://huggingface.co/intfloat/multilingual-e5-large): 日本語を含む多言語文埋め込みモデル
結果・考察
各トークナイザーの1トークンあたりの文字数のboxプロット.サンプル数40. 緑の△は平均値を表している
40サンプルのテキストをトークナイズしたときの、1トークンあたりの平均文字数
| モデル | 1トークンあたりの平均文字数 |
|---|---|
| OpenAI/cl100k_base(GPT4/3.5 etc.) | 0.96 |
| OpenAI/p50k_base(davinci-003 etc.) | 0.64 |
| OpenAI/r50k_base(davinci,GPT2) | 0.64 |
| line-corporation/japanese-large-lm-3.6b | 2.3 |
| rinna/japanese-gpt-neox-3.6b | 2.07 |
| rinna/bilingual-gpt-neox-4b | 2.16 |
| cyberagent/open-calm-7b | 2.62 |
| stockmark/gpt-neox-japanese-1.4b | 2.64 |
| abeja/gpt-neox-japanese-2.7b | 1.58 |
| matsuo-lab/weblab-10b | 0.93 |
| retrieva-jp/t5-large-long | 2.18 |
| elyza/ELYZA-japanese-Llama-2-7b | 0.78 |
| elyza/ELYZA-japanese-Llama-2-7b-fast | 1.63 |
| cl-tohoku/bert-base-japanese-v3 | 1.47 |
| pkshatech/GLuCoSE-base-ja | 2.18 |
| intfloat/multilingual-e5-large | 1.77 |
OpenAIのモデルの1トークン数あたりの文字数が1.0文字を下回ったのに対して、LINEやRinna, CyberAgentなどの日本語特化のLLMでは1トークン数あたりの文字数が2.0を上回りました(一部例外もあります)。
また、Llama 2を日本語データで追加学習したELYZA-japanese-Llama-2-7b は本家のLlama 2と同じく0.78文字/トークンというかなり数値を出していましたが、日本語トークンを追加したELYZA-japanese-Llama-2-7b-fastでは、1.63文字/トークンとかなり数値上の改善が見られています。
簡単な考察・感想
まず、GPT-3.5-turbo/4に比べて、日本語特化のLLMのトークン数あたりの文字数が大きかったです。日本語に特化しているので当たり前ですね。標準的な日本語トークナイザーであれば2.0~2.6トークンくらいであるという数値が得られたのですが、一部の日本語トークナイザーでは2.0を下回る数値が出ており、詳細が少し気になりました。特に、cl-tohoku/bert-base-japanese-v3ではMeCabによる形態素解析がsubword分割の前段で行われており、その影響で1トークンあたりの文字数が下がったのではないかと考察できます。
ELYZAのELYZA-japanese-Llama-2-7b-fastは、Llama-2を日本語データで追加学習・語彙追加するというアプローチで学習されていますが、1トークン数あたりの文字数2倍程度に増加していました。語彙追加は、非日本語LLMを日本語で使うのにトークナイザーの観点で有効なアプローチであるようです。
最後に、GPT-3.5-turbo/4の8192トークンに日本語特化LLMが勝てるのか?を考えてみます。GPT-3.5-turbo/4は今回の結果から、8192*0.96=7864.32[文字]が、入力・生成できる文字数上限の期待値ということになります。今回、最大トークン数が2048であった日本語LLMの中で最も文字数/トークンが大きかったcyberagent/open-calm-7bの入力・生成できる文字数上限の期待値は2048*2.62=5365.76[文字]でした。また、ELYZA-japanese-Llama-2-7b-fastは、Llamma-2ベースのモデルなので4096トークンまで入力可能で最大入力可能文字数は4096*1.63=6676.48[文字]でした。意外と健闘していますが、いまのところ(2023/9/16現在)日本語LLMが扱える文字数はOpenAIに及ばないとい結果になりました。今後の日本語LLMの進展に期待です。
Discussion