複雑な論理推論を制する:Chain-of-Thoughtを用いたスケジューリング最適化プロンプト

Tech

creation_date: 2024-05-22 topic: Chain-of-Thought Optimization for Complex Reasoning target_model: Gemini 1.5 Pro, GPT-4o prompt_technique: Few-shot CoT, Structured Reasoning, Self-Correction version: 1.0

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。

複雑な論理推論を制する:Chain-of-Thoughtを用いたスケジューリング最適化プロンプト

【ユースケース定義と課題】

複数の制約条件が絡み合う複雑な会議スケジューリングを、論理的矛盾なくJSON形式で出力する推論タスク。

  • 入力の型:テキスト(参加者の空き時間、優先度、部屋の制約)

  • 出力の型:JSON(reasoning: 思考過程, schedule: 確定した予定)

【プロンプト設計のループ】

graph TD
A["設計: 思考ステップの構造化"] --> B["実行: 推論プロセスの強制書き出し"]
B --> C["評価: 制約違反と論理破綻の抽出"]
C -->|改善: 自己検閲フェーズの追加| A
  1. 設計: LLMが結論を急がないよう、Thinking Processタグを用いた思考の分離を設計します。

  2. 実行: 特定の論理パズルやスケジュール制約を与え、ステップ・バイ・ステップで解かせます。

  3. 評価: 出力されたJSONの構文と、時間重複などの論理的矛盾をLLM-as-a-Judgeで検証します。

【プロンプトの実装案】

# Role

あなたは複雑な制約条件を解く論理パズルのエキスパートです。

# Task

以下の「制約条件」に基づき、最適な会議スケジュールを策定してください。
回答は必ず「思考プロセス」を詳細に書き出した後、最終的な「スケジュール」をJSON形式で出力してください。

# Constraints (制約条件)


1. 参加者:Aさん(10:00-12:00可能)、Bさん(11:00-13:00可能)、Cさん(10:30-11:30不可)。

2. 会議時間は60分間とする。

3. 全員が参加できる時間帯を最優先する。

4. 会議室は1つしかない。

# Instruction


- Step 1: 各参加者の共通空き時間を抽出する。

- Step 2: 制約条件に反する時間帯を排除する。

- Step 3: 最適な時間を選択し、その理由を述べる。

# Output Format

<thinking>
(ここに詳細な思考プロセスを記述)
</thinking>

```json
{
  "reasoning_summary": "決定に至った主な理由",
  "schedule": {
    "start_time": "HH:MM",
    "end_time": "HH:MM",
    "attendees": ["A", "B", "C"]
  }
}
### 【評価指標と誤り分析】

#### 失敗パターン


- **早まった結論(Leaping to Conclusions)**: 思考プロセスを飛ばして、制約違反のある時間を提示する。

- **計算ミス**: 10:30から60分後を11:00と誤認するなどの算術的エラー。

- **JSON構文崩れ**: 思考プロセスがJSON内部に混入し、パース不可になる。

#### 採点基準(LLM-as-a-Judge)

| 評価項目 | 採点基準 (1-5) | 判定基準 |
| :--- | :--- | :--- |
| **論理的整合性** | 5 | 全ての制約条件を完璧に満たしている |
| **思考の透明性** | 5 | 矛盾の解消プロセスがステップごとに明文化されている |
| **フォーマット遵守** | 5 | 指定されたJSON構造で出力され、パースエラーがない |
| **自己修正能力** | 4 | 推論の途中で誤りに気づき、修正した形跡がある |

### 【改良後の最適プロンプト】

分析結果に基づき、**「自己検閲(Self-Correction)」**と**「Few-shot(例示)」**を強化したプロンプトです。

```text

# Role

論理的推論と構造化データ出力のスペシャリスト。

# Instructions


1. まず、`<thinking>`タグ内で、与えられた条件を箇条書きで整理してください。

2. 次に、可能性のある選択肢を列挙し、制約に抵触しないか1つずつ検証してください。

3. 最後に、検証済みの結果のみをJSON形式で出力してください。
※注意:JSONを出力する直前に、必ず「本当にこの時間は全員可能か?」を再チェックしてください。

# Example

Input: A(9-11), B(10-12), 60min meeting.
<thinking>

- A is free 9:00-11:00.

- B is free 10:00-12:00.

- Intersection: 10:00-11:00.

- Meeting duration is 60min. 10:00-11:00 fits perfectly.

- Re-check: A(OK), B(OK).
</thinking>
```json
{
  "selected_time": "10:00-11:00",
  "validation": "Passed"
}

Target Task

[ここに具体的なスケジュール要件をペースト] “`

【まとめ】

  1. 思考の分離: <thinking>タグ等を用いて、モデルに「書くことで考えさせる」物理的なスペースを与える。

  2. 自己検閲の強制: 「出力直前に再チェックせよ」という指示が、Gemini 1.5 Pro等の最新モデルでは幻覚抑制に劇的な効果を発揮する。

  3. 型定義の厳格化: JSON等の構造化出力を求める場合、思考プロセスをJSONの外に出すことでパースエラーを最小限に抑える。

ライセンス:本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL(本ページ)を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました