今頃聞けないLLMの「温度」の話を徹底解説
温度とは何か?——AIの「性格」を決める魔法のつまみ LLMが文章を生成するプロセスは、次に続く単語を無数の候補の中から一つずつ選んでいく、連続した予測作業です。このとき、AIは各候補単語に対して「次に来る単語として、どれくらいふさわしいか」を点数化します。これを「スコア」と呼びましょう。 例えば、「今日の天気は」という文の次には、「晴れ」「雨」「曇り」といった単語が候補に挙がります。LLMは内部の知識から、「晴れ」のスコアが最も高く、次いで「曇り」、「雨」と続く、というように序列をつけます。 ここで登場するのが「温度」です。LLMは、このスコアをそのまま使うのではなく、最終的に「softmax」という関数を通して「確率」に変換します。この変換プロセスの直前に、各単語のスコアを温度の値で割り算するという一手間が加えられます。この単純な割り算こそが、AIの性格を劇的に変えるのです。 温度が低い場合(例:0.2):スコアを小さな値で割るため、元々スコアが高かった単語と低かった単語の差が、さらに大きく開くことになります。先ほどの例で言えば、1位の「晴れ」のスコアが突出して高くなり、その確率が90%以上にまで跳ね上がる一方、2位以下の単語の確率は限りなく0に近づきます。結果として、LLMはほぼ間違いなく「晴れ」という単語を選びます。これは、最も「勝ち筋」と判断した選択肢に強く依存する、堅実で保守的な振る舞いと言えます。 温度が高い場合(例:1.0):スコアを比較的大きな値で割るため、スコア上位の単語と下位の単語の差が縮まります。1位の「晴れ」の確率が少し下がり、その分2位の「曇り」や3位の「雨」、さらには少し意外な「最高」といった単語が選ばれる可能性も出てきます。これは、多様な選択肢に目を向け、時には意外な一手を打つ、柔軟で創造的な振る舞いです。 つまり、「温度」とは、LLMが持つ知識や理解そのものを変えるスイッチではありません。同じ知識を元にしながら、それをどのような性格(キャラクター)で表現するかを調整するためのダイヤルなのです。料理に例えるなら、レシピ(知識)は同じでも、「火加減(温度)」を変えることで、しっかり焼き上げるか、ふんわりと仕上げるかをコントロールするようなものだとイメージすると分かりやすいでしょう。 ユーザー体験は温度で決まる——「堅実さ」と「ひらめき」のトレードオフ この「温度」というダイヤル調整は、ユーザーが直接触れるサービスの体験(UX)に絶大な影響を与えます。システムの要件に応じて、どちらの方向性を優先するかを明確にすることが、設計の第一歩となります。 低温度がもたらす「安心感」と「一貫性」 温度を低く設定すると、LLMの応答は安定し、表現も落ち着いたものになります。同じ入力に対しては、ほぼ同じ出力が返ってくるため、ユーザーは予測可能な対話を行えます。これは、特に以下のような業務領域で大きな価値を発揮します。 FAQチャットボット: 顧客からの問い合わせに対し、常に規定通りの正確な情報を提供する必要がある。 設定情報の自動生成: JSONやSQLなど、厳密な構文が求められるコードを生成する。 社内規程に基づいた案内: コンプライアンス上、逸脱した解釈や表現が許されない情報の提示。 これらの用途では、誤解や誤情報のリスクを最小限に抑えることが最優先されます。創造性よりも、信頼性と一貫性が求められる場面では、低温度の設定が基本方針となります。 高温度がもたらす「柔軟性」と「創造性」 一方、温度を高く設定すると、LLMの応答は人間らしい柔らかさを持ち、表現の幅が大きく広がります。同じ質問をしても、その時々で異なる言い回しや視点を提供してくれるため、対話が単調になりません。 アイデア出しの壁打ち: 新しい企画や広告のキャッチコピーについて、多様な切り口の提案が欲しい。 文章の校正・リライト: 硬い表現の文章を、より自然で分かりやすい表現に言い換える。 パーソナルアシスタント: ユーザーとの雑談や対話の中で、親しみやすさや驚きを提供する。 ただし、高温度の設定は諸刃の剣です。表現が豊かになる一方で、事実に基づかない情報(ハルシネーション)を生成したり、文脈から逸脱した応答をしたりするリスクも高まります。企業利用においては、この「ひらめき」のメリットと、「正確性の低下」というデメリットを天秤にかけ、どのレベルのリスクまで許容できるかを慎重に判断する必要があります。 「温度0」でも答えがブレる?——システム開発者が知るべき再現性の罠 理論上、温度を0に設定すれば、スコアの割り算は行われず、常に最高スコアの単語が100%の確率で選ばれるはずです。したがって、同じ入力(プロンプト)に対しては、必ず同じ出力が得られると期待されます。 しかし、実際の運用環境では、温度を0にしても応答がわずかに揺らぐことがあります。これは、多くの開発者を悩ませる「再現性の罠」であり、その原因はLLMの推論サーバ内部の計算方法にあります。 コンピュータが扱う小数(浮動小数点数)の計算は、足し算の順番が変わると、ごくわずかな「丸め誤差」が生じる特性を持っています。一方、LLMの推論サーバは、処理効率を高めるために、複数のリクエストをまとめて(バッチ処理で)計算します。その時々のサーバの負荷状況によって、このバッチサイズ(一度に処理するリクエスト数)は変動します。 バッチサイズが変わると、内部の計算、特に複数の値を合計するような処理(例えばRMSNormや行列積など)の順序が微妙に変化することがあります。この順序の変化が、前述の丸め誤差を生み、最終的な各単語のスコアに、ごくごく僅かな差となって現れるのです。 普段なら無視できるほどの小さな差ですが、もし複数の単語のスコアが非常に僅差で競い合っている場面では、この誤差が順位の逆転を引き起こす可能性があります。一度違う単語へ分岐してしまえば、その後の文章生成は全く異なるものになります。これが、温度0でも応答が固定されない現象の正体です。 では、どうすれば完全な再現性を確保できるのか? システムの要件として、入力と出力の一致が厳密に求められる場合は、以下の対策を講じる必要があります。 バッチ不変な実装の採用: バッチサイズが変わっても計算順序が変動しないように設計された推論用の実装(ライブラリやカーネル)を選択します。 環境の完全固定: モデル、推論エンジン、各種ライブラリ、GPUドライバなど、実行環境のバージョンをすべて固定します。 乱数シードの固定: 乱数を用いる処理が含まれる場合に備え、シード値を固定します。 これらの対策を徹底することで、初めて「同一入力に対して、同一出力を保証できる」と言い切れるようになります。 合わせ技で応答を磨く——top-p, top-k, ペナルティとの賢い付き合い方 実務では、「温度」単体で応答を制御することは稀で、他のサンプリング関連パラメータと組み合わせて使うのが一般的です。代表的なものに「top-p」と「top-k」、そして各種「ペナルティ」があります。これらの役割を理解し、適切に使い分けることが、応答品質を磨き上げる鍵となります。 top-k: 単純明快で、スコアが上位「k個」の単語だけを次の候補とします。例えば k=5 なら、どんなに確率分布がなだらかでも、候補は5つに絞り込まれます。 top-p: 確率が高い順に単語を足し上げていき、その合計確率が「p」に達した時点で候補を打ち切ります。例えば p=0.9 の場合、上位の数単語で確率の9割を占めるような分布(低温度時など)では候補が少なくなり、逆に確率が分散している分布(高温度時など)ではより多くの単語が候補に含まれます。文脈に応じて候補数を動的に変える、賢い手法です。 ペナルティ…

