見出し画像

【論文を読む】プロンプトレポート：プロンプト技術の体系的調査 6

日考塾Media

前回は、論文のセクション5「プロンプトの問題」をご紹介してきました。セクション5の内容は、外部ツールや複雑な評価アルゴリズムの追加によってプロンプティングの拡張が可能であることなどを分析していました。
まだお読みでない方は下記よりお読みください。

今回は、セクション5「プロンプトの問題」をご紹介します。


6 ベンチマーク

プロンプト技術の体系的なレビューを行った後、異なる技術の実証的な性能を2つの方法で分析します。正式なベンチマーク評価と、実際の課題に対するプロンプトエンジニアリングの詳細なプロセスを示します。

6.1 技術ベンチマーク

プロンプト技術の正式な評価は、数百のモデルとベンチマークにわたる数百の技術を比較する広範な研究で行うことができます。これは本稿の範囲を超えますが、これまで行われていないため、この方向への第一歩として、選ばれたプロンプティング技術のサブセットを使用して、広く使用されているベンチマークMMLUを実施します。代表的なサブセットとして2,800のMMLU質問（各カテゴリの質問の20％）を使用し、すべての実験でgpt-3.5-turboを使用しました。

6.1.1 プロンプト技術の比較

6つの異なるプロンプト技術を、同じ一般的なプロンプトテンプレートを使用してベンチマークしました。このテンプレートは、プロンプトの異なる要素の位置を示しています。基本指示と質問はすべてのプロンプトに存在します。基本指示は「問題を解決し、（A）、（B）、（C）または（D）を返します」といったフレーズであり、場合によっては変更します。また、2つの質問形式をテストしました。質問形式はプロンプトテンプレートの「{QUESTION}」の位置に挿入されます。各プロンプト技術を6つの総変種でテストし、自己一致性を使用するものを除きました。

ゼロショット
ベースラインとして、プロンプティング技術を使用せずに直接モデルに質問を通しました。このベースラインでは、2つの形式および基本指示の3つのフレーズ変種を使用しました。したがって、このベンチマークには2,800の質問に対して合計6回の実行が行われました。これには、エグゼンプラーや思考誘導が含まれていません。

ゼロショットCoT技術
ゼロショットCoTも実行しました。3つの異なる変種として、標準の「ステップバイステップで考えましょう」チェーンオブソートを含む3つの思考誘導を使用しました。また、ThoTとPlan and Solveも使用しました。次に、これらの中で最適なものを選択し、自己一致性を3回繰り返し、過半数の応答を取りました。

Few-Shot技術
Few-ShotプロンプトとFew-Shot-CoTプロンプトも実行しました。いずれも、著者の一人が生成したエグゼンプラーを使用しました。各々に対して基本指示の3つの変種および2つの質問形式を使用しました（これもエグゼンプラーに適用されました）。次に、最も優れたパフォーマンスのフレーズを自己一致性で3回繰り返し、過半数の応答を取りました。

図6.1 各プロンプティング技術の精度値を示しています。紫のエラーバーは、各技術が異なるフレーズや形式で実行されたため、最小値と最大値を示しています（SCを除く）。

6.1.2 質問形式

フォーマットの選択がベンチマーク結果に与える影響を調査したSclar et al. (2023b) の2つのフォーマットを使用しました。これらはタスクで異なる結果をもたらすフォーマットです（図6.3と図6.4）。

図6.2 ベンチマーク用のプロンプトテンプレート
<code class="code-block">
{BASE_INSTRUCTION}
{EXEMPLARS}
{QUESTION} {THOUGHT_INDUCER}
</code>

図6.3 質問形式1
<code class="code-block">
Problem
{QUESTION}
Options
(A)::{A} (B)::{B} (C)::{C} (D)::{D}
Answer
</code>

図6.4 質問形式2
<code class="code-block">
PROBLEM::{QUESTION}, OPTIONS::
(A): {A}
(B): {B}
(C): {C}
(D): {D}, ANSWER::
</code>

6.1.3 自己一致性

2つの自己一致性の結果については、Wang et al. (2022) のガイドラインに従い、温度を0.5に設定しました。他のすべてのプロンプトでは温度0を使用しました。

6.1.4 応答の評価

LLMが質問に適切に回答したかどうかを評価することは難しいタスクです（セクション2.5）。回答が特定の識別可能なパターン（例：括弧内にある唯一の大文字のアルファベット（A-D）や、「正しい回答は」というフレーズに続くもの）に従っている場合、正しいとマークしました。

6.1.5 結果

技術が複雑になるにつれて、パフォーマンスは一般的に向上しました（図6.1）。しかし、ゼロショットCoTはゼロショットから急激に低下しました。広範なバリエーションを持ちながら、すべての変種でゼロショットが優れたパフォーマンスを示しました。自己一致性の2つのケースは、単一の技術を繰り返すため自然に広がりが少なくなりますが、ゼロショットプロンプトのみで精度が向上しました。Few-Shot CoTが最も良いパフォーマンスを示し、特定の技術による未解明のパフォーマンス低下はさらなる研究が必要です。プロンプト技術の選択はハイパーパラメータ検索に似ており、非常に困難なタスクです（Khattab et al., 2023）。しかし、この小規模な研究が、よりパフォーマンスが高く堅牢なプロンプト技術に向けた研究を促進することを期待しています。

6.2 プロンプトエンジニアリングケーススタディ

プロンプトエンジニアリングは、専門職として実践され始めたばかりの技術であり、そのプロセスに関する詳細なガイドはまだ文献に含まれていません。ここでは、難しい実世界の問題に対するプロンプトエンジニアリングの注釈付きケーススタディを示し、経験豊富なプロンプトエンジニアがどのようにタスクに取り組むかを具体例を通じて示します。このケーススタディは問題の解決そのものではなく、プロンプトエンジニアリングの過程と得られた教訓を示すことを目的としています。

6.2.1 問題

今回のケーススタディの課題は、潜在的に自殺の危険がある個人が書いたテキストから、危機レベルの自殺リスクを予測する信号を検出することです。自殺は世界的に深刻な問題であり、多くの精神衛生リソースの不足によってさらに悪化しています。米国では、全国人口の半数以上が連邦政府によって定義された精神衛生提供者不足地域に住んでおり、多くの精神衛生専門家が自殺予防の基本的な能力を欠いています。2021年には、1,230万人のアメリカ人が真剣に自殺を考え、170万人が実際に自殺を試み、48,000人以上が死亡しました。米国では、自殺は10〜14歳、15〜24歳、25〜34歳の人々の死因の第2位であり、35〜54歳の人々の死因の第5位です。

最近の研究では、自殺危機の状態、つまり差し迫った自殺行動のリスクが高い状態を特定することに特化した評価が重要であることが示されています。しかし、自殺危機症候群（SCS）や急性自殺傾向情動障害などの診断アプローチの検証済み評価は、個人的な臨床的相互作用や数十の質問を含む自己報告アンケートを必要とします。個人の言語における自殺危機の指標を正確にフラグ付けできる能力は、臨床判断の代替ではなく、既存の実践を補完する方法として精神衛生エコシステムに大きな影響を与える可能性があります。

ここでは、自殺危機症候群の評価の最も重要な予測因子である「フランティックホープレスネス」または「束縛感」に焦点を当てます。これは、「逃れられない状況から逃れたいという願望であり、すべての逃げ道が塞がれていると認識されている状態」です。この特徴は、自殺に至る精神的プロセスの他の特徴づけにも中心的なものです。

6.2.2 データセット

メリーランド大学のReddit自殺傾向データ設置のサブセットを使用しました。このデータセットは、r/SuicideWatchに投稿された投稿から構成されており、自殺の考えに苦しむ人々のためのピアサポートを提供しています。自殺危機症候群の要因の認識に関して訓練を受けた2人のコーダーが、221の投稿を束縛感の有無でコード化し、クリッペンドルフのアルファ0.72の堅固な一致度を達成しました。

6.2.3 プロセス

著名なプロンプトエンジニアが、このタスクに取り組み、LLMを使用して投稿内の束縛感を特定するためのプロンプトを作成しました。プロンプトエンジニアは、自殺危機症候群と束縛感に関する口頭および書面による概要、121の開発投稿とその正/負のラベル（「正」は束縛感が存在することを意味します）を与えられ、残りの100のラベル付き投稿はテスト用に予約されました。この限定された情報は、タスクの説明とデータに基づいてプロンプトが開発されるという現実的なシナリオを反映しています。一般的には、自然言語処理やAIにおいて、コード化（注釈付け）をラベル付けタスクとしてアプローチし、ラベルが実際には微妙で複雑な社会科学的構造を指す可能性があることを深く掘り下げない傾向と一致しています。

プロンプトエンジニアリングの過程を記録し、経験豊富なプロンプトエンジニアがどのように作業を進めるかを示しました。この演習は47の開発ステップを経て進行し、約20時間の作業がかかりました。初期段階では0％のパフォーマンス（プロンプトが正しく構造化された応答を返さない）から始まり、F1スコアを0.53まで向上させました。このF1は、0.86の精度と0.38のリコールの調和平均です。

下記のプロンプトセットはテストアイテムであり、質問、思考過程、エグゼンプラーにおける回答を示しています。

図6.5 F1スコアは、最低のパフォーマンスから最高のパフォーマンスまでのプロンプトまで幅広く変化しましたが、ほとんどのプロンプトは同様の範囲内に収まりました。
図6.6 最初のプロンプト（ゼロショット+Context）から最後のプロンプト（匿名化された電子メール）まで、F1スコアの向上は困難であり、多くの場合、パフォーマンスの低いプロンプトを複数回テストしてから効果的なものを見つけました。緑の線は現在の最高F1スコアに対する改善を示し、赤の線は悪化を示しています。

6.2.3.1 データセットの探索（2ステップ）

プロンプトエンジニアはまず、束縛感の説明を確認しました（図6.7）。この説明は、コーダーが初期のコーディングプロセスで使用したものであり、SCSに精通しているため、正式な定義ではなく包括的でもないことを認識していました。次に、プロンプトエンジニアはデータセットをPythonノートブックにロードしてデータ探索を行いました。gpt-4-turbo-previewに対して束縛感が何かを尋ねました（図6.8）が、LLMの応答は与えられた説明とは異なっていました。そのため、プロンプトエンジニアは今後のすべてのプロンプトに図6.7の説明を含めました。

図6.7 プロンプトエンジニアが使用した束縛感の説明
<code class="code-block">
出口がないと感じる
絶望感を感じる
道がないと感じる
物事が二度と正常にならないと恐れる
変える力がないと感じる
閉じ込められた感じがする
運命が決まっていると感じる
物事が変わることはないと思う
逃げ道がないと感じる
問題に対する良い解決策がないと感じる
</code>

図6.8 LLMに束縛感について尋ねた質問（トレーニングデータが関連知識を提供していなかった）
<code class="code-block">
自殺危機症候群に関して、エントラップメント（閉じ込められた感じ）とは何ですか？
</code>

6.2.3.2 ラベルの取得（8ステップ）

セクション6.1で述べたように、LLMは敏感なドメインでは予測不可能で制御が難しい行動を示します。プロンプトエンジニアリングプロセスの複数のステップで、LLMがラベル付けではなくメンタルヘルスのアドバイスを提供していることがわかりました（図6.9）。これはGPT-4-32Kモデルに切り替えることで解決しました。

図6.9 出力の一部。このスニペットは、データポイントをラベル付けするのではなく、ユーザーにメンタルヘルスのサポートを提供しようとします。このような出力は、しばしばこのスニペットの5倍の長さです。
<code class="code-block">
もし自分を傷つける危険が迫っている場合は、緊急サービスやお住まいの地域の危機ホットラインに連絡してください。彼らは即時の支援を提供し、あなたの安全を確保する手助けをしてくれます。
</code>

6.2.3.3 プロンプト技術（32ステップ）

プロンプトエンジニアは、その後、プロンプト技術の改善に大部分の時間を費やしました。これは、Few-Shot、Chain-of-Thought、AutoCoT、Contrastive CoT、複数の回答抽出技術などを含みます。これらの技術の最初の実行の統計を報告します。温度とtop pをゼロに設定しても、F1スコアは最大0.04まで変わる可能性があります。

ゼロショット+Context
最初に評価された技術は、図6.7の説明を使用したゼロショット+Contextです。プロンプトから最終応答を得るためには、LLM出力からラベルを抽出する必要がありました。エンジニアは2つの抽出器をテストしました。1つは出力が「Yes」または「No」と一致するかをチェックし、もう1つはこれらの単語が出力の最初の数文字と一致するかをチェックします。後者の方がパフォーマンスが良く、このセクションではCoTに達するまで使用されました。このアプローチは0.25のリコール、1.0の精度、0.40のF1を達成しました。

図6.10 ゼロショット+Contextプロンプトの例、最も単純なプロンプト
<code class="code-block">
{ENTRAPMENT DEFINITION (Figure 6.7)}
{𝑞𝑖𝑛𝑓}
Is this entrapment? Yes or no.
</code>

10-Shot+Context
次に、プロンプトエンジニアは最初の10件のデータサンプル（ラベル付き）をQ：（質問）A：（回答）形式でプロンプトに追加しました。この10-shotプロンプトは、トレーニング/開発セットの残りのアイテムで評価されました。精度は0.30、リコールは0.05、F1は0.45となり、前回の最高のプロンプトに対して改善が見られました。

図6.11 10-Shot+Contextプロンプトの例
<code class="code-block">
{ENTRAPMENT DEFINITION (Figure 6.7)}
Q: {𝑞1}
A: {𝑎1}
…
Q: {𝑞10}
A: {𝑎10}
Q: {𝑞𝑖𝑛𝑓}
A:
</code>

One-Shot AutoDiCot+Full Context
10ショットプロンプトを実行した後、プロンプトエンジニアは開発セットの12番目のアイテムが誤ってポジティブなインスタンスとしてラベル付けされていることに気付き、そのアイテムを正しくラベル付けするためのプロンプトの修正方法を実験し始めました。この誤ラベルが発生している理由を把握するために、プロンプトエンジニアはLLMに対して、12番目のアイテムがそのようにラベル付けされた理由の説明を生成するよう促しました。

図6.12は、そのプロセスのバージョンを示しており、アイテム12だけでなく、セットT内のすべての開発質問/回答アイテム(𝑞𝑖, 𝑎𝑖)に対して説明を生成するように一般化されています。誤ってラベル付けされた𝑞12に関して引き出された推論ステップ𝑟12に基づき、以前のプロンプトは、間違った推論の例として𝑟12を含むOne-Shot CoT例で修正されました（図6.13）。

図6.12 自動Directed CoT（AutoDiCoT）のアルゴリズム
<code class="code-block">

  1. Require: Development items 𝑇 with 𝑛 pairs (𝑞𝑖,𝑎𝑖)

  2. For each pair (𝑞𝑖,𝑎𝑖) in 𝑇:
    (a) Label 𝑞𝑖 as entrapment or not entrapment using the model
    (b) If the model labels correctly:
    i. Prompt the model with "Why?" to generate a reasoning chain 𝑟𝑖
    (c) Else:
    i. Prompt the model with "It is actually [is/is not] entrapment, please explain why." to generate a reasoning chain 𝑟𝑖
    (d) Store the tuple (𝑞𝑖,𝑟𝑖,𝑎𝑖)

  3. Return: 𝑛 tuples (𝑞𝑖,𝑟𝑖,𝑎𝑖)
    </code>

図6.12のアルゴリズムを自動指示CoT（AutoDiCoT）と呼びます。これは、特定の方法で推論するようにCoTプロセスを自動的に指示するためです。この技術は、あらゆるラベリングタスクに一般化できます。これは、Zhang et al. (2022b)によるCoTの自動生成と、Chia et al. (2023)の対照的なCoTの場合のように、悪い推論の例をLLMに示すことを組み合わせたものです。このアルゴリズムは、後のプロンプト開発にも使用されました。

最後に、プロンプトには2つの追加の文脈/指示が追加されました。1つ目は、プロジェクトの全体目標を説明するプロンプトエンジニアが受け取ったメールメッセージで、エントラップメントの概念とそれをラベル付けしたい理由についての文脈を提供しました。2つ目は、モデルがエントラップメントのポジティブラベルを頻繁に過剰生成していることにプロンプトエンジニアが気付いたことから着想を得ました。モデルがあまりにも積極的に前訓練に基づく推論を行っていると仮定し、エントラップメントの明示的な表現に限定するようモデルに指示しました（図6.13）。以下では、エントラップメントの説明に加えて提供されるこれら2つの文脈を「完全な文脈」と呼びます。

また、このプロンプトには新しいエクストラクターも使用されました。これは、出力の最初の単語ではなく最後の単語が「Yes」または「No」であるかどうかを確認します。この更新されたプロンプトは、最初の20件を除くすべての開発セットの入力に対してテストされました。F1スコアは改善しませんでしたが、F1スコアは0.09（0.36）から減少しましたが、プロンプトエンジニアを別の方向に導くきっかけとなりました。精度は0.09（0.39）に向上し、リコールは0.03（0.33）に低下しました。

しかし、この時点で観察する価値があるのは、最終的にはF1スコアの向上に繋がったものの、ポジティブラベルの過剰生成を減らすために取られたステップは、長期的な目標に照らして正しい動きではなかったということです。エントラップメントは必ずしも明示的に表現される必要はなく（例えば、「私は閉じ込められている気がする」や「逃げ道がない」といったフレーズ）、むしろテキストを調査した臨床専門家は、エントラップメントの表現が暗示的であり、かなり微妙である可能性があると考えました。さらに、エントラップメントを自動的に検出する多くのユースケースでは、精度とリコールが同等に重要であるとは限らず、リコール/感度（すなわち、リスクのある人物を見逃さないこと）がより重要である可能性が高いです。なぜなら、偽陰性の潜在的なコストは非常に高いからです。

ここでの教訓は、後から得られた洞察ですが、プロンプト開発のプロセスが実際の目標から逸脱しないようにするためには、プロンプトエンジニアと現実のユースケースを深く理解しているドメイン専門家との定期的な連携が重要であるということです。

6.2.4 議論

プロンプトエンジニアリングは、現在文献に詳細に記載されていない複雑なプロセスです。完全手動のプロセスから得られた主な教訓は、次のとおりです。プロンプトエンジニアリングは他の方法とは根本的に異なり、これらのシステムは説得されているのであり、プログラムされているわけではないということです。また、特定のLLMに非常に敏感であり、特定のプロンプトの詳細に非常に敏感であることが多いです。次に、データを掘り下げることが重要であり、プロンプトエンジニアとドメインの専門家との間で定期的な連携が必要です。

最終的に、プロンプトエンジニアリングの自動化方法に大きな可能性があることが示されましたが、その自動化と人間のプロンプトエンジニアリング/改訂を組み合わせることが最も成功したアプローチであることがわかりました。このケーススタディが、プロンプトエンジニアリングのより堅牢な検討への一歩となることを期待しています。

最後に

今回もお読みいただきありがとうございました。もし前の記事をお読みでない方は、下記よりマガジンとしてまとめていますのでどうぞ併せてお読みください。

もしかしたら専門家から見れば稚拙な表現などがあるかもしれませんが、その点はご容赦いただいた上で、次回以降もお読みいただければと存じます。

読んでいる方へのお願い

この内容が役に立ったという方は、「♡（スキ）」や「フォロー」をお願いします。「X」「facebook」「LINE」でシェアいただけるとさらに嬉しいです。

また日考塾Mediaでは、サポートをお受けしています。活動を継続させていくために、どうかお願い申し上げます。

日考塾Sapientiaでは、読んでいただいた方々に良質な記事をお届けするために日々励んでおります。しかし、良質な記事をお届けするためには、出ていくものも多いのが現状です。どうか、活動を継続させていくために、サポートををお願い申し上げます。