サンプリング設定

サンプリングは推論の最後の1インチ。モデルは語彙の全トークンにスコアを付け、あなたの設定がその分布を1トークンにどう変えるかを決める。ノブは相互作用するので、操作順序がどの単一値より重要。

パイプライン、順番に

大半のエンジンは概ねこの順でサンプラを適用する。

• ロジット——生のスコア。語彙トークンごとに1つ(5万〜15万エントリ)。
• 繰り返しペナルティ——最近見たトークンのロジットが押し下げられる。
• temperature——ロジットをTで割り、全体を鋭くまたは平坦に。
• top_k——ハードキャップ。上位k個のトークンだけが生き残る。
• top_p——核集合。確率質量のpを覆う最小の上位セット。
• min_p——相対的な下限。min_p × P(最上位トークン)未満のトークンを落とす。
• サンプル——残りから1トークン選び、追加し、繰り返す。

早く適用されたフィルタは、後続の全フィルタが見るものを変える。積み重ねるときは心に留めておくこと。

temperature

temperature Tはソフトマックスの前にロジットを割る。低いTは分布を最上位トークンへ鋭くし、高いTは一様へ平たくなる。具体例:3トークンへのロジット[5.0, 3.0, 1.0]。

T → 0でこれはgreedyに崩壊する。常にargmax、完全に決定的。

抽出、分類、実行ごとに再現したいものにはtemperature 0(0を禁じるエンジンでは0.000001)を使う。チャットは0.6〜0.8を好み、創作は0.9〜1.2に耐える。

top_k:ハードキャップ

確率上位k個のトークンだけを保持し、その中でサンプルする。top_k 40は、何があっても41位以下を不可能にする。

ぶ厚い道具である。「フランスの首都は」の後ではk=40は広すぎ、候補が2つしか重要でない稀少トークン位置では不条理な無駄。一般的なデフォルト:40。min_pを使うときは無効化(0または-1、エンジン依存)。

top_p:核集合

確率で並べ替え、累積確率がpに達する最小のセットを保持し、再正規化してサンプル。

実例:確率[0.867, 0.117, 0.016]にtop_p 0.9。最上位トークンだけでは0.867 < 0.9。2番目を加えると0.984 ≥ 0.9。2トークンからサンプルし、[0.88, 0.12]に再正規化。

候補セットはモデルが確信するとき自動的に縮み、迷うと膨らむ。典型的な範囲:0.9〜0.95。

min_p:ローカルの宠児

確率がmin_p × P(最上位トークン)以上のトークンだけを保持。下限はスケール相対。

• モデルが99%確信 → 下限 = 0.05 × 0.99 ≈ 0.05。本物の挑戦者だけが生き残る。
• 最上位トークンが30% → 下限 = 0.05 × 0.30 = 0.015。多様性が生き残る。

これがtop_k/top_pの古典的失敗——確信した分布の刈りすぎ、平坦な分布の刈り足りない——を殺し、min_pは高temperatureと安全に合成できる。「創造的だが一貫」レシピ:temp 1.0〜1.5、min_p 0.05〜0.1。よくあるローカル設定:min_p 0.05でtop_kとtop_pはオフ。

repeat_penalty(llama.cpp系)

temperature適用の前、最近のコンテキストに出現したトークンのロジットがペナルティで割られる。1.0未満の値は逆に繰り返しを強める。妥当な範囲:1.0〜1.1。

副作用は現実。コードとデータは意図的にトークンを繰り返すから。

• 識別子は正当に繰り返される。counter.countの中のcount。
• JSONのキーと閉じ括弧は、配列内の全オブジェクトで繰り返される。
• ペナルティ1.2以上は、文章のループを直すよりずっと前にコードとJSONを壊す(落ちた括弧、「修正」された引用符)。

現代のinstructモデルが1.05超を必要とすることはまれ。コードと構造化出力には1.0が正当な選択。

frequencyペナルティとpresenceペナルティ(API式)

OpenAI互換APIは、llama.cppがrepeat_penaltyを使う場所でfrequency_penalty(繰り返しごとに増大)とpresence_penalty(既出トークンへの一律ペナルティ)を公開する。意図は同じ、数学は違う。両方を実装するローカルエンジンばかりではない——重ね掛けする前に自分の実装を確認:エンジンパラメータ。

サンプラの積みすぎで詰む

temp 0.1 + top_k 10 + top_p 0.5 + min_p 0.2 + repeat_penalty 1.3の同時適用は、全候補トークンを隠し得る。症状:NaN logprob警告、空の生成、「sampling returned zero candidates」による中断。

壊れたモデルではない。空の候補集合だ。1ノブずつ緩めること。完全な切り分け:トラブルシューティング。

機能するプリセット

チャット行をllama.cppフラグで。

llama-server -m model.gguf --temp 0.7 --top-p 0.95 --min-p 0.05 --repeat-penalty 1.05

一度に変えるのは1つ

プリセットは法律でなく出発点として扱う。temperatureとtop_pを一緒に動かして出力が改善しても、どのノブが効いたかは何も学んでいない。

1. テストセットを固定:気にかけることを試す5〜10プロンプト。
2. 構成ごとに出力を保存し、並べてdiff。
3. 1実行につき厳密に1ノブだけ変更。
4. 勝者を名前付きプリセットとして保存——すべてのエンジンとUIが保存できる。

これらのノブがエンジンフラグとAPIフィールドにどう対応するか:エンジンパラメータ。

関連: エンジンパラメータ · プロンプト · 構造化出力 · トラブルシューティング