Reasoning Model Story

この応用編は、Mini Transformer Lab の基礎編を読んだあとに、「推論モデル」と呼ばれるものをどう理解すればよいかを整理するページです。

ここで扱う推論モデルは、単に API の推論実行を意味するだけではありません。複雑な問題に対して、最終回答を出す前に内部作業を増やす model / system の考え方を指します。

大事な境界があります。推論モデルは Transformer の別アーキテクチャとは限らないし、prompt に「step by step」と書くだけの技でもありません。実際の製品では、事前学習済み language model に対する post-training、推論時の追加 token、検証、tool use、応答形式の制御などが組み合わさります。この lab では、そのうち 推論時に作業領域を使う 部分を小さく再現します。

対応するハンズオン:

• Reasoning Model Hands-on: hidden scratchpad、reasoning effort、verifier、self-consistency を mini-transformer-reason で動かして確認します。

全体像

base language model は、基本的には「これまでの token から次 token を予測する」機械です。推論モデルは、その予測をすぐ visible answer に使うのではなく、内部で途中状態を作り、必要なら複数案を比較し、最後に答えだけを返す方向へ設計されます。

flowchart LR
    P["prompt"] --> M["base model"]
    M --> R["hidden reasoning tokens"]
    R --> V["verifier / self-check"]
    V --> A["visible answer"]
    R --> T["optional tool use"]
    T --> V

概念補助:

• reasoning tokens: 最終回答に直接表示されない内部作業用 token。OpenAI の reasoning model docs では、reasoning effort が応答前に生成される reasoning tokens の量に関係すると説明されています。
• visible answer: ユーザーに返す最終出力。内部作業をそのままユーザーに見せる教材ではありません。
• hidden scratchpad: この lab で内部作業を観察するための呼び名です。実APIの hidden reasoning tokens そのものではなく、学習用のミニ実装です。

reasoning effort

reasoning effort は、推論時にどれくらい内部作業を使うかを表す制御です。低い effort は速く安いが、分解や検証が少ない。高い effort は遅く重いが、候補生成、検証、再試行により複雑な問題で安定しやすい、という見方になります。

flowchart TB
    L["low effort"] --> L1["direct answer"]
    M["medium effort"] --> M1["direct answer"]
    M1 --> M2["verify once"]
    H["high effort"] --> H1["candidate paths"]
    H1 --> H2["self-consistency vote"]
    H2 --> H3["verify"]

概念補助:

• effort: 推論時の計算予算。必ず正答率が上がる保証ではないが、内部作業を増やす余地を作る。
• latency: 応答までの時間。内部作業が増えるほど長くなりやすい。
• token budget: context window と出力 token の予算。reasoning tokens も予算を消費する点が重要です。

verifier

verifier は、候補回答が条件に合っているかを外側から確認する部品です。model の「それっぽい出力」をそのまま信じず、別の規則、別の model、テスト、schema validation、tool result などで確認します。

この lab では、数式をもう一度評価して同じ答えになるかを見るだけの小さな verifier を作ります。これは本格的な数学 verifier ではありませんが、「答えを生成する部品」と「答えを確認する部品」を分ける感覚を掴むためには十分です。

概念補助:

• verifier: 候補の正しさを評価する仕組み。
• schema validation: JSON などの出力形式が契約通りかを検査すること。
• test-time verification: 学習時ではなく、推論時に答えを検査する設計。

self-consistency

self-consistency は、1つの答えを一発で信じるのではなく、複数の推論経路から候補を作り、多数派や検証済み候補を採用する考え方です。

この lab では deterministic な数式評価なので複数候補は同じ結果になります。それでも、候補生成、vote、verification の流れをコードで持つことで、実際の推論システムが「内部で複数案を扱う」感覚を観察できます。

概念補助:

• candidate path: 1つの推論経路から出た候補回答。
• vote: 複数候補から採用する答えを選ぶ処理。
• failure mode: 複数候補が同じ間違いを共有する場合、vote だけでは正しくならない。

tool use

tool use は、model が外部の計算、検索、DB、コード実行などを使う設計です。tool use は reasoning そのものではありません。reasoning は「何を調べるか」「結果をどう解釈するか」「次に何をするか」の制御にも関係します。

この lab の mini-transformer-reason は外部 API を呼びませんが、数式 evaluator を小さな tool として扱います。model が曖昧に計算するのではなく、計算可能な部分は決定的な関数で確認する、という agent 設計の基本に接続します。

概念補助:

• tool: model の外にある実行可能な能力。
• tool result: tool から返った観測結果。
• controller: prompt、model、tool、verifier をつないで次の行動を決める外側の制御。

この lab で作るもの

応用編ハンズオンでは、次の小さな推論ループを作って動かします。

実際の手順は Reasoning Model Hands-on で進めます。

flowchart LR
    Q["arithmetic prompt"] --> P["parse expression"]
    P --> C["candidate paths"]
    C --> S["self-consistency"]
    S --> V["verify by evaluator"]
    V --> A["final answer"]

これは本物の大規模 reasoning model ではありません。目的は、推論モデルの完全再現ではなく、次の設計要素を手元で確認することです。

• hidden scratchpad と visible answer を分ける。
• reasoning effort で内部作業量を変える。
• verifier を model 出力の外側に置く。
• self-consistency を候補選択として見る。
• tool use を「できることは外部関数で確認する」設計として理解する。

Source Guide