0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

LLMの「モデル」と「パラメーター」をちゃんと分けて考える

0
Posted at

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を理解しやすいと思っています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?