7.3.4 主流な大規模モデルアーキテクチャのバリエーション

この節の位置づけ

はじめて大規模モデルの仲間に触れると、名前が違うだけに見えることがあります。

• BERT
• GPT
• T5
• Mixtral

でも、本当に学ぶべきなのは次の点です。

アーキテクチャが違うのは、「誰が誰を見てよいのか」「どう学習するのか」「何に向いているのか」に、それぞれ違う答えを出しているからです。

この授業では、こうした分岐を土台の構造から見直していきます。

学習目標

• Encoder-only、Decoder-only、Encoder-Decoder の基本的な違いを理解する
• アーキテクチャの選択と、学習目標・タスクの関係を理解する
• 実行可能な例を通して、さまざまな mask の背後にある情報の流れを見る
• 「このタスクにはどの構造が向いているか」の最初の判断軸を作る

---

一、なぜ同じ Transformer なのに、こんなに多くの分岐があるのか？

タスクが違えば、情報の流れに関する制約も違うから

NLP のタスクは、本質的な要求がそれぞれ違います。

• テキスト分類は「文全体を理解する」ことを重視する
• 自由生成は「過去の文脈だけを使って続きを書く」ことを重視する
• 翻訳や要約は「まず入力をエンコードして、それから出力を生成する」ことを重視する

そのため、土台の部品がどれも Transformer block だとしても、
最終的には違う構造に育っていきます。

わかりやすい例え

3つの代表的なアーキテクチャは、3つの読み方だと考えるとわかりやすいです。

• Encoder-only：文章全体を先に通読してから判断する
• Decoder-only：書きながら前の文だけを見る。後ろは見ない
• Encoder-Decoder：まず原文をしっかり読んでから、要約や翻訳を書く

このイメージがつかめると、
あとの違いも理解しやすくなります。

---

二、3つの代表的な構造は、それぞれ何をしているのか？

Encoder-only：理解に向いていて、自由な続きを書くのは得意ではない

Encoder-only の代表例は次の通りです。

• BERT

特徴は次のとおりです。

• 各位置が左右両方の文脈を見られる
• より完全な意味表現を作りやすい
• 分類、照合、抽出などの理解タスクに向いている

ただし、自由生成には自然には向きません。
学習時に「過去だけを見る」という厳密な制約が入っていないからです。

Decoder-only：生成に最も素直なルート

Decoder-only の代表例は次の通りです。

• GPT
• LLaMA
• Qwen

重要な制約は次の通りです。

• 現在の token は、それより前の token だけを見られる

これは生成タスクと完全に一致します。生成するときも、私たちは一歩ずつ先へ書いていくからです。

長所は次のとおりです。

• 学習目標が統一されている
• 生成の流れが自然
• 大規模な自己回帰モデリングに向いている

Encoder-Decoder：入力と出力の役割を分ける

Encoder-Decoder の代表例は次の通りです。

• T5
• BART

考え方はこうです。

1. Encoder が入力を理解する
2. Decoder がその表現をもとに出力を生成する

この構造は特に次のタスクに向いています。

• 翻訳
• 要約
• 言い換え
• 質問応答生成

これらのタスクは本質的に、

• 何かを入力として受け取り
• 別のものを出力する

という形だからです。

MoE：情報の流れを変えるのではなく、「誰が計算するか」を変える

モデルがどんどん大きくなると、
もう一つの重要な分岐が出てきます。

• Mixture of Experts

ここでのポイントは、自分注意の基本ルールを変えることではありません。
代わりに、

毎回すべての大きな FFN を通すのではなく、token ごとに一部の expert ネットワークだけを動かす

という点です。

この仕組みの主な目的は次のとおりです。

• パラメータ規模を大きくしながら、毎回の前向き計算量は抑える

つまり MoE は、「スケールアップのためのバリエーション」と考えるとわかりやすいです。

図の読み方

token の視点で MoE を見てください。各 token はまずルーターに入り、ルーターが複数の Expert FFN にスコアを付け、上位 top-k の expert だけを動かします。だから MoE は総パラメータを増やしつつ、token ごとの実際の計算量を dense FFN より抑えられます。

初学者が飛ばさないほうがよい MoE 用語

用語	やさしい意味	なぜ重要か
Router	token が使う expert を決めるモジュール	token ごとの計算経路を決める
Top-k	スコアが高い k 個の expert だけを選ぶこと	token ごとに動かす expert 数を制御する
負荷分散	一部の expert に token が集中しすぎないようにすること	偏ると一部が過負荷になり、他の expert が使われにくい
Expert FFN	expert プール内の前向きネットワーク	MoE は dense FFN 部分を置き換えたり拡張したりすることが多い
活性化計算量	1つの token が実際に使うパラメータと計算	総パラメータ数とは別の概念

---

三、まずは本当に意味のある構造差の例を動かしてみよう

次のコードはモデルを学習するものではありません。
ただし、3つの代表的なアーキテクチャの最も大事な違いを、そのまま表示してくれます。

• どの位置がどの位置を見られるのか

これは、単に辞書を出力するよりも、構造そのものに近い理解になります。

def full_mask(length):
    return [[1 for _ in range(length)] for _ in range(length)]


def causal_mask(length):
    return [[1 if j <= i else 0 for j in range(length)] for i in range(length)]


def cross_attention_map(src_length, tgt_length):
    return [[1 for _ in range(src_length)] for _ in range(tgt_length)]


def pretty_print(title, matrix):
    print(title)
    for row in matrix:
        print(" ".join(str(x) for x in row))
    print()


length = 5
pretty_print("encoder-only self-attention", full_mask(length))
pretty_print("decoder-only self-attention", causal_mask(length))
pretty_print("encoder-decoder cross-attention", cross_attention_map(4, 3))

期待される出力：

encoder-only self-attention
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1

decoder-only self-attention
1 0 0 0 0
1 1 0 0 0
1 1 1 0 0
1 1 1 1 0
1 1 1 1 1

encoder-decoder cross-attention
1 1 1 1
1 1 1 1
1 1 1 1

このコードは何を教えているのか？

ここで教えているのは、最も基本的な3点です。

1. Encoder-only は双方向に見られる
2. Decoder-only は因果的に見る
3. Encoder-Decoder の decoder は、入力系列も追加で見られる

つまり、
多くのアーキテクチャの違いは最終的に次の点へたどり着きます。

• 情報の流れの制限が違う

なぜ mask がそんなに重要なのか？

mask は、学習中にモデルが何を知ってよいかを決めるからです。

もし decoder に causal mask がなければ、
学習時に未来の token を見てしまいます。
でも実際の生成時には未来は見えません。これでは、学習と推論が一致しません。

なぜこれでタスク適性が決まるのか？

タスクそのものが、情報の流れの違いに対応しているからです。

• 分類：入力全体を見てもよい
• 生成：未来は見られない
• 翻訳：出力側は未来を見られないが、入力側は全体を見られる

構造が合っているかどうかは、本質的には情報の流れの制約がタスクに合っているかどうかです。

図の読み方

この図を見るときは、まず「誰が誰を見られるのか」を考えます。Encoder-only は入力全体を双方向に見られるので理解に向いています。Decoder-only は過去しか見られないので生成に向いています。Encoder-Decoder は入力を先に完全にエンコードし、その後に出力を因果的に生成するので、翻訳や要約に向いています。

---

四、3つのルートを代表的なタスクにつなげて考える

テキスト理解タスクで Encoder-only がよく使われるのはなぜ？

この種のタスクでは、次の点が重要だからです。

• 文全体の意味
• token 同士の双方向の関係
• ある位置が前後の文脈をまとめて理解すること

たとえば次のようなタスクです。

• 感情分類
• 意味類似度判定
• 固有表現抽出

これらは「全文を読んでから判断する」イメージに近いです。

なぜ今の大規模モデルは、ほぼ Decoder-only が主流なのか？

目的が次のようなものになると、

• 汎用対話
• 自由生成
• コード補完
• 長文の続きを書く

decoder-only 構造が最も扱いやすいからです。

さらに次の利点もあります。

• 事前学習の目標が統一しやすい
• 推論の流れが明確
• 超大規模化しても高い性能が出やすい

その結果、LLM 時代の主流ルートになりました。

Encoder-Decoder が消えていないのはなぜ？

今でもとても向いているタスクがあるからです。

• 翻訳
• 要約
• 文の言い換え
• 入力と出力の差がはっきりした生成タスク

タスクが本質的に「入力を与えて、別の出力を作る」形なら、
encoder-decoder は今でも強いです。

MoE はどんな場面に向いているのか？

次のような目標を持つときです。

• もっと大きなパラメータ規模にしたい
• でも毎回すべてのパラメータを計算したくない

このとき MoE が注目されます。

ただし、次のような新しい実装上の課題も出てきます。

• ルーティングが安定するか
• 負荷が均等に分かれるか
• 分散学習がより複雑にならないか

---

五、構造の違いは「どれが強いか」ではなく、「どれが合っているか」

永遠に最強の万能構造は存在しない

初心者がよく次のように考えます。

• BERT、GPT、T5 のどれが一番強いの？

でも、より適切な問いは次のようなものです。

• タスクは何か？
• 学習目標は何か？
• 推論の仕方は何か？

構造はランキングではありません。
タスクとの相性の問題です。

「性能差」の多くは、構造だけでなく学習規模とデータから来る

たとえば GPT 系が強いのは、decoder-only だからだけではありません。
次の要因も大きいです。

• データ量が多い
• パラメータ数が大きい
• 工学的な成熟度が高い

なので、構造だけを唯一の原因のように考えないことが大切です。

構造と目的関数はセットで考える

一般的には、次のような組み合わせをよく見ます。

• Encoder-only + masked language modeling
• Decoder-only + causal language modeling
• Encoder-Decoder + seq2seq / denoising

つまり、
アーキテクチャと学習目標は、たいてい一体の設計です。適当にバラバラに組み合わせるものではありません。

---

六、よくある誤解

誤解1：BERT は「古いモデル」だから、学ぶ必要はない

違います。
今でも、理解タスクや表現学習の重要な基準モデルです。

誤解2：Decoder-only は何でもできるから、必ず最適解

たしかに汎用性は高いです。
ただし、入力と出力がはっきり分かれたタスクでは、
encoder-decoder のほうが自然なこともあります。

誤解3：MoE は「ただのもっと大きい普通のモデル」

完全には正しくありません。
MoE の本質的な変化は次の点です。

• パラメータ規模と、実際に動く計算量を切り分けている

これにより、学習とデプロイの複雑さが変わります。

---

まとめ

この節で最も大事なのは、名前を覚えることではありません。
構造の地図を頭に作ることです。

Encoder-only は「読んで理解する」、Decoder-only は「時間順に生成する」、Encoder-Decoder は「先に読んでから書く」、MoE は「大規模化するときに計算の通り道を変える」構造です。

アーキテクチャ、タスク、情報の流れの 3 つを結びつけられれば、
これから新しいモデル名を見ても、「流行っているらしい」だけで終わらなくなります。

---

練習

1. 自分の言葉で説明してください：なぜ causal mask は decoder-only の核心的な制約なのですか？
2. 翻訳または要約のタスクを 1 つ考え、なぜそれが自然に encoder-decoder に向いているのか説明してください。
3. テキスト分類をするなら、encoder-only と decoder-only のどちらをより優先して考えますか？その理由は何ですか？
4. もし超大規模モデルの拡張を続けたいが、1 回ごとの計算予算が限られているなら、なぜ MoE が魅力的になるのでしょうか？