Tokenizerは、あなたがモデルに送った文が最初に通る部品で、理解を担当するのではなく、分割と番号付けだけを行います。テキストが大規模モデルに入る前に、Tokenizerはそれをtokenに切り分け、語彙表の番号に置き換えます。モデルが実際に読むのは、その番号の列です。ここが分かると、多くの疑問が解けます。tokenは文字でも単語でもありません。
切っているのは文字ではなく、出現頻度
現在主流のTokenizerの多くは、BPE(バイト対符号化)と呼ばれるアルゴリズムを使っています。学習の段階で、どの文字の組み合わせが一緒によく現れるかを数え、頻度が高い組み合わせほど、まるごと1つのtokenにまとめられやすくなります。その結果、よくある単語や部分語はひとかたまりのまま残りやすく、英語の単語1つが1 tokenになることも珍しくありません。一方、珍しい単語や人名、新語は細かく割れ、1語が3〜4個に分かれることもよくあります。
空白、句読点、数字、コードも分割の対象で、規則は直感的ではありません。英語では単語の前の空白が単語と一緒に同じtokenに含まれることが多く、改行や数字の並び、インデントされたコードはそれぞれ別に扱われます。つまり、同じ内容でも書式を変えるだけでtoken数が変わることがあります。
同じ文なのに、モデルが違うと数が合わない理由
モデルの語彙表はそれぞれ別々に学習されており、大きさも、結合の規則も、得意な言語も異なります。語彙表が大きいほど、長い断片をまるごと残せることが多い。中国語のカバーが良い語彙表では漢字1字が1 tokenで済む一方、カバーが悪いと1字がバイト単位の複数のtokenに割れてしまいます。
これがタイトルの疑問への答えです。目安として、英語では1 tokenがおよそ3〜4文字に相当します。中国語はばらつきがずっと大きく、1字で1 tokenはよくある話で、2個以上になっても不思議ではなく、どのモデルか次第です。Aモデルの数え方でBモデルの消費量を見積もって合わなくても、それが普通で、どちらのモデルが数え間違えたわけでもありません。
token数は実際のコストにも直結します。従量課金では、入力も出力も多くはtoken単位で計算されます。コンテキストウィンドウの上限や、一度に入る会話履歴の量もtokenで数え、生成すべきtokenが多いほど、返答はたいてい遅くなります。ナレッジベースを作るときはさらに顕著で、RAGとは何か?ファインチューニングやプロンプトエンジニアリングとの違いで触れた文書のチャンク分割も、文字数ではなくtokenで数えます。チャンクが大きすぎればウィンドウを無駄にし、小さすぎれば意味が途中で切れてしまいます。
よくある3つの計算違い
1つ目は、文字数から直接費用を見積もることです。文字数とtoken数に固定の換算はなく、英語・中国語・コードが混ざるとずれはさらに大きくなります。文字数ベースの見積もりは低く出がちです。
2つ目は、中国語は必ず安い、あるいは必ず高いと決めつけることです。より正確な言い方はこうです。主流の語彙表の多くでは、同じ内容を言うのに中国語は英語より多くのtokenを消費しがちです。英語の常用語はひとかたまりで当たりやすく、中国語は割れやすいからです。ただし絶対ではなく、中国語に最適化された語彙表に変えれば差ははっきり縮まります。結論は常に具体的なモデルに結びつけて考える必要があります。
3つ目は、token数をモデルの強さの証拠だと思うことです。同じ文があるモデルでは80 token、別のモデルでは110 tokenだったとしても、それは切り方が違うというだけで、どちらが賢いかとは直接関係ありません。語彙表の設計はトレードオフです。語彙表が大きいと切り方は粗くなりますが、tokenあたりの表現コストは上がります。小さいと細かく切る分、列は長くなります。
Tokenizerにできないこと
Tokenizerはモデルそのものではありません。テキストをどの粒度で入れるかを決めるだけで、意味を理解したり、文が正しいかどうかを判断したりはしません。切り方の良し悪しはモデルの出来に影響し、下手な分割は計算や珍しい単語の理解を難しくしますが、理解と推論は結局モデルのパラメータの仕事です。この2つを分けて考えれば、Tokenizerに過剰な期待をしたり、見当違いな文句を言ったりせずに済みます。
日常の簡単なチェック方法があります。費用と長さを見積もるときは文字数を頭で数えず、使っているモデルに対応したtoken数カウントツールで実際のテキストを一度数えてください。システムプロンプト、会話履歴、出力の余裕も含めて数え、2割ほどの余裕を持たせます。文字数ではなくtokenで予算を組む習慣がつけば、請求額の予想外やコンテキストあふれは、たいてい事前に避けられます。