「一歩ずつ考えよう」というマントラよりも効果的で、プロジェクトが改善されていることを示す

大規模言語モデル (LLM) は、適切なプロンプトがあれば、多くの自然言語処理タスクにとって強力なツールとなります。ただし、モデルの感度が高いため、最適なヒントを見つけるには、多くの場合、手作業による試行錯誤が必要になります。さらに、最初のプロンプトが本番環境に導入されると、予期しないエッジケースが発生する可能性があり、プロンプトをさらに改良するために手動の調整をさらに繰り返す必要があります。

これらの課題により、自動提案エンジニアリングという新たな研究分野が生まれました。この分野では、LLM 自体の機能を活用するというアプローチが目立っています。具体的には、「現在のプロンプトと一連の例を確認し、新しいプロンプトを提案する」などの指示で LLM にメタプロンプトを出すことが含まれます。

これらの方法は優れたパフォーマンスを達成しましたが、次の疑問は、自動ヒントエンジニアリングに適したメタキューの種類は何かということです。

この疑問に答えるために、南カリフォルニア大学とマイクロソフトの研究者は、2 つの重要な観察結果を結び付けています。(1) プロンプト エンジニアリングは、それ自体が深い推論を必要とする複雑な言語タスクです。これには、モデルのエラーを綿密に調査し、現在のプロンプトに何が欠けているか、または誤解を招くかを仮説し、タスクをより明確に LLM に渡す方法が含まれます。 （２）LLMでは、モデルに「段階的に考える」ように促すことで複雑な推論能力を引き出すことができ、出力を振り返るように導くことでこの能力をさらに強化することができます。

論文アドレス: https://arxiv.org/pdf/2311.05661.pdf

研究者らは、これまでの 2 つの観察結果を結び付けて、LLM がより効果的にキュー エンジニアリングを実行できるように導くメタ キューを構築することを目標に、キュー エンジニアリングを実行しました (下の図 2 を参照)。既存の方法の限界を反映し、複雑な推論プロンプトの最近の進歩を取り入れることで、ステップバイステップの推論テンプレートやコンテキスト仕様などのメタプロンプトコンポーネントを導入し、プロンプトエンジニアリングプロセス中に LLM 推論を明示的にガイドしました。

さらに、プロンプトエンジニアリングは最適化問題として捉えることができるため、バッチサイズ、ステップサイズ、モメンタムなどの一般的な最適化概念からインスピレーションを得て、それらの言語表現をメタキューに導入することで、メタキューを導入します。私たちは、MultiArith と GSM8K という 2 つの数学的推論データセットでこれらのコンポーネントとバリアントを実験し、PE2 という最もパフォーマンスの高い組み合わせを特定しました。

PE2 は強力な経験的パフォーマンスを実現します。 TEXT-DAVINCI-003 をタスク モデルとして使用すると、PE2 によって生成されたプロンプトは、ゼロ ショット思考連鎖のステップ バイ ステップ プロンプトよりも、MultiArith で 6.3%、GSM8K で 3.1% 優れています。さらに、PE2 は、2 つの自動提案エンジニアリング ベースラインである Iterative APE と APO よりも優れています (図 1)。

特に、PE2 は反事実タスクで最も効果的に機能します。さらに、この研究は、長い現実世界のプロンプトを最適化するための PE2 の幅広い適用可能性を実証しています。

研究者は、PE2 のプロンプト編集履歴を確認したところ、PE2 が常に意味のあるプロンプト編集を提供していることを発見しました。間違ったヒントや不完全なヒントを修正し、詳細を追加することでヒントを充実させ、最終的なパフォーマンスの向上に貢献します (表 4 を参照)。

興味深いことに、PE2 は 8 進数の加算を知らなかったため、例から独自の算術ルールを作成しました。「両方の数が 50 未満の場合、合計に 2 を加算します。どちらかの数が 50 以上の場合、合計に 22 を加算します。」これは不完全で使いやすいソリューションですが、反事実的な状況で推論する PE2 の優れた能力を示しています。

これらの成果にもかかわらず、研究者は PE2 の限界と失敗例も認識しています。 PE2 は、与えられた命令の妥当性を無視したり、エラーを生成したりするなど、LLM 固有の制限によっても影響を受け、制限されます (下の表 5 を参照)。

背景

ヒントエンジニアリング

プロンプトエンジニアリングの目標は、与えられたLLM M_taskをタスクモデルとして使用したときに、与えられたデータセットDで最高のパフォーマンスを達成するテキストプロンプトp∗を見つけることです（次の式に示すように）。より具体的には、すべてのデータセットはテキストの入力と出力のペア、つまり D = {(x, y)} としてフォーマットできると想定します。ヒントを最適化するためのトレーニング セット D_train、検証用の D_dev、最終評価用の D_test。研究者によって提案された記号表現によれば、工学上の問題は次のように記述できます。

ここで、M_task(x; p) はプロンプト p が与えられた場合にモデルによって生成される出力であり、f は各例の評価関数です。たとえば、評価基準が完全一致の場合、

自動プロンプトエンジニアリングにLLMを使用する

初期のプロンプト セットが与えられると、自動提案エンジニアは継続的に新しい、より優れたプロンプトを提案します。タイムスタンプ t で、チップ エンジニアはチップ p^(t) を取得し、新しいチップ p^(t+1) を書き込むことが期待されます。新しいプロンプトの生成中に、例のバッチ B = {(x, y, y′)} を調べることを選択できます。ここで、y ′ = M_task (x; p) はモデルによって生成された出力を表し、y は真のラベルを表します。 p^meta を使用してメタヒントを表します。これは、LLM の M_proposal が新しいヒントを提案するようにガイドするために使用されます。したがって、

提案されたヒントp^(t+1)の品質を向上させるために、より優れたメタヒントp^metaを構築することが、この研究の主な焦点です。

より優れたメタプロンプトの構築

ヒントが最終的なタスクのパフォーマンスに重要な役割を果たすのと同様に、式 2 に導入されたメタヒント p^meta は、新しく提案されたヒントの品質と自動ヒントエンジニアリングの全体的な品質に重要な役割を果たします。

研究者らは主にメタプロンプトp^metaのプロンプトエンジニアリングに焦点を当て、LLMプロンプトエンジニアリングの品質向上に役立つ可能性のあるメタプロンプトコンポーネントを開発し、これらのコンポーネントに関する体系的なアブレーション研究を実施しました。

私たちは、(1)詳細なガイダンスと背景情報を提供すること、(2)共通のオプティマイザーの概念を組み込むこと、という2つの目的に基づいてこれらのコンポーネントの基盤を設計しました。次に、研究者らはこれらの要素をより詳細に説明し、関連する原則を説明します。下の図 2 は視覚的に表したものです。

詳細な手順とコンテキストを提供します。これまでの研究では、メタキューは、提案されたモデルにキューの言い換えを生成するように指示するか、一連の例を調べるための最小限の指示を含んでいました。したがって、メタヒントに追加の指示とコンテキストを追加すると有益な場合があります。

(a) プロンプトエンジニアリングチュートリアル。 LLM がヒント エンジニアリングのタスクをよりよく理解できるように、MetaHint でヒント エンジニアリングのオンライン チュートリアルを提供します。

(b) 2段階タスクの説明。キュー エンジニアリング タスクは、Pryzant らが行ったように、2 つのステップに分解できます。最初のステップでは、モデルは現在のキューと一連の例を調べる必要があります。 2 番目のステップでは、モデルは改善されたプロンプトを構築する必要があります。しかし、Pryzant らの方法では、各ステップがリアルタイムで解釈されます。対照的に、研究者たちはメタキューでこれら 2 つのステップを明確にし、事前に期待を伝えることを検討しました。

(c) ステップバイステップの推論テンプレート。モデルがバッチ B の各例を注意深く調べ、現在のプロンプトの制限を反映するように促すために、プロンプト提案モデル M_proposal に一連の質問に答えるようにガイドします。たとえば、出力は正しいですか?プロンプトはタスクを正しく説明していますか?プロンプトを編集する必要がありますか?

（d）文脈的規範実際には、入力シーケンス全体にわたってヒントが挿入される位置は柔軟です。 「英語をフランス語に翻訳する」など、テキストを入力する前にタスクを説明できます。また、「段階的に考えてください」などの入力テキストの後にも表示され、推論能力を刺激することもできます。これらの異なるコンテキストを認識するために、研究者は手がかりと入力の間の相互作用を明示的に指定しました。たとえば、「Q: <入力> A: 段階的に考えてください。」

一般的なオプティマイザーの概念を組み込みます。上記の式 1 で説明したヒント エンジニアリングの問題は本質的に最適化の問題であり、式 2 のヒント提案は最適化ステップを実行するものと見なすことができます。したがって、勾配ベースの最適化で一般的に使用される次の概念を考慮し、それらのメタキューで使用される対応する用語を開発します。

(e) バッチサイズ。バッチサイズは、各ヒント提案ステップで使用される（失敗した）例の数です（式 2）。著者らは分析でバッチサイズ {1、2、4、8} を試しました。

(f) ステップサイズ。勾配ベースの最適化では、ステップ サイズによってモデルの重みの更新の大きさが決まります。ヒント エンジニアリングでは、これに対応するものは変更できる単語 (トークン) の数になります。著者は、「元のプロンプトでは最大 s 個の単語を変更できます」と直接指定しています。ここで、s ∈ {5、10、15、None} です。

(g) 履歴と勢いを最適化する。 Momentum (Qian、1999) は、過去の勾配の移動平均を維持することで最適化を高速化し、振動を回避する手法です。勢いの言語版を開発するために、この論文には過去のすべてのプロンプト（タイムスタンプ 0、1、...、t − 1）、開発セットでのパフォーマンス、およびプロンプト編集の概要が含まれています。

実験

著者らは、PE2 の有効性と限界を評価するために、次の 4 つのタスク セットを使用します。

1. 数学的推論、2. 指導的誘導、3. 反事実的評価、4. 生産プロンプト。

更新された LLM によるベンチマークの改善。表 2 の最初の 2 つの部分では、TEXT-DAVINCI-003 を使用するとパフォーマンスが大幅に向上し、ゼロショット CoT で数学的推論問題を解決する能力が向上することがわかります。さらに、2つの手がかりの間のギャップは狭まり（MultiArith：3.3％→1.0％、GSM8K：2.3％→0.6％）、TEXT-DAVINCI-003は手がかりの解釈に対してそれほど敏感ではないことが示されました。これを考慮すると、反復 APE などの単純な解釈に依存する方法では、最終結果を効果的に改善できない可能性があります。パフォーマンスを向上させるには、より正確で的を絞ったキュー編集が必要です。

PE2 は、さまざまなタスクにおいて Iterative APE および APO よりも優れたパフォーマンスを発揮します。 PE2 は、MultiArith で 92.3% の精度 (Zero-shot CoT より 6.3% 高い)、GSM8K で 64.0% (+3.1%) のヒントを見つけることができます。さらに、PE2 によって検出されたプロンプトは、命令誘導ベンチマーク、反事実評価、および生成プロンプトにおいて、反復 APE および APO よりも優れています。

上の図 1 では、著者らは、命令誘導ベンチマーク、反事実評価、および生成プロンプトで PE2 によって達成されたパフォーマンスの向上をまとめており、PE2 がさまざまな言語タスクで優れたパフォーマンスを達成することを示しています。特に、帰納的初期化を使用する場合、PE2 は 12 の反事実タスクのうち 11 で APO よりも優れたパフォーマンスを発揮し (図 6)、PE2 が矛盾した反事実的な状況について推論できることが実証されています。

PE2 は、ターゲットを絞ったプロンプト編集と高品質のプロンプトを生成します。図4(a)では、ヒントの改良中のヒント提案の品質をプロットしています。実験では、3 つのプロンプト最適化方法の間に非常に異なるパターンが観察されました。反復 APE は言い換えに基づいているため、新しく生成されたプロンプトの分散は小さくなります。 APO は大幅なキュー編集を行ったため、最初のステップでパフォーマンスが低下しました。 PE2 は 3 つの方法の中で最も安定しています。表 3 では、著者らはこれらの方法によって見つかった最良のヒントをリストしています。 APO と PE2 はどちらも、「すべての部品/詳細を考慮する」指示を提供できます。さらに、PE2 はバッチを二重チェックするように設計されており、単純な言い換え編集を超えて、「必要に応じて追加または削除することを忘れないでください」などの非常に具体的なプロンプト編集を行うことができます。

詳細については、原文論文を参照してください。