高度な自律型エージェントの最適化：PromptWizard（命令最適化）とAgent Lightning（動作訓練）の比較

Tech

{ “system_purpose”: “Prompt optimization and agent training methodology comparison”, “methodologies”: [“PromptWizard”, “Agent Lightning”, “Chain-of-Thought”, “LLM-as-a-Judge”], “target_model”: “Gemini 1.5 Pro/Flash, GPT-4o”, “version”: “1.1” }

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

高度な自律型エージェントの最適化：PromptWizard（命令最適化）とAgent Lightning（動作訓練）の比較

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

ユースケース： 不透明な顧客リクエストから、複数の内部ツールを組み合わせた実行プランをJSON形式で生成する「自律型カスタマーエンジニアリング」。

課題：

  • PromptWizard的課題： 曖昧な指示による推論の脱線や、出力フォーマットの崩壊（命令精度の不足）。

  • Agent Lightning的な課題： ツール実行の試行錯誤（軌跡）が多すぎてトークンを浪費し、最終回答までのレイテンシが許容範囲を超える（動作効率の不足）。

入出力の型：

  • Input: ユーザーの非構造化テキスト

  • Output: {"plan": [{"tool": "name", "args": {...}}], "reasoning": "..."}（JSON形式）

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

PromptWizard（命令の反復改善）とAgent Lightning（動作の固定化/高速化）のサイクルを統合したプロセスを設計します。

graph TD
A["設計: 命令定義と軌跡設計"] --> B["実行: Few-shot/CoTによる推論"]
B --> C["評価: 精度・速度・コストの計測"]
C -->|命令の弱点改善| A
C -->|動作の定型化/蒸留| D["最適化: Agent Lightning適用"]
D --> B

  1. 設計: ツール仕様と推論ステップの記述（PromptWizard的アプローチ）。

  2. 実行: 実際にエージェントを動かし、思考プロセス（CoT）をログ化。

  3. 評価: 成功パターンのログを収集し、LLM-as-a-Judgeで採点。

  4. 最適化: 成功した思考の「型」をプロンプトにハードコード、または小規模モデルへ蒸留（Agent Lightning的アプローチ）。

【プロンプトの実装案】

PromptWizard的な「自己改善プロセス」を含めた、Few-shot/CoTプロンプトの例です。

# Role

あなたは複雑な技術課題を解決するカスタマーエンジニアリング・エージェントです。

# Task

ユーザーの入力を分析し、利用可能なツールを用いて最適な実行プランをJSONで生成してください。

# Tools


1. get_user_log(user_id): ログ抽出

2. check_api_status(service_name): サービス死活監視

# Thought Process (Chain-of-Thought)


1. ユーザーの真の目的を特定する

2. 必要な情報を収集するためのツールを選択する

3. 依存関係を考慮して実行順序を決定する

4. JSON形式で出力する

# Example (Few-shot)

User: "ユーザーAがログインできないと言っている"
Thought: ログイン失敗の原因を特定するため、まずはログを確認し、次に認証サービスのステータスを確認する必要がある。
Response: 
{
  "plan": [
    {"tool": "get_user_log", "args": {"user_id": "A"}},
    {"tool": "check_api_status", "args": {"service_name": "auth_service"}}
  ],
  "reasoning": "Login failure investigation requires log analysis and service health check."
}

# Constraint


- 出力は純粋なJSONのみ。解説は不要。

- 知らない情報は推測せず、ツールで確認するプランを立てること。

【評価指標と誤り分析】

エージェントのパフォーマンスを以下の基準で評価し、PromptWizard（命令修正）かAgent Lightning（軌跡固定）かを判断します。

指標 失敗パターン 分析と対策
指示遵守（PromptWizard） Markdownが混じる、JSONが壊れる 指示の優先順位を明確化、出力例を強化
推論精度（PromptWizard） ツール選択の誤り、論理の飛躍 CoTのステップを細分化、Few-shotの差し替え
実行速度（Agent Lightning） 思考プロセスが長すぎる、冗長なツール呼び出し 思考ログを短縮（蒸留）、決定的な判断ロジックへの変換
信頼性（Agent Lightning） 同じ入力に対して出力が不安定 成功した軌跡（Trajectory）を固定テンプレート化

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

Agent Lightningの「効率的な軌跡」をPromptWizardで「洗練された命令」に昇華させた、Gemini 1.5 Pro等に最適なプロンプトです。

# System

Structure: {Thought -> Plan -> Output}
Strict Mode: JSON Only

# Mission

Analyze the input and provide the minimum necessary tool-call sequence.

# Success Trajectory (Agent Lightning Reference)


- Input: "Issue with API latency"

- Logic: check_status -> get_metrics -> find_bottleneck

- Decision: Do not use get_user_log if the issue is global.

# Output Schema

{
  "thought_process": "Brief step-by-step logic",
  "execution_plan": [
    {"step": 1, "action": "tool_name", "params": {}}
  ]
}

# Execution

User Query: {{QUERY}}

【まとめ】

実務でプロンプトを運用するための3つの鉄則：

  1. 「命令」と「軌跡」を分けて管理する： プロンプトの内容（PromptWizard）で解決するか、実行手順のパターン化（Agent Lightning）で解決するかを評価ログに基づいて切り分ける。

  2. LLM-as-a-Judgeを早期に導入する： 人手による評価はスケールしない。改良したプロンプトを「評価用LLM」にかけ、前バージョンとの勝率を自動計測する環境を構築する。

  3. トークン効率を「品質」とみなす： Agent Lightningの思想を取り入れ、冗長なCoTは「成功パターンの要約」に置き換えることで、精度を維持したままレイテンシとコストを削減する。

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

コメント

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