BPE（Byte Pair Encoding）（バイトペアエンコーディング）
BPE（Byte Pair Encoding）は、テキストをサブワード単位に分割するトークン化アルゴリズムで、GPT系モデルやLLaMA等の大規模言語モデルで標準的に採用されている手法である。
BPE（Byte Pair Encoding）とは
BPE（Byte Pair Encoding）は、テキストを効率的にサブワード単位へ分割するトークン化アルゴリズムである。元々は1994年にPhilip Gageがデータ圧縮手法として提案したが、2016年にSennrichらが機械翻訳のサブワード分割に応用し、以降GPT-2/GPT-3/GPT-4oやLLaMA 3.1/3.2、Mistral 7B/8x7Bなど主要LLMの標準トークナイザとして広く採用されている。
アルゴリズムの仕組み
BPEの学習プロセスは以下の手順で進行する：
- 初期化: 訓練コーパス内の全テキストを文字（またはバイト）単位に分解し、初期語彙を構築する
- 頻度カウント: 隣接するトークンペアの出現頻度を集計する
- マージ操作: 最頻出ペアを1つの新トークンとして語彙に追加する
- 反復: 目標語彙サイズに達するまでステップ2-3を繰り返す
- 適用: 学習済みマージルールを未知テキストに順序通り適用してトークン化する
GPT-4oでは約200,000トークンの語彙サイズを使用し、GPT-2の50,257トークンから大幅に拡張されている。語彙サイズの増加により、1トークンあたりの情報量が増え、同一テキストのトークン数が削減される。
主なBPE実装の比較
| 実装 | 採用モデル | 語彙サイズ | 処理速度 | 特徴 |
|---|---|---|---|---|
| tiktoken | GPT-4o / GPT-4 | 200,000 / 100,256 | 3-6x高速（Rust実装） | OpenAI公式・バイトレベルBPE |
| Hugging Face Tokenizers | LLaMA 3 / Mistral | 128,256 / 32,768 | 高速（Rust実装） | 多モデル対応・学習機能あり |
| SentencePiece BPE | LLaMA 2 / Gemma | 32,000 / 256,000 | 中程度（C++実装） | Unigram切替可・言語非依存 |
| Byte-Level BPE | RoBERTa / BLOOM | 50,265 / 250,680 | 高速 | UTF-8バイト単位・OOV不要 |
| MinBPE | 教育用途 | 任意 | 低速（Python） | Andrej Karpathy作・学習用 |
Byte-Level BPEの進化
従来のBPEは文字単位で動作するため、未知文字（漢字、アラビア文字等）に対応できない問題があった。GPT-2で導入されたByte-Level BPE（BBPE）は、テキストをUTF-8のバイト列として扱うことでこの問題を解決した：
- 基本語彙: 256個のバイト値 + 特殊トークン
- OOVゼロ保証: あらゆる言語・記号を256バイト値の組合せで表現可能
- 多言語対応: 日本語・中国語・韓国語等のCJK文字も事前辞書なしでトークン化
- 圧縮効率: 英語で約4文字/トークン、日本語で約1.5-2文字/トークン
GPT-4oのtiktoken（cl200k_base）では、日本語テキストの圧縮効率がGPT-3.5比で約1.5倍改善されており、同じ文章でもより少ないトークンで表現できる。
BPEと他のトークン化手法の比較
| 手法 | 原理 | 語彙構築 | OOV処理 | 主な採用モデル |
|---|---|---|---|---|
| BPE | 最頻出ペアの反復マージ | ボトムアップ | サブワード分割 | GPT系・LLaMA・Mistral |
| WordPiece | 尤度最大化ペアのマージ | ボトムアップ | ##接頭辞分割 | BERT・DistilBERT |
| Unigram LM | 確率最大の分割を選択 | トップダウン（刈込） | 確率的サブワード | T5・mBART・ALBERT |
| 文字単位 | 1文字=1トークン | 不要 | なし（全文字対応） | ByT5・Charformer |
BPEは決定論的にマージ順序が決まるため再現性が高く、実装も比較的シンプルである。一方、Unigram LMは複数の分割候補から確率的に最適な分割を選ぶため、正則化の効果が期待できる。
実装時の注意点と最適化
BPEトークナイザを実務で使う際の重要なポイント：
- 語彙サイズの選定: 小さすぎると1単語が多トークンに分割され推論コスト増加、大きすぎると埋め込み層のパラメータ数が膨張する。32K-128Kが一般的な範囲
- 特殊トークン管理:
<|endoftext|>、<|im_start|>、<|tool_call|>等のモデル固有トークンの追加と管理 - 正規化前処理: Unicode正規化（NFC/NFKC）、空白処理、数字分割等をトークン化前に適用
- キャッシュ戦略: 頻出パターンのトークン化結果をキャッシュし、推論時のレイテンシを削減（tiktokenは内部的にLRUキャッシュを使用）
- 並列処理: HuggingFace Tokenizersは複数テキストの並列トークン化をサポートし、バッチ処理で10-100倍高速化
よくある質問（FAQ）
Q1: BPEの語彙サイズはどのくらいが最適ですか？ A: 用途とモデル規模による。汎用LLMでは50K-200Kが主流で、GPT-4oは200K、LLaMA 3は128Kを採用している。多言語対応が必要な場合は大きめの語彙が有利だが、埋め込み層のメモリコストとのトレードオフがある。
Q2: BPEとWordPieceの実用上の違いは何ですか？ A: BPEは最頻出ペアを貪欲にマージする一方、WordPieceは語彙追加時にコーパス全体の尤度向上を基準にする。結果的にBPEは頻出パターンを優先的に圧縮し、WordPieceはより統計的に最適な分割を目指す。現在の大規模LLMではBPE系が主流。
Q3: 日本語テキストでBPEの圧縮効率が悪いのはなぜですか？ A: 日本語はひらがな・カタカナ・漢字で数千種類の文字があり、Byte-Level BPEでは1文字が2-3バイト（=初期トークン）に分解されるため、英語（1バイト/文字）に比べて圧縮率が低くなる。GPT-4oではCJK対応の語彙拡張により改善されたが、依然として英語比1.5-2倍のトークン数が必要。
まとめ
- BPEは最頻出ペアの反復マージによるサブワードトークン化手法
- GPT-4o（200Kトークン）やLLaMA 3（128K）等の主要LLMで標準採用
- Byte-Level BPEにより多言語OOVゼロを実現
- tiktoken（Rust）やHuggingFace Tokenizers（Rust）による高速実装が利用可能
- 語彙サイズは圧縮効率と埋め込みコストのトレードオフで決定する