ChatGPT Hands-on Path

このページは、商用 ChatGPT そのものを再現する計算規模の話ではありません。ChatGPT級のLLMシステムが成立するまでに必要な処理を、Mini Transformer Lab で小さく順番に作っていくための導線です。

ここでの「ChatGPTを作る」は、次の3層を分けて進めます。

• Model layer: data pipeline、tokenizer、pretraining、generation、model size / context length。
• Post-training layer: chat template、instruction data、supervised fine-tuning、preference / alignment、safety behavior。
• Product layer: chat runtime、conversation history、RAG、tool use、agent loop、serving、evaluation、logs。

重要な境界があります。この lab は「ChatGPT級の能力を持つモデル」を作るものではありません。小さな実験で、ChatGPT級システムに必要な処理を順番に理解するための教材です。

Stage status

flowchart LR
    DP["data pipeline"] --> T["tokenizer"]
    T --> P["base pretraining"]
    P --> CF["chat format"]
    CF --> SFT["instruction SFT"]
    SFT --> AL["preference / alignment"]
    AL --> CR["chat runtime"]
    CR --> RS["reasoning controller"]
    RS --> RAG["RAG + evaluation"]
    RAG --> TOOLS["tools / agent"]
    TOOLS --> OPS["serving / logs / safety"]

0. セットアップ

Status: Runnable now

対応する処理:

• 実験環境を固定する。
• Python と Node の依存関係を揃える。
• テストで壊れていない状態から始める。

devbox run install
devbox run test
devbox run site

読む場所:

• Foundations
• Base Hands-on

影響:

• 環境差分による失敗を減らす。
• 以降の実験結果を比較しやすくする。

1. data pipeline を小さく作る

Status: Runnable now

ChatGPT級のモデルでは、dataset は単なる巨大テキストではありません。収集、重複除去、品質フィルタ、分割、混合比、評価データへの混入チェックが性能と安全性に直結します。

uv run mini-transformer-prepare-data --input data/natural/tiny.txt --output-dir runs/data-natural --dedupe --splits 0.8,0.1,0.1
uv run mini-transformer-mixture-report --natural data/natural/tiny.txt --code data/code/tiny.py.txt --ratio 0.7,0.3 --target-total 20
uv run mini-transformer-contamination-check --train runs/data-natural/train.txt --eval data/eval/tiny_prompts.txt

読む場所:

• Data Pipeline Hands-on

ソース:

src/mini_transformer_lab/data_pipeline.py
src/mini_transformer_lab/dataset_mixture.py

影響:

• train loss が低くても、validation や held-out task で崩れる理由が見える。
• 同じ model でも dataset mixture により文体、コード能力、暗記リスクが変わる。
• downstream evaluation の信頼性は contamination 管理に依存する。

2. tokenizer を作って比較する

Status: Runnable now

ChatGPT級のモデルでも、最初に text を token ID に変換します。tokenizer は「モデルが何を1単位として見るか」を決めます。

devbox run compare
uv run mini-transformer-compare-tokenizers --file data/natural/tiny.txt
uv run mini-transformer-compare-tokenizers --file data/code/tiny.py.txt

ソース:

src/mini_transformer_lab/tokenizers.py
src/mini_transformer_lab/compare_tokenizers.py

影響:

• 語彙数。
• context window に入る情報量。
• 日本語、英語、コード、記号の扱いやすさ。

次に作るもの:

• BPE / unigram など、より実運用に近い tokenizer の比較。
• tokenizer training data が model の見え方を変える実験。

3. base language model を事前学習する

Status: Runnable now

次に、token 列から次 token を予測する base language model を作ります。ChatGPTも、土台には next-token prediction の学習があります。

devbox run train:natural
uv run mini-transformer-generate --run runs/natural-char --prompt "小さな"

devbox run train:code
uv run mini-transformer-generate --run runs/code-regex --prompt "def "

ソース:

src/mini_transformer_lab/model.py
src/mini_transformer_lab/train.py
src/mini_transformer_lab/generate.py

影響:

• dataset の文体、構文、癖を学ぶ。
• 自然言語とコードで、同じモデルでも出力の性質が変わる。
• train loss と valid loss で、学習不足と覚え込みを見分ける。

4. モデルサイズと文脈長を変える

Status: Runnable now

ChatGPT級のモデルでは、parameter 数、層数、head 数、context length が能力、速度、費用に強く効きます。この lab では小さい値で同じ構造を観察します。

uv run mini-transformer-train --dataset data/natural/tiny.txt --tokenizer char --steps 80 --d-model 32 --n-heads 4 --n-layers 2 --context-length 64 --output-dir runs/d32
uv run mini-transformer-train --dataset data/natural/tiny.txt --tokenizer char --steps 80 --d-model 128 --n-heads 4 --n-layers 2 --context-length 64 --output-dir runs/d128

uv run mini-transformer-train --dataset data/natural/tiny.txt --tokenizer char --steps 80 --context-length 32 --output-dir runs/ctx32
uv run mini-transformer-train --dataset data/natural/tiny.txt --tokenizer char --steps 80 --context-length 128 --output-dir runs/ctx128

影響:

• d_model: token を表す内部ベクトルの幅。
• n_layers: 変換を何段重ねるか。
• context_length: 何 token 前まで見られるか。
• 小さい dataset では、大きいモデルほど過学習しやすい。

5. chat template と chat runtime を作る

Status: Planned

base language model は、まだ assistant ではありません。ChatGPT 風にするには、入力を「誰が何を言ったか」という構造にし、会話履歴をどの順番で model に渡すかを実装します。

これから追加するハンズオン:

<system>
あなたは簡潔に答える assistant です。

<user>
Transformer とは何ですか？

<assistant>

作る処理:

• system / user / assistant role を text template に変換する。
• message list を保持する。
• context window を超える会話履歴を切り詰める。
• CLI chat loop を作る。
• その後、HTTP API / UI / streaming に分ける。

影響:

• system prompt は model weight を直接書き換えるものではない。
• role と template は、同じ model に対する入力構造を変える。
• conversation history と context truncation は、回答の一貫性と忘却に直結する。
• tool result や検索結果は、権限のない外部テキストとして扱う必要がある。

6. instruction tuning 用の最小データを作る

Status: Planned

ChatGPT は、pretraining だけで完成するのではなく、人間の指示に答えるよう post-training されます。この lab では、商用規模の RLHF ではなく、最初に supervised fine-tuning 風 dataset を小さく作ります。

作る処理:

• prompt -> response の小さな instruction dataset。
• chat template。
• assistant response 部分だけを loss 対象にする実験。

影響:

• base model と instruction-following model の違いが見える。
• prompt の書き方ではなく、dataset と training objective の違いとして理解できる。

7. preference / alignment を追加する

Status: Planned

SFT だけでは、ユーザーにとって望ましい回答、避けるべき回答、拒否すべき要求を十分に制御できません。現実の instruction-following model では、回答候補の比較、preference data、reward model、DPO / RLHF 系の最適化、安全性評価が重要になります。

これから追加するハンズオン:

• 同じ prompt に対する2つの回答候補を作る。
• どちらが helpful / harmless / honest かをラベルする。
• toy preference scorer または DPO 風の loss を実装する。
• refusal が必要な例と、普通に答えるべき例を分ける。

影響:

• instruction に従う能力と、望ましい assistant behavior は別物だと理解できる。
• safety behavior は後付けの文言だけではなく、data、objective、evaluation の問題になる。
• InstructGPT 系の流れでは、SFT の後に ranking / reward / RLHF が置かれる。

8. reasoning controller simulator を接続する

Status: Runnable now

複雑な問題では、最終回答をすぐ出すだけではなく、内部作業、検証、候補比較を使います。ただし、この lab の reasoning 実装は、学習済み tiny Transformer が推論を獲得した証拠ではありません。外部の deterministic evaluator を使う controller simulator です。

devbox run reason
uv run mini-transformer-reason --prompt "8 * 6 - 5" --effort high --show-trace
uv run mini-transformer-reason --prompt "8 * 6 - 5" --effort high --samples 5

読む場所:

• Reasoning
• Reasoning Hands-on

ソース:

src/mini_transformer_lab/reasoning.py

影響:

• hidden scratchpad と visible answer を分ける。
• reasoning effort は latency、token budget、cost に効く。
• verifier と self-consistency は、model 出力を外側から扱う設計につながる。
• 次の段階では、候補生成を tiny model に寄せ、verifier を外部に置く構成へ進める。

9. RAG と RAG evaluation を追加する

Status: Planned

ChatGPT 風 product では、model weight にない情報を外部文書から渡すことがあります。RAG は、parametric memory である model と、non-parametric memory である外部検索を組み合わせる構成として理解すると現実に近くなります。

これから追加するハンズオン:

• 文書を chunk に分ける。
• chunk を embedding 相当の特徴量で検索する。
• 検索結果を context として chat prompt に入れる。
• 回答に根拠 chunk を紐づける。
• retrieval precision / recall を小さく測る。
• grounding / citation mismatch を検出する。
• 検索文書内の prompt injection を untrusted text として扱う。

影響:

• model の知識不足を外部情報で補う。
• context window を消費する。
• retrieval が悪いと、正しい model でも悪い回答になる。
• RAG は「検索結果を入れる」だけでなく、retrieval quality と grounding evaluation が必要になる。

10. tool use と agent loop に進む

Status: Planned

ChatGPT 風 agent は、回答するだけでなく、関数、検索、ファイル操作、DB などを呼び出します。現実的には、tool を呼べることよりも、いつ呼ぶか、どの引数を渡すか、結果をどう検証するか、どこまでの権限を与えるかが重要です。

これから追加するハンズオン:

• tool schema を定義する。
• model 出力を tool call として検査する。
• tool result を次の prompt に戻す。
• side effect のある tool と read-only tool を分ける。
• permission boundary、retry limit、timeout、schema validation を入れる。
• prompt injection を含む tool result を命令として扱わない。

影響:

• model の能力と tool の権限を分けて考えられる。
• prompt だけではなく、外側の controller が重要になる。
• agent の安全性は tool 権限と検証に強く依存する。

11. serving、評価、ログ、運用を見る

Status: Planned

ChatGPT級のシステムでは、作って終わりではありません。API boundary、streaming、latency、cost、回答品質、安全性、失敗ログを見ながら改善します。

これから追加するハンズオン:

• 固定質問セットで回答を比較する。
• 生成時間と token 数を記録する。
• schema validation や禁止出力チェックを入れる。
• 失敗例を dataset / prompt / post-training / retrieval / tool / verifier のどこで直すか分類する。
• API endpoint と streaming response の最小実装を作る。

影響:

• どの変更が効いたかを判断できる。
• agent の事故をログから追いやすくなる。
• cost と latency を設計変数として扱える。
• product としての ChatGPT 風システムは、model だけでなく runtime と observability で成立する。

今後の追加順

この導線に沿って、次の実装を順番に追加します。

具体的なPR分割、追加CLI、追加ファイル、テスト、完了条件は Planned Implementation Plan にまとめています。

Source Guide