LLMの「モデル」と「パラメーター」をちゃんと分けて考える
生成AIを使っていると、「パラメーター」という言葉をよく見かけます。
たとえば、
- Temperature
- Top P
- Max Tokens
- Frequency Penalty
- Presence Penalty
- Seed
などです。
一方で、
このモデルは70B Parameterです
のような説明もあります。
同じ「Parameter」という言葉ですが、ここで言っているものはまったく違います。
さらに、
Temperatureを下げれば精度が上がる
Temperatureを0にすれば毎回同じ回答になる
Max Tokensを増やせば、より深く考えてくれる
といった説明も見かけます。
もちろん、入門的な説明としては分かりやすいこともあります。
ただ、こうした説明だけで覚えてしまうと、
「Parameterを変えると、モデルの何が変わるのか」
が分かりにくくなります。
私は、LLMのParameterを見るときは、
そのParameterは、処理のどこに作用しているのか?
と考えるのが一番分かりやすいと思っています。
その前提として、まず、
「モデルそのもの」と「モデルをどう動かすか」を分ける
ところから始めます。
「Parameter」という言葉は一種類ではない
LLMで「Parameter」と言ったとき、まず大きく二つに分けて考えることができます。
一つは、モデルそのものが内部に持っているParameter。
もう一つは、モデルを利用するときにAPIなどから指定するParameterです。
たとえば、
70B Parameters
のParameterと、
temperature = 0.7
のParameterは同じものではありません。
ここを最初に分けておくだけでも、かなり見通しがよくなります。
Model Parameters
モデル内部に存在するParameterは、ニューラルネットワークが学習によって獲得したWeight(重み)などです。
かなり単純化すると、
大量のTraining Data
↓
Training
↓
Model Parameters
↓
LLM
という関係です。
モデルについて、
7B
70B
などと表現することがあります。
B は billion なので、70Bなら約700億Parameterです。
これは通常、
temperature = 0.5
のようにAPI利用者が変更するものではありません。
モデルそのものを構成している内部の値です。
APIから指定するParameter
一方、普段LLMのAPIを使っていると、
temperature
top_p
max_tokens
frequency_penalty
presence_penalty
といった値を指定することがあります。
これらは、モデル内部のWeightとは別物です。
かなり大きくまとめれば、
モデルを使って推論や回答生成を行うときの動作を制御する値
です。
イメージとしては、
Model
+
Input
+
API Parameters
↓
Inference
↓
Output
となります。
つまり、
Model
↓
何ができるモデルなのか
API Parameters
↓
そのモデルをどう動かすのか
と分けると理解しやすくなります。
なお、ここで紹介するParameterがすべてのモデルやAPIで利用できるわけではありません。
利用できるParameterや具体的な挙動は、モデルやAPIによって異なります。
Modelを変えるのとParameterを変えるのは違う
モデルを変更することと、Temperatureを変更することは根本的に違います。
モデルには、
- Architecture
- Learned Weights
- Contextを扱う能力
- Reasoningの特性
- Tool Callingの能力
などがあります。
かなり単純化すれば、
Model A
├─ Architecture
├─ Learned Weights
└─ Characteristics / Capabilities
├─ Reasoning
├─ Context Handling
└─ Tool Calling
Model B
├─ 別のArchitecture
├─ 別のLearned Weights
└─ 別のCharacteristics / Capabilities
となります。
一方で、
temperature = 0.2
を、
temperature = 0.8
に変更しても、別のモデルになるわけではありません。
ここはかなり重要です。
Parameterを調整しても、モデルそのものの能力が上がるわけではありません。
Temperatureは「創造性」ではなく、確率分布に作用する
Generation Parameterの中でも、特によく知られているのがTemperatureです。
LLMは次のTokenを生成するとき、候補となるTokenについてスコアを計算します。
たとえば、
Token Logit
----------------
東京 8.2
大阪 5.1
京都 4.7
のようになったとします。
このSoftmax前の値がLogitです。
Temperature (T) を考慮すると、概念的には次のようになります。
[
P_i =
\frac{e^{z_i/T}}
{\sum_j e^{z_j/T}}
]
(z_i) がLogitです。
処理の流れで見ると、
Model
↓
Logits
↓
TemperatureでLogitをスケーリング
↓
Softmax
↓
Probability Distribution
↓
Sampling
↓
Next Token
となります。
Temperatureを低くすると、高確率のTokenへ分布が集中しやすくなります。
Temperature: Low
東京 ███████████████████
大阪 █
京都 █
Temperatureを高くすると、低確率の候補にも確率が分散しやすくなります。
Temperature: High
東京 ██████████
大阪 █████
京都 ████
そのため、
Temperature = AIの創造性
と説明されることがあります。
結果として「創造的になった」「保守的になった」ように見えることはあります。
ただ、仕組みとしては、
Token選択に使われる確率分布の形を変えている
と考えた方が分かりやすいです。
そして重要なのは、
Temperatureを下げても、モデルそのものが賢くなるわけではない
ということです。
Top Pは候補Tokenを絞る
Top PもToken Samplingに関係するParameterです。
たとえば、
Token Probability
A 0.40
B 0.30
C 0.15
D 0.08
E 0.04
F 0.03
という確率分布があるとします。
top_p = 0.9 の場合、確率の高いものから累積します。
A 0.40 累積 0.40
B 0.30 累積 0.70
C 0.15 累積 0.85
D 0.08 累積 0.93
---------------------
E
F
一般的なNucleus Samplingでは、累積確率が指定したTop P以上になるまでのTokenを候補集合に含めます。
この例ではA〜DがSampling対象になります。
Temperatureとの違いをかなり単純化すると、
Temperature
↓
確率分布の形を変える
Top P
↓
Samplingする候補集合を絞る
となります。
両方とも「回答のランダムさを変えるParameter」とだけ覚えてしまうと、この違いが見えなくなります。
Max Tokensは「どこまで出せるか」
Max TokensはTemperatureやTop Pとは役割が違います。
max_tokens = 500
と指定した場合、生成できるToken数の上限を制御します。
つまり、
Temperature / Top P
↓
どのTokenを選ぶか
Max Tokens
↓
どこまで生成できるか
です。
Max Tokensを増やしたからといって、モデルの知識が増えるわけではありません。
推論能力そのものが上がるわけでもありません。
出力できる量の上限と、モデルの能力は別物です。
「Max Tokensを増やせば詳しく考える」という理解ではなく、
どこまで生成を許すか
というParameterだと考えた方がよいです。
Frequency PenaltyとPresence Penalty
Frequency PenaltyとPresence Penaltyは、繰り返しを抑える方向に使われるParameterです。
かなり単純化すると、
Frequency Penalty
↓
何回登場したか
Presence Penalty
↓
すでに登場したか
という違いがあります。
Frequency Penaltyは、登場回数が増えるほどPenaltyが強くなる方向に働きます。
Presence Penaltyは、そのTokenがすでに登場しているかどうかを重視します。
どちらも、
モデルそのものを書き換えているわけではありません。
生成時のToken選択に影響を与えています。
なお、具体的な計算方法や利用可否は、モデルやAPIによって異なります。
Seedを固定しても完全一致とは限らない
Seedは、生成結果の再現性を高めるために指定できる値です。
一般には乱数生成の初期値として理解できます。
seed = 12345
のように指定します。
ただし、
同じPrompt
+
同じModel
+
同じParameters
+
同じSeed
だからといって、
必ず完全に同じ文字列が返る
とは限りません。
LLMを利用したシステム全体が、常に完全な決定論的処理として動作するとは限らないためです。
これはLLMをテストするときにも重要です。
Temperature = 0
や、
Seed固定
だけを理由に、
通常の関数と同じような文字列完全一致のUnit Testができる
と考えるのは危険です。
Stopは「いつ終わるか」
Stopは生成の終了条件です。
たとえば、
stop = "END"
のように指定して、特定の文字列を生成しようとしたところで停止させる、といった使い方ができます。
これもTemperatureとは役割が違います。
Temperature
↓
Tokenをどう選ぶか
Stop
↓
いつ生成を終了するか
です。
同じParameterでも、作用する場所はかなり違います。
Response Formatは出力構造を制御する
最近のLLMアプリケーションでは、Response Formatも重要です。
特にAgentやプログラムからLLMを利用する場合、
{
"result": "OK",
"score": 0.95
}
のような構造化された結果が欲しくなることがあります。
これは、
Temperature
↓
Token Sampling
Response Format
↓
出力構造
という違いがあります。
「LLMのParameter」と一括りにするより、
何を制御するParameterなのか
を見る方が分かりやすくなります。
AgentになるとTool Choiceも出てくる
Agent型のシステムでは、Tool利用に関するParameterも登場します。
たとえば、
Agent
├─ Web Search
├─ Database
├─ Weather
└─ Send Mail
といったToolをLLMへ与える場合です。
処理は、
User Request
↓
LLM
↓
Toolを使う?
↓
Tool Call
↓
Tool Result
↓
LLM
↓
Final Answer
のようになります。
このとき、Tool Choiceのような設定でTool利用を制御できる場合があります。
ここまで来ると、「LLMのParameter」という話は単純な文章生成だけの話ではなくなります。
Reasoning EffortはTemperatureとは別の話
Reasoning Modelでは、Reasoningに関係するParameterが用意されていることがあります。
概念的には、
Reasoning Effort
↓
回答を生成するための推論に
どの程度のリソースを割くか
というものです。
Temperatureとは違います。
Temperature
↓
Token Samplingの性質
Reasoning Effort
↓
推論の程度
です。
つまり、
Temperatureを下げれば、より深く考える
ということではありません。
Token Samplingの調整と、Reasoningの調整は別の話です。
Parameterを「作用する場所」で見てみる
ここまで出てきたParameterを並べると、役割がかなり違うことが分かります。
Parameters
│
├─ Model Parameters
│ └─ Learned Weightsなど
│
└─ API / Inference Parameters
│
├─ Sampling
│ ├─ Temperature
│ └─ Top P
│
├─ Generation Limit
│ └─ Max Tokens
│
├─ Penalty
│ ├─ Frequency Penalty
│ └─ Presence Penalty
│
├─ Reproducibility
│ └─ Seed
│
├─ Termination
│ └─ Stop
│
├─ Output Control
│ └─ Response Format
│
├─ Tool Control
│ └─ Tool Choice
│
└─ Reasoning Control
└─ Reasoning Effort
表にすると、次のようになります。
| 分類 | Parameter | 主な役割 |
|---|---|---|
| モデル内部 | Model Parameters | 学習されたWeightなど |
| モデル選択 | Model | どのモデルを利用するか |
| Sampling | Temperature | 確率分布を調整 |
| Sampling | Top P | 候補Tokenを絞る |
| 出力量 | Max Tokens | 最大生成量 |
| 反復抑制 | Frequency Penalty | 頻出Tokenを抑える |
| 多様性 | Presence Penalty | 既出Tokenを抑える |
| 再現性 | Seed | 再現性を高める |
| 終了 | Stop | 生成停止条件 |
| 出力 | Response Format | 出力構造 |
| Agent | Tool Choice | Tool利用の制御 |
| Reasoning | Reasoning Effort | 推論の程度 |
こうして見ると、
Parameter = AIの賢さを調整するツマミ
ではないことが分かります。
それぞれ、処理の違う場所へ作用しています。
Parameterを調整してもModelそのものは変わらない
最後に、一番重要だと思っているところです。
高性能なModel
+
適切なParameters
と、
能力の低いModel
+
Parametersを頑張って調整
は同じではありません。
TemperatureやTop Pをいくら調整しても、モデルそのものの知識や推論能力が増えるわけではありません。
Parameterは、
モデルが持っている能力を、推論や生成の中でどう使うかを調整するもの
と考えると分かりやすいです。
文章生成だけをかなり単純化すると、
Input / Context
│
┌───────┼────────┐
│ │ │
Instructions History RAG ...
│ │ │
└───────┼────────┘
↓
┌───────────┐
│ Model │
└─────┬─────┘
│
Logits
│
↓
┌─────────────────┐
│ Sampling Params │
│ │
│ Temperature │
│ Top P │
│ Penalties │
└────────┬────────┘
│
↓
Token Selection
│
↓
Output
となります。
Agentになると、さらに、
Prompt
+
Context
+
Tools
↓
Model
↓
Reasoning
↓
Token Generation / Tool Call
↓
Tool Result
↓
Contextへ追加
↓
Model
↓
Output
というループになります。
LLMを理解するとき、Parameter名を暗記するより、
そのParameterは、処理のどこに作用しているのか?
と考える方が理解しやすいと思います。
TemperatureならSampling。
Max Tokensなら出力量。
Response Formatなら出力構造。
Tool ChoiceならTool利用。
Reasoning EffortならReasoning。
そして、それらを動かしている本体がModelです。
Parameterという名前を見たときには、
「この値を変えると、モデルそのものが変わるのか。それとも、モデルを使う処理のどこかが変わるのか」
と考えてみる。
私は、その見方の方がParameter名を一つずつ暗記するより、LLMを理解しやすいと思っています。