Chain of Thought、RLVR、Test-Time Computeを測る

2つ目のバージョンは「考えた」と言いたくなります。ですが、その言い方は避けましょう。仕組みはもっと単純で、知っておく価値も高いからです。

transformerは、生成するtokenごとに固定量の計算を行います。1回のforward pass。同じlayers、同じmatrices、同じ演算数です。質問が2+2は何かでも、この定理を証明せよでも変わりません。modelの内部に「今回はもっと頑張る」というダイヤルはありません。

したがって、modelに即座に答えを求めると、利用できる計算全体は1回のforward passだけです。すべての中間量はその1回のpassのactivationsに収まる必要があり、そこで計算できないものは計算できません。

tokenを出力すると、この状況が変わります。しかも、分けて考えるべき2つの形で変わります。

• 計算量が増えます。 生成されるtokenごとに、もう1回まるごとのforward passが走ります。145 token分の作業は、すぐ答える場合の145倍の算術です。
• 記憶が外部化されます。 tokenはcontextに書き込まれるため、次のpassでそれを読めます。5 × 13 = 65 はactivation内に保持して先へ運ぶ必要のある値ではなく、入力内の事実になります。modelは自分自身の出力をscratchpadとして使っているのです。

見落とされがちなのは2つ目の点で、作業が役に立つには書き出されている必要がある理由もここにあります。「黙って考えてから答えて」と言われたmodelには、その考えを置く場所がありません。

ここに神秘的なものは何も必要ありません。そして、これは明確な予測を生みます。chain of thoughtが最も効くのは、直列的な構造を持つ問題 — ステップ2がステップ1の結果を必要とする問題 — であり、単一のlookupで済む問題には最も効きにくいはずです。文献が示しているのもまさにそれであり、「think step by step」がフランスの首都はどこかに何の効果もない理由でもあります。

この技法は2022年に2つの形で登場しました。Weiらは、promptに解答例 — 答えの前に推論が示されているdemonstrations — を含めると、算術やcommonsense benchmarkで大きな改善が得られることを示しました。¹ 続いてKojimaらは、さらに奇妙なことを示しました。例は不要なのです。zero-shot promptに**「Let's think step by step」**を付け加えるだけで、同じ改善の多くを捉えられます。²

何が起きているのかを教えてくれるのは、2つ目の結果です。魔法のフレーズが振る舞いを解放するなら、その振る舞いはすでにmodelの中にあったということです。pretrainingには解法付きの例が大量に含まれており、そのフレーズはdistribution内のその領域へのポインタです。Chain of thoughtはmodelに何かを教えたわけではありません。modelがすでに持っていたものを選択したのです。

この見方は、この技法がやがて不要になることも予測します。それについては章の終わりで戻ってきます。

次の一手は明らかです。1本の推論chainが間違うなら、複数をsampleして多数決を取ればよい。それがself-consistencyです。³ これは明らかに支出が大きくなります。1回ではなく $n$ 回の完全なgenerationを行うからです。直感としては、間違った答えは散らばり、正しい答えは一致する、というものです。

同じ問題のうち16問で測定しました。temperature 0.8でsamplingし、$n$ 本のchainで多数決を取ります。

16問は分母として小さく、第4章のルールはこの表にも他のどの表にも同じように当てはまります。16問中13問は81%で、95% Wilson intervalは[57, 93]です。16問中16問は100%で、[81, 100]です。これらは重なっています。 読むべきは曲線の形であり、それが発見です。平坦化する正確な段は読まないでください。16問ではそこを特定できません。

この表には2つのことがあります。そして2つ目は、私が予想していたものではありません。

曲線は $n = 3$ で平坦化します。 3つ目のsampleで正解率は上限に達し、残り2つのsampleは何も買いません。それでも1つあたり172 token、2つで345 tokenかかります。これは文献で報告されるあらゆるself-consistency曲線の形であり、「sampleは多いほどよい」という見方が示唆するより、ずっと早く訪れます。

そしてgreedy decodingはすでに100%でした。 章の冒頭を見直してください。1本のchain、samplingなし、145 token、24/24。temperature 0.8でのsamplingは正解率を81%に下げ、self-consistencyは3回のgenerationを使って、単一のgreedy passがすでに到達していた場所へ戻る必要がありました — 3.6倍のtokenで。平坦化する場所を知らずに5回までsweepすれば、6倍です。

これはself-consistencyへの反論ではありません。それが何をしているのかを正確に述べたものです。temperatureはerrorを注入することで多様性を買い、votingはたった今注入したerrorを取り除きます。 greedy decodingが失敗する問題 — 最も確率の高い単一のchainが間違った場所に進み、確率の低い別のchainが正しい問題 — では、この取引は割に合います。だからこそ、この技法は存在します。greedyがすでに成功する問題では、6倍のbudgetを使って損益分岐に戻る方法です。

2つ目のケースは誰もpublishしません。だからこそ、この技法を採用する前に自分のtaskで測る価値があります。これは小さなmodelに対する簡単な2段階問題です。このような結果になるregimeなのです。

ここまでのすべては、そのために特別にtrainingされていないmodelに対して、prompt時に起きていることです。現在のgenerationのreasoning modelを生んだ変化は、これをtrainingに移したことでした。そして、それを可能にした鍵は、響きほど広いものではありません。

第11章のpost-trainingには人間のpreferencesが必要でした。「これは良い答えだったか？」にはprogrammaticな答えがないからです。しかし、一部の質問にはそれがあります。数学の答えは正しい値と一致するか、一致しないかです。codeはtestに通るか、通らないかです。proofはcheckされるか、されないかです。

そうした領域では、reward modelをverifierで置き換えられます。すると下流のすべてが一度に改善します。annotatorは不要、Bradley–Terry fittingも不要、第11章で測った種類のreward hackingも不要です。unit testにお世辞は通じないからです。これがreinforcement learning from verifiable rewardsであり、GRPOが作られたsettingです。同じ問題に対するsolution attemptのgroupをsampleし、それぞれをcheckし、groupの平均scoreをbaselineとして使います。criticなし、annotatorなし、reward modelなし。正しいか間違っているかを返すprogramだけです。

この分野の見方を変えた結果は、2025年初頭のDeepSeekから出ました。⁶ 彼らはbase modelを取り、verifiable rewardsによるreinforcement learningを直接適用しました。最初にsupervised fine-tuning stageを置かずにです — 第11章では、これがすべての土台として提示されていたstageです。それでも長い推論chainはemergeしました。誰もtrainingしていない振る舞いも同じです。modelは自分自身のstepを再確認し始め、paperで最も引用された一節では、solutionの途中でapproachを自発的に再考しました。

正直な読み方は、reasoningが魔法だということではありません。rewardされるものが正しいことだけであり、難しい問題で正しくあるには作業を進める必要があるなら、optimiserが見つけるのはその作業だということです。そこには、人間も行う作業の部分が含まれます。誰かが教えたからではなく、問題がそれを要求するからです。

このすべての実務上の帰結は、reasoning modelが、あなたが求めたtokenと求めていないtokenの両方を生成し、その両方に対して料金が発生するということです。

providerごとに扱いは異なり、その違いは重要です。

• ほとんどのAPIは、reasoning tokenをoutput token countの内側に数えます。あなたの請求額と max_tokens limitの両方に、見えないthinkingが含まれます。
• GoogleのGeminiは、thinking tokenを標準のoutput countの外側にある別fieldとして報告します。

これは、同じものを数える2つの方法の間にある本物の非互換性です。providerをまたいでコストを計算したりbudgetを強制したりするcodeは、これを正規化する必要があります。第16章ではこれがmoneyになり、第23章では強制可能なbudgetになります。

もう1つの帰結は、初めての人を驚かせるlatencyです。reasoning modelの最初の可視tokenまでの時間には、そのthinkingのすべてが含まれます。したがって、8秒間何もstreamせず、その後1秒で答えるrequestは、connectionが固まっているのではありません。modelが作業しているのです。8秒間、説明なしのspinnerだけを見せるinterfaceがあるなら、それはnetworkingの問題ではなくdesignの問題です。

最後に警告です。この章の内容が誤って適用される最も一般的な形だからです。

前半のすべては、reasoningするようにtrainingされていないmodelに、それでもreasoningを生成させるための技法です。RLVRでtrainingされたmodelはすでにそれを行います。答える前に、自分自身の作業を、自分自身の長さで出力します。そのようなmodelにthink step by stepと伝えることは、よくても冗長で、悪ければ有害です。modelが自力で生成したはずの長いchainの代わりに、短いprompt風のchainを生成してしまうことがあり、一部のproviderはまさにこれをdocumentしています。

application codeで組まれた精巧なreasoning scaffoldにも同じことが当てはまります。modelが内部ですでにnavigateしているdecision treeをpromptで歩かせることは、training済みの振る舞いを制約するためにあなたのtokenを使うことです。これは、このcourseの残りを通じて続くthemeの最初の登場です。2022年には不可欠だった技法が、2025年には迷信になったのです。そして、今日のあなたのmodelにとってどちらなのかを知る唯一の方法は、両方を測ることです。

第15章では、その測定が意見ではなく規律になります。

reasoningには厄介な性質があります。質問が難しくなるほどcostが増える唯一のcapabilityなのです。900 token考えるmodelは900回のforward passを行い、そのすべてについて増大するcacheをmemoryに保持し、その間GPUを占有します。

そのため、reasoning modelをserveする経済性は、chat modelをserveする場合よりはるかに厳しくなります。そして一連のimplementation detailsが、成立するproductと成立しないproductの差になります。過去のkeysとvaluesのcacheをどう保存して再利用するか、何件のrequestがforward passを共有できるか、weightsに実際どれだけのprecisionが必要か、という点です。

第13章は、modelがportの背後にあるserviceではなく、あなたのmemory内のobjectである最後の章です。そして、そのobjectをserveできるほど安くする話です。また、この章からの約束も回収します。speculative decodingです。小さなmodelに予測させ、大きなmodelにcheckさせることで、ほぼ1個分の価格で複数tokenを生成するtrickです。forward passの大部分が算術ではなくmemory待ちに費やされていることを見て初めて意味を持つtrickでもあります。

この章のすべての測定は、生成した24個の2段階文章題に対して Qwen/Qwen2.5-0.5B-Instruct から得たものです。samplingと明記した箇所以外はgreedy decodingで、使用したtoken capでは切り詰められたgenerationは0でした。再現可能ですが、簡単な問題に対する小さなmodelです。self-consistencyの結果はbenchmarkとしてではなく、mechanismのdemonstrationとして読んでください。CS229 lecture notesの第18章とHugging Face LLM Courseの第12章は、より大きなmodelと適切なbenchmarkでこの内容を扱っています。