PromptWizard: Optimizing Prompts via Task-Aware, Feedback-Driven Self-Evolution

生成日: 2026-05-24 02:20

# PromptWizard: Optimizing Prompts via Task-Aware, Feedback-Driven Self-Evolution

- PromptWizard は、black-box LLM 向けに、プロンプト指示と in-context examples を自動で作り直す離散プロンプト最適化の枠組みである。
- 失敗例を手がかりに、候補生成、採点、批評、合成、例示の作成、Chain-of-Thought の検証を順に行い、人が読めるプロンプトを得る。
- BBII、BBH、算術推論を含む 45 タスクで既存手法を上回り、API 呼び出し数とトークン使用量も小さく抑えたと報告している。

## Abstract（日本語訳）

大規模言語モデル（Large Language Models; LLMs）は多様な領域で AI を変えてきたが、その出力を望ましい方向へ導くうえでプロンプトは中心的な役割を担っている。しかし、手作業によるプロンプトエンジニアリングは労力を要し、領域に依存するため、自動化された解決策が必要となる。本論文では、自己進化・自己適応の仕組みを用いる、離散プロンプト最適化の完全自動フレームワーク PromptWizard を提案する。PromptWizard は、フィードバックに基づく批評と合成の過程を通じて探索と活用の有効な均衡をとり、プロンプト指示と in-context examples の双方を反復的に洗練することで、人間が読めるタスク固有のプロンプトを生成する。この誘導された方法はプロンプトの品質を体系的に改善し、45 タスクにわたって優れた性能をもたらす。PromptWizard は、限られた学習データ、小さめの LLM、さまざまな LLM アーキテクチャにおいても良好に機能する。さらに、コスト分析では API 呼び出し、トークン使用量、総コストが大きく削減されることが示され、既存のプロンプト最適化戦略に対する PromptWizard の効率性、スケーラビリティ、利点が示されている。

## 論文の面白いところ

この論文の主眼は、プロンプトを「よく書く」問題を、人手の技能ではなく、評価可能な探索問題として扱う点にある。従来の自動プロンプト最適化には、soft prompt のように中身が読みにくいものや、進化的探索のように試行回数が多くなりやすいものがあった。PromptWizard は、自然言語のプロンプトを保ったまま、失敗例に基づいてどこを直すべきかを LLM 自身に批評させる。これにより、単に候補を大量に並べるのではなく、誤答の原因に近い箇所へ探索を寄せる設計になっている。

また、プロンプト本文だけでなく、few-shot の例示も同じ最適化の対象に入れている。実務で LLM を使う場合、指示文だけを整えても、例示が悪ければ出力は安定しない。この論文はその点を正面から扱い、失敗した訓練例や合成例を使って、タスクに合う例示を作る。さらに、その例示に Chain-of-Thought を付け、LLM による検証で破綻した推論を取り除く。手法全体は複雑だが、出力されるものは最終的に人が読める通常のプロンプトであり、既存の API 利用にも載せやすい。

## 問題設定

LLM の性能は、モデル本体だけでなく、与えるプロンプトに大きく左右される。算術推論、分類、変換、質問応答のようなタスクでは、同じモデルでも指示の言い方や例示の選び方によって正答率が変わる。ところが、手作業でプロンプトを作るには経験が必要で、タスクやモデルが変わるたびに再調整が要る。特に API だけで使う black-box LLM では、内部勾配や確率分布に直接触れられないため、勾配に基づく最適化を使いにくい。

既存の離散プロンプト最適化は、複数の候補を作って性能を比較するが、探索がランダムになりやすく、API 呼び出しも増える。フィードバックを使う手法もあるが、収束までに多くの時間と計算費用がかかることがある。論文が扱う課題は、少量の訓練例だけを使い、black-box LLM に対して、人が読める自然言語プロンプトを効率よく最適化することである。評価では、BIG-Bench Instruction Induction（BBII）、BIG-Bench Hard（BBH）、GSM8K などの算術推論データセットを用いる。著者らは、45 タスクにまたがる一般的な言語理解と推論の場面で、この方法がどの程度再利用できるかを調べている。

## 提案手法

PromptWizard は、初期の問題記述と少数の訓練サンプルを入力として受け取り、最適化されたプロンプト指示と few-shot examples を出力する。最初に、LLM は複数の「thinking styles」に従って指示文の変種を作る。たとえば「問題を単純化するにはどう考えるか」「別の観点は何か」といった発想を使い、似た言い換えだけに偏らない候補を作る。次に、それぞれの候補を小さな訓練ミニバッチで採点し、性能のよい候補を残す。

残った候補について、PromptWizard は誤答例を見て、どの関係を見落としたか、どの推論が曖昧だったかを批評する。その批評をもとに、指示文を再合成し、よりタスク固有の表現へ直す。続いて、訓練例の中から、現在のプロンプトが失敗する例を中心に few-shot examples を選び、必要に応じて合成例も作る。これらの例示にも同じく批評と合成を行い、指示文と例示を順番に改善する。最後に、few-shot examples に Chain-of-Thought を生成し、別の検証過程で説明の一貫性や関連性を確認する。タスク意図と expert persona も問題記述から作られ、最終プロンプトに組み込まれる。

## 結果

BBII の 19 タスクでは、GPT-3.5 Turbo を用いた zero-shot 設定で、PromptWizard が 13 タスクで最高精度を示した。比較対象の Instinct は 8 タスクで最高であり、PromptWizard はより多くのタスクで上位に入っている。one-shot 設定では、PromptWizard が 16 タスクで最高精度となり、例示の最適化が効いていることが示された。GPT-4 を base model とした追加実験でも、PromptWizard は 19 タスク中 15 タスクで Instinct を上回った。

算術推論では、GSM8K、AQUARAT、SVAMP の各データセットで、PromptWizard は比較した手法を上回った。GSM8K では GPT-3.5 Turbo の zero-shot 設定で 90.0% を示し、DSPy の 78.2%、PromptAgent の 68.8% を上回っている。BBH の 23 タスク平均では 88.1% で、APE の 71.85%、EvoPrompt の 75.03% を上回った。コスト面では、BBII 相当の比較で PromptWizard は平均 69 回の API 呼び出しで最適化を行い、Instinct / InstructZero の 1730 回、PromptBreeder の 18600 回、EvoPrompt の 5000 回より少ない。算術タスクでも、PromptWizard の最適化コストは 1 タスクあたり 0.049 ドルとされ、APO や PromptAgent より低い。アブレーションでは、指示文だけでなく例示、合成例、Chain-of-Thought を合わせた場合に GSM8K の性能が最も高く、各段階が寄与していることが示された。

## 具体例

たとえば、企業内で「問い合わせ文を読んで、請求、技術障害、契約変更のどれに当たるかを分類する」タスクを LLM に任せる場面を考える。入力は「先月の請求額が契約書と違うようです。明細を確認してください」のような短い文で、期待される出力は「請求」である。手作業のプロンプトでは、「問い合わせを分類してください」とだけ書かれ、モデルが「契約書」という語に引かれて契約変更と誤ることがある。PromptWizard は、少数の訓練例に対して複数の指示文を試し、このような誤答を negative examples として扱う。

その後、批評過程では「金額、明細、請求額などの語がある場合は請求カテゴリを優先する必要がある」といった弱点が抽出される。合成過程では、その観点を指示文に組み込み、さらに紛らわしい例を few-shot examples として追加する。合成例には、「契約書に記載された料金と実際の請求が違う」という入力と「請求」という出力が含まれ、必要なら理由の説明も付く。最終的なプロンプトは、単なる分類指示ではなく、カテゴリ境界と紛らわしい語の扱いを含むものになる。間違えやすい点は、表面上の単語だけで分類してしまうことであり、PromptWizard は失敗例を通じてその境界をプロンプトに明示させる。

PromptWizard: Optimizing Prompts via Task-Aware, Feedback-Driven Self-Evolution

PromptWizard は、black-box LLM 向けに、プロンプト指示と in-context examples を自動で作り直す離散プロンプト最適化の枠組みである。
失敗例を手がかりに、候補生成、採点、批評、合成、例示の作成、Chain-of-Thought の検証を順に行い、人が読めるプロンプトを得る。
BBII、BBH、算術推論を含む 45 タスクで既存手法を上回り、API 呼び出し数とトークン使用量も小さく抑えたと報告している。

Abstract（日本語訳）

大規模言語モデル（Large Language Models; LLMs）は多様な領域で AI を変えてきたが、その出力を望ましい方向へ導くうえでプロンプトは中心的な役割を担っている。しかし、手作業によるプロンプトエンジニアリングは労力を要し、領域に依存するため、自動化された解決策が必要となる。本論文では、自己進化・自己適応の仕組みを用いる、離散プロンプト最適化の完全自動フレームワーク PromptWizard を提案する。PromptWizard は、フィードバックに基づく批評と合成の過程を通じて探索と活用の有効な均衡をとり、プロンプト指示と in-context examples の双方を反復的に洗練することで、人間が読めるタスク固有のプロンプトを生成する。この誘導された方法はプロンプトの品質を体系的に改善し、45 タスクにわたって優れた性能をもたらす。PromptWizard は、限られた学習データ、小さめの LLM、さまざまな LLM アーキテクチャにおいても良好に機能する。さらに、コスト分析では API 呼び出し、トークン使用量、総コストが大きく削減されることが示され、既存のプロンプト最適化戦略に対する PromptWizard の効率性、スケーラビリティ、利点が示されている。

論文の面白いところ

この論文の主眼は、プロンプトを「よく書く」問題を、人手の技能ではなく、評価可能な探索問題として扱う点にある。従来の自動プロンプト最適化には、soft prompt のように中身が読みにくいものや、進化的探索のように試行回数が多くなりやすいものがあった。PromptWizard は、自然言語のプロンプトを保ったまま、失敗例に基づいてどこを直すべきかを LLM 自身に批評させる。これにより、単に候補を大量に並べるのではなく、誤答の原因に近い箇所へ探索を寄せる設計になっている。

また、プロンプト本文だけでなく、few-shot の例示も同じ最適化の対象に入れている。実務で LLM を使う場合、指示文だけを整えても、例示が悪ければ出力は安定しない。この論文はその点を正面から扱い、失敗した訓練例や合成例を使って、タスクに合う例示を作る。さらに、その例示に Chain-of-Thought を付け、LLM による検証で破綻した推論を取り除く。手法全体は複雑だが、出力されるものは最終的に人が読める通常のプロンプトであり、既存の API 利用にも載せやすい。

問題設定

LLM の性能は、モデル本体だけでなく、与えるプロンプトに大きく左右される。算術推論、分類、変換、質問応答のようなタスクでは、同じモデルでも指示の言い方や例示の選び方によって正答率が変わる。ところが、手作業でプロンプトを作るには経験が必要で、タスクやモデルが変わるたびに再調整が要る。特に API だけで使う black-box LLM では、内部勾配や確率分布に直接触れられないため、勾配に基づく最適化を使いにくい。

既存の離散プロンプト最適化は、複数の候補を作って性能を比較するが、探索がランダムになりやすく、API 呼び出しも増える。フィードバックを使う手法もあるが、収束までに多くの時間と計算費用がかかることがある。論文が扱う課題は、少量の訓練例だけを使い、black-box LLM に対して、人が読める自然言語プロンプトを効率よく最適化することである。評価では、BIG-Bench Instruction Induction（BBII）、BIG-Bench Hard（BBH）、GSM8K などの算術推論データセットを用いる。著者らは、45 タスクにまたがる一般的な言語理解と推論の場面で、この方法がどの程度再利用できるかを調べている。

提案手法

PromptWizard は、初期の問題記述と少数の訓練サンプルを入力として受け取り、最適化されたプロンプト指示と few-shot examples を出力する。最初に、LLM は複数の「thinking styles」に従って指示文の変種を作る。たとえば「問題を単純化するにはどう考えるか」「別の観点は何か」といった発想を使い、似た言い換えだけに偏らない候補を作る。次に、それぞれの候補を小さな訓練ミニバッチで採点し、性能のよい候補を残す。

残った候補について、PromptWizard は誤答例を見て、どの関係を見落としたか、どの推論が曖昧だったかを批評する。その批評をもとに、指示文を再合成し、よりタスク固有の表現へ直す。続いて、訓練例の中から、現在のプロンプトが失敗する例を中心に few-shot examples を選び、必要に応じて合成例も作る。これらの例示にも同じく批評と合成を行い、指示文と例示を順番に改善する。最後に、few-shot examples に Chain-of-Thought を生成し、別の検証過程で説明の一貫性や関連性を確認する。タスク意図と expert persona も問題記述から作られ、最終プロンプトに組み込まれる。

結果

BBII の 19 タスクでは、GPT-3.5 Turbo を用いた zero-shot 設定で、PromptWizard が 13 タスクで最高精度を示した。比較対象の Instinct は 8 タスクで最高であり、PromptWizard はより多くのタスクで上位に入っている。one-shot 設定では、PromptWizard が 16 タスクで最高精度となり、例示の最適化が効いていることが示された。GPT-4 を base model とした追加実験でも、PromptWizard は 19 タスク中 15 タスクで Instinct を上回った。

算術推論では、GSM8K、AQUARAT、SVAMP の各データセットで、PromptWizard は比較した手法を上回った。GSM8K では GPT-3.5 Turbo の zero-shot 設定で 90.0% を示し、DSPy の 78.2%、PromptAgent の 68.8% を上回っている。BBH の 23 タスク平均では 88.1% で、APE の 71.85%、EvoPrompt の 75.03% を上回った。コスト面では、BBII 相当の比較で PromptWizard は平均 69 回の API 呼び出しで最適化を行い、Instinct / InstructZero の 1730 回、PromptBreeder の 18600 回、EvoPrompt の 5000 回より少ない。算術タスクでも、PromptWizard の最適化コストは 1 タスクあたり 0.049 ドルとされ、APO や PromptAgent より低い。アブレーションでは、指示文だけでなく例示、合成例、Chain-of-Thought を合わせた場合に GSM8K の性能が最も高く、各段階が寄与していることが示された。

具体例

たとえば、企業内で「問い合わせ文を読んで、請求、技術障害、契約変更のどれに当たるかを分類する」タスクを LLM に任せる場面を考える。入力は「先月の請求額が契約書と違うようです。明細を確認してください」のような短い文で、期待される出力は「請求」である。手作業のプロンプトでは、「問い合わせを分類してください」とだけ書かれ、モデルが「契約書」という語に引かれて契約変更と誤ることがある。PromptWizard は、少数の訓練例に対して複数の指示文を試し、このような誤答を negative examples として扱う。

その後、批評過程では「金額、明細、請求額などの語がある場合は請求カテゴリを優先する必要がある」といった弱点が抽出される。合成過程では、その観点を指示文に組み込み、さらに紛らわしい例を few-shot examples として追加する。合成例には、「契約書に記載された料金と実際の請求が違う」という入力と「請求」という出力が含まれ、必要なら理由の説明も付く。最終的なプロンプトは、単なる分類指示ではなく、カテゴリ境界と紛らわしい語の扱いを含むものになる。間違えやすい点は、表面上の単語だけで分類してしまうことであり、PromptWizard は失敗例を通じてその境界をプロンプトに明示させる。