元記事のリンク: https://towardsdatascience.com/automated-prompt-engineering-78678c6371b9 LinkedInプロフィールリンク: https://linkedin.com/in/ianhojy 購読用の Medium プロフィールリンク: https://ianhojy.medium.com/ 著者 | イアン・ホー 編纂者：岳陽 ここ数ヶ月、LLMを使った様々なアプリの開発に取り組んできました。正直なところ、LLMから期待通りの出力を得るためにPromptの改良にかなりの時間を費やしてきました。 何度も空虚感と混乱に陥り、自分は単なる見せかけの即席エンジニアなのだろうかと自問します。LLM（大規模言語モデル）と人間のインタラクションの現状を考えると、やはり「まだだめだ」と結論づけてしまいがちですが、大抵の夜はなんとかインポスター症候群を克服しています。（訳注：これは、個人が自分の業績や能力に疑問を抱き、しばしば自分が詐欺師のように感じ、自分がその業績に値しない、あるいは達成していないと思い込み、それが暴露されることを恐れる心理現象です。）今のところ、この問題についてはこれ以上深く掘り下げません。 しかし、いつかプロンプト作成のプロセスが大部分自動化される日が来るのだろうかと、私は今でもよく考えます。この疑問に答える鍵は、プロンプトエンジニアリングの本質を理解することです。 インターネット上にはプロンプト エンジニアリングのプレイブックが大量に存在しますが、それでもプロンプト エンジニアリングが芸術なのか科学なのかは判断できません。 一方で、モデルの出力から得た観察に基づいて、自分が書いたプロンプトを繰り返し学習し、改良していく作業は、まるで芸術のように感じました。時が経つにつれ、細かい点も非常に重要であることに気づきました。例えば、「should（すべき）」ではなく「must（しなければならない）」を使うことや、ガイドラインをプロンプトの真ん中ではなく最後に置くことなどです。タスクによっては、一連の指示やガイドラインを表現する方法があまりにも多く、常に試行錯誤を繰り返しているように感じることもありました。 一方、手がかり語は単なるハイパーパラメータだと主張する人もいるかもしれません。結局のところ、LLM（大規模言語モデル）は、私たちが記述する手がかり語を、他のハイパーパラメータと同様に埋め込みとして扱います。機械学習モデルの訓練とテスト用に準備され承認されたデータセットがあれば、手がかり語を調整し、そのパフォーマンスを客観的に評価することができます。最近、HuggingFaceの機械学習エンジニアであるMoritz Laurer[1]の投稿を見ました。
少し考えた結果、答えはその中間にあると思います。プロンプトエンジニアリングが科学か芸術かは、LLMに何を達成させたいかによって決まります。この1年間、LLMは多くの素晴らしい成果を上げてきましたが、私は大規模モデルを使用する意図を、問題解決と創造という2つのカテゴリーに大きく分けています。 問題解決という観点から見ると、LLMは数学の問題を解いたり、感情を分類したり、SQL文を生成したり、テキストを翻訳したりします。一般的に、これらのタスクは比較的明確な入出力ペア（入力データとそれに対応するモデル出力データの関係）を持つことができるため、まとめて分類できると思います。（そのため、少数のプロンプトのみを使用して対象タスクをうまく達成できるケースが多く見られます。）明確に定義されたトレーニングデータを持つこれらのタスクでは、プロンプトエンジニアリングは私にとってより科学に近いように思えます。そのため、本稿の前半では、プロンプトをハイパーパラメータとして扱うという観点から、自動プロンプトエンジニアリングの研究の進展を探ります。 創造的なタスクという点では、LLMに求められるタスクはより主観的で曖昧です。これには、メール、レポート、詩、要約の作成が含まれます。まさにこの領域において、私たちはより曖昧な問題に遭遇します。ChatGPTの文章は非個人的なのでしょうか？（私がこれまでにChatGPTに書かせた何千もの記事に基づくと、私の現在の意見は「はい」です。）さらに、 LLMがどのように反応するかについてのより客観的な基準が欠如していることが多いため、創造的なタスクの性質と要件は、手がかりとなる単語をハイパーパラメータのように調整および最適化できるパラメータとして扱うことに一般的に適していません。 ここまで読んで、クリエイティブなタスクには常識だけで十分だと言う人もいるかもしれません。正直なところ、私も以前はそう思っていました。母にChatGPTを使って仕事用のメール作成を手伝ってもらうまで。このような状況では、プロンプトエンジニアリングは単発のイベントではなく、継続的な試行錯誤を通じて改善していくことが主な目的であるため、（前述の通り）汎用性を維持しながら、自分のアイデアを適用してプロンプトを改善するのは必ずしも簡単ではありません。 簡単に言うと、大規模なモデルから生成されたサンプルに対するユーザーフィードバックに基づいてプロンプトを自動的に改善できるツールを徹底的に探しましたが、見つかりませんでした。そこで、そのようなツールのプロトタイプを作成し、実行可能な解決策が存在するかどうかを検討しました。この記事の後半では、リアルタイムのユーザーフィードバックに基づいてプロンプトを自動的に改善できるツールをテストしましたので、ご紹介します。 01 パート1 – LLMをソルバーとして：ハイパーパラメータ最適化の一部としてのプロンプトエンジニアリングの扱い業界の多くの人は、論文「大規模言語モデルはゼロショット推論器である」[2]で登場する有名な「ゼロショットCOT」という用語をよく知っています（訳注：このモデルは、特定のタスクのための明示的な訓練データを学習することなく、既存の知識を組み合わせることで新しい問題を解決します）。周ら（2022）は、論文「大規模言語モデルは人間レベルのプロンプトエンジニアである」[3]で、その改良版をさらに探求することにしました。「正しい答えが得られるように、段階的に解いていきましょう」。以下は、彼らが提案した自動プロンプトエンジニア手法の概要です。 出典：大規模言語モデルは人間レベルのプロンプトエンジニアである[3] この論文を要約すると次のようになります。
いくつかの興味深い結論が見つかりました。
そして2023年、Google DeepMindの研究者たちは「プロンプティングによる最適化（OPRO）」と呼ばれる手法を発表しました。前例と同様に、メタプロンプト（ユーザー向けのプロンプトの構築または生成を支援するために使用されるプロンプト）には、一連の入力/出力ペア（特定のタスクまたは問題に対する入力と期待される出力の組み合わせを記述したもの）が含まれています。ここでの主な違いは、メタプロンプトには、以前にトレーニングされたプロンプトサンプルとその正解または解決策、これらのプロンプトへの回答におけるモデルの精度、そしてメタプロンプトの様々な部分間の関係を詳述するガイドプロンプトも含まれていることです。 著者らが説明しているように、研究における各キューワード最適化ステップでは、以前の学習軌跡を参照することを目的として新しいキューワードが生成され、モデルが現在のタスクをよりよく理解して、より正確な出力結果を生成できるようになります。 出典：大規模言語モデルを最適化装置として利用する[4] Zero-Shot-COT シナリオでは、「深呼吸をして、この問題に段階的に取り組んでください」というキューワード最適化手法を提案し、優れた成果を達成しました。 これについてはいくつか考えがあります:
例えば、GSM8KテストセットでPaLM 2-L評価モデルを使用した場合、「段階的に考えましょう。」の精度は71.8%に達し、「一緒に問題を解決しましょう。」の精度は60.5%でしたが、最初の2つの指示語の意味の組み合わせである「一緒にこの問題を段階的に解決しましょう。」の精度はわずか49.4%でした。 この動作により、シングルステップ命令間の差異が増大し、最適化プロセス中に発生する変動も増大するため、最適化プロセスの安定性を向上させるために、各ステップで複数のシングルステップ命令を生成する必要が生じます。 論文の結論では、もう一つの重要な点についても言及されています。「このアルゴリズムを現実世界の問題に適用する際の現在の限界の一つは、プロンプトの最適化に使用されている大規模言語モデルが、トレーニングセット内のエラー事例を効果的に活用してプロンプトの改善に向けた有望な方向性を推論できていないことです。実験では、各最適化ステップでトレーニングセットからランダムにサンプリングするのではなく、トレーニングまたはテスト中に発生したエラー事例をメタプロンプトに組み込むようにしましたが、結果はほぼ同じでした。これは、これらのエラー事例から得られる情報だけでは、最適化LLM（プロンプトの最適化に使用される大規模言語モデル）が誤った予測の理由を理解するには不十分であることを示しています。」この点は確かに強調する価値があります。なぜなら、これらの手法は、プロンプトの最適化プロセスが従来のML/AIにおけるハイパーパラメータ最適化プロセスに類似していることを強く示しているものの、LLMにどのようなコンテンツ入力を提供するか、あるいはLLMにプロンプトを改善するようどのように導くかなど、肯定的で積極的な事例を優先する傾向があるからです。しかし、従来のML/AIでは、この傾向は通常それほど顕著ではありません。エラー自体の方向や種類にあまり注意を払うのではなく、エラー情報を活用してモデルを最適化する方法に重点を置いています (つまり、-5 と +5 のエラーをほとんど同じように扱います)。 APE（Automated Prompt Engineering）にご興味がございましたら、https://github.com/keirp/automatic_prompt_engineer からダウンロードしてご利用いただけます。 出典: APEのサンプルノートブックのスクリーンショット[5] APE と OPRO の両方のメソッドには重要な要件があります。最適化を支援するためのトレーニング データが必要であり、最適化されたプロンプトの一般性を保証するためにデータセットが十分に大きい必要があります。 ここで、すぐに利用できるデータがない可能性がある別の種類の LLM タスクについてお話ししたいと思います。 02 パート 2 – クリエイターとしての LLM: プロンプトエンジニアリングを継続的な実験と調整のプロセスとして捉える。では、これから短編小説をいくつか考えてみましょう。 モデルを学習させるための小説テキスト例が不足しており、適切な小説テキスト例の作成には時間がかかりすぎます。さらに、モデルの出力は多様で許容範囲も広いため、大規模なモデルに「いわゆる正解」を出力させることに意味があるのかどうかも疑問です。したがって、APEのような手法を用いてプロンプト語のエンジニアリングを自動化することは、この種のタスクでは実質的に非現実的です。 しかし、なぜプロンプト作成のプロセスを自動化する必要があるのか疑問に思う読者もいるかもしれません。「 しかし、このような状況で、キューワードエンジニアリングから最も恩恵を受けるのは誰でしょうか？まさに、モデルに提供されるキューワードを微調整し、改善する経験が不足している、経験の浅いキューワード作成者です。私は、母に仕事のタスクでChatGPTの使い方を教えているときに、このことを直接体験しました。 母はChatGPTの出力結果に対する不満をプロンプトの改善に結びつけるのがあまり得意ではないかもしれませんが、プロンプトエンジニアリングのスキルとは関係なく、私たちが本当に得意とするのは、目にした問題（つまり不満）を表現することだと気づきました。そこで、ユーザーが不満を表明し、LLMにプロンプトを改善させるツールを開発しようと試みました。これは私にとってより自然なインタラクション方法に思え、LLMをクリエイティブなタスクに使用しようとしている私たちにとっても、より使いやすくなるように思えました。 あらかじめ述べておきますが、これはあくまで概念実証に過ぎません。読者の皆様は、ぜひ著者と良いアイデアを共有してください。 まず、{{}}変数を使ってプロンプトを記述します。ツールはこれらのプレースホルダーを検出し、後で入力できるようにします。上記の例を使って、大規模モデルにシンガポールの不平等に関する独創的なストーリーを出力させましょう。 次に、ツールは入力プロンプトに基づいてモデル応答を生成します。 次に、フィードバックを提供します（モデルの出力に関する苦情を表明します）。 その後、モデルはストーリーアイデアの例の生成を停止し、最初の反復で改善されたプロンプトを出力するように指示されました。以下に示すプロンプトは改善され、一般化されており、ユーザーに「これらの課題を克服または取り組むための戦略を説明してください」と求めていることに注意してください。最初のモデル出力に対する私のフィードバックは、「物語の主人公が不平等にどのように対処しているかを説明してください」でした。 次に、改善されたプロンプトを使用して、大きなモデルに短編小説を再考するよう依頼しました。 「次の例を生成」をクリックすると、他の入力変数に基づいて新しいモデル応答を生成することもできます。以下は、中国におけるレイオフに関するクリエイティブなストーリーの例です。 次に、上記のモデルの出力に関するフィードバックが提供されます。 その後、プロンプト語はさらに最適化されました。 最適化の結果はかなり良さそうです。元々は単なるシンプルなプロンプトでしたが、2分足らず（とはいえ、ややざっくりとした）フィードバックと3回の反復を経て、この最適化されたプロンプトにたどり着きました。これで、LLMの出力に不満があれば、あとはただ座ってプロンプトの最適化を続けるだけです。 この機能の内部実装はメタプロンプトから始まり、動的なユーザーフィードバックに基づいて継続的に最適化され、新しいプロンプトを生成します。特別なことは何もありませんし、確かに改善の余地はありますが、すでに良いスタートを切っています。 prompt_improvement_prompt = """# コンテキスト # オリジナルのプロンプトが提供されます。
元のプロンプトを使用して、いくつかの回答例を生成しました。それぞれの回答に対して、望ましい回答を改善するためのフィードバックが提供されました。
あなたの仕事は、すべてのフィードバックを確認し、フィードバックに対応した改善されたプロンプトを返すことです。これにより、GPT言語モデルに対するプロンプトに対して、より適切な応答を生成できるようになります。# ガイドライン # - 元のプロンプトには、二重中括弧で囲まれたプレースホルダーが含まれます。これらは、例で表示される入力値です。
- 改善されたプロンプトは200語を超えてはならない
- 改善されたプロンプトのみを返し、その前後に何も記述しないでください。二重中括弧で囲んだ同じプレースホルダーを含めることを忘れないでください。
- 改善されたプロンプトを作成する際は、プロンプト全体を1つの段落で記述することは避けてください。代わりに、タスクの説明、ガイドライン（ポイント形式）、その他のセクションを適宜組み合わせてプロンプトを作成してください。
- ガイドラインはポイント形式で、タスクの繰り返しではなく、それぞれ明確に区別できる必要があります。
- 改善されたプロンプトは、言語モデルが最もよく理解できる通常の英語で記述する必要があります。
- 提供されたフィードバックに基づいて、応答の望ましい動作を、「すべき」という示唆的な文ではなく、「しなければならない」という命令形の文に言い換える必要があります。
- プロンプトに加えられた改善は、1つの例に過度に特化すべきではありません。# 詳細 # 元のプロンプトは次のとおりです:```
{元のプロンプト}
```提供された例とそれぞれのフィードバックは次のとおりです:```
{例}
改善されたプロンプトは次のとおりです。
「」 このツールの使用中に観察されたいくつかの点:
このツールはまだデプロイしていません。メタプロンプトでどのアプローチが最適かを確認したり、Streamlitフレームワークの問題を解決したり、プログラムで発生する可能性のあるその他のエラーや例外を処理したりするために作業を進めているからです。しかし、ツールはまもなく利用可能になる予定です。 03 結論プロンプトエンジニアリングの分野全体は、タスク解決に最適なプロンプトを提供することに焦点を当てています。APEとOPROはこの分野における最も重要かつ優れた例ですが、全体像を代表するものではありません。今後、この分野でどれだけの進歩を遂げられるか、非常に楽しみです。これらの手法を様々なモデルで有効性を評価することで、それらのモデルの動作傾向や特性を明らかにすることができ、また、どのメタプロンプト手法が効果的かを理解するのにも役立ちます。したがって、これは非常に重要な研究であり、LLMを日常業務や生産的な実践に活用する上で役立つと考えています。 しかし、これらのアプローチは、LLMを創造的なタスクに活用したいと考えている人には適さないかもしれません。現在、多くの既存の学習マニュアルが初期段階のガイドとして役立ちますが、試行錯誤を繰り返すことに勝るものはありません。したがって、短期的には、人間の強み（フィードバックの提供）を活かしながら、この実験プロセスをいかに効率的に実施し、LLMに残りの作業（プロンプトの改良）を任せることができるかが最も重要だと考えています。 概念実証（POC）にも力を入れていきますので、ご興味がありましたらお気軽にご連絡ください（https://www.linkedin.com/in/ianhojy/）。 読んでくれてありがとう！ 終わり 参考文献 [1] https://www.linkedin.com/in/moritz-laurer/?originalSubdomain=de [2] https://arxiv.org/pdf/2205.11916.pdf [3] https://arxiv.org/pdf/2211.01910.pdf [4] https://arxiv.org/pdf/2309.03409.pdf [5] https://github.com/keirp/automatic_prompt_engineer [6] https://arxiv.org/abs/2104.08691 [7] https://medium.com/mantisnlp/automatic-prompt-engineering-part-i-main-concepts-73f94846cacb [8] https://www.promptingguide.ai/techniques/ape この記事は、原著者の許可を得てBaihai IDPによって翻訳されました。翻訳の転載をご希望の場合は、お問い合わせください。 オリジナルリンク: https://towardsdatascience.com/automated-prompt-engineering-78678c6371b9 |
