SentencePiece語彙管理（センテンスピース ゴイカンリ）

SentencePiece語彙管理とは

SentencePiece語彙管理は、トークナイザーが保持するサブワード語彙の構築・分析・最適化に関する一連のプラクティスを指す。語彙サイズの選定、特殊トークンの設計、多言語モデルにおける言語間バランスの調整、そして学習済み語彙の品質評価が含まれる。LLMの性能はトークナイザーの語彙品質に大きく依存するため、適切な語彙管理は不可欠である。

語彙ファイルの構造

SentencePieceの学習により出力される.vocabファイルは、タブ区切りのテキスト形式で以下の構造を持つ：

<unk>	0
<s>	0
</s>	0
▁the	-2.3456
▁a	-3.4567
▁is	-3.7891
ing	-4.1234
▁機械	-8.9012
学習	-9.0123

各行は「サブワード（タブ）ログ確率」の形式で、確率が高い（値が0に近い）サブワードほど頻出する基本的なトークンである。

語彙サイズの設計指針

モデル規模と語彙サイズの関係

実例：主要モデルの語彙サイズ推移

2024年以降、語彙サイズは拡大傾向にある。これはモデルパラメータの増大により埋め込み層のコストが相対的に小さくなり、語彙拡張によるトークン効率改善のメリットが上回るためである。

語彙の分析手法

Python APIによる語彙探索

import sentencepiece as spm

sp = spm.SentencePieceProcessor()
sp.load('model.model')

# 語彙サイズの確認
print(f'語彙サイズ: {sp.get_piece_size()}')

# 特定トークンの確認
print(f'ID→トークン: {sp.id_to_piece(100)}')
print(f'トークン→ID: {sp.piece_to_id("▁the")}')

# トークンのスコア（ログ確率）
print(f'スコア: {sp.get_score(100)}')

# 特殊トークンの確認
print(f'UNK ID: {sp.unk_id()}')
print(f'BOS ID: {sp.bos_id()}')
print(f'EOS ID: {sp.eos_id()}')
print(f'PAD ID: {sp.pad_id()}')

語彙カバレッジの評価

テスト用コーパスに対する語彙のカバレッジを以下の指標で評価できる：

def evaluate_vocabulary(sp, test_corpus_path):
    total_chars = 0
    total_tokens = 0
    unk_count = 0
    used_ids = set()

    with open(test_corpus_path, 'r') as f:
        for line in f:
            line = line.strip()
            total_chars += len(line)
            ids = sp.encode(line, out_type=int)
            total_tokens += len(ids)
            unk_count += ids.count(sp.unk_id())
            used_ids.update(ids)

    return {
        'token_char_ratio': total_tokens / total_chars,
        'unk_rate': unk_count / total_tokens,
        'vocab_utilization': len(used_ids) / sp.get_piece_size(),
        'avg_token_length': total_chars / total_tokens,
    }

多言語語彙のバランス調整

多言語モデルでは、リソース量の異なる言語間で語彙のバランスを取ることが重要な課題である。

Fertility（トークン増殖率）

各言語のテキストがトークン化後にどの程度膨張するかを示す指標：

LLaMA 2の32K語彙では日本語テキストが英語の3.2倍にトークン膨張していたが、LLaMA 3の128K語彙では1.5倍に改善された。Gemmaの256K語彙ではさらに1.2倍まで圧縮されている。

語彙バランスの改善手法

• Temperature sampling：P(lang) ∝ size(lang)^α（α=0.3〜0.7）で低リソース言語のサンプリング比率を上げる
• 語彙予算の言語別割り当て：事前に各言語の語彙数を設定
• 段階的学習：まず高リソース言語で基本語彙を学習し、低リソース言語の固有トークンを追加

特殊トークンの設計パターン

チャットモデル向け

<|begin_of_text|>     # テキスト開始
<|start_header_id|>   # ヘッダー開始（system/user/assistant）
<|end_header_id|>     # ヘッダー終了
<|eot_id|>            # ターン終了
<|end_of_text|>       # テキスト終了

コード生成モデル向け

<|fim_prefix|>   # Fill-in-the-Middle 接頭辞
<|fim_middle|>   # Fill-in-the-Middle 中間
<|fim_suffix|>   # Fill-in-the-Middle 接尾辞
<|file_sep|>     # ファイル区切り

これらはSentencePieceトレーナーのuser_defined_symbolsまたはcontrol_symbolsで予約する。

よくある質問（FAQ）

Q1: 語彙サイズを大きくすると推論速度は遅くなりますか？

A: 語彙サイズの増加は埋め込み層と出力層の行列サイズに影響するが、Transformerの注意機構のコストと比較すると影響は軽微である。32Kから128Kへの拡大でメモリ使用量は約300MB増加するが、トークン数の削減により実効的な推論速度は向上することが多い。

Q2: 学習済みモデルの語彙を事後的に縮小できますか？

A: 語彙の縮小（Vocabulary Pruning）は技術的に可能だが、対応する埋め込みの再学習が必要で実用的でない。代わりに、不要トークンの埋め込みをゼロベクトルに置換し、トークナイザー側で使用不可にする方法が取られることがある。

Q3: 複数のSentencePieceモデルを統合する方法はありますか？

A: 直接的な統合APIは存在しない。実務上は各モデルの.vocabファイルからトークンリストを抽出し、統合コーパスから新しいモデルを再学習するのが標準的なアプローチである。HuggingFace TokenizersのBPE実装では部分的な語彙マージが可能。

まとめ

• 語彙管理はLLMの性能に直結する重要な設計要素
• 語彙サイズは2024年以降拡大傾向（32K→128K→256K）
• 多言語モデルではFertility（トークン増殖率）の監視が必須
• byte_fallbackによりUNK率ゼロを保証するのが現代の標準
• 特殊トークンの設計はモデルの用途（チャット/コード/翻訳）に応じて決定
• 語彙カバレッジの定期的な評価と改善が品質維持に不可欠