PromptWizard vs Agent Lightning：高度な構造化データ抽出のためのプロンプト最適化戦略

Tech

{ “expert_role”: “Prompt Engineering Specialist”, “methodology”: [ “PromptWizard (Iterative Optimization)”, “Agent Lightning (Trajectory Distillation)”, “Chain-of-Thought (CoT)”, “LLM-as-a-Judge” ], “target_model”: “Gemini 1.5 Pro / GPT-4o”, “version”: “1.0” }

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

PromptWizard vs Agent Lightning：高度な構造化データ抽出のためのプロンプト最適化戦略

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

ユースケース： 複雑な金融報告書（非構造化データ）から、特定の親子関係を持つエンティティ（企業名、投資額、日付、リスク要因）を抽出し、厳密なJSON形式で出力する。 課題： 単純なFew-shotでは、文脈が複雑な場合にエンティティの紐付けミス（幻覚）や、JSONスキーマの崩れが発生し、実運用に耐えうる精度（95%以上）の確保が困難である。

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

graph TD
    A["設計: タスク定義とスキーマ指定"] --> B["実行: プロンプト投入と推論"]
    B --> C["評価: 精度・形式の自動検出し、スコア化"]
    C -->|改善案の生成: PromptWizard的アプローチ| A
    C -->|成功軌跡の蒸留: Agent Lightning的アプローチ| A

  1. 設計: PromptWizardの手法を用い、指示文を「メタ指示」として分離。

  2. 実行: Agent Lightningの思想に基づき、最適な推論ステップ（思考の軌跡）をモデルに辿らせる。

  3. 評価: LLM-as-a-Judgeにより、失敗パターンの原因（指示の曖昧さ、情報の見落とし）を特定。

  4. 改善: 失敗例を負の例（Negative Constraints）としてプロンプトへ再注入する。

【プロンプトの実装案】

PromptWizardの「指示の動的最適化」と、Agent Lightningの「効率的な推論パス」を組み合わせたハイブリッド・プロンプトです。

# Role

あなたは高度な金融データアナリストであり、複雑なドキュメントから正確な情報を抽出する専門家です。

# Task

提供された[Input Text]から、以下の[JSON Schema]に従ってデータを抽出してください。

# Constraints


- 全ての数値は半角数字で抽出すること。

- 不明な項目は null とし、推測で埋めないこと。

- Step-by-Stepで思考し、最終的なJSONのみを出力してください。

# Reasoning Process (Chain-of-Thought)


1. 文脈から「投資主体」と「被投資主体」の関係を特定する。

2. 関連する金額と日付を、文中の表現から直接引用する。

3. リスク要因は、具体的な名詞句として抽出する。

# Input Text

(ここに分析対象のテキストを挿入)

# JSON Schema

{
  "investor": "string",
  "target": "string",
  "amount": "number",
  "currency": "string",
  "date": "YYYY-MM-DD",
  "risks": ["string"]
}

【評価指標と誤り分析】

抽出精度の向上を妨げる要因を分析し、以下の基準で自動評価を行います。

評価項目 評価内容 失敗パターン
スキーマ整合性 JSONがパース可能か、型は正しいか カンマ欠落、文字列型の数値
抽出正確性 文中の事実と合致しているか 投資額の単位ミス（百万と十億の取り違え）
紐付け精度 エンティティ間の関係性が正しいか A社がB社に投資したのを、逆転して抽出
幻覚率 本文にない情報を捏造していないか 不足情報を一般論で補完する

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

PromptWizardの最適化プロセスを経て、Agent Lightning的な「成功パターンの圧縮」を反映させた最終プロンプトです。

# 指示

以下のテキストから金融データを抽出し、JSON形式で出力せよ。
出力はJSONブロックのみとし、前後の説明は一切不要。

# 思考ルール（Agentic Trace）


- [STEP 1: 固有表現抽出] テキスト内の組織名と数値を全てリストアップせよ。

- [STEP 2: 関係性定義] どの組織が主体で、どの組織が対象かを確認せよ。

- [STEP 3: 形式変換] 抽出した要素を、以下のスキーマにマッピングせよ。

# 厳守事項（Negative Constraints）


- "不明" を "0" と定義してはならない。必ず null を使用すること。

- 通貨単位（JPY, USD等）を ISO 4217 形式に統一せよ。

- 思考プロセスを表示せず、内部的に実行せよ（隠れ思考）。

# Input

{{TEXT}}

# Output Schema

```json
{
  "deal_structure": {
    "investor": "string",
    "target": "string",
    "value": {"amount": number, "currency": "string"},
    "execution_date": "string"
  },
  "risk_assessment": ["string"]
}

“`

【まとめ】

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

  1. 定量的評価の自動化: 人手によるチェックではなく、抽出結果をJSON SchemaバリデーターやLLM-as-a-Judgeにかけ、エラー率をログ化すること。

  2. 思考プロセスの制御: 複雑なタスクでは「思考ステップ（CoT）」を明示的に指定しつつ、最終出力からは分離することで、後続システムでの扱いやすさを確保する。

  3. 負のフィードバックループ: 過去にLLMが間違えたパターン（例：特定用語の誤認）を、「禁止事項」としてプロンプトに動的に追加し続けること。

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

コメント

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