LLM における温度とは何か？

Scrapeless Agent Browser は、ウェブ自動化のためのクラウドブラウザを提供します。

LLM における温度は、次のトークンをサンプリングする際に用いられる相対的な確率を変化させるデコーディングパラメータです。低い正の値は、高スコアの候補に確率を集中させます。高い値は分布を平坦化し、起こりにくい候補がより頻繁に選ばれることを許します。温度は選択の挙動を変えるものであり、モデルに知識を追加するものではありません。

その区別は、本番環境のアシスタントを構成する際に重要です。より多様な言い回しはブレインストーミングに役立つ一方で、抽出では一貫した書式の方が重要かもしれません。どちらの目的も、万能な最適数値に還元することはできません。実際のモデル、プロンプト、タスクを評価して設定を選択してください。

温度はトークン確率をどう変えるか

温度は、サンプリング分布が計算される前にトークンスコアを再スケーリングします。一般的な定式化では、各候補のロジットを正の温度で割り、その結果に softmax を適用します。値が 1 のとき、温度はロジットを再スケーリングしません。1 未満の値は既存のスコア差をより顕著にし、1 を超える値はその相対的な効果を弱めます。

仮想的な次トークン選択の場面を考えてみましょう。一方の候補が他方より高いスコアを持っているとします。温度を下げると、高スコアのトークンの相対的な優位性が増します。これは証拠チェックを導入したり、そのトークンが真かどうかを判断したりするものではありません。この仕組みは、モデルが予測した継続部分に対して動作し、自信はあるが裏付けのない記述を優先することもあります。

The ニューラルテキストのデコーディングに関する研究 は、学習目標と生成挙動を区別し、デコーディングの選択がテキスト品質に影響する理由を検証しています。アプリケーション設計にとって有用な帰結は単純です。完全な出力を評価してください。トークン単位の変更は、単一の例からは分からない形で、後続の文、ツール選択、停止判断を変える可能性があります。

低温度でできること・できないこと

低温度は一般に、もっともらしい継続を優先することでサンプリングの変動を減らします。これは、タスクが安定したラベル、簡潔な抽出、一貫した言い回しを必要とする場合に有用です。それでも依然として確率的な生成設定であり、正しさを保証するものではなく、その効果はモデルや提供システムがデコーディングをどのように実装しているかに依存します。

0 として公開されている値は、しばしば単なる 0 での割り算ではなく特別なデコーディングケースとして扱われます。その挙動に依存する前に、選択したモデルのインターフェースを確認してください。貪欲な選択ポリシーであっても、あらゆるデプロイ条件で常に同一の出力を約束するものとして説明すべきではありません。モデル更新や提供の詳細は、可視化されたサンプリング制御とは独立に再現性に影響し得ます。

仮想的な商品抽出タスクでは、設定を低くすると出力フォーマットは安定する一方で、誤った通貨を繰り返し返すかもしれません。この場合に必要なのは、証拠の扱いと検証の改善です。温度をさらに下げても、入力に含まれていない通貨を供給することはできません。期待から補完させるのではなく、欠損値は欠損値として明示的に保ってください。

なぜ高温度が創造性の保証にはならないのか

高温度は、低確率の継続が選ばれる可能性を高め、より多様な出力を生むことがあります。その多様性は、名前の検討、言い換え、可能な解釈を探索するのに役立つことがあります。同時に、無関係または一貫性のないテキストを生むこともあります。設定が有用なバリエーションを高めているかを測る前に、有用なバリエーションとは何かを定義してください。

ブレインストーミングの評価では、制約を満たしつつ意味のある違いを持つアイデアを高く評価するかもしれません。事実に基づく要約の評価では、文体が魅力的であっても裏付けのない主張を減点するかもしれません。これらのタスクには異なる評価基準が必要です。ユニークな語の数を数えることは、出力が有用かどうかを評価するための弱い代替案にすぎません。

温度と問題解決性能 に関する研究は、普遍的な精度ルールではなく、タスクやモデルに依存した挙動を見いだしています。低温度を真実設定として扱ったり、高温度を知能設定として扱ったりするのは避けてください。自分が気にかける実際の挙動を評価し、その選択の根拠となる証拠を保持してください。 温度と top-p およびその他の制御の違い

温度は相対スコアを再スケーリングし、top-p は累積確率がしきい値に達するトークン集合にサンプリング対象を制限します。これらの制御は選択プロセスの異なる部分に影響します。両者の組み合わせた挙動は、モデルインターフェースが実装する順序や詳細に依存します。

出力長の制限は、「どれだけのテキストを生成してよいか」という別の問題に対処します。フォーマット制約は、許容される出力構造に関わります。システムインストラクションは、望ましい挙動を記述します。いずれか 1 つの制御を変えても、他の制御が不要になるわけではありません。低温度の応答であっても、長すぎたり、下流のパーサにとって不正な形式だったり、ソースで裏付けられていなかったりする可能性があります。

問題の診断時には、一度に 1 つの制御だけを変更してください。プロンプトを書き換え、検索結果を差し替え、サンプリングも変更すると、結果が改善してもどの介入が寄与したのか分かりません。比較可能性を保つため、各評価について入力、モデルの識別情報、設定、スコアリング判断を記録してください。

Scrapeless でスクレイピングを始めよう

反復可能な評価で設定を選ぶ

温度の選択は、タスク固有の評価セットと許容される振る舞いの定義から始めるべきです。通常のリクエストに加え、あいまいな入力、不足している証拠、矛盾する情報源、異常に長い文書などの難しいケースも含めてください。候補となる設定間で、同じ評価入力を維持してください。

各設定を複数のリクエストで実行し、品質とばらつきの両方を確認します。繰り返しサンプリングは、単一のうまくいった回答では見えない不安定性を明らかにできます。実行回数は、一律で任意の要件を課すのではなく、その決定のコストと観測されたばらつきに応じて設定してください。失敗した例も記録に残してください。それらを除外すると、実際よりも設定が優れて見えてしまいます。

構造化抽出では、フィールド精度、欠損値の扱い、出力の妥当性を別々に評価します。ライティングでは、制約の順守と有用な多様性を評価します。エージェントでは、ツール引数と完了条件を評価します。文章の多様性を高める設定は、ツール選択タスクの予測可能性を下げるかもしれないため、アプリケーションが構成を分けられる場合は、それらの側面を独立してテストしてください。

サンプリングの問題と証拠の問題を分ける

サンプリングの問題は、モデルがどのように回答を選ぶかのばらつきに関するものであり、証拠の問題は、必要な情報が利用可能で信頼できるかどうかに関するものです。回答に裏付けのない最新の事実が含まれている場合は、まず証拠の問題を診断してください。別の温度にしても、モデルに保存された知識は更新できません。

この リアルタイムのウェブ検索ワークフロー は、最新の情報源の取得に対処します。アプリケーションは依然として、その素材を精査し、どれが回答を裏付けるかを判断する必要があります。ブラウザアクセスとデコード設定は異なるレイヤーで動作するため、それぞれのレイヤーをその責務に照らして評価してください。

追加コンテキストは、情報だけでなく気を散らす要素も持ち込む可能性があります。 言語モデルタスクにおける無関係なコンテキスト に関する実験は、なぜコンテキスト選択に個別の注意を払う必要があるかを示しています。不一致な回答を修正するためにサンプリングを調整する前に、プロンプトが関連する証拠と無関係なナビゲーション、重複コンテンツ、取得したページからの矛盾した指示を混在させていないか確認してください。

意思決定タイプ別にエージェントを構成する

エージェントはいくつかの種類のモデルによる意思決定を行うことがあり、共有された温度がそれらに異なる影響を与える可能性があります。検索クエリの作成、ツールの選択、価格の抽出、最終説明文の作成は、同一の要件を持ってはいません。アーキテクチャが対応している場合は、タスク全体に1つの設定が当てはまると仮定するのではなく、意思決定タイプごとに構成を評価してください。

実行上の制約はサンプリングの外側に保ってください。ツールの許可リスト、引数の検証、支出上限は、モデルがどのようなテキストを生成するかに関係なく有効であるべきです。エージェントが許可されていないアクションを提案した場合、ランタイムはそのアクションを拒否しなければなりません。より保守的なサンプリングは望ましくない提案をいくらか減らすかもしれませんが、アクセス制御の負担を負うべきではありません。

ブラウザベースのタスクでは、 Agent Browser がインタラクションの表面を提供します。モデルの構成は、それを取り巻くアプリケーション側に属します。モデル呼び出しのコストとブラウザ作業のコストを分けて比較し、後者には Scrapeless pricing を用いて、すべてのランタイム料金をトークンとして扱わないようにしてください。

結果の限界を記録する

温度の推奨は、それを裏付ける評価の範囲を明示すべきです。モデル構成、タスクセット、プロンプトのバージョン、品質基準を記録してください。これらのいずれかが変わった場合、以前の結果を現行のものとして扱う前に、その設定が同じ要件をまだ満たしているか確認してください。

狭い範囲の評価結果を、すべての言語モデルに対する一般則として報告することは避けてください。2つのシステムが同じ名前のパラメータを公開していても、そのサポート、デフォルト値、他の制御との相互作用は異なる場合があります。有用なエンジニアリングメモは、何が評価され、どのような失敗ケースが残っているかを示します。ある値が普遍的に最も安全、あるいは最も創造的だと主張する必要はありません。

要点

温度はトークンサンプリングに用いる分布を制御します。アプリケーションに必要な振る舞いを測定して選択し、欠落している証拠や不十分な検証は別個に調査してください。明確なタスクルーブリックから始め、固定入力上で候補設定を比較し、なぜその設定が適合しているのかを説明する例を保存しておきましょう。