大規模言語モデルに関する完全な技術ガイド — 生のテキストがどのように数値になるかから、transformer アーキテクチャと attention メカニズムを経て、訓練、アライメント、推論、RAG、本番展開まで。曖昧な説明なし。実際の数式と実際のコード。
大規模言語モデル（LLM）は、テキストの系列における次の token を予測するよう訓練されたニューラルネットワークである。この単一の目的 — 次の token の予測 — は、極めて強力であることが判明している：うまく予測するために、モデルは文法、事実、推論パターン、コードの構文、その他多くを学習しなければならない。
「大規模」とは、パラメータ数（数十億から数兆の学習済み重み）と訓練データの規模（ウェブ、書籍、コードから得られる数兆の tokens）を指す。十分な規模になると、モデルは創発的能力を示す — より小さなモデルには存在せず、明示的に訓練されていない能力であり、多段の算術、類推的推論、わずかな例からの in-context learning などである。
アーキテクチャ上、今日の主要な LLM はすべて decoder-only transformer である（GPT ファミリー、Llama、Mistral、Claude、Gemini）。モデルは token ID の系列を入力として受け取り、次の token について語彙上の確率分布を生成する。生成は autoregressive である：モデルは token を 1 つサンプリングし、系列に追加し、これを繰り返す。
graph LR A[Input Text] --> B[Tokenizer] B --> C[Token IDs] C --> D[Embedding Layer] D --> E[Transformer Blocks xN] E --> F[LM Head] F --> G[Logits over Vocabulary] G --> H[Softmax + Sampling] H --> I[Next Token] I -->|Autoregressive loop| C
ある規模の閾値を超えて初めて現れる能力 — few-shot 学習、chain-of-thought 推論、指示の遵守 — であり、明示的に訓練されていないもの。
モデルは、重みの更新なしに prompt 内の例（few-shot）に基づいて振る舞いを適応させる。コンテキストウィンドウは推論中の唯一の「記憶」である。
モデルの重みは訓練コーパスの非可逆圧縮を符号化する。事実は逐語的に保存されない — 数十億の重みにわたって分散しており、それがハルシネーションが起きる理由である。
LLM は文字や単語ではなく tokens を扱う。tokens は同じコーパスで訓練された tokenizer が生成するサブワード単位である。tokenization を理解すると、コスト、コンテキスト長、そしてモデルの振る舞いの多くの癖が説明できる。
GPT-2, GPT-3, GPT-4o, Llama 4, Mistral Large 3
最も頻出する隣接バイトまたは文字のペアを反復的にマージする。個々のバイトから始まるため、未知の token なしにあらゆる Unicode テキストを処理する。
BERT, DistilBERT, ALBERT
BPE に似ているが、マージは生の頻度ではなく、言語モデルの下で訓練データの尤度を最大化するように選ばれる。
T5, Gemma, Qwen
tokenization を確率的セグメンテーション問題として扱う。言語非依存 — 事前 tokenization なしに生のテキストから動作する（空白は通常の文字として扱われる）。
| 単語 | GPT-4o tokens | token 数 |
|---|---|---|
| transformer | transformer | 2 |
| tokenization | tokenization | 2 |
| def calculate_loss(logits): | def calculate_loss(logits): | 6 |
| Üniversität | Üniversität | 4 |
| hello | hello | 1 |
| (3 spaces) | 1 |
| モデル | Tokenizer | 語彙サイズ | 備考 |
|---|---|---|---|
| GPT-2 | BPE | 50,257 | バイトレベル BPE |
| GPT-3 / GPT-3.5 | BPE (cl100k) | 100,277 | GPT-4 と同一 |
| GPT-4 / GPT-4o | BPE (o200k) | 200,019 | より優れた多言語対応 |
| Llama 3.x / 4.x | BPE (tiktoken) | 128,256 | Llama 2 の 32k から改善 |
| Mistral v0.x | BPE (SentencePiece) | 32,768 | 小さいが効率的 |
| Gemma 2 | SentencePiece | 256,000 | 非常に大きな多言語語彙 |
import tiktoken
# GPT-4o uses the o200k_base encoding
enc = tiktoken.get_encoding("o200k_base")
text = "Tokenization is the first step in every LLM pipeline."
tokens = enc.encode(text)
print(f"Token IDs: {tokens}")
# Token IDs: [5808, 2065, 374, 279, 1176, 3094, 304, 1475, 445, 11237, 15598, 13]
print(f"Token count: {len(tokens)}") # 12
print(f"Decoded: {[enc.decode([t]) for t in tokens]}")
# ['Token', 'ization', ' is', ' the', ' first', ' step', ' in', ' every', ' L', 'LM', ' pipeline', '.']
# Cost estimation: GPT-4o input = $2.50 / 1M tokens
cost_per_token = 2.50 / 1_000_000
print(f"Cost for this sentence: ${cost_per_token * len(tokens):.8f}")「Attention Is All You Need」（Vaswani et al., 2017）で導入された transformer は、再帰型ネットワークを完全に attention ベースのアーキテクチャに置き換えた。今日の主要な LLM はすべてこの基盤の上に構築されている。
graph TD A[Input Tokens] --> B[Token Embeddings] B --> C[+ Positional Encoding] C --> D[Multi-Head Self-Attention] D --> E[Add and Layer Norm] E --> F[Feed-Forward Network] F --> G[Add and Layer Norm] G --> H[Next Block or Output]
Transformer の核心的洞察：各 token は系列内の他のすべての token に同時に注意を向けられる。入力行列 X が与えられると、3 つの学習済み射影が queries (Q)、keys (K)、values (V) を生成する：
Multi-head attention は H 個の独立した attention 演算を並列に実行し、それぞれ異なる学習済み射影を持つ。これによりモデルは異なる表現部分空間からの情報に同時に注意を向けられる。GPT-3 は 96 個の attention heads を使用し、Llama 4 Maverick は効率的なサービングのために grouped-query attention (GQA) を使用する。
import torch
import torch.nn.functional as F
def scaled_dot_product_attention(Q, K, V, mask=None):
"""
Q, K, V: (batch, heads, seq_len, head_dim)
Returns: (batch, heads, seq_len, head_dim)
"""
d_k = Q.size(-1)
# Compute attention scores
scores = torch.matmul(Q, K.transpose(-2, -1)) / (d_k ** 0.5) # (batch, heads, seq, seq)
# Apply causal mask (decoder: attend only to past tokens)
if mask is not None:
scores = scores.masked_fill(mask == 0, float('-inf'))
# Softmax over key dimension
attn_weights = F.softmax(scores, dim=-1)
# Weighted sum of values
return torch.matmul(attn_weights, V), attn_weights各 transformer ブロックは、各 token 位置に独立して適用される 2 層の MLP を含む。隠れ次元は通常モデル次元の 4× である（例：典型的な 8B クラスのモデルで d_model=4096、d_ff=16384）。現代の LLM は SwiGLU 活性化（SiLU のゲート付き変種）を使用し、これは経験的に ReLU や GELU を上回る。
FFN 層はモデルの事実的知識の大部分を保存する — 研究によれば、FFN に集中した「知識ニューロン」を特定し外科的に編集できる（ROME/MEMIT を参照）。attention はルーティングと合成を扱い、FFN 層は保存を扱う。
各サブ層（attention、FFN）は残差接続（output = x + sublayer(x)）と layer 正規化を使用する。現代の LLM は訓練の安定性のために Post-Norm ではなく Pre-Norm（サブ層の前に正規化）を使用し、効率のために RMSNorm（Root Mean Square norm、平均中心化なし）を使用する。
| 種類 | 例 | Attention | 最適な用途 |
|---|---|---|---|
| Encoder-only | BERT, RoBERTa, DeBERTa | 双方向（全 attention） | 分類、NER、embeddings |
| Decoder-only | GPT-4o, Llama 4, Mistral Large 3, Claude Sonnet 4.6 | 因果（左から右） | テキスト生成、チャット、推論 |
| Encoder-Decoder | T5, FLAN-T5, BART | 全 encoder + cross-attention | 翻訳、要約、seq2seq |
Pretraining は最もコストのかかる段階であり — 通常は総計算量の 95 % 以上を占める。モデルは数兆の tokens を見て、次の token を予測することを学習する。この単純な目的は、十分な規模では、我々が LLM に結びつける能力の大部分を生み出す。
tokens の系列 [t₁, t₂, ..., tₙ] が与えられると、モデルは先行するすべての token を条件として各 token の対数尤度を最大化するよう訓練される：
各順伝播は完全な系列を処理し、すべての位置で損失を並列に生成する（teacher forcing）。推論時には、tokens は autoregressive に、1 つずつ生成される。
Hoffmann et al. (2022) は、以前の大規模モデル（GPT-3、Gopher）が訓練不足であったことを示した — tokens が少なすぎる割にパラメータが多すぎた。Chinchilla の最適比は：
最適 tokens ≈ 20× パラメータ
7B パラメータのモデルは、計算最適な訓練のために ~140B tokens で訓練すべきである。実際には、推論コストが重要であるため、モデルははるかに多く訓練される（Llama 3.1 8B：15T tokens；Llama 4 モデル：~40T 推定） — より小さくより多く訓練されたモデルはサービングコストが低い。
| モデル | パラメータ | 訓練 tokens | 年 |
|---|---|---|---|
| GPT-2 | 117M – 1.5B | ~10B | 2019 |
| GPT-3 | 175B | ~300B | 2020 |
| Chinchilla | 70B | 1.4T | 2022 |
| Llama 2 (historical) | 7B – 70B | 2T | 2023 |
| Mistral 7B | 7.3B | ~8T (est.) | 2023 |
| Llama 3.1 8B | 8B | 15T | 2024 |
| Llama 3.1 405B | 405B | 15T | 2024 |
| Llama 4 Scout | ~17B active (MoE) | ~40T (est.) | 2025 |
| Llama 4 Maverick | ~17B active (MoE) | ~40T (est.) | 2025 |
ペタバイト規模のウェブクロールで、生のものと filtered なもの。ほとんどの pretraining コーパスの大部分を構成する。広範な品質フィルタリング（重複除去、言語検出、毒性除去）を要する。
GitHub、ArXiv、PubMed、FreeLaw、DM Mathematics を含む 22 のソースにまたがる 825GB のキュレーション済みデータセット。オープンで再現可能。
LLaMA 訓練データのオープンな再現。DCLM（DataComp-LM、2024）は、最適なフィルタリングパイプラインを見つけるための厳密なデータ品質アブレーションに焦点を当てる。
Books3、Gutenberg、ArXiv、S2ORC。信号対雑音比が高く、長文の推論と事実的深さに不可欠。
各 GPU がモデルのレプリカを保持し、バッチは GPU 間で分割される。勾配は各逆伝播後に平均化される（AllReduce）。すべてのサイズで標準。
個々の重み行列が GPU 間で分割される。高帯域幅の相互接続（NVLink）を要する。単一 GPU の VRAM を超えるモデルに使用される。
異なる層が異なる GPU に割り当てられる。マイクロバッチがパイプラインを流れる。非常に深いモデルに効率的だが、バブルを最小化する慎重なスケジューリングを要する。
Pretrain された基盤モデルは、強力だが予測不能な次 token 予測器である — 有害なコンテンツを含め、あらゆるテキストを継続する。アライメント訓練は、それを役に立ち、無害で、正直なアシスタントに変える。
基盤モデルは、人間のアノテーターによって書かれた、またはキュレーションされた（指示、理想的な応答）ペアのデータセットでファインチューニングされる。これによりモデルは指示遵守の形式を学ぶ。訓練目的は pretraining と同一（交差エントロピー）だが、データセットは小規模（数万の例）で高品質である。SFT の後、モデルは指示に従えるが、まだ不正確または有害な場合がある。
graph LR A[Pretrained LLM] --> B[SFT on Instruction Data] B --> C[SFT Model] C --> D[Generate Completions] D --> E[Human Preference Labels] E --> F[Train Reward Model] F --> G[RLHF with PPO] G --> H[Aligned LLM]
報酬モデル： 人間のアノテーターはモデル応答のペアを比較し、その好みをラベル付けする。別個のモデルが、与えられた prompt に対して人間が好む応答を予測するよう訓練される。このスカラー報酬信号は、損失関数として指定しにくい微妙な品質判断を捉える。
PPO (Proximal Policy Optimisation)： SFT モデル（「policy」）は報酬モデルのスコアを最大化するよう最適化され、その一方で KL ダイバージェンスのペナルティが SFT ベースラインからの過度な逸脱（報酬ハッキングを引き起こす）を防ぐ。PPO は計算コストが高い：4 つのモデルを同時にメモリに保持する必要がある。
Rafailov et al. (2023) は、RLHF の目的が、別個の報酬モデルや RL ループなしに policy モデル上で直接最適化できることを示した。好まれる応答と拒否される応答のペアが与えられると、DPO は報酬を policy モデルと参照モデルの対数確率の関数として再パラメータ化する：
DPO は PPO を用いる RLHF よりも単純で、安定しており、安価である。ほとんどのオープンソースのアライメント済みモデル（Llama 4 Instruct、Mistral Instruct）は、選好アライメント段階に DPO またはその変種（SimPO、IPO）を使用する。
| 手法 | 報酬モデル | RL ループ | 安定性 | 使用例 |
|---|---|---|---|---|
| RLHF (PPO) | あり | あり (PPO) | 中程度 | InstructGPT, early ChatGPT |
| DPO | なし | なし | 高い | Llama 4, Mistral, Zephyr |
| Constitutional AI (CAI) | 自己批評 | あり (RLAIF) | 高い | Claude (Anthropic) |
| GRPO / DAPO | ルールベース | グループ相対 | 高い | DeepSeek-R1, Qwen |
各生成ステップで、モデルはサイズ |vocabulary| の logit ベクトルを出力する。サンプリング戦略は、この分布から単一の token をどのように選ぶかを決定し — 出力の品質、多様性、一貫性に絶大な影響を与える。
| Temperature | 効果 | ユースケース |
|---|---|---|
| 0.0 (Greedy) | 常に最も確率の高い token を選ぶ。決定論的。 | 分類、構造化抽出、事実的 Q&A |
| 0.2 – 0.4 | より鋭い分布。ほぼ最も可能性の高い経路に従うが、小さな変動を許す。 | コード生成、要約 |
| 0.6 – 0.8 | バランス型。一貫性と多様性の良い混合。 | 一般的なチャット、指示遵守（ほとんどのモデルの既定値） |
| 1.0 | モデル分布から直接サンプリングする。より多様。 | 創作、ブレインストーミング |
| > 1.0 | 分布を平坦化する。ランダム性と繰り返しを増やす。しばしば一貫性のない出力を生む。 | 本番ではめったに有用でない |
tokens を確率順にソートし、累積確率が ≥ p となる最小の集合を取り、その集合からサンプリングする。p=0.9 では、モデルは合わせて確率質量の 90 % を占める tokens のみを考慮する。候補集合のサイズを動的に適応させる：確信があるとき核は小さく、不確実なときはより広くなる。
分布を最も可能性の高い上位 k の tokens に切り詰め、そこからサンプリングする。top-p より単純だが、分布の形状に関わらず固定の k を使用する。一般に top-p が好まれる；top-k は候補集合のサイズを厳密に制御する必要があるときに有用。
from openai import OpenAI
client = OpenAI()
# Factual / structured output: low temperature, no top-p
factual = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "What is the capital of France?"}],
temperature=0.0,
max_tokens=50,
)
# Creative writing: higher temperature + nucleus sampling
creative = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Write a haiku about neural networks."}],
temperature=0.9,
top_p=0.95,
max_tokens=100,
)
# Code generation: low temp, deterministic
code = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Write a Python quicksort function."}],
temperature=0.2,
max_tokens=300,
)Transformer には token の順序という本質的な概念がない — attention は置換不変である。位置エンコーディングが順序情報を注入する。エンコーディング手法の選択は、訓練長より長い系列にモデルがどれだけうまく一般化するかを決定する。
学習済みまたは固定（正弦波）のベクトルが、位置 i で各 token embedding に加算される。GPT-2 と BERT は学習済みの絶対 embeddings を使用する。厳しい制限：モデルは訓練中に見たことのない位置に一般化できない。
Q と K のベクトルを位置に比例した角度で複素空間で回転させることにより位置を符号化する。attention スコアは自然に token 間の相対距離に依存する。Llama 4、Mistral Large 3、Qwen、およびほとんどの現代のオープンウェイトモデルで使用される。YaRN や LongRoPE のようなコンテキスト拡張技術を可能にする。
Autoregressive 生成中、モデルは各ステップですべての token について attention を再計算する — 素朴にはステップあたり O(n²)。KV-cache は先行するすべての token の key と value のテンソルを保存する。新しいステップごとに、新しい token の Q、K、V だけが計算され、キャッシュされた K、V が追加される。これにより生成は新しい token あたり O(n²) から O(n) に削減される。
| モデル | コンテキストウィンドウ | 位置エンコーディング | 実効長* |
|---|---|---|---|
| GPT-4o | 128K | 学習済み + RoPE（推定） | 128K |
| Claude Sonnet 4.6 | 200K | 非公開 | ~150K（実用） |
| Gemini 2.5 Pro | 1M | 非公開 | ~500K（実用） |
| Llama 4 Maverick | 1M | RoPE | 1M |
| Mistral Large 3 | 128K | Sliding Window + RoPE | 128K |
| DeepSeek-R1 | 128K | RoPE | 128K |
*実効長：モデルが確実に情報を取得できるウィンドウ。「Lost in the middle」の研究は、非常に長いコンテキストの中央に置かれたコンテンツでは性能が低下することを示している。
RAG は LLM の 2 つの根本的な制約に対処する：知識のカットオフとハルシネーションへの傾向である。モデルが訓練中に記憶したものに頼る代わりに、RAG は推論時に関連文書を取得し、prompt に注入する。
graph LR A[User Query] --> B[Embed Query] B --> C[Vector Search] C --> D[Top-k Chunks] D --> E[Inject into Prompt] A --> E E --> F[LLM Generation] F --> G[Grounded Answer]
クエリを embed → top-k 類似検索 → チャンクを prompt に追加 → 生成。単純だが、無関係な取得とコンテキスト過負荷に陥りやすい。
クエリの書き換え、re-ranking（cross-encoders）、仮想文書 embeddings（HyDE）、再帰的取得、コンテキスト圧縮を追加する。
疎結合パイプライン：ルーティング、クエリ変換、取得、スコアリング、フィルタリング、融合をそれぞれ独立に差し替えられる。最大の柔軟性。
M token のオーバーラップで N token ごとに分割する。高速だが文の途中で切れることがある。良いベースライン。
文または段落の境界で分割する。意味的単位を保持するが、チャンクのサイズは変動する。
embedding 類似度の高い文を一貫したチャンクにグループ化する。最良の取得品質；インデックス作成時の計算コストは最も高い。
複数の粒度（文書 → セクション → 段落）でインデックスを作成する。クエリの具体性に一致するレベルで取得する。
| データベース | デプロイ | 規模 | 最適な用途 |
|---|---|---|---|
| pgvector | セルフホスト（Postgres 拡張） | 数百万 | 既存の Postgres ユーザー；よりシンプルなスタック |
| Qdrant | セルフホスト／クラウド | 数十億 | 高性能、豊富なフィルタリング、オープンソース |
| Weaviate | セルフホスト／クラウド | 数十億 | マルチモーダル、意味的 + キーワードのハイブリッド |
| Pinecone | フルマネージドクラウド | 数十億 | マネージド SaaS、最小限の運用 |
| Chroma | ローカル／セルフホスト | 数百万 | プロトタイピング、ローカル開発 |
オープンウェイトとプロプライエタリのフロンティアモデルの差は劇的に縮まった。Llama 4 Maverick は多くの benchmarks で GPT-4o に匹敵し；DeepSeek-R1 は訓練コストのわずかな割合で数学とコーディングにおいて o1 を上回る。選択はますますデプロイモデル、データプライバシー、総所有コストに関するものになっている。
| モデル | パラメータ | コンテキスト | ライセンス | MMLU | 最適なユースケース |
|---|---|---|---|---|---|
| Open Weight | |||||
| Llama 4 Scout | ~17B active (MoE) | 1M | Llama 4 Community License | 79.6 | 高速、長いコンテキスト、オンデバイス |
| Llama 4 Maverick | ~17B active (MoE) | 1M | Llama 4 Community License | 85.5 | 能力／コストのバランス、長いコンテキスト |
| Llama 4 Behemoth | ~288B active (MoE) | 128K | Llama 4 Community License | ~92 (est.) | フロンティアのオープンウェイトタスク |
| Mistral Large 3 | ~123B | 128K | Mistral Research License | 84.0 | 多言語エンタープライズ |
| Qwen2.5 72B | 72B | 128K | Apache 2.0 | 86.0 | コード、数学、多言語 |
| DeepSeek-R1 | 671B MoE | 128K | MIT | 90.8 | 推論、数学、科学 |
| Gemma 2 27B | 27B | 8K | Gemma License | 75.2 | 研究、ファインチューニング |
| Phi-4 | 14B | 16K | MIT | 84.8 | |
| プロプライエタリ | |||||
| GPT-4o | ~200B est. | 128K | Proprietary | 88.7 | 一般フロンティア、マルチモーダル |
| Claude Sonnet 4.6 | Undisclosed | 200K | Proprietary | 88.7 | 長いコンテキスト、コーディング、安全性 |
| Gemini 2.5 Pro | Undisclosed | 1M | Proprietary | 85.9 | 非常に長いコンテキスト、マルチモーダル、推論 |
| o3 / o1 | Undisclosed | 200K | Proprietary | ~91+ | 複雑な推論、フロンティア研究 |
LLM を大規模にサービングするには、メモリ（VRAM は希少）、スループット（多数の同時ユーザー）、遅延（ユーザーは高速な最初の tokens を望む）の解決が必要である。エコシステムは各課題に対して強力な解決策を開発してきた。
モデルの重みの数値精度を下げると VRAM が縮小し計算が高速化する。現代の技術（GPTQ、AWQ、GGUF）は quantisation を不均一に適用し、最も敏感な重みを保護する。
| フォーマット | ビット／重み | 相対サイズ | 品質保持 | ツール |
|---|---|---|---|---|
| FP32 | 32 | 100% | 100 %（基準） | PyTorch default |
| FP16 / BF16 | 16 | 50% | ~100 % | Standard training/inference |
| INT8 | 8 | 25% | ~99 % | bitsandbytes, TensorRT-LLM |
| INT4 (GPTQ/AWQ) | 4 | 12.5% | ~95–98 % | AutoGPTQ, AutoAWQ, llama.cpp |
| GGUF Q4_K_M | ~4.5 | ~14% | ~96 % | llama.cpp, Ollama |
| GGUF Q2_K | ~2.6 | ~8% | ~88 % | llama.cpp (CPU focus) |
効率的な KV-cache 管理のための PagedAttention、連続バッチング、テンソル並列。高スループット GPU サービングのゴールドスタンダード。OpenAI 互換 API。
Hugging Face の本番サーバー。Flash Attention 2、連続バッチング、投機的デコーディング。Inference API を支える。
GGUF モデルによる極めて単純なローカルサービング。任意のモデルを取得して実行する 1 つのコマンド。高い並行性向けには設計されていないが、開発には優れる。
GGUF quantisation を用いた純粋な C++ 推論。MacBook M シリーズの CPU やコンシューマー GPU で動作する。裏で Ollama を支える。
vLLM の PagedAttention（Kwon et al., 2023）は、KV-cache メモリを OS の仮想メモリのように管理する — それを非連続に割り当てられる固定サイズのページに分割する。これは断片化と無駄な予約を排除し、同等の GPU メモリで HuggingFace Transformers より 2–24× 多いスループットを可能にする。
連続バッチングは、バッチ全体を待つのではなく、系列が完了するとすぐに新しいリクエストが進行中のバッチに加わることを可能にする。これは可変長のワークロードの下で GPU 利用率を劇的に改善する。
# Start a vLLM server for Llama 4 Scout Instruct
# Requires: pip install vllm, CUDA GPU with ≥16GB VRAM
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-4-Scout-17B-16E-Instruct \
--tensor-parallel-size 1 \
--max-model-len 32768 \
--dtype bfloat16 \
--port 8000
# The server exposes an OpenAI-compatible API:
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "meta-llama/Llama-4-Scout-17B-16E-Instruct",
"messages": [{"role": "user", "content": "Explain attention mechanisms."}],
"temperature": 0.7,
"max_tokens": 512
}'評価は LLM 研究において最も難しい未解決問題の 1 つである。標準的な benchmarks は特定の能力を測定するが、実世界での有用性とは不完全にしか相関しない。包括的な評価戦略は、自動化された benchmarks、人間による評価、LLM-as-judge を組み合わせる。
| Benchmark | 測定対象 | 形式 | 制約 |
|---|---|---|---|
| MMLU | 幅広い知識（57 科目） | 4 択 MCQ | MCQ 形式；汚染のリスク |
| HumanEval | Python コード生成 | 関数補完 + ユニットテスト | Python のみ；狭いタスク分布 |
| GSM8K | 小学校レベルの文章題（数学） | 自由形式の算術 | フロンティアモデルで飽和（>95 %） |
| HellaSwag | 常識的 NLI | 4 択の文補完 | 飽和；敵対的だが古い |
| MT-Bench | 指示遵守（マルチターン） | LLM-as-judge (GPT-4) | GPT-4 ジャッジには独自のバイアスがある |
| GPQA Diamond | 大学院レベルの科学 | ドメイン専門家による 4 択 MCQ | 小さなデータセット；スケールが難しい |
| MATH-500 | 競技数学 | 厳密な解答一致 | 形式に敏感；解答が記憶されうる |
| モデル | MMLU | HumanEval | GSM8K | MATH |
|---|---|---|---|---|
| GPT-4o | 88.7 | 90.2 | 96.0 | 76.6 |
| Claude Sonnet 4.6 | 88.7 | 92.0 | 96.0 | 78.3 |
| Gemini 2.5 Pro | 85.9 | 84.1 | 91.7 | 67.7 |
| DeepSeek-R1 | 90.8 | 92.3 | 97.3 | 97.3 |
| Llama 4 Maverick | 85.5 | 85.4 | 95.0 | 72.0 |
| Llama 4 Scout | 79.6 | 77.0 | 89.0 | 58.0 |
| Mistral Large 3 | 84.0 | 92.0 | 93.0 | 69.0 |
| Llama 3.1 8B (2024) | 73.0 | 72.6 | 84.5 | 51.9 |
参照解答が存在しない自由なタスクでは、強力な LLM が構造化されたルーブリックを用いて応答を採点できる。MT-Bench と Chatbot Arena はこのアプローチを使用する。主なリスクは位置バイアス（ジャッジは最初に現れる解答を好む）と冗長性バイアス（品質に関わらず長い解答ほど高得点になる）である。
from openai import OpenAI
client = OpenAI()
def llm_judge(question: str, answer: str, rubric: str) -> dict:
prompt = f"""You are an expert evaluator. Score the following answer on a 1-10 scale.
Question: {question}
Answer: {answer}
Rubric: {rubric}
Respond with JSON: {{"score": <int>, "reasoning": "<str>", "strengths": ["..."], "weaknesses": ["..."]}}"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"},
temperature=0.0,
)
import json
return json.loads(response.choices[0].message.content)
result = llm_judge(
question="Explain the attention mechanism in transformers.",
answer="Attention computes a weighted sum of values...",
rubric="Accuracy (4pt), Clarity (3pt), Completeness (3pt)",
)
print(f"Score: {result['score']}/10 — {result['reasoning']}")LLM の仕組みを理解することは基盤である — しかし、特定のユースケースに適したモデル、デプロイアーキテクチャ、評価戦略を選ぶには実践的な経験が必要である。私たちのチームは、RAG、エージェント、ファインチューニング、エンタープライズ展開にわたる本番 LLM システムを構築してきた。あなたのプロジェクトについて話すために相談を予約してください。