Chain-of-Thought

Introduction

Chain-of-Thought（CoT）プロンプティングは大型言語モデルが複雑な推論問題を解決する際に中間段階の思考過程を明示的に生成させるプロンプティング技法です。別途のモデルファインチューニングなしでもFew-shot例示だけでモデルの推論能力を劇的に向上させることができる方法論です。

最近の研究のPrompting方法はCoTを基盤としているほど、Prompt Engineering分野では基礎方法として定着した重要な手法です。

Motivation

この方法は大規模言語モデル（LLM）が複雑な推論タスクを効果的に実行できない問題を解決するために作成されました。

• モデルサイズ増加だけでは複雑な推論能力向上に限界

  • 最近言語モデルの規模を拡大することが性能向上に役立つことが実証されましたが、算術、常識、記号的推論のような困難なタスクでは単純にモデルサイズを増やすだけでは高い性能を達成するのに十分ではありませんでした。

• 既存推論向上技法の限界:

  • 自然言語推論過程生成（Rationale generation）技法の高コスト: 以前にモデルが自然言語中間段階を生成するよう学習させたりファインチューニングする研究がありましたが、このような方式は高品質の推論過程を大量に生成するのにコストがかかるという限界がありました。一般的な機械学習で使用される単純な入力-出力ペアよりもはるかに複雑だからです。

  • 従来のFew-shotプロンプティングの推論タスクに対する低い性能: Brown et al.（2020）が大衆化した従来のFew-shotプロンプティング方式は簡単な質問-回答タスクでは成功的でしたが、推論能力が必要なタスクでは正常に動作せず、言語モデル規模が大きくなっても性能が大幅に向上しない傾向を示しました。

Method

CoT種類2つ

Zero-Shot-CoT

最も簡単な方式です。質問の後に単純に**「Let's think step by step」のような文句を追加してLLM自身で段階別推論をするようにします。別途の例示（demonstration）が不要で便利ですが、性能はManual-CoT**より低いです。

Manual-CoT

質問と共に人が直接設計した推論過程例示（demonstration）を複数示す方式です。この例示は質問、中間推論段階（rationale）、そして正答で構成されています。 Manual-CoTはZero-Shot-CoTよりも良い性能を示しますが、問題はこの例示を手動で、一つずつ作成しなければならない点です。これは相当な努力と時間がかかり、さらにタスクごとに異なって設計する必要がある場合もあります。

Zero-Shot-CoT例示

プロンプト:

Johnは飴を5個持っています。お母さんが飴袋を2袋追加で買ってくれました。各袋には飴が3個ずつ入っています。Johnは今飴を総何個持っているでしょうか？

段階別に考えてみましょう。

AI応答:

段階別に解いてみます：

1. Johnが最初に持っていた飴: 5個
2. お母さんが買ってくれた飴袋: 2袋
3. 各袋に入っている飴: 3個ずつ
4. 新しく受け取った飴の総個数: 2袋 × 3個 = 6個
5. Johnが持っている飴の総個数: 5個 + 6個 = 11個

したがってJohnは今飴を総11個持っています。

Manual-CoT例示

質問: 学校給食室にりんごが23個ありました。昼食作りに20個を使用し、新しく6個を追加で買いました。今りんごは何個でしょうか？
答: 給食室に元々りんごが23個ありました。昼食作りに20個を使用したので23 - 20 = 3個が残りました。その後に6個を追加で買ったので3 + 6 = 9個になりました。答えは9個です。

質問: Sarahはチョコレートを32個持っていて、姉のEmilyは42個を持っています。二人合わせて35個を食べたとすると、総何個残ったでしょうか？
答: Sarahが32個、Emilyが42個を持っていたので総32 + 42 = 74個でした。二人で35個を食べたので74 - 35 = 39個が残りました。答えは39個です。

質問: Johnは飴を5個持っています。お母さんが飴袋を2袋追加で買ってくれました。各袋には飴が3個ずつ入っています。Johnは今飴を総何個持っているでしょうか？
答:

AI応答:

Johnは最初に飴を5個持っていました。お母さんが飴袋を2袋買ってくれたのですが、各袋に3個ずつ入っているので2 × 3 = 6個をさらに受け取りました。総飴個数は5 + 6 = 11個です。答えは11個です。

Details

1. モデルサイズに比例した結果

研究結果によると、Chain-of-Thoughtプロンプティングはモデルサイズが100Bパラメータを超える時に創発的に現れる能力です。

実験結果:

• GSM8K数学問題: PaLM 540Bで17.9% → 56.9%（39%p向上！）

• 算術推論: GPT-3 175Bで15.6% → 46.9%（31.3%p向上！）

• 常識推論: 多様なベンチマークで一貫した性能向上

💡 核心成功要因

適切な例示個数: 一般的に4-8個例示が最適

• 少なすぎるとパターン学習不足

• 多すぎるとコンテキスト限界とコスト増加

一貫した形式: すべての例示で同一構造維持

✅ 良い例示:
問題: [問題内容]
推論: [段階別思考過程]
答: [最終答]

❌ 悪い例示:
問題1: [内容] → 答: [結果]
Q: [内容] A: [過程] = [結果]

2. 🏆 効果的な例示設計原則

a. 明確で一貫した構造維持

✅ 推奨テンプレート:
問題: [具体的な問題状況]
解決: [段階別推論過程、各段階を明確に区分]
答: [最終結果]

例示:
問題: カフェテリアにりんごが23個ありました。昼食作りに20個を使用し、6個を追加で買いました。今りんごは何個ありますか？
解決: カフェテリアには元々23個のりんごがありました。20個を使用したので23 - 20 = 3個が残りました。その後6個を追加で買ったので3 + 6 = 9個があります。
答: 9個

b. 適切な複雑度の例示選択

• 簡単すぎる問題: モデルがパターンを学習しにくい

• 難しすぎる問題: 混乱を引き起こす可能性

• 推奨: 目標問題と類似した難易度の例示使用

c. 多様性と代表性確保

✅ 良い例示セット:
- 足し算が必要な問題1個
- 引き算が必要な問題1個
- 掛け算/割り算が必要な問題1個
- 複合演算が必要な問題2-3個
- 多様なコンテキスト（ショッピング、料理、旅行など）

❌ 避けるべき例示セット:
- すべて似たようなパターンの問題
- 一つの演算のみ繰り返される構造

3. 🔧 一般的な間違いと解決策

間違いa: 不一致な形式

❌ 問題のある例示:
Q1: "問題内容" → 答: 結果
問題2: [内容] 解決過程... = 答
質問: 内容? A: 答はX

✅ 改善された例示:
問題: "問題内容"
解決: [段階別過程]
答: 結果

（すべての例示で同一形式維持）

間違いb: 過度に複雑な推論

❌ 複雑すぎる例示:
"まずAを考慮し、Bの影響を分析した後、Cとの相関関係を確認して、
Dの条件下でEを計算すると..."

✅ 適切な複雑度:
"最初にX個がありました。Y個を使用したのでX-Y=Z個が残りました。
追加でW個を購入したので最終的にZ+W個です。"

間違いc: 計算エラー含有

⚠️ 注意事項:
例示で計算ミスがあるとモデルも同じミスを繰り返す可能性が高い

推奨方法:
- 例示作成後検算必須
- 可能なら計算機で検証
- 同僚レビュー過程を経る

4. 📈 性能最適化ティップ

a. 例示順序最適化

• 簡単な問題から難しい問題順に配置

• 各タイプ別に最低1個ずつ含有

• 最後の例示は目標問題と最も類似させる

b. 長さ調節

• 推論過程が長すぎるとトークン制限問題

• 短すぎると学習効果減少

• 推奨: 問題当たり50-150トークン内外

c. 検証と反復

性能改善プロセス:
1. 初期例示セットでテスト
2. 失敗事例分析
3. 不足パターン把握
4. 例示追加/修正
5. 再テスト

Applicability

🎯 Chain-of-Thoughtが必須の状況

1. 複雑な多段階推論が必要な場合

• 数学問題（特に文章題）

• 論理的推論チェーンが長い問題

• 複数情報を総合する必要がある状況

2. 大型言語モデルを使用する場合

• 100B+パラメータモデルでのみ効果的

• GPT、Claude、PaLMなど

3. 解釈可能性が重要な状況

• 推論過程を検証する必要がある業務

• 教育用コンテンツ生成

• 意思決定過程の透明性が必要な場合

Limitations

1. 単純なタスク

❌ 非効率的な場合:
"パリはフランスの首都ですか？"
→ 単純な事実確認は標準プロンプティングで十分

✅ 効果的な場合:
"フランス大統領の任期が7年から5年に変わった理由とその影響を分析してください"
→ 複雑な分析と推論が必要

2. 小型モデル使用時

• 100B未満パラメータモデル

• ローカルで実行する小型モデル

• 性能向上よりもむしろ低下の可能性

3. トークンコストが極度に敏感な状況

• 大量バッチ処理

• リアルタイム応答が重要なサービス

• コスト対効果を慎重に考慮する必要