<p><meta/>{“status”: “concept”, “focus”: “PromptWizard_vs_AgentLightning”, “model”: “Gemini 1.5 Pro”}
本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト(未検証)</strong>です。</p>
<h1 class="wp-block-heading">自動最適化の極致:PromptWizardとAgent Lightningによる高精度エージェント構築</h1>
<h3 class="wp-block-heading">【ユースケース定義と課題】</h3>
<p>複雑な非構造化ビジネス文書から、特定のエンティティと論理関係を抽出し、厳密なJSON形式で出力する。抽出漏れと推論エラーの解消が困難。</p>
<ul class="wp-block-list">
<li><p><strong>入力の型</strong>: テキスト(PDF抽出済み文字列、議事録、契約書等)</p></li>
<li><p><strong>出力の型</strong>: JSON(定義されたSchemaに準拠)</p></li>
</ul>
<h3 class="wp-block-heading">【プロンプト設計のループ】</h3>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
graph TD
A["設計: 命令とFew-shotの構成"] --> B["実行: 大規模モデルによる推論"]
B --> C["評価: スキーマ検証と事実確認"]
C -->|改善: 誤差逆伝播的な指示修正| A
</pre></div>
<ol class="wp-block-list">
<li><p><strong>設計</strong>: <code>PromptWizard</code>的手法を用い、指示文の「変異(Mutation)」と「交差」を試行。</p></li>
<li><p><strong>実行</strong>: <code>Agent Lightning</code>的な高速推論ループでトークン効率と精度を両立。</p></li>
<li><p><strong>評価</strong>: LLM-as-a-Judgeにより、期待されるJSON構造との乖離を数値化。</p></li>
</ol>
<h3 class="wp-block-heading">【プロンプトの実装案】</h3>
<p>PromptWizardの「反復改善」の結果、最も抽出精度が高かった「思考プロセス明示型(CoT)」の構成例です。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># Role
あなたは高度なビジネス文書アナリストです。与えられた文書から重要な「合意事項」と「期限」を抽出してください。
# Constraints
- 出力は必ず以下のJSON形式に準拠すること。
- 不明な情報は null とし、推測で埋めないこと。
- 思考プロセス(Thought)をJSONの外に出さないこと。
# Output Format
{
"analysis": "思考プロセスをここに記述",
"entities": [
{"name": "組織名", "role": "役割"},
],
"agreements": [
{"item": "合意内容", "deadline": "YYYY-MM-DD"}
]
}
# Input
{{document_text}}
# Execution Process
Step 1: 文書全体をスキャンし、日付と組織名にマーキングする。
Step 2: 各組織間の権利義務関係を特定する。
Step 3: 指定されたJSON形式に変換し、構文エラーがないかセルフチェックする。
</pre>
</div>
<h3 class="wp-block-heading">【評価指標と誤り分析】</h3>
<p>抽出タスクにおいて発生しやすい「失敗パターン」を分析し、評価基準を設定します。</p>
<figure class="wp-block-table"><table>
<thead>
<tr>
<th style="text-align:left;">評価項目</th>
<th style="text-align:left;">失敗パターン(分析)</th>
<th style="text-align:left;">採点基準 (1-5)</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left;"><strong>スキーマ整合性</strong></td>
<td style="text-align:left;">カンマ欠落、エスケープ漏れによるJSON破損。</td>
<td style="text-align:left;">5: 完全、1: パース不可</td>
</tr>
<tr>
<td style="text-align:left;"><strong>事実忠実性</strong></td>
<td style="text-align:left;">日付の取り違え、存在しない条項の捏造(幻覚)。</td>
<td style="text-align:left;">5: 誤りなし、1: 重大な捏造</td>
</tr>
<tr>
<td style="text-align:left;"><strong>網羅性</strong></td>
<td style="text-align:left;">複数の合意事項がある場合に、最初の1つしか抽出しない。</td>
<td style="text-align:left;">5: 全抽出、1: 漏れ多数</td>
</tr>
</tbody>
</table></figure>
<h3 class="wp-block-heading">【改良後の最適プロンプト】</h3>
<p>Agent Lightningの思想(低遅延・高精度)を取り入れ、指示を構造化した「最強プロンプト」です。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"><system_instruction>
## Task
Extract specific data points from business text into valid JSON.
## Extraction Rules
- IGNORE: Informal greetings, boilerplate legal disclaimers.
- CAPTURE: Dates, Party Names, Monetary values, Obligations.
- FORMAT: Strict JSON. No preamble, no markdown code blocks unless requested.
## Reasoning Protocol (Internal)
Before generating JSON, internally verify:
1. Are all date formats ISO-8601?
2. Did I capture multiple entities if present?
3. Is every key in the schema addressed?
</system_instruction>
<few_shot_examples>
Input: "2023年10月5日、A社はB社に100万円支払うことで合意した。"
Output: {"date": "2023-10-05", "payer": "A社", "receiver": "B社", "amount": 1000000}
</few_shot_examples>
<input_data>
{{target_text}}
</input_data>
</pre>
</div>
<h3 class="wp-block-heading">【まとめ】</h3>
<p>実務でプロンプトを運用するための3つの鉄則:</p>
<ol class="wp-block-list">
<li><p><strong>「命令」と「データ」の分離</strong>: <code><system_instruction></code> や <code><input_data></code> 等のタグを使用し、LLMが指示の範囲を誤認しないようにする。</p></li>
<li><p><strong>ネガティブ・プロンプトの活用</strong>: 「~しないでください(IGNORE)」を具体的に記述することで、不要なトークン消費とノイズを削減する。</p></li>
<li><p><strong>自動評価ループの構築</strong>: PromptWizardのように、一度作って終わりにせず、評価スコアが下がった際に「どの指示が弱かったか」をLLMに自己分析させ、プロンプトを動的に更新し続ける。</p></li>
</ol>
{“status”: “concept”, “focus”: “PromptWizard_vs_AgentLightning”, “model”: “Gemini 1.5 Pro”}
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証) です。
自動最適化の極致:PromptWizardとAgent Lightningによる高精度エージェント構築
【ユースケース定義と課題】
複雑な非構造化ビジネス文書から、特定のエンティティと論理関係を抽出し、厳密なJSON形式で出力する。抽出漏れと推論エラーの解消が困難。
【プロンプト設計のループ】
graph TD
A["設計: 命令とFew-shotの構成"] --> B["実行: 大規模モデルによる推論"]
B --> C["評価: スキーマ検証と事実確認"]
C -->|改善: 誤差逆伝播的な指示修正| A
設計 : PromptWizard的手法を用い、指示文の「変異(Mutation)」と「交差」を試行。
実行 : Agent Lightning的な高速推論ループでトークン効率と精度を両立。
評価 : LLM-as-a-Judgeにより、期待されるJSON構造との乖離を数値化。
【プロンプトの実装案】
PromptWizardの「反復改善」の結果、最も抽出精度が高かった「思考プロセス明示型(CoT)」の構成例です。
# Role
あなたは高度なビジネス文書アナリストです。与えられた文書から重要な「合意事項」と「期限」を抽出してください。
# Constraints
- 出力は必ず以下のJSON形式に準拠すること。
- 不明な情報は null とし、推測で埋めないこと。
- 思考プロセス(Thought)をJSONの外に出さないこと。
# Output Format
{
"analysis": "思考プロセスをここに記述",
"entities": [
{"name": "組織名", "role": "役割"},
],
"agreements": [
{"item": "合意内容", "deadline": "YYYY-MM-DD"}
]
}
# Input
{{document_text}}
# Execution Process
Step 1: 文書全体をスキャンし、日付と組織名にマーキングする。
Step 2: 各組織間の権利義務関係を特定する。
Step 3: 指定されたJSON形式に変換し、構文エラーがないかセルフチェックする。
【評価指標と誤り分析】
抽出タスクにおいて発生しやすい「失敗パターン」を分析し、評価基準を設定します。
評価項目
失敗パターン(分析)
採点基準 (1-5)
スキーマ整合性
カンマ欠落、エスケープ漏れによるJSON破損。
5: 完全、1: パース不可
事実忠実性
日付の取り違え、存在しない条項の捏造(幻覚)。
5: 誤りなし、1: 重大な捏造
網羅性
複数の合意事項がある場合に、最初の1つしか抽出しない。
5: 全抽出、1: 漏れ多数
【改良後の最適プロンプト】
Agent Lightningの思想(低遅延・高精度)を取り入れ、指示を構造化した「最強プロンプト」です。
<system_instruction>
## Task
Extract specific data points from business text into valid JSON.
## Extraction Rules
- IGNORE: Informal greetings, boilerplate legal disclaimers.
- CAPTURE: Dates, Party Names, Monetary values, Obligations.
- FORMAT: Strict JSON. No preamble, no markdown code blocks unless requested.
## Reasoning Protocol (Internal)
Before generating JSON, internally verify:
1. Are all date formats ISO-8601?
2. Did I capture multiple entities if present?
3. Is every key in the schema addressed?
</system_instruction>
<few_shot_examples>
Input: "2023年10月5日、A社はB社に100万円支払うことで合意した。"
Output: {"date": "2023-10-05", "payer": "A社", "receiver": "B社", "amount": 1000000}
</few_shot_examples>
<input_data>
{{target_text}}
</input_data>
【まとめ】
実務でプロンプトを運用するための3つの鉄則:
「命令」と「データ」の分離 : <system_instruction> や <input_data> 等のタグを使用し、LLMが指示の範囲を誤認しないようにする。
ネガティブ・プロンプトの活用 : 「~しないでください(IGNORE)」を具体的に記述することで、不要なトークン消費とノイズを削減する。
自動評価ループの構築 : PromptWizardのように、一度作って終わりにせず、評価スコアが下がった際に「どの指示が弱かったか」をLLMに自己分析させ、プロンプトを動的に更新し続ける。
ライセンス :本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL(本ページ)を明記してください。
利用ポリシー もご参照ください。
コメント