Token・確率・サンプリング

文字列はどう入力になり、スコアから次の token はどう決まるのでしょうか。テキスト → token ID → logits → 確率 → 選択を辿り、温度と候補の絞り込みを比べます。数値例はデコードの仕組みを示し、設定の良否は実際のタスクで評価します。

テキストからトークンIDへ

トークンは語彙の単位であり、文字や単語とは一致しない

テキストモデルは通常、文字列を整数のシーケンスにエンコーディングします。各整数は語彙内のトークンに対応します。1つのトークンは、完全な単語、単語の一部、句読点、空白の組み合わせ、またはバイトの断片を表すことができます。1つのUnicode文字が複数のトークンにまたがることもあれば、逆に複数の文字が1つのトークンに合成されることもあります。したがって、すべてのモデルの入力を「漢字数×2」で計算することはできません。

BPE（Byte Pair Encoding）は一般的なサブワード構築手法です。トレーニング時には小さな単位から始め、コーパスの統計に基づいて隣接する単位を反復的にマージします。エンコーディング時には、毎回トレーニングを行うのではなく、すでに学習済みの語彙とマージルールを使用します。例えば、⁠仮に順序通り (l,o)→lo、(lo,w)→low のマージが学習されている場合、l o w e r は low e r として処理されます。これはメカニズムの例示であり、既存のモデルが lower を実際にどのように分割するものではないことに注意してください。

バイトレベルBPEは、バイトを基礎とした表現を使用して、純粋な文字ベースの語彙で特定の文字が欠落する問題を回避できますが、「BPE」という名前自体がバイトフォールバックを保証するものではありません。トークン化には、UnigramやWordPieceなどの手法も使用され、設定内の正規化、プリトークン化、特殊トークンも最終結果に影響を与えます。Tokenizers モデルタイプ

なぜ本文のみをカウントすれば十分ではないか

チャットシステムでは、役割やメッセージの境界をモデル入力にエンコーディングする必要があります。ツール定義、構造化コンテンツ、画像なども追加のカウントを生成する可能性があります。ユーザーに見える文字列の長さと、モデルの入力長さは異なる表現層に属しています。完全なリクエストがどのように構築されるかをまず決定し、その後にトークン数を計算する必要があります。

例えば、2つのユーザーメッセージと、2つのテキストを1つのメッセージに結合した場合、本文の文字数は完全に同じでも、メッセージの境界は異なる可能性があります。トークナイザーに正規化処理が含まれている場合、外見が同じまたは類似したUnicode文字列でも異なる結果を生じることがあり、すべてのトークナイザーがこの差異を保持する、あるいは消除するとは限りません。トークナイズパイプライン

サーバー側のカウントは、対象モデルに対応するインターフェースを使用し、実際のレスポンスの usage 情報でキャリブレーションを行うべきです。Claudeのカウントドキュメントでも、カウント結果は推定値であり、モデルが更新されたら再カウントすべきであると説明されています。すべての中国語、コード、ツールスキーマに通用する、モデル間の換算倍率は存在しません。Claude トークンカウント

ロジットから確率へ

標準的な自己回帰的テキスト生成は、現在のプレフィックス条件下で次のトークンを予測します。モデルは語彙の各位置に対するスコア（ロジット）を出力し、デコーダーは設定に基づいて1つのIDを選択し、それをプレフィックスに接続して続行します。実際の推論エンジンではバッチ処理や推論デコーディングを使用して実行を最適化できますが、条件生成のセマンティクスはこの段階的なプロセスとして理解できます。

正の温度 $T$ において、softmaxの数値的に安定した書き方は以下の通りです：

pᵢ = exp((zᵢ − max(z))/T) / Σⱼ exp((zⱼ − max(z))/T)

最大値を引くことで正規化後の確率には影響を与えませんが、巨大な指数を直接計算することを回避できます。A、B、Cの3つの候補のみが存在し、ロジットが [2, 1, 0] であると仮定します：

温度を下げる（降温）と相対的なスコア差が拡大し、温度を上げる（升温）と分布はより平坦になります。これは選択のランダム性を変化させますが、「正解率のノブ」ではありません。もし誤った答えが本来最も高いスコアを持っていた場合、温度を下げるとその誤答をより安定的に選択することになります。また、回答全体が1回のサンプリングで書かれるわけではなく、初期のトークンの変化が後の条件分布を変更します。

候補の絞り込み：top-k と top-p

top-k はスコアが最も高い k 個の候補を保持します。top-p は確率でソートし、累積確率が閾値 p に初めて達する最小の接頭辞を保持し、その後、保持された集合内で再正規化を行います。後者の集合サイズは分布に応じて変化します。

上記の T=1 の分布において、top-p=0.8 の場合、A だけの確率は 0.6652 で不十分です。B を加えると約 0.9100 になるため、A と B を保持し、C を棄却します。再正規化すると A≈0.7311、B≈0.2689 となります。top-p=0.8 は語彙の 80% を保持するわけでも、最高スコア候補に 80% の確率を持たせるわけでもありません。

T=0.5 の場合、A だけの確率がすでに 0.8 を超えているため、同じ閾値でも A だけを保持します。したがって、温度とフィルタリングの順序は結果に共同で影響を与えます。異なるエンジンでは、ペナルティ、最小保持数、その他のフィルターを組み合わせる場合もあります。具体的な実装の順序を確認する必要があり、異なるサービス上の同名のパラメータを完全に同一であると見なしてはいけません。Transformers 生成設定

以下の独立した例では、表の数値を再現し、「温度適用後に top-p を行う」という順序を明確に採用しています。モデルのダウンロードは不要です。

import math

def softmax(logits, temperature=1.0):
    if not logits or temperature <= 0:
        raise ValueError("空でないロジットと正の温度が必要です")
    peak = max(logits)
    weights = [math.exp((z - peak) / temperature) for z in logits]
    total = sum(weights)
    return [w / total for w in weights]

def nucleus(probs, threshold):
    if not 0 < threshold <= 1:
        raise ValueError("閾値は (0, 1] の範囲である必要があります")
    kept, mass = [], 0.0
    for i in sorted(range(len(probs)), key=lambda i: (-probs[i], i)):
        kept.append(i)
        mass += probs[i]
        if mass >= threshold:
            break
    return {i: probs[i] / mass for i in kept}

p = softmax([2, 1, 0])
q = nucleus(p, 0.8)
assert list(q) == [0, 1]
assert math.isclose(q[0], 1 / (1 + math.exp(-1)))
assert nucleus(softmax([2, 1, 0], 0.5), 0.8) == {0: 1.0}
assert math.isclose(sum(p), 1.0)
assert len(nucleus(p, 1.0)) == 3
print([round(x, 4) for x in p])
print({i: round(v, 4) for i, v in q.items()})
# [0.6652, 0.2447, 0.09]
# {0: 0.7311, 1: 0.2689}

この実験は確率変換を検証するものであり、ある閾値が実際のタスクでより優れていることを証明するものではありません。ニューラルテキスト退化の元研究では、オープンエンドのテキスト生成における確率の裾野と退化問題について議論されています。その結果から、翻訳、コード、分類などのすべてのタスクで同じデコーディング方式を採用すべきだと直接導き出すことはできません。The Curious Case of Neural Text Degeneration

確率から 1 回の選択へ

確率を [0,1) の区間と考えると、抽選は u の位置探しです。C を消すだけでは隙間が残るため再正規化が必要です。与えられたスコアからの選択であり、正答確率を示すものではありません。

$$p_i=\frac{e^{(z_i-\max z)/T}}{{\sum }_j{e}^{(z_j-\max z)/T}}$$

貪欲選択と決定論

greedy（貪欲法）は、各ステップで最高スコアの候補を選択します。T=0 の場合、上記の除算公式は未定義になります。いくつかのインターフェースではゼロ温度を貪欲デコーディングとして規定していますが、他のインターフェースではサンプリングを無効にするために個別のパラメータを要求します。数学的な極限とインターフェースの規約を区別する必要があります。

貪欲法は局所的な選択を保証するだけです。ステップ1で A=0.6、B=0.4 であり、A を選択した後の最適な次のステップ確率が 0.5、B を選択した後の最適な次のステップが 0.9 であると仮定します。この場合、2つの候補パスの確率はそれぞれ 0.30 と 0.36 になります。段階的な貪欲法はまず A を選択しますが、これは2つのパスのうち確率がより高い方ではありません。ビームサーチは、複数の候補を保持することでこの種の問題を緩和しますが、検索幅、長さバイアス、スコアリング目標の制限を受け続けます。シーケンス確率が最高であっても、それが事実上最も正しいことを意味するわけではありません。

完全に同一のロジットに対して、同点処理を固定した argmax は決定論的です。しかし、実際のサービスが完全に同一のロジットを再度生成できるかどうかは、モデルバージョン、精度、カーネル、バッチ処理、および決定論設定に依存します。固定シードは、対応する乱数プロセスのみを制御し、すべての実行条件をロックするものではありません。低い温度だけでは逐バイトの再現性を約束できず、低い effort（努力/リソース投入）も決定論の代替設定ではありません。

監査や回帰テストのためには、完全な入力、モデルと生成設定、サービスバージョン情報、および生出力を保存してください。もし以前表示された内容を再現する必要がある場合は、その時の保存結果を読み取るべきです。これは、モデルを再実行して同じ答えを得るのとは異なる、2種類の保証です。

各段階の最大値は経路全体でも最大か

局所選択は現在の接頭部分に対する候補だけを比較します。B の続きが 0.75 を超えると経路の順位は逆転しても、貪欲法は A を選びます。確率の比較から真偽は決まりません。

出力の停止とフォーマット制約

例えば、注文JSONを生成する際、スキーマで quantity が整数であることを要求していても、倉庫の実在庫が2個しかないことまでは知らない可能性があります。出力 {"quantity": 5} は構文としては有効でも、業務的には無効です。クライアント側では、停止理由の確認、完全な解析、フィールド検証の実行、および業務層での在庫と権限の検証を行う必要があります。

重複ペナルティにもトレードオフがあります。コード内の変数名、JSONフィールド、または固定用語は、本来繰り返し出現する必要があります。強すぎるペナルティは一貫性を損なう可能性があります。サンプリングパラメータを選択する前に、出力プロトコルとタスク制約を確認してください。構造化出力の完全なフローについては、プロンプトエンジニアリングと構造化出力 を参照してください。

移行時のベースライン再構築

モデルを変更する際は、トークナイザー、チャットテンプレート、サポートされている生成パラメータとそのデフォルト値をそれぞれ確認し、同じタスクセット上で長さ、フォーマット通過率、タスクの正解率、結果のばらつきを比較してください。「ローカル」または「ホスト済み」という理由だけで、特定のパラメータがサポートされる、またはされないことを推測しないでください。具体的なモデルとエンドポイントを基準にしてください。Claude 移行ガイド

新しいインターフェースで temperature が提供されなくなった場合は、サポートされていないフィールドをまず削除し、明確なタスク制約と評価を用いて出力動作を確認してください。effort は推論リソースの投入を調整し、temperature はサンプリング分布を調整します。これらを数値でマッピングすることはできません。「4つの異なる方案を提示する」と要求することは、出力目標を表現しますが、温度を上げるのとは等価ではありません。「1つのラベルのみを出力する」と要求することも、effort を下げるのとは等価ではありません。推論リソースの独立したトレードオフについては、推論と思考 を参照してください。

次に読む：Attention・FFN・MoE。