s1を読む：少ないデータで推論を伸ばす時、何を測るか

予算を増やすと、モデルは何をしているのか

s1: Simple test-time scalingは2025-01-31公開の論文で、推論能力を伸ばすための巨大な学習実験だけが選択肢ではないことを示そうとする。中心の問いは単純である。既存モデルが考える時間を、学習時と推論時にどのように与えれば、限られた計算でも難しい問題へ届くのか。回答の長さを無条件に増やせばよいわけではない。無関係なtokenは費用を増やし、停止を誤れば正答を切る。

1. 1高品質な少数reasoning例
2. 2SFT
3. 3推論モデル

1. 1問題
2. 2thinking budget
3. 3解答
4. 4verifier/評価

1. 1予算を増減
2. 2正答率・token・待ち時間の曲線

論文は高品質な小さなデータセットを選び、SFTでreasoning modelを作ること、そしてbudget forcingで推論tokenの消費を制御することを提案する。abstractと本文を読む時、ここでの「少ない」はデータ量だけを指すのか、教師を生成する費用や基礎モデルの能力を含むのかを分ける。強いbase model、厳選された例、特定の数学・競技プログラミング評価が前提なら、その前提を外した実装で同じ結果を期待できない。

データ選別は件数を削る操作ではない

s1の実践的な含意は、推論データの品質が単純な大量収集より支配的になり得るという点にある。良い例には、問題が明確、最終解が検証できる、途中の方針転換が意味を持つ、不要な装飾が少ない、といった性質がある。だが「教師が長く書いた」だけでは高品質ではない。正答でも循環論法、計算飛躍、別問題の記憶、形式違反が混ざる。

データを選ぶ時は、問題の分布、最終解の検証器、token長、言語、重複、教師の生成条件を記録する。人手で読む20例は、数万例の自動フィルタより早く破綻を発見することがある。特に日本語や自分の業務文書では、英語数学データの「きれいさ」がそのまま移らない。

budget forcingの意味と危険

推論時のbudget forcingは、モデルにすぐ最終回答へ行かず、ある程度の思考を続けるよう誘導する考え方として読める。実装の細部は論文・公式repoの該当revisionを確認する必要があるが、製品の視点では二つの失敗が重要になる。一つは、易問に余計な時間を使うこと。もう一つは、難問で長く考えた出力が正しいと利用者が思い込むことだ。

1. 1易問
2. 2小さなbudget
3. 3validator
4. 4早く終了

1. 1難問/不確実
2. 2追加budget
3. 3再検査
4. 4根拠付き回答

1. 1budget上限
2. 2不明/保留
3. 3人または後続jobへ

budgetは一律に固定しない。まず小さいbudgetで解き、検証器が失敗、引用が不足、schemaが壊れた場合だけ次の段階へ進む。これは正答率を最大化する仕組みではなく、利用者の待ち時間と費用を制御する仕組みである。追加試行の前後で同じ誤答を繰り返すなら、budgetではなく検索、ツール、入力の曖昧さが問題かもしれない。

再現設計

1. 著者の公開repoを使う前にLICENSE、モデルの利用条件、必要なGPU、データ取得先を読む。論文版とrepoのcommitが一致するかは別に記録する。
2. 10〜30問の小さな検証セットを、訓練・開発・最終確認に分ける。最終確認へ頻繁に合わせない。
3. base model、SFTのみ、budgetを二段階にした推論の三条件で比較する。各条件の最大token、sample数、temperature、wall timeを固定する。
4. 正答率だけでなく、平均とp95の生成時間、出力token、途中停止、JSON/引用の失敗を測る。answer-onlyの採点で隠れる失敗を一件ずつ読む。
5. 難度のラベルを事前に人手で付け、易問で無駄に長くなっていないか、難問で正答が改善したかを分けて見る。

トレードオフ

test-time scalingは、モデルの能力を必要な時だけ使えるように見える。しかし推論token、複数sample、verifier呼び出しはすべてコストになる。長い思考は内容安全の検査面積も増やす。教師データを少数に絞ると、領域外の問題に脆くなる。SFTは安定でも、探索で見つかる新しい解法を必ず学べるわけではない。

この論文を読む最良の実習は、長文を出すモデルを作ることではない。自分のタスクで「追加の1000 tokenが、どの失敗を何件減らすか」を測ることだ。曲線が平らなら、賢さを足す前に検索、入力設計、検査、UIを直すべきである。

実運用での停止規則

推論budgetを増やす条件は、利用者の不安ではなく検査結果で決める。例えば一次回答がschemaを満たさない、検索根拠が二件未満、計算validatorが失敗した時だけ追加試行を許す。二度の追加試行でも同じ失敗なら停止して、人への確認または後続jobへ渡す。これにより、難問への計算配分と、失敗ループの費用を同時に制御できる。正答が不確かなまま長く話すことを、親切さと取り違えない。

比較表には、追加budgetで改善した問題番号と、改善しなかった問題番号を両方残す。平均tokenが増えても難問の正答が増えなければ、その予算は別の検証器や検索へ回したほうがよい。逆に短い回答でも正答なら、見かけの思考量で品質を判断しない。s1の方法を使うかどうかは、こうした曲線を自分の制約下で描いてから決める。

この判断は毎回同じモデルで再利用できる。モデル更新後に曲線が変われば、以前のbudget設定を固定の常識にせず、評価セットで測り直す。

利用者へは推論token数を見せる必要はないが、時間がかかる理由と中止できることは見せる。性能実験のパラメータを、そのまま体験の仕様にしない。

追加tokenが判断を変えるかを試す

budget forcingが有用なのは、追加computeが検証可能な判断を変える時だけである。固定held-out setでfirst answer、final answer、stop reason、token count、verifier resultを保存する。final answerが誤ったfirst answerを直した回数、正しいfirst answerを壊した回数、文章を繰り返しただけの回数を計算する。これでscalingと長いformatを分けられる。

small modelでscalingを再現する2025年2月のReddit threadは、budget増加で改善も劣化もしたという逸話的な警告である。閾値やmodel familyの規則の証拠にはせず、上のpaired curveを実行する理由として扱う。

Quiet-STaR（2024）は、より多くのreasoning生成にはcompute costがあるという早期の注意である。test-time scalingではtokenまたはwall-clockの上限を事前に宣言し、hold-out taskでcorrectnessを上限に対して描く。長いbudgetで最終回答が改善しても、internal rationaleがfaithfulだと推論しない。

2026-09-23投稿のPTTSは、executorを固定して独立branchと共同で計画したoutlineを比べる。benchmarkはs1型systemの一般的な利点を示さない。budget curveには実行前の異なるapproach数を一つ追加し、その数に対して検証済みcompletionとcostを描く。追加branchがduplicateになったら止める。