第2章. モデル・重み・トークナイザ

この章の目的

この章では、LLM（大規模言語モデル）を理解する上で不可欠な「モデル」という言葉が指す多様な意味を明確にし、その構成要素である「重み」「トークナイザ」といった主要な概念を深く掘り下げます。特に、これらの用語がどのように関連し、LLMの機能に貢献しているのかを初心者から中級者までが理解できるよう解説します。

この章で覚えるべきこと

LLMにおける「モデル」の多義性を理解し、文脈に応じて適切に解釈できるようになる。
architecture、weights、parameters、checkpointといった概念の違いと関係性を説明できるようになる。
tokenizerとvocabularyの役割を理解し、テキスト処理における重要性を説明できるようになる。
context lengthとembeddingがLLMの性能にどのように影響するかを説明できるようになる。

導入

「モデル」という言葉は、LLMの世界では非常に多くの意味で使われます。例えば、「GPT-3モデル」と言えば、特定の性能を持つAIを指すこともあれば、そのAIの内部構造や学習済みのデータそのものを指すこともあります。この多義性は、特に学習を始めたばかりの皆さんを混乱させる原因となりがちです。

しかし、ご安心ください。この章を読み終える頃には、「モデル」という言葉が指す具体的な要素、そしてそれらがどのように組み合わさってLLMを形成しているのかを明確に理解できるようになるでしょう。本章では、LLMの「脳」と「言葉の理解」を司る主要な構成要素に焦点を当て、その仕組みを解説していきます。

基本概念

LLMの「モデル」を構成する主要な要素は、大きく分けて「構造（architecture）」と「学習結果（weights/parameters）」、そして「言語処理の入り口（tokenizer）」の3つに分類できます。

1. architecture (アーキテクチャ)

ひとことで言うと: LLMの骨格となる設計図。何のカテゴリか: モデルの構造、設計思想。何に使うのか: モデルがどのように情報を処理し、学習するかを定義する。代表例: Transformer、BERT、GPTシリーズの基本構造。よく混同される用語: weights（重み）、checkpoint（チェックポイント）。初心者向け注意点: architectureは「何を学習したか」ではなく「どのように学習するか」を決めるものです。

LLMのarchitectureは、モデルの内部構造、つまりニューラルネットワークの層の数、各層の種類（例: 注意機構、フィードフォワードネットワーク）、それらの接続方法などを定めた「設計図」です。例えば、Transformerというarchitectureは、現在の多くのLLMの基盤となっています。この設計図自体には、まだ具体的な知識は含まれていません。

2. weights (重み) / parameters (パラメータ)

ひとことで言うと: architectureが学習によって獲得した知識や経験。何のカテゴリか: モデルの学習結果、数値データ。何に使うのか: 入力データに対してどのような出力を生成するかを決定する。代表例: model.bin、.safetensorsといったファイルに保存された数値の集合。よく混同される用語: architecture（アーキテクチャ）、model（モデル）。初心者向け注意点: weightsとparametersはほぼ同義で使われますが、厳密にはparametersは重みだけでなくバイアス項なども含む広義の概念です。

weights（重み）やparameters（パラメータ）は、architectureという骨格に肉付けされた「知識」そのものです。これらは、モデルが大量のテキストデータから学習した結果として得られる膨大な数の数値の集合体です。これらの数値が、入力されたテキストをどのように解釈し、次の単語を予測するかを決定します。

$$ \text{output} = f(\text{input}, \mathbf{W}) $$

ここで、$f$はarchitectureによって定義される関数、$\text{input}$は入力データ、$\mathbf{W}$は重み（parameters）の集合を表します。この$\mathbf{W}$が、モデルの「知性」の源です。

3. checkpoint (チェックポイント)

ひとことで言うと: 特定の学習段階におけるモデルの状態（architectureとweightsの組み合わせ）。何のカテゴリか: モデルの保存形式。何に使うのか: 学習の再開、異なる環境でのモデル利用、モデルのバージョン管理。代表例: pytorch_model.bin、model.safetensorsなどのファイル群。よく混同される用語: weights（重み）、model（モデル）。初心者向け注意点: checkpointは、architectureとweightsの両方、またはそれらを復元するための情報を含んでいます。

checkpointは、学習途中の特定の時点や学習完了後のモデルの状態を保存したものです。これには通常、モデルのarchitectureを再構築するための情報と、その時点でのweightsが含まれます。これにより、学習を中断した場所から再開したり、学習済みのモデルを他の環境で利用したりすることが可能になります。

graph TD
    A["LLM開発プロセス"] --> B["Architecture設計"]
    B --> C["データ収集・前処理"]
    C --> D["モデル学習"]
    D -- "定期的に保存" --> E["Checkpoint (学習途中)"]
    D -- "学習完了" --> F["Checkpoint (最終モデル)"]
    F --> G["モデルデプロイ"]
    E --> D
    subgraph "Checkpointの内容"
            F
            F
    end

この図は、LLM開発プロセスにおけるcheckpointの位置づけと、その内容を示しています。checkpointは、architectureとweightsをセットで保存することで、モデルの状態を完全に再現可能にします。

4. tokenizer (トークナイザ)

ひとことで言うと: 人間の言葉をモデルが理解できる数値の列に変換する道具。何のカテゴリか: 自然言語処理の前処理ツール。何に使うのか: テキストをモデルの入力形式に変換し、モデルの出力を人間に読める形式に戻す。代表例: SentencePiece、Byte-Pair Encoding (BPE) を利用したトークナイザ。よく混同される用語: vocabulary（語彙）。初心者向け注意点: トークナイザはモデルとセットで使うことがほとんどです。異なるモデルには異なるトークナイザが必要です。

tokenizerは、人間が話す自然言語（テキスト）を、LLMが処理できる数値の列（トークンID）に変換する役割を担います。例えば、「こんにちは、世界！」という文を、[101, 7592, 1234, 2088, 5678, 102]のような数値の列に変換します（実際の値はトークナイザによって異なります）。この逆の変換（数値列からテキストへの復元）も行います。

5. vocab (ボキャブラリ)

ひとことで言うと: トークナイザが知っている単語や文字のリストと、それに対応する数値IDの対応表。何のカテゴリか: トークナイザの構成要素。何に使うのか: テキストをトークンIDに変換する際の辞書として機能する。代表例: vocab.txt、tokenizer.jsonなどのファイルに含まれる単語とIDのペア。よく混同される用語: tokenizer（トークナイザ）。初心者向け注意点: vocabularyはトークナイザの一部であり、トークナイザがテキストをトークンに分割する際の「辞書」です。

vocab（ボキャブラリ）は、tokenizerが使用する「単語（または単語の一部、文字）と、それに対応する一意の数値ID」の対応表です。このリストにない単語は、通常「未知のトークン」（UNKトークン）として処理されます。

6. context length (コンテキスト長)

ひとことで言うと: モデルが一度に処理できるテキストの最大量。何のカテゴリか: モデルの制約、性能指標。何に使うのか: モデルがどれくらいの長さの情報を記憶し、参照できるかを決定する。代表例: 2048トークン、4096トークン、32768トークンなど。よく混同される用語: モデルの学習データ量。初心者向け注意点: コンテキスト長が長いほど、より長い文章の理解や生成が可能になりますが、計算コストも増加します。

context length（コンテキスト長）は、LLMが一度に考慮できる入力テキストの最大トークン数です。これを超えると、モデルはそれ以前の情報を「忘れて」しまいます。例えば、コンテキスト長が4096トークンのモデルは、4096トークンを超える入力があった場合、最初の部分を切り捨てるか、エラーを発生させるか、スライディングウィンドウ方式で処理します。

7. embedding (埋め込み)

ひとことで言うと: 単語や文の意味を数値ベクトルで表現したもの。何のカテゴリか: 意味表現、特徴量。何に使うのか: モデルが単語の意味的な関係性を理解し、計算できるようにする。代表例: Word2Vec、GloVe、Transformerモデルの内部表現。よく混同される用語: トークンID。初心者向け注意点: embeddingは単なるIDではなく、意味的な情報を持った高次元の数値ベクトルです。

embedding（埋め込み）は、単語や文といった言語要素を、意味的な情報を持った高次元の数値ベクトルに変換したものです。例えば、「王様」と「女王」のembeddingベクトルは、互いに近い位置に配置され、「リンゴ」とは遠い位置に配置されるなど、単語間の意味的な関係性を数値的に表現します。LLMは、このembedding表現を用いてテキストを処理します。

$$ \text{Embedding}(\text{word}) = \mathbf{v}_{\text{word}} \in \mathbb{R}^d $$

ここで、$\text{Embedding}(\text{word})$は単語の埋め込みベクトルを生成する関数、$\mathbf{v}_{\text{word}}$はその単語に対応する$d$次元のベクトルです。このベクトル空間では、意味的に近い単語ほどベクトル間の距離が近くなります。

具体例

LLMの利用シナリオを通じて、これらの概念がどのように連携するかを見てみましょう。

graph TD
    A[ユーザーの入力テキスト] --> B(Tokenizer)
    B --> C{Vocabulary}
    C --> D[トークンIDの列]
    D --> E[Embedding層]
    E --> F[Embeddingベクトル]
    F --> G(Architecture)
    G --> H{"Weights / Parameters"}
    H --> I["モデルの出力 (次のトークンID)"]
    I --> J(Tokenizer)
    J --> K[生成されたテキスト]

    subgraph "LLMの内部"
        G
        H
        E
    end
    subgraph "言語処理の入り口・出口"
        B
        C
        D
        J
    end

ユーザーの入力: 「今日の天気は？」
Tokenizerによる処理: tokenizerがこのテキストをvocabularyを参照しながら、[101, 1234, 5678, 9012, 102]のようなトークンIDの列に変換します。
Embedding: これらのトークンIDは、モデルのembedding層に入力され、それぞれのトークンに対応するembeddingベクトルに変換されます。これにより、モデルは単語の意味を数値的に理解できるようになります。
ArchitectureとWeightsによる推論: embeddingベクトルは、architecture（例: Transformer）によって定義された構造を通り、weights（学習済みの知識）を使って計算されます。このプロセスで、モデルは入力された文脈を理解し、次に続く可能性のある単語（トークン）を予測します。
モデルの出力: モデルは、次に続くトークンのトークンIDを出力します。例えば、「晴れ」に対応するIDかもしれません。
Tokenizerによる復元: 出力されたトークンIDは、再びtokenizerによって人間に読めるテキスト「晴れ」に変換され、ユーザーに提示されます。

この一連の流れの中で、context lengthは、モデルが「今日の天気は？」という文脈全体をどれだけ長く記憶し、その後の予測に利用できるかを決定します。

よく混同される用語との比較

モデル名 vs 重みファイル

特徴	モデル名 (例: GPT-3, Llama 2)	重みファイル (例: `model.safetensors`)
ひとことで言うと	特定の`architecture`と`weights`の組み合わせに与えられたブランド名。	`architecture`が学習によって獲得した知識（数値データ）そのもの。
内容	`architecture`の設計思想、`weights`の学習データや学習方法、性能、バージョンなどを含む包括的な概念。	モデルの各層の接続強度を示す膨大な数値の集合。
実体	概念的な名称、または特定の`checkpoint`を指す。	物理的なファイル（通常は数GB〜数百GB）。
役割	モデルの識別、性能や特徴の伝達。	モデルが推論を行うための具体的なデータ。
例	「Llama 2 7B」は、Meta社が開発した70億パラメータを持つモデル。	Llama 2 7Bの`weights`が保存された`.safetensors`ファイル。
関係	モデル名が指す実体の一部が重みファイル。	重みファイルはモデル名が指すAIの「脳」そのもの。

tokenizer vs vocabulary

特徴	Tokenizer (トークナイザ)	Vocabulary (ボキャブラリ)
ひとことで言うと	テキストをトークンIDに変換・復元する「道具」または「機能」。	トークンとIDの対応関係を定義した「辞書」。
内容	テキスト分割のルール（BPEなど）、`vocabulary`、特殊トークン情報など。	トークン（単語、サブワード、文字）と、それに対応する一意の数値IDのリスト。
実体	プログラムコード、設定ファイル、`vocabulary`ファイルを含むパッケージ。	通常はテキストファイルやJSONファイルとして保存される。
役割	自然言語とモデルの間の橋渡し。	トークナイザがテキストを数値に変換する際の参照元。
例	`transformers`ライブラリの`AutoTokenizer`クラス。	`vocab.txt`や`tokenizer.json`に含まれる`{"hello": 1234, "world": 5678}`のような対応表。
関係	トークナイザはボキャブラリを「利用する」。	ボキャブラリはトークナイザの「構成要素」の一つ。

parameter数 vs 実行メモリ

特徴	Parameter数 (パラメータ数)	実行メモリ (RAM/VRAM)
ひとことで言うと	モデルの「大きさ」や「複雑さ」を示す指標。	モデルを動かすために必要なコンピュータの記憶領域。
内容	モデルの`weights`や`biases`の総数。	モデルの`weights`、`embedding`、中間計算結果、`context`などを保持する領域。
単位	億、兆 (例: 7B, 13B, 70B)	GB (ギガバイト)
影響	多いほど表現力が高まる傾向があるが、学習・推論コストも増大する。	不足するとモデルが動作しない、または処理が非常に遅くなる。
関係	パラメータ数が多いほど、それを保持するための実行メモリも多く必要になる。	実行メモリは、パラメータ数だけでなく、`context length`やバッチサイズにも依存する。
計算例	7B (70億) パラメータのモデルをFP16で動かす場合: $7 \times 10^9 \times 2 \text{ bytes} \approx 14 \text{ GB}$	14GBのVRAMを持つGPUが必要。さらに中間計算や`context`で追加のメモリが必要。

実務での位置づけ

これらの概念は、LLMを実際に利用したり、開発したりする上で非常に重要です。

graph TD
    A["LLMの利用・開発"] --> B["モデルの選択"]
    A --> C["リソースの見積もり"]
    A --> D["性能チューニング"]
    A --> E["モデルのカスタマイズ"]

    B -- "依存" --> B1["Architecture特性"]
    B -- "依存" --> B2["Weightsの学習データ"]

    C -- "考慮" --> C1["Parameter数"]
    C -- "考慮" --> C2["Context Length"]
    C -- "考慮" --> C3["データ型 (FP16/FP8など)"]

    D -- "影響" --> D1["Tokenizerの選択"]
    D -- "影響" --> D2["Tokenizer設定"]

    E -- "基盤" --> E1["既存Checkpoint"]
    E -- "手法" --> E2["ファインチューニング"]

    subgraph "主要概念"
        B1
        B2
        C1
        C2
        C3
        D1
        D2
        E1
        E2
    end

この図は、LLMの利用や開発において、各概念がどのように実務上の意思決定に影響するかを示しています。

モデルの選択: どの「モデル」（例: Llama 2 7B、Mistral 7B）を選ぶかは、そのarchitectureの特性とweightsの学習データに依存します。
リソースの見積もり: parameter数とcontext lengthは、モデルを実行するために必要なGPUメモリ（VRAM）や計算リソースを見積もる上で不可欠です。
性能チューニング: tokenizerの選択や設定は、モデルの入力処理の効率性や、特定の言語・タスクにおける性能に大きく影響します。
モデルのカスタマイズ: 既存のcheckpointを基に、追加の学習（ファインチューニング）を行うことで、特定のタスクに特化したモデルを作成できます。

これらの要素を理解することで、単にLLMを使うだけでなく、その挙動を深く理解し、目的に応じて最適化できるようになります。

まとめ

3行まとめ

LLMの「モデル」は、architecture（設計図）とweights（学習結果）の組み合わせであり、checkpointとして保存される。
tokenizerとvocabularyは、人間が話す言葉をモデルが理解できる数値に変換し、その逆も行う言語処理の要である。
parameter数、context length、embeddingは、モデルの性能、リソース要件、そして意味理解の深さに直結する重要な概念である。

混同しやすい用語

モデル名と重みファイル: モデル名はブランド、重みファイルは中身。
TokenizerとVocabulary: トークナイザは道具、ボキャブラリは辞書。
Parameter数と実行メモリ: パラメータ数はモデルの大きさ、実行メモリはそれを動かすための容量。

次に読むべき章

第3章: LLMの学習プロセスとファインチューニング (この章で学んだweightsがどのように形成され、checkpointがどのように活用されるかをさらに深く掘り下げます。)