AI推論ガイド
推論が非決定的である理由
「同じ」質問という思い込み
LLMの出力は、2つのリクエストが同一に見える場合でも変わり得ます。サンプリングは意図的に変動をもたらし、サービング側の変更、見えないコンテキスト、ツールの実行結果、一部の並列カーネルがさらに変動を加えます。バイト単位での再現性を得るには、入力全体、デコーディング設定、モデルとランタイムのバージョン、そして実行環境のすべてを制御する必要があります。
重要な視点：変動は主に4つの領域から生じます。生成とサンプリング、コンテキストと入力、システムとアーキテクチャ、ハードウェアと実装です。これらの要因を理解することが、信頼できるAIシステムを作る鍵になります。
カテゴリー1：意図的な生成・サンプリングのパラメータ
「サイコロ」：サンプリングは出力の多様性を高め得る
1. Temperature
サンプリング前にトークンのlogitsを再スケールし、確率分布の集中度を変えます。
2. シード
コンピュータは擬似乱数列を生成するために「シード」（開始値）を使います。
3. Top-P（Nucleus Sampling）
累積確率がしきい値（たとえば0.9）に達する最小のトークン集合からサンプリングします。候補集合は生成ステップごとに計算し直されます。
4. Top-K
確率が高い上位K個のトークン（たとえば上位50個）からサンプリングします。
5. その他のサンプリング手法
Mirostatやtypical samplingなどのサンプラーは、別の規則で候補トークンを選びます。
カテゴリー2：出力を形づくるリクエスト設定
これらの設定を変えると出力の取り決めが変わります。非決定性の証拠ではありません
6. repetition／frequency／presenceの各ペナルティ
これらの設定は、すでに出現したトークンのスコアを下げ、繰り返しを抑制します。ペナルティを変えれば、シードを固定していても候補の分布は変わります。
7. 停止条件（max tokens）
応答の長さに対する上限です。max_tokens=50での実行はmax_tokens=500での実行とは異なります。
8. 停止条件（stopシーケンス）
設定した文字列（たとえば "\nHuman:"）を生成すると、モデルは停止します。確率的なサンプリングでは、経路によって停止シーケンスに達する位置が変わることがあります。
カテゴリー3：コンテキストと入力時の変数
「記憶」：モデルへの入力には、直近のユーザーメッセージ以外も含まれることが多い
9. 会話履歴（コンテキストウィンドウ）
非決定的だと感じる最も一般的な原因です。モデルは直前の質問だけでなく、それまでの会話全体を見ています。
トークンが1つ変わるだけで入力は別物になり、出力が変わることがあります
10. コンテキストウィンドウの上限（「忘却」点）
モデルのコンテキストウィンドウは有限で、その大きさはモデルごとに異なります。長い会話は、周囲のアプリケーションによって切り詰められたり、要約されたり、拒否されたりします。送信されたコンテキストの外にある内容をモデルは参照できません。
11. システムプロンプト
アプリケーションやAPIが与える優先度の高い指示です。開発者には見えても利用者には隠されていることがあり、これを変更すると応答のスタイルや振る舞いが変わり得ます。
12. 検索と外部ツール
リクエストごとに入力が変わる主要な要因です。検索に基づくワークフローでは、アプリケーションは次のように動作することがあります。
- 生成を一時停止する
- 外部ツールを呼び出す（例：Google Search API）
- 新しい動的データ（検索結果）を受け取る
- そのデータをコンテキストに挿入する
ツールの結果はリクエストごとに変わり得ます。それによってモデルへの入力が変わり、答えも変わることがあります
カテゴリー4：システムとアーキテクチャの変数
「オーケストラ」：「モデル」は多くの場合、複数のモデルからなる複雑なシステム
13. モデルの更新とバージョン
今日使っているモデルは、昨日のものから新しくなったり、再学習されたり、更新されたりしている可能性があります。v1.2のモデルとv1.3のモデルでは応答が異なります。
14. A/Bテストとカナリアリリース
プロバイダーや自社のゲートウェイが、ロールアウト中に複数バージョンへトラフィックを振り分けることがあります。バージョンを固定できない場合、2つのリクエストが別々のデプロイに届き、異なる答えを返すことがあります。
15. 投機的デコーディング
ドラフトモデルが提案したトークンをターゲットモデルが検証します。厳密な実装はターゲットの分布を保つことを目指しますが、ランタイム、バッチング、近似、設定の違いが再現性に影響することはあります。
16. Mixture of Experts（MoE）アーキテクチャ
ルーターがトークンごとにエキスパートの部分集合を選びます。入力が固定であればルーティング関数は決定的になり得ますが、容量制限、バッチング、実装の詳細によってデプロイ単位の変動が生じることがあります。
カテゴリー5：ハードウェアと低レベル実装
「物理」：最も深く、最も制御が難しい変動要因
注意：temperatureが0でシードを固定していても、ランタイム側の選択によって結果が変わることがあります。
17. 並列カーネルと浮動小数点の縮約順序
決まった演算を決まった順序で行えば再現できます。並列カーネルや縮約が異なる順序で実行され、丸め誤差が伝播すると変動が生じ得ます。
- 並列性：GPUは数十億回の計算を並列に実行します
- 浮動小数点演算：小数を扱う計算機の算術は完全な結合則を満たしません
- 帰結：候補どうしが非常に近い場合、わずかなスコア差でも選ばれるトークンが変わり得ます
例：丸めにより (a+b)+c ≠ a+(b+c) → 0.81234567 と 0.81234568 → 選ばれる単語が変わる
18. 量子化の設定
量子化されたモデルは別のビルドより低い精度の表現を使うため、スコアや出力が異なることがあります。量子化済みモデルとランタイムを固定すれば、それ自体が非決定的なわけではありません。正確な量子化方式とランタイムをモデルバージョンの一部として記録してください。
19. バッチング
あなたのリクエストは他の利用者のリクエストと同じ「バッチ」で処理されます。そのまとめ方とパディングの仕方によってGPU計算の正確な順序が変わり、浮動小数点の問題が表面化することがあります。
20. 推論時のドロップアウト
推論時、ドロップアウトは通常は無効です。モンテカルロ・ドロップアウトのような研究手法はあえて有効のままにします。そのように設定された本番ランタイムは、乱数状態を制御しない限り確率的に振る舞います。
開発者が押さえておくべき点
決定性に近づける
- temperatureを0にする（greedyデコーディング）
- シードの値を固定する
- 入力コンテキストをすべて厳密に制御する
- 同じモデルバージョンを使う
- ハードウェアレベルの変動は残り得ると受け入れる
非決定性を前提にする
- 変動を無理なく扱えるシステムとして設計する
- 意味的な同等性を考慮した評価指標を使う
- 再試行は、安全な操作や冪等な操作に限り、回数を区切って行う
- 出力の一致ではなく、品質の安定性に注目する