この回のゴール
- LLM が扱う最小単位「トークン」を理解する
- BPE (Byte-Pair Encoding) など現代のサブワード分割の考え方を知る
- 「1 トークン ≈ 1 単語」ではないことを体感する
- 日本語と英語でトークン効率がなぜ違うか を理解する(API 料金にも直結)
1. なぜトークン化が必要か
前章の N-gram は「スペース区切り」で単語を扱いました。でも実用上:
- 英語:
"running"と"run"を別モノと扱うと語彙が爆発 - 日本語: そもそもスペースが無い
- 未知語 (
COVID-19、絵文字、URL): 事前に語彙に入れられない
👉 だから サブワード分割(単語より小さい単位)が必要。
2. トークン化の段階
| 粒度 | 単位 | 例: "unbelievable" | 問題 |
|---|---|---|---|
| 文字 | 1 文字 | u-n-b-e-l-i-e-v-a-b-l-e | 系列が長すぎる |
| 単語 | 1 単語 | unbelievable | 未知語・活用に弱い |
| サブワード | 部分単語 | un-believ-able | 🎯 ちょうど良い |
LLM は サブワード分割 を採用しています。
3. BPE (Byte-Pair Encoding) の仕組み
GPT/Claude 系で使われる主要なアルゴリズム。直感は「よく出るペアを 1 つの記号にまとめていく」。
学習アルゴリズム(簡略版)
TOOLS = [{"name": "...", "input_schema": {...}}]
TOOL_FUNCS = {"...": lambda: ...}
例: "low lower lowest"
- 初期:
l o w,l o w e r,l o w e s t - ペア
l oが最頻出 → 1 トークンに:lo w,lo w e r,lo w e s t - 次に
lo w→low, ...
結果として よく使われる単位 が 1 トークンになり、珍しい単語は複数トークン になる。
4. トークン効率 — 日本語が「損」する理由
Claude / GPT 系のトークナイザは主に 英語コーパス で学習されています。その結果:
| 言語 | 文字数 | トークン数 | 1 トークンあたり文字 |
|---|---|---|---|
| 英語 "Hello, how are you?" | 20 | 6 | 3.3 |
| 日本語 「こんにちは、元気ですか?」 | 13 | ~12 | 1.1 |
日本語は英語の約 3 倍のトークンを消費 → API 料金も約 3 倍。
これは現代 LLM の重要な実務知識です。
5. 特殊トークン
LLM では 意味を持つ特殊トークン がいくつか予約されています:
| 役割 | 例 |
|---|---|
| 文頭/文末 | <s>, </s>, <\|endoftext\|> |
| パディング | <pad> |
| 未知 | <unk> |
| チャット区切り | <\|im_start\|>, <\|assistant\|> |
チャットモデル (ChatGPT, Claude) では 会話の役割 も特殊トークンで区切られています。
まとめ
- トークン化 = 文字列を モデルが扱える単位 に分割する処理
- 現代の LLM は BPE / SentencePiece など サブワード分割 を採用
- 日本語は英語の約 3 倍のトークンを消費 → API 料金 3 倍
- 「1 トークン = 1 単語」ではない(英語でも単語が複数トークンになる)
この回の限界(次への動機)
トークン化したら、ID は単なる数字。意味の近さ・遠さは数字 ID から読み取れない。 👉 次回「埋め込みベクトル」では、トークン ID を 意味を持つ密ベクトル に変換します。
参考文献
- Sennrich et al. (2016) Neural Machine Translation of Rare Words with Subword Units — BPE 論文
- OpenAI Tokenizer — 公式可視化ツール
- tiktoken: OpenAI 公式トークナイザライブラリ