推論時計算・候補・検証

推論への投入を増やすと有用な候補が増えることも、同じ誤りを繰り返すこともあります。学習・生成・アプリ側の検証を分け、正しい候補の存在と最終的な選択を区別して、タスク結果で計算予算を評価します。

訓練と推論段階の計算

訓練はモデルのパラメータを調整する；推論は与えられたパラメータと入力に基づいて出力を生成する。推論計算を増やすことは、中間ステップの生成、複数の候補の試行、新情報を取得するためのツール呼び出し、またはフィードバックに基づく修正として現れる。これはモデルの重みを自動的に更新するものではなく、入力にない外部の事実を自動的に補えるわけでもない。

Chain-of-Thought (CoT) プロンプティングの古典的な手法は、プロンプトに中間ステップを含む例示を与え、モデルが同様の形式で新しい問題を解決させることである。オリジナルの論文では、特定モデルおよび算数、常識、記号タスクにおいて向上が観察された；これは「段階的に思考するように言えばどんなタスクにも適用できる」という法則ではない。Chain-of-Thought Prompting

推論モデルは通常、推論段階の計算を活用する能力を高めるために特別に訓練される。APIにおけるthinkingは、プロダクトが提供する推論制御と返却構造であり、これらは同じ階層ではない：プロンプトで解答プロセスの出力を要求できても、それによってモデル内部でどのような訓練方法が採用され、どの程度の隠れ計算が行われ、真の外部チェックが実行されたかを推測することはできない。

追加計算を候補と検証に使う

分解により中間結果を検査可能にする

27×453を計算する場合、20×453=9060 と 7×453=3171 に分解し、加算して 12231 を得ることができる。別の分解方法として 453×(30−3)=13590−1359=12231 もある。2つの計算は互いに照合できるが、どちらも同じシステムによる誤った実行であれば、共に誤る可能性がある。より強力な計算保証が必要な場合は、決定論的な算術ツールを使用できる。

この例は人間が検査可能な解答説明に過ぎず、あるモデルの内部プロセスの記録ではない。それは分解の役割を示している：各ステップに入力、操作、検証可能な出力があり、「注意深くチェックした」と言うよりも、これらの中間生成物はエラーを発見しやすい。

複数の候補は選択が有効な場合にのみ価値を持つ

self-consistency は複数の解答パスをサンプリングし、最終回答を集約する；その研究はいくつかの推論ベンチマークで利益を観察した。Self-Consistency もし複数の候補がすべて同じ誤った事実に依存している場合、投票は誤った答えをより自信を持って選ぶ可能性がある。

仮に各試行が独立し、成功率が 0.6 であると仮定しても、3回中少なくとも1回成功する確率は 1−0.4³=0.936 であり、最終成功率を直接 93.6% と書くことはできない。この数字は候補の中に正解が存在する確率を示すだけで、アプリケーションはそれを識別する必要がある；そして実際のモデルが繰り返し生成する場合、通常は独立誤り仮定を満たさない。

外部フィードバックにより検索を検証可能な改善に変える

ソート関数の修正を例にとる。候補Aは通常の正数のサンプルでは通過するが、重複要素を含む場合に安定順序を破壊する。この失敗入力と期待結果をモデルに提供することは、「もう一度注意深くチェックして」とだけ要求するよりも、より明確な修正シグナルを提供する。候補Bがこの例を通過した後、他の修正に使用されていないケースでもチェックし、反例に対するパッチ当てのみを防ぐ。

バリデーターにも境界がある：ユニットテストはテスト条件のみをカバーする；別のモデルによるスコアリングにもバイアスがある；多数決は比較可能な回答形式を必要とする。推論計算の配分は、タスクの難易度、候補の品質、バリデーターの能力によって異なり、出力トークン数に対して線形に収益を拡大できるものではない。Scaling LLM Test-Time Compute Optimally

正しい候補があっても選び損ねる理由

93.6% を正解候補が利用可能な確率として、条件付き識別率 q を掛けます。q は一般の評価器精度ではなく、正解が含まれる場合に定義されます。誤りを共有する極端な比較で独立性の仮定を確認します。

$$P(\text{final correct})=[1-(1-p{)}^n]q$$

可視化された説明、内部計算、実行証拠

Claude において、現在の thinking ドキュメントは、可視化された thinking テキストがサマリーであり、表示を省略しても構造化されたブロックが存在し、継続送信が必要になる可能性があることを示している。サービス内の内部推論課金は、可視サマリーの文字数を数えることで復元できない；これらはこのインターフェースのセマンティクスであり、すべてのオープンモデルがプロセステキストを返さないという一般化として拡張すべきではない。Claude Thinking

アプリケーションは、プロトコル継続用の元のレスポンス構造、表示可能なテキスト、および実際のツール実行記録を別々に保存すべきである。サマリーから署名や他の不透明なフィールドを再構築してはならない。ツールループ内のフィードバック要求、履歴ブロック保持ポリシーは、現在のモデルドキュメントに従うべきである。1回のレスポンスには thinking、テキスト、ツール呼び出しが含まれる可能性があり、最初の段落の文字だけを取ってラウンド全体のタスク完了を宣言することはできない。

フロントエンドが進捗を表示する必要がある場合、実際のリクエスト状態と発生したツールイベントを表示できる；thinking サマリーは補助として機能できるが、「テストを実行する予定」と「テスト合格」を混同して表示してはならない。テキストが出力されないからといって、それがハングアップを単独で証明するものではなく、リクエスト状態、タイムアウト、接続イベントと組み合わせて判断する必要がある。

3種類の予算制御

effort は行動傾向であり、ハードカウンターではない

Claude の output_config.effort を例にとる。これはレスポンス時の計算とトークン使用の傾向を調整し、thinking、ツール呼び出し、説明に影響を与える可能性がある。サポートされるグレードと各グレードの効果はモデルによって異なる；high を固定されたトークン生成数と解釈することはできず、effort を下げることが可視回答を必ず短縮するとも限らない。Claude Effort

temperature は候補の確率分布を変え、effort は推論投入を変え、ユーザーが要求する篇幅は最終的な表示目標を制約する。「2文で回答して」という場合は、篇幅の要求を直接表現すべきである；厳密な証明が必要な場合は、温度で代替するのではなく、命題、条件、検証基準を提供すべきである。サンプリングメカニズムについては トークンとサンプリング を参照。

単回出力制限とリクエスト間予算

Claude の task budget は、モデルへのタスクレベルの予算シグナルであり、カウントはクライアントが履歴を再送信したり、請求書の使用状況を確認したりすることとは必ずしも一致しない；財務帳やアプリケーションのハードリミットを直接代替するものではない。Task budgets

例えば、アプリケーションは本タスクで12回のツール呼び出しのみを許可し、合計120秒のタイムリミットがある。このルールは実行器によってチェックされなければならず、プロンプトに書き込むだけで遵守されると仮定してはならない。ツールを実行するたびに、残りの呼び出し回数と終了期限を確認する；予算が尽きた後は、結果、未完成項目、および復旧位置を保持する。リクエストのキャンセルは、すでに送信された外部操作が自動的にロールバックされることを意味するものではなく、ツールのセマンティクスに基づいて結果を確認する必要がある。

API 設定はモデル世代間で区別する

Claude の手動 budget_tokens と adaptive thinking にはそれぞれサポート範囲がある；現在のドキュメントでは手動モードを旧モードとしてリストし、移行手順を提供している。「ある世代のモデルが手動設定を拒否する」ということをすべてのモデルの一般則として拡張してはならず、設定を統一するためにサポートされていないフィールドを各エンドポイントに送信してはならない。Extended thinking

設定アダプテーションレイヤーは、対象モデル、サポートモード、および出力制限を明確にし、リクエストを構築すべきである；サポートされていないパラメータによる 400 エラーとモデルタスクの失敗は別々に集計する。理論論文は制御の意味を保持し、接続コードのフィールド、デフォルト値、互換性テーブルは対象モデルの現在のドキュメントを基準とする。

タスク成功率で収益を計算する

同一のタスクセットで、完全な実行を比較する

固定されたタスクセット、入力素材、ツール権限、検証ルール、およびタイムアウトを設定し、推論グレードまたは候補戦略のみを変更する。分類と抽出ではラベルの正確率とフォーマットを見る必要があり、コードタスクでは実際のテストを見る必要があり、長い Agent タスクでは最終目標が達成されたかどうかを見る必要があり、各ラウンドの文字列が進行しているように見えるかどうかだけを見てはならない。

以下は仮定の 100 件のタスク結果である。各実行のコストには、今回の戦略における失敗試行と検証が含まれている；計算を容易にするため、すべてのコストを架空のコスト単位に統一している。

B の成功率は 10 ポイント向上したが、成功あたりの平均コストも上昇した。追加の 100 コストで 10 個の追加成功を得た。限界コストは 10 である。それが価値があるかどうかは、タスクの価値、品質の閾値、およびレイテンシの制約によって異なる；「より成功した」または「より多くのトークンを消費した」というだけの結論を出してはならない。

from fractions import Fraction

runs = {"A": (70, 100), "B": (80, 200)}
for name, (successes, cost) in runs.items():
    print(name, "成功あたりの平均コスト", round(float(Fraction(cost, successes)), 2))
assert Fraction(200 - 100, 80 - 70) == 10
# A 成功あたりの平均コスト 1.43
# B 成功あたりの平均コスト 2.5

実際の比較では、p50/p95 レイテンシ、タイムアウト率、リトライ、およびツール費用も記録すべきである。新しい戦略が異なる入力または異なるモデルを使用した場合は、変化のすべてを effort に帰因することはできない。サンプルが少ない場合は、問題ごとのペア結果を保持し、ランダム性のあるタスクで繰り返し測定し、1回の実行の小さな変動でグレードを決定しないようにする。

失敗の原因に応じて計算を調整し、一律に最大値にしない

完全な観測では、リクエスト、ツール、成果物、およびタスクレベルの結果を接続する必要がある。詳細は 評価と観測可能性 を参照。推論予算はこのループ内の制御点の1つである；モデルの提案を制御されたアクションに変換できるかどうかは、Agent ループとツール使用 で引き続き参照。

次に読む：プロンプトと出力契約。