今回の論文
今回取り上げるのは、Xuezhi Wang、Jason Wei、Dale Schuurmans らによる論文「Self-Consistency Improves Chain of Thought Reasoning in Language Models」です。2022 年 3 月に arXiv で公開された論文で、研究分野は大規模言語モデルの推論手法、推論時最適化、Chain-of-Thought reasoning です。URL は https://doi.org/10.48550/arXiv.2203.11171 です。
この論文を選んだ理由は、モデルを追加学習しなくても、推論のさせ方だけで精度を大きく伸ばせるからです。特に、数学問題、複数ステップの判断、ルールベースの業務判定のように「1 回の推論でたまたま外す」ことが痛い場面では、かなり実務的な発想です。モデルの重みを変えずに品質を上げたい場面に直結します。
どんな技術か
Self-Consistency は、LLM に 1 本の思考過程だけを出させて終わるのではなく、複数の異なる思考過程をサンプリングし、その中で最も一貫して現れる最終答えを採用する推論手法です。
普通の Chain-of-Thought では、モデルに「順を追って考えて」と促したうえで、1 回だけ推論を走らせ、その結果をそのまま答えにします。しかしこの方法では、途中の思考が少しでもズレると、そのまま誤答になります。特に greedy decoding のように 1 本のもっともらしい経路だけを選ぶ方式では、その 1 本がたまたま悪い経路だったときに立て直せません。
Self-Consistency は、この弱点に対して「考え方が違っても、正しい答えなら最後は同じところに集まりやすい」という考えを使います。一言でいえば、Self-Consistency は「推論経路を複数出して、多数決や集約で最終答えを安定化する技術」です。
課題
この技術が解決しようとしているのは、LLM の推論が 1 本の生成経路に強く依存してしまう問題です。
何が難しいのかというと、多段の推論タスクでは途中の計算や判断が少しずれるだけで、最後の答えが全体として間違ってしまうからです。算数文章題、常識推論、ルール判断のようなタスクでは、最終答えだけでなく、途中の推論経路にも不確実性があります。
既存の方法では、Chain-of-Thought 自体は推論力を引き上げましたが、基本的には 1 本の reasoning path を生成して終わることが多く、その 1 本が最適とは限りません。beam search のような探索もありますが、尤度の高い近い表現に寄りやすく、多様な考え方を十分に拾えないことがあります。検証器や reranker を別途学習する方法もありますが、追加学習や人手アノテーションが必要になり、導入コストが上がります。
なぜこの課題を解く必要があるのかというと、実際の AI システムでは「一見それっぽいが答えは違う」出力がかなり危険だからです。社内問い合わせ分類、見積もり補助、ログ解析、データ整形、構造化抽出のような処理では、自然な文章で間違えるより、多少遅くても答えが安定しているほうが価値があります。
つまり Self-Consistency の課題設定は、モデルを作り直さずに、推論時の計算のかけ方だけで答えの信頼性をどこまで上げられるか、という点にあります。
用語解説
- Chain-of-Thought
- 最終答えの前に途中の思考手順を書かせるプロンプト手法です。Self-Consistency はこの出力を前提にしており、複数の思考経路を比較するための土台になります。
- greedy decoding
- 各時点で最も確率が高い次トークンを選び続ける生成方法です。速い反面、1 本の局所的に良さそうな経路へ固定されやすく、推論の分岐を拾いにくい点がこの論文の出発点です。
- sampling
- 確率分布から次トークンをサンプルして複数の生成候補を作る方法です。Self-Consistency では、異なる推論経路を集めるためにこの多様性が重要になります。
- reasoning path
- モデルが最終答えに至るまでの中間推論列です。この論文では、正しい答えに至る reasoning path は複数あっても、誤った経路より最終答えで一致しやすいという仮説を置いています。
- marginalization
- 個々の推論経路そのものではなく、その先に出てきた最終答えの分布を集約して意思決定する考え方です。Self-Consistency の本質は、途中経路ではなく最終答えの一貫性を見る点にあります。
技術の仕組み
Self-Consistency のポイントは、推論経路を直接「採点」するのではなく、複数の経路を通した最終答えの合意を使うことです。実装としては難しいモデル改造をせず、推論の回し方を変えるだけで成立します。
基本アイデア
基本アイデアは単純です。まず Chain-of-Thought 形式でモデルに考えさせます。ただし 1 回だけではなく、温度付きサンプリングなどを使って複数回生成します。すると、同じ問題に対して少しずつ違う思考過程が得られます。
その後、それぞれの出力から最終答えを抽出し、最も多く現れた答えを採用します。途中の説明文が多少違っていても、最終答えが一致していれば、その答えを強く支持するという考え方です。
処理の流れ
推論フローは大まかに 3 段階です。
まず、few-shot あるいは明示的な Chain-of-Thought プロンプトでモデルに「途中経過を含めて答える」よう促します。次に、greedy ではなく sampling で複数の候補を生成します。最後に、各候補の最終答えだけを取り出して集計し、最多の答えを返します。
この構造は、複数モデルのアンサンブルに似ていますが、違うのは 1 つのモデルを何度か走らせているだけという点です。論文でも、これは追加学習を必要としない self-ensemble 的な方法として位置づけられています。
なぜ複数経路が効くのか
この手法の前提は、難しい問題には複数の正しい考え方がありうる一方で、誤答はばらつきやすいということです。たとえば算数問題なら、式の立て方が少し違っても答えが一致することがあります。逆に間違った推論は、途中のミスの入り方によって答えが散りやすいです。
そのため、1 本の「もっともらしい経路」だけを見るより、複数経路の最終答え分布を見るほうが、正答を拾いやすくなります。Self-Consistency は、推論の多様性と最終答えの収束性を同時に使っているわけです。
集約方法
論文では、最終答えの単純多数決がかなり強いことが示されています。各出力にモデル確率を掛けて重み付けする案も検討されていますが、実際には単純な多数決と大きく変わらない、あるいは扱い方によっては悪化するケースもありました。
これは重要です。実務で使うなら、複雑なスコアリングより、まずは「答えを正規化して vote する」実装で十分戦える可能性があります。算数なら数値正規化、分類ならラベル正規化、JSON 出力ならキーの整形といった前処理のほうが効きやすいです。
モデル構造や学習は変えるのか
この論文の良いところは、モデル本体の構造も重みも変えない点です。新しい層を足したり、追加学習したりしません。既存の LLM に対して、推論時に複数サンプルを引いて、最終答えを集約するだけです。
そのため、今ある API ベースの LLM や社内推論基盤にも比較的載せやすいです。もちろんトークンコストは増えますが、モデル再学習よりははるかに軽く、PoC しやすいアプローチです。
重要な工夫
この論文の工夫は、beam search のように似た候補を深掘りするのではなく、多様な reasoning path を意図的に集めたことです。さらに、推論経路自体の品質判定ではなく、最終答えの整合性へ問題を落とし直した点も大きいです。
これは現在のエージェント設計でも有効です。途中の tool call や reasoning trace を完全採点するのは難しくても、最終アクションや最終 JSON の一致率を見る形なら、かなり実装しやすいからです。
実験と結果
論文では、Self-Consistency が本当に精度改善につながるのか、どのモデルでも効くのか、他のデコーディング戦略より強いのかを広く検証しています。
何を検証したのか
主な検証は 3 つあります。1 つ目は、通常の Chain-of-Thought + greedy decoding と比べて、Self-Consistency がどれだけ精度を改善するかです。2 つ目は、PaLM-540B、LaMDA-137B、GPT-3-175B、UL2-20B など複数モデルで効果が出るかです。3 つ目は、単純な sample-and-rank、beam search、アンサンブル型の比較法より優れているかです。
データセットや評価指標
評価対象は、算術推論と常識推論を含む複数ベンチマークです。代表例として GSM8K、SVAMP、AQuA、StrategyQA、ARC-challenge などが使われています。指標は主に accuracy で、最終答えが正しいかどうかを見ています。
この設定は実務的にも読みやすいです。途中の文章が自然かではなく、答えが当たったかを直接見ているので、業務ロジックの自動判定や structured output の評価感覚に近いです。
どのような結果が出たのか
論文の代表的な結果では、Self-Consistency は Chain-of-Thought の greedy decoding に対して大きな改善を示しました。具体的には、PaLM-540B や GPT-3 と組み合わせた場合に、GSM8K で +17.9 ポイント、SVAMP で +11.0 ポイント、AQuA で +12.2 ポイント、StrategyQA で +6.4 ポイント、ARC-challenge で +3.9 ポイントの絶対改善が報告されています。
また、論文では単純な多数決がかなり強く、複雑な重み付け集約が必ずしも有利ではないことも示しています。これは、モデル自身の生成確率が「正しい推論」と「もっともらしい誤答」を十分に見分けられていない場合があることを示唆しています。
結果から何が言えるのか
この結果から言えるのは、推論性能はモデルサイズや追加学習だけで決まるわけではなく、test-time compute の使い方でも大きく変わるということです。特に reasoning 系タスクでは、1 回の最良っぽい出力より、複数回の合意を取るほうが強い場面があります。
もう 1 つ重要なのは、改善幅が算術だけでなく常識推論にも出ている点です。つまり Self-Consistency は単なる「計算問題専用の小技」ではなく、途中の思考経路が最終答えへ影響するタスク全般に広がる可能性があります。
何に使える？
Self-Consistency は、多少コストをかけても誤答率を下げたい LLM アプリに向いています。特に、最終出力が短く、答えの正誤を定義しやすいタスクと相性が良いです。
数値判断やルール判定を含む社内ツール
見積もり補助、請求チェック、在庫判定、障害切り分けのように、途中で複数の条件分岐が入る業務では使いやすいです。1 回だけの推論だと条件の見落としが起きやすいですが、複数経路を回して最終ラベルを集約すれば、偶発的なミスを減らせます。
エージェントの最終アクション選択
AI エージェントでは、途中の思考より「どのツールを使うか」「最終的に何を返すか」が重要です。Self-Consistency の考え方を使えば、複数回の plan を生成して、最終 action type や API call の一致を取る設計ができます。特に高コストな外部操作の前段で使うと有効です。
構造化出力の安定化
JSON 生成、カテゴリ分類、SQL 生成のように、出力形式が比較的固定されている処理にも向いています。複数候補を生成して、最終値や主要フィールドの一致を取ると、1 回だけの生成より壊れにくくなります。単純な majority vote だけでなく、フィールド単位の投票へ拡張することもできます。
RAG の最終回答検証
RAG 自体の検索精度を上げる技術ではありませんが、取得済みコンテキストをもとに回答を組み立てる段階で使えます。同じ文書群から複数の説明経路を生成し、最終結論や抽出値の一致を見ることで、回答の安定性を上げやすくなります。
開発や事業へのヒント
この論文から得られる一番大きなヒントは、モデル改善のレバーは「学習」だけではなく、「推論の設計」にもあるということです。これは小規模チームにとってかなり重要です。
まずは再学習より推論設計を疑う
自分で AI アプリを作るとき、精度が足りないとすぐ fine-tuning を考えがちです。ただ、最終答えが 1 回の偶然に左右されているだけなら、Self-Consistency のような複数サンプル集約で十分改善することがあります。学習基盤が弱いチームほど、先に試す価値があります。
高付加価値領域では「1 回あたりのコスト増」を許容しやすい
法務チェック、経理補助、セキュリティ運用、開発支援のレビュー補助など、1 回のミスが高くつく領域では、推論回数を数倍にしても十分元が取れる場合があります。Self-Consistency は、速度より正確さを優先するプランを商品として切り分ける発想にもつながります。
小規模プロダクトでも実装しやすい
この手法はモデルの再学習や重い MLOps を前提にしません。API を複数回叩いて、最後に正規化して集約するだけでも始められます。つまり、小規模 SaaS や社内自動化でも導入の敷居が低いです。特に MVP 段階では、学習投資より先に推論設計で勝てることがあります。
今後注目すべき方向性
Self-Consistency を起点に見ると、今後注目すべき方向性は 2 つあります。1 つは、必要なときだけ複数サンプルへ切り替える適応的な test-time compute 制御です。もう 1 つは、最終答えの多数決だけでなく、途中の不確実性推定や verifier と組み合わせる方向です。これは現代の reasoning model や agentic workflow に直結しています。
限界
Self-Consistency の最大の弱点は、単純に推論コストが増えることです。複数サンプルを引くので、トークン消費もレイテンシもその分大きくなります。高頻度リクエストの API やリアルタイム用途では、そのままでは重すぎる可能性があります。
また、この手法は「正しい答えが複数経路で収束しやすい」ことを前提にしています。そのため、そもそも問題設定が曖昧なタスクや、最終答えの正規化が難しい自由生成タスクでは扱いづらいです。意見生成や長文クリエイティブ生成のようなケースでは、多数決の意味が薄くなります。
さらに、複数回サンプルしても、モデルが同じ誤ったバイアスを繰り返すなら改善しません。元のモデル知識が不足している場合や、誤った前提文脈を読ませている場合には、合意がそのまま誤答の合意になることもあります。
実装面では、最終答えの抽出と正規化が意外に重要です。数値、選択肢、JSON、ラベルなど、タスクごとに answer parser を丁寧に作らないと、多数決の前段で壊れます。論文でも、答えの取り出し方はタスク依存です。
よくある質問
Q. Self-Consistency は Chain-of-Thought と何が違うのですか？
A. Chain-of-Thought は途中の思考手順を書かせるプロンプト手法で、Self-Consistency はその出力を複数回生成して最終答えを集約する推論手法です。前者は「考えさせる」方法、後者は「複数の考えをまとめる」方法です。
Q. どんなタスクで特に効果が出やすいですか？
A. 算術、ルール判定、分類、構造化出力のように、最終答えを比較しやすいタスクで効果が出やすいです。逆に、自由記述の長文生成では多数決の設計が難しくなります。
Q. beam search より良いのですか？
A. この論文の主張は、多様な推論経路を集める点で Self-Consistency が有利だというものです。beam search は高確率な近い候補へ寄りやすく、別の考え方を十分に拾えないことがあります。
Q. 実務では何回くらいサンプルすればよいですか？
A. 論文は複数サンプルで効果を示していますが、実務ではコストとのバランスで決める必要があります。まずは 3 回から 5 回程度で効果を測り、難問だけ 10 回以上に増やす段階的設計が現実的です。これは論文の直接記載ではなく、実装上の推奨です。
Q. fine-tuning の代わりになりますか？
A. 場合によります。モデル知識自体が足りないなら fine-tuning や RAG が必要です。一方で、知識はあるが 1 回の推論が不安定という課題には、Self-Consistency のほうが低コストで効くことがあります。
今日の学び
この論文は、LLM の推論が 1 本の生成経路に依存しすぎるという課題を扱いました。これに対して Self-Consistency は、複数の reasoning path をサンプリングし、最終答えの一貫性で集約することで解こうとしました。
ここから得られるヒントは、AI の性能改善は学習だけでなく推論設計でも実現できるということです。特に、答えを 1 回で決めると不安定なタスクでは、複数経路から合意を取る発想が、開発やプロダクト設計の強い武器になります。