PromptWizard vs Agent Lightning：タスク最適化とエージェント訓練の比較検証ガイド

Tech

RESEARCH-FIRST: PromptWizard (Iterative prompt optimization via evolutionary algorithms) and Agent Lightning (High-speed agent training/finetuning focusing on tool-use trajectories). PLAN: Define a complex “Technical Support Router” use case to test these methodologies. Compare instruction-level optimization (PromptWizard) versus trajectory-level optimization (Agent Lightning). 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

PromptWizard vs Agent Lightning：タスク最適化とエージェント訓練の比較検証ガイド

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

ユースケース： 多言語かつ技術的に複雑なカスタマーサポートチケットの自動分類・優先度判定・初動回答案の生成。

課題：

  • 専門用語の誤認による分類ミス（例：ハードウェア障害をソフトウェアバグと誤判定）。

  • 優先度（P1-P4）の判定基準が曖昧で、SLA（サービス品質保証）を遵守できない。

  • 型定義： 入力は「問い合わせ原文」、出力は「カテゴリ、優先度、理由、回答案」を含むJSON形式。

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

graph TD
A["設計: 役割と出力形式の定義"] --> B["実行: PromptWizard/Agent式入力"]
B --> C["評価: LLM-as-a-Judgeによる自動採点"]
C -->|分類誤り/様式崩れ| A
C -->|精度向上| D["最適プロンプトの確定"]

  1. 設計：Few-shot例とChain-of-Thought（思考連鎖）を組み込んだベースライン作成。

  2. 実行：Gemini 1.5 Pro等のモデルに対し、多様なテストケースを投入。

  3. 評価：後述する評価指標に基づき、期待値との乖離（ロス）を算出。

  4. 改善：PromptWizard的アプローチ（指示文の進化）またはAgent Lightning的アプローチ（行動軌跡の修正）による再設計。

【プロンプトの実装案】

ここでは、PromptWizardの思想（指示の具体化）とfew-shotを組み合わせた初期プロンプトを提示します。

# Role

あなたは熟練したテクニカルサポートエンジニア兼、チケット仕分けの専門家です。

# Task

入力されたユーザーの問い合わせを分析し、以下のJSON形式で出力してください。

# Output Format

{
  "category": "Software / Hardware / Billing / Other",
  "priority": "P1 (Critical) / P2 (High) / P3 (Medium) / P4 (Low)",
  "reasoning": "なぜその判定に至ったかの簡潔な理由",
  "draft_response": "ユーザーへの丁寧な初動回答"
}

# Guidelines (Chain-of-Thought)


1. 問い合わせ内容から「製品名」「エラーコード」「緊急性を示すキーワード」を抽出せよ。

2. データの損失やサービス停止が伴う場合は、無条件でP1と判定せよ。

3. 回答案には、必ず次にユーザーがすべきアクション（ログの送付等）を含めよ。

# Examples

Input: "ログインできない。DBエラー500が出ている。至急直して。"
Output: {
  "category": "Software",
  "priority": "P1",
  "reasoning": "サーバー内部エラー(500)が発生しており、全ユーザーに影響する可能性があるため。",
  "draft_response": "ご不便をおかけしております。現在調査中ですが、エラー発生直前の操作内容を教えていただけますか？"
}

【評価指標と誤り分析】

期待通りにいかない主要なパターン：

  • ハルシネーション：存在しない製品マニュアルを参照した回答。

  • 様式崩れ：JSONの末尾に不要な解説テキストが付随する。

  • 優先度ブレ：同一の内容でも実行ごとにP2とP3が入れ替わる。

LLM-as-a-Judge 採点基準

評価項目 判定基準 配点
形式遵守 JSONとしてパース可能か、スキーマは正しいか 30点
分類精度 正解ラベルとカテゴリ・優先度が一致しているか 40点
回答妥当性 回答案が具体的かつ解決に資する内容か 20点
思考論理 Reasoningが論理的整合性を保っているか 10点

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

Agent Lightningの「軌跡の最適化（最適ルートの提示）」とPromptWizardの「指示の進化」を統合したプロンプトです。Gemini 1.5 Proの長いコンテキスト窓を活かし、「失敗例とその修正プロセス」を明示します。

# Role

System Triage Agent v2.0 (Optimized via Trajectory Analysis)

# Constraints


- Output strictly in JSON. No preamble or postscript.

- Use 'Reasoning-First' approach: Internal monologue before final decision.

# Knowledge Base (Anti-Patterns)


- DO NOT classify "slow performance" as P1 unless it affects >50% of users.

- DO NOT provide generic answers like "Please wait". Always ask for specific logs.

# Thinking Process (Task Decomposition)


1. Analyze User Intent: Is this a feature request or a bug?

2. Impact Assessment: Estimate number of affected users based on keywords.

3. Priority Matrix: 

   - Data Loss -> P1

   - Critical Feature Blocked -> P2

   - Workaround Available -> P3

   - Cosmetic/UI -> P4

# Few-shot Trajectories (Self-Correction Examples)

[Input] "I found a typo in the settings menu."
[Thought] Low impact, cosmetic. No functional block. 
[Result] {"category": "Other", "priority": "P4", "reasoning": "UI typo, zero impact on functionality.", "draft_response": "Thank you for the report. We've logged this for a future UI update."}

[Input] {{USER_QUERY}}

【まとめ】

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

  1. 「指示」よりも「思考プロセス」を固定する： 単に「正確に判定して」と書くのではなく、判定に至るまでの思考ステップ（Impact Assessment等）をプロンプト内で定義する。

  2. ネガティブ制約（アンチパターン）を明記する： PromptWizard的手法で得られた「過去の失敗」を、プロンプトに「やってはいけないこと」としてフィードバックし続ける。

  3. LLMによる自動評価をパイプラインに組み込む： 人間が毎回確認するのではなく、別のLLM（評価者）にJSONスキーマと論理性に基づいたスコアリングをさせ、精度を定量化する。

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

コメント

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