LLM temperatureとは：top-pとサンプリングの計算例

LLM temperature（温度パラメータ）は、サンプリング前に次のトークンの確率分布の集中度を変える生成設定です。正の温度を低くすると、通常は元から確率の高いトークンが選ばれやすくなり、温度を高くすると分布が平坦になります。核サンプリングとも呼ばれるtop-pは、累積確率が指定したしきい値に達する、確率の高いトークンの集合にサンプリングを限定します。

執筆：Ai Flowi · 公開日 2026-10-11

サンプリングで次のトークンを選ぶ

生成型の言語モデルは、プロンプトと生成済みのトークンを使って、次に出現し得るトークンにスコアを付けます。サンプリング手順は、そのスコアをもとにトークンを選びます。応答が伸びるにつれてこの処理が繰り返されるため、初期のトークンが違うと、その後の文章も変わることがあります。これらのパラメータは選択に影響しますが、不足する事実を補ったり、モデルの学習済みの重みを変えたりはしません。

トークンは、回答の選択肢全体ではなく、単語の一部の場合もあります。以下の例では計算を確認しやすいように、4つの抽象的な候補をそれぞれ1つのトークンとして扱います。表すのは生成の1段階だけであり、応答全体、分類の確信度、文が真である確率を表すものではありません。

4候補の確率表

確率は説明用に作成した入力値であり、モデルの測定値ではありません。 核サンプリングの絞り込みを適用する段階で、候補A、B、C、Dの確率を0.50、0.30、0.15、0.05とします。すでに大きい順に並んでおり、合計は1.00です。

Aだけでは0.8に届きません。Bを加えるとしきい値に達するため、この例ではAとBを残し、その段階からCとDを除きます。残った確率の合計は0.80です。各確率を0.80で割ると、0.50 / 0.80 = 0.625、0.30 / 0.80 = 0.375になります。絞り込み後の確率の合計は1です。

残ったどちらのトークンも選ばれる可能性があります。top-pが0.8でも、Bが選ばれる、毎回違う応答になる、出力が正しい確率が0.8である、という意味ではありません。しきい値は候補選択に使う確率の合計を定めるものであり、事実の信頼度を示すスコアではありません。

しきい値を超えることになるトークンも集合に含めます。同じ説明用の分布でしきい値を0.75とすると、Aだけでは不足し、合計が0.80でも、AとBが、先頭から選んだ、しきい値を満たす最小の候補集合になります。しきい値が0.90の場合はCも必要です。これは計算例であり、プロバイダー設定の推奨値ではありません。

同じ例で温度が変えるもの

通常のソフトマックスの式では、ロジットと呼ばれるトークンのスコアを、確率に変換する前に正の温度Tで割ります。基準の確率が同じスコアからT = 1で得られた場合、調整後の確率はp^(1/T)に比例します。変換後の各値を合計値で割って正規化します。

説明用にT = 0.5とすると、基準値を2乗します。値は0.25、0.09、0.0225、0.0025となり、合計は0.365です。0.365で割ると、以下の分布になります。これは仮定した入力値による計算であり、スライダーを操作した際の観測結果ではありません。

丸めているため、表示した列の合計は正確に1にならない場合があります。温度によって相対的な選ばれやすさは変わりますが、A、B、C、Dの順序は変わりません。正のTを高くすると、逆に分布が平坦になります。どちらの変化も、どの候補がタスクの受け入れ基準を満たすかを確定するものではありません。

温度とtop-pはどう相互作用しますか？

この計算例では、温度の調整を核サンプリングの候補選択より先に行います。T = 0.5では、絞り込み前のAとBの確率の合計は約0.9315です。top-pのしきい値が0.8でも、この2候補が残りますが、再正規化後はAが約0.7353、Bが約0.2647になります。同じ候補を残しても、選ばれる確率が同じとは限りません。

すべてのAPIがこの順序でサンプリング設定を適用し、同じ選択肢を提供すると考えてはいけません。利用可能な場合、top-kは累積確率ではなく候補数を制限します。制約、ペナルティー、モデル固有の動作も分布に影響することがあります。出力の違いを解釈する前に、実際に設定したモデルで有効になった設定を確認してください。

T = 0は、上記の正の温度の式の対象外です。APIは、貪欲選択モードや別の特別な規則でゼロを扱う場合があります。ゼロが最も確率の高いトークンを要求する場合でも、呼び出し、モデルの改訂、提供環境が変わっても同じ文章になるという共通の保証ではありません。根拠のない回答を正しくすることもできません。

AI Flowi Workflowで文書化されている設定

要求インターフェースはLanguage Modelのリファレンスを参照してください。サンプリング設定に関しては、temperatureがsliderとしてエクスポートされており、この項目にはtop_pという名前のフィールドがない点に注意します。

Vertex AIのカタログ項目では、別途temperatureとtop_pをfloat、top_kをintとして公開しています。そのため、記録用紙では、要求した各設定をどのコンポーネントが提供したかを区別する必要があります。

Language ModelとVertex AIの状態：カタログに記載されていますが、Ai Flowiによる本番環境でのテストは実施されていません。 エクスポートには、これらのフィールドの範囲、既定値、検証済みのサンプリング順序はありません。フィールドが存在しても、選択したすべてのモデルが受け入れるとは限りません。このページには、これらを組み合わせたワークフローの検証済み事例や、すべてに通用するスライダーの推奨値はありません。

自分で試す場合は、利用権限のあるプロバイダーアカウントと、そのAPIキーまたは必要な認証情報を使います。プロバイダーのモデル呼び出しは別料金です。秘密情報は評価記録に含めません。保存した設定が有効になったと決めつけず、実際の応答やエラーを確認します。

繰り返し出力の評価記録

比較ごとに、同じタスク入力、指示、原文の根拠を使います。対応しているサンプリングパラメータを1つずつ変え、変えていない設定も記録します。以下は記入前の手作業用の記録用紙であり、標準のログ機能でも完了済みのテストでもありません。

試行ID:
モデルとバージョン（公開されている場合）:
正確なプロンプトと原文の根拠のバージョン:
要求した温度、top-p、top-k（対応している場合）:
確認した有効な設定、または不明:
試行番号と保存した出力:
プロバイダーのエラーまたは出力の欠落:
タスクの受け入れ確認と確認担当者の判断:
表現が変化、判断が変化、または変化なし:
この設定を受け入れる、または拒否する理由:

候補となる各設定を、同じ確認済みの入力で繰り返し試し、すべての試行を残します。ラベル付けのタスクでは、表現の変化とラベルの変化を分けます。原文に基づく回答では、主張が引き続き根拠と一致しているかを確認します。エラーを捨てて好ましい応答だけを数えたり、少数の完成した回答だけからトークンの確率を推測したりしてはいけません。

指示の設計はプロンプトエンジニアリング、アクションの確認はAIエージェント評価ガイドで扱います。この記録では、サンプリング設定を変えたときに何が変わるかを測ります。

同じ回答が繰り返されても、温度フィールドが無視されたとは断定できません。確率の高い冒頭のトークンが複数回のサンプリングを占めることがあり、異なるトークンの経路でも似た文章になることがあります。一方、モデルのバージョンや原文の文脈も変わった場合、回答が変わっても要求した設定が有効になった証拠にはなりません。有効な設定を確認できていない場合は不明と記録し、見た目だけでパラメータについて結論を出さないようにします。