Chain-of-Thought を1から — 「考えを書かせる」と何が変わるのか
「ステップごとに考えて」と一言足すだけで解ける問題が増えるのはなぜか。few-shot CoT・zero-shot CoT・self-consistency を前提知識ゼロから解説し、計算の直列化という理屈、効かない条件、推論モデルとの関係まで踏み込む。
Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
一次資料 — この記事の根拠
論文の発表 2022-01-28→この解説の公開 2026-09-084年7か月後
Chain-of-Thought Prompting Elicits Reasoning in Large Language ModelsJason Wei, Xuezhi Wang, Dale Schuurmans ほか · 2022-01-28 · v6arXiv:2201.11903論文ページ·PDFLarge Language Models are Zero-Shot ReasonersarXiv:2205.11916論文ページ·PDF
Self-Consistency Improves Chain of Thought Reasoning in Language ModelsarXiv:2203.11171論文ページ·PDF
Chain of Thought Empowers Transformers to Solve Inherently Serial ProblemsarXiv:2402.12875論文ページ·PDF
To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoningarXiv:2409.12183論文ページ·PDF
Language Models Don't Always Say What They ThinkarXiv:2305.04388論文ページ·PDF
原文の要旨(Abstract)を読む
We explore how generating a chain of thought -- a series of intermediate reasoning steps -- significantly improves the ability of large language models to perform complex reasoning. In particular, we show how such reasoning abilities emerge naturally in sufficiently large language models via a simple method called chain of thought prompting, where a few chain of thought demonstrations are provided as exemplars in prompting. Experiments on three large language models show that chain of thought prompting improves performance on a range of arithmetic, commonsense, and symbolic reasoning tasks. The empirical gains can be striking. For instance, prompting a 540B-parameter language model with just eight chain of thought exemplars achieves state of the art accuracy on the GSM8K benchmark of math word problems, surpassing even finetuned GPT-3 with a verifier.
暗算と筆算のちがい
「23 × 47 は?」と口頭で聞かれて即答できる人は多くありません。でも紙とペンを渡されれば、ほぼ全員が解けます。頭が良くなったわけではなく、途中の数字を紙に置けるようになっただけです。書いて、読み返して、次へ進む。この往復が、頭の中だけでは支えきれない長さの計算を最後まで運びます。
大規模言語モデル(LLM)に起きているのも同じことです。「答えだけ言え」と指示すると間違える問題が、「途中も書いて」と言い添えるだけで解ける。この現象と、それを引き出すプロンプトの型を Chain-of-Thought(思考の連鎖、以下CoT) と呼びます。2022年の論文 "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" が名前を与えました。
不思議なのは、モデルの重みが1バイトも変わっていないことです。言い方を変えただけで解ける問題が増える。この記事はその「なぜ」を、理屈からコード、落とし穴まで降りていきます。
まず現物を見る: few-shot CoT
元論文がやったことは驚くほど素朴です。プロンプトに入れるお手本の答え方を変えた、それだけです。
【従来】
Q: 駐車場に車が3台あります。2台来ました。何台?
A: 5台
【CoT】
Q: 駐車場に車が3台あります。2台来ました。何台?
A: 最初は3台。2台増えたので 3 + 2 = 5。答えは5台。
このお手本を2〜8個並べてから本題を出すと、モデルは真似をして途中式を書き始め、書いた結果として正答率が上がります。お手本と本題は別の問題で構いません。「答え方の型」だけが伝わればいいのがポイントです。
お手本の計算が間違っていても効果がある程度残る、という報告もあります。モデルは正解より「段階を踏んで書く」という振る舞いの形式を真似ているのです。
呪文だけで済ませる: zero-shot CoT
お手本を書くのは面倒です。翌年の "Large Language Models are Zero-Shot Reasoners" は、お手本をゼロにして、質問の後ろに一行足すだけでよいと示しました。
Q: (問題文)
A: ステップごとに考えてみましょう。
英語の原文は "Let's think step by step." です。この一行が、出力分布を「いきなり結論を書く」領域から「手順を書き下す」領域へ押しやります。
論文はもう一つ実務的な工夫を入れています。2段階に分けるやり方です。1回目で推論だけを書かせ、その出力を丸ごと入力に戻して「したがって答えは」と続けさせ、2回目で答えを取り出す。パースが安定するので、いまでもそのまま使えます。
なぜ効くのか: 計算を「深さ」から「長さ」へ移す
理由は大きく2つあります。
1つ目は、書いた文字が入力に戻ってくること。 LLMは次の1トークンを出すたびに、それまでの全文(プロンプト+自分がすでに書いた分)を読み直します。途中式を書く行為は、モデルにとって外部メモに書き付けることそのものです。「3 + 2 = 5」と一度書けば、その先のトークンは5をAttention機構で直接参照できます。書かなければ、その5は活性値のどこかに曖昧に留まるか、そもそも計算されずに消えます。
2つ目は、こちらが本質ですが、1トークンあたりの計算量が固定されていること。 Transformerは層を 段積んだ固定の構造で、1トークンを出すのに使える「直列につながった計算の段数」はおおむね で頭打ちです。ところが世の中には、前の結果が出ないと次へ進めない本質的に直列な問題があります。繰り上がりのある掛け算、リストの逐次更新、多段の論理推論などです。必要な段数が を超えていれば、1回の前向き計算では原理的に届きません。
CoTはここを迂回します。
左辺は「答えを一発で書かせたときに使える計算の深さ」、右辺は「途中を トークン書かせたときの深さ」です。 は層数(作った時点で固定)、 は生成する長さ(こちらが指定できる)。モデルを大きくせずに、出力を長くして計算を増やしているわけです。
理論的な裏づけも出ています。"Chain of Thought Empowers Transformers to Solve Inherently Serial Problems" などは、一定の仮定のもとで、固定の深さのTransformerが1回の前向き計算では扱えない問題を、十分な長さのCoTを挟めば扱えるようになることを示しました。CoTは「考え方を教えている」というより、計算資源の使い方を変えていると捉えるほうが正確です。
この見方をすると、CoTがテスト時スケーリングの入口だったことが分かります。学習を増やす代わりに推論時に計算を積む、その最初で最も安上がりな形でした。
Self-Consistency: 何度も解かせて多数決を取る
CoTの弱点は、途中で1つ間違えるとそのまま最後まで走り切ってしまうことです。人間の筆算と同じで、直列な手順は1箇所で全体が壊れます。
Self-Consistency(自己一貫性)の処方箋は単純で、同じ問題を何度も解かせ、最終的な答えだけで多数決を取る。
は解かせる回数、 は 回目に出た最終的な答え、 は中身が成り立つとき1・そうでないとき0になる関数です。「 個の答えを並べて、いちばん多く出たものを採用する」と書いてあるだけです。
理屈は、正解へ至る道筋は複数あるが、間違え方はバラバラになりやすいことです。文面が違っても正しく解けたものは同じ数値に着地し、ミスの結果はミスの仕方によって散らばる。答えの側で数えると正解が山になります。
ここで決定的なのがサンプリング温度です。温度0(貪欲デコード)で何度呼んでも毎回同じ文章が返るため、温度を上げて道筋をばらけさせるのが前提になります。上げすぎれば答えまで散って山ができません。
実装はこれだけです。
from collections import Counter
def self_consistency(model, question, n=8, temperature=0.7):
prompt = f"{question}\nステップごとに考え、最後に「答え: X」の形で書いてください。"
answers = []
for _ in range(n):
text = model.generate(prompt, temperature=temperature) # 毎回ちがう道筋
answers.append(extract_final_answer(text)) # 「答え: 」以降だけ取る
return Counter(answers).most_common(1)[0][0] # 最頻値を採用
コストは素直に 倍で、精度をトークンで買っている手法です。答えが自由記述だと表記ゆれで多数決が壊れるため、数値や選択肢のように正規化できる答えに向きます。
効かない条件を先に知っておく
モデルが小さいとき。 元論文の重要な観察は、効果がモデル規模に依存することでした。小さいモデルに途中式を書かせると、もっともらしい形式の文章ができるのに中身が破綻し、答えだけ言わせたときより悪くなることがあります。形式は中身より先に真似できるのです。
タスクが数学・記号処理でないとき。 多数の実験を横断集計した "To CoT or not to CoT?" は、利得が数学や記号操作にほぼ集中し、常識推論や知識想起では小さいと報告しています。直列な計算が要らない問題に、計算段数を増やす仕掛けは効きません。
書かれた推論を説明として信じるとき。 "Language Models Don't Always Say What They Think" は、選択肢の並び順のような無関係な手がかりに答えが引きずられている場合でも、書かれたCoTはその手がかりに一切触れず、もっともらしい別の理由を並べることを示しました。CoTは思考の記録ではなく、出力されたテキストです。
出力形式を強く縛るとき。 JSONスキーマで {"answer": ...} だけを許すと、推論を書く場所が無くなり実質CoTなしになります。推論させたいならスキーマに reasoning を作り、answer より前に置く。JSONのキーは生成順がそのまま計算順です。
推論モデルとの関係
2024年以降の「推論モデル」は、この話の続きです。CoTをプロンプトで頼むのをやめ、強化学習で長い思考を自分で書く癖を焼き付けたものだと理解すると見通しが良くなります。計算資源の増やし方は同じ(出力を長くする)で、指示する主体がプロンプトから学習済みの方策へ移りました。
実務上の含意は明快です。推論モデルに「ステップごとに考えて」と足してもたいてい無意味で、指示の重複が思考を歪めることすらあります。触るのは各社が用意する思考量のつまみ(reasoning effort、thinking budget といった名前)です。通常モデルではCoTプロンプトはいまも有効で、安価なモデル+CoTと高価な推論モデルの素の呼び出しは、タスクごとに実測して選びます。Self-Consistencyの発想も、多数決や検証器による絞り込みとして推論モデルの内側や上位の制御層に残っています。
現場ではこう使う
誰がいつ触るか。 LLMを組み込んだ製品の開発者が、精度の足りない機能(見積り計算、条件分岐の多い問い合わせ判定、表からの集計など)をチューニングするとき。評価担当が、タスクにどのモデル階層を割り当てるか決めるときの比較軸としても使います。
触るパラメータ。 temperature(Self-Consistencyでは0以外必須、0.5〜0.9あたりから探る)、n(サンプル回数)、max_tokens、stop 文字列、構造化出力のスキーマとキー順、推論モデルなら思考量のパラメータ。
知らないと事故になる落とし穴。
max_tokens切れ。 CoTで出力が伸び、上限に当たって答えの直前で切れる。パースは空を返し、集計上は「推論の失敗」に見える不正解になる。CoT導入時は上限を上げ、打ち切り率を指標として計測する。- 温度0でSelf-Consistencyを回す。 同じ文章が 個返り、多数決は常に全会一致。精度は上がらず費用だけ 倍になる。
- 答えの抽出。 「答えは5台です」「5」「5」を正規表現1本で拾おうとすると壊れる。形式を明示し、それでも取れなければ2段階方式に落とす。
- CoTを利用者に見せる判断。 途中式が本当の根拠とは限らない以上、「AIの判断理由」として画面に出すのは説明の信頼性を過大に約束することになる。医療・金融・人事など説明責任が問われる領域では特に慎重に。
- ログのコスト。 全リクエストのCoTを保存すると保管量が桁で増える。何を残すかを先に決める。
設計レビューで問われる問い。 「Self-Consistencyとビームサーチの違いは何か」— 核は、文面が違っても答えが同じなら1票に数える点、つまり尤度の高い系列ではなく答えの合意を選んでいる点です。プロンプト技法全般の検証方法はプロンプトエンジニアリングの科学で扱っています。
まとめ
- CoTは「途中を書かせる」プロンプト。few-shotのお手本でも、一行の指示(zero-shot CoT)でも引き出せる
- 効く理由は、書いた文字が入力に戻ることと、1トークンあたり固定だった計算の深さを、出力の長さに置き換えられること
- Self-Consistencyは複数の道筋を走らせて答えで多数決を取る。温度0では成立せず、コストは回数に比例する
- 効かない条件(小さいモデル、直列計算を要さないタスク)と、書かれた推論が真の根拠とは限らないことを、必ずセットで覚える
- 推論モデルはこのCoTを学習で内在化したもの。プロンプトで頼む時代から、つまみで量を指定する時代へ移っている
コメント
コメントにはログインが必要です