より良いアウトラインを作成するために 55 のプロンプトをテストした方法

公開: 2024-02-06

ヘッダー画像の DALL-E-3 プロンプト: 「非常に単純なプロンプトでツールがどのように動作するかをテストする必要があります。 詳細を追加せず、そのまま使用してください: オフィスのホワイトボードに概要を書くロボット。 アウトラインをローマ数字のラベルが付いたいくつかのセクションに整理し、基礎となるサブセクションがメインのヘッダーに対して適切にインデントされていることを確認してください。」 画像だけでなく、このプロンプトからも解き明かすべきことがたくさんあります。DALL-E の詳細については、近くの Verblog で間もなく公開される予定ですので、ご期待ください。

AI を使用してコンテンツを作成していて、わざわざプロンプトをテストする必要がないと思われる場合は、プロンプト テストがなぜそれほど重要なのかについての私の前回の記事をざっと読んでください。

この記事では、人間が作成した AI コンテンツの顧客向けにアウトラインを生成する方法を変更するために、私が最近 55 のプロンプト バリエーションをテストした方法を共有します。

ここでの私の目標は、独自のテスト プロセスについて考えるのに役立つことです。 別の目標がある場合や、プロンプトを使用してアウトラインの生成以外の別のことを実行している場合もありますが、一般原則とフレームワークはユースケースに関係なく役に立ちます。

簡単な用語集:

  • プロンプトのバリエーション:同じ目標 (アウトラインを書くなど) を目的とした複数の異なるプロンプトをテストする場合、それらはプロンプトのバリエーションです。 特定のバリエーションは、単一のプロンプトである場合もあれば、チェーン内の複数のプロンプトが含​​まれる場合もあります。
  • 入力:プロンプト内で使用される特定の変数を参照するために「入力」を使用しています。 これらの変数を使用してプロンプトを作成すると、同じプロンプトを何度も再利用できます。
  • 出力:出力とは、プロンプトに対する LLM の応答を指します。 ChatGPT では、これがウィンドウに表示される応答です。 これは、OpenAI API を介した、 response.choices[0].message.contentフィールドの応答です。 プロンプト チェーンを使用するとき、私は最終出力 (つまり、モデルの中間応答ではなく、実際に必要なコンテンツを含む出力) を参照するために「出力」を使用します。

LLM テストの 2 つの戒め

1. 良いものをできる限り定量的に定義する

LLM のテストは、多くの場合、「どのプロンプトによってより良い出力が得られるかを確認したい」という曖昧な考えから始まります。 その「より良い」の一部は主観的なものである可能性があり、それを回避する方法はありません。 ただし、少なくともいくつかの定量的な尺度を考え出すと、たとえその尺度が収まる必要がある一般的な範囲を知るだけであっても、テストしているプロンプトの出力を評価することがはるかに簡単になります。

さまざまなテストに使用したメトリクスの例:

  • 文字数: たとえば、紹介文を作成するとき、特定の文字数の範囲内に収めたいと考えていました。
  • 読解レベル: 特定の読解レベルをターゲットにするために、Readability などのツールを使用してプロンプト出力の実行を自動化し、読解レベルを比較しました。 (GPT-4 の可読性を評価する機能について最初にこの記事を読んでいたら、別のツールではなくそのモデルを使用したでしょう。注意してください、この記事には大量の統計概念が含まれていますが、興味のある方はざっと読む価値があります。読みやすさにはまったく興味がありません。)
  • キーワードの使用回数
  • 禁止用語の使用の有無
  • オリジナルと比較した長さ: たとえば、私は AI が生成したコンテンツから綿毛の一部を削除し、より簡潔に書き直すツールを構築していました。 書き換えたテキストが元のテキストと比べてどのくらいの長さになるかを気にしました。それは、テキストをあまり短くしたくなかったためですが、テキストが長くなっていないことも確認したかったからです。 単語数だけでは、知りたいことはわかりません。特定の入力と比較して出力を評価する必要がありました。
  • 実行時: 誰かがリアルタイムで出力を待っている場合、実行に数分かかるプロンプト チェーンは使用したくありません。

おそらく、すべての評価を定量的な指標に落とし込むことはできません。 ある時点で、実際に出力を確認して、「これが最良の時期だった」と自分で判断する必要があります。 「最悪の時代だった」は、「喜びと悲しみの両方が特徴の時代でした」よりも強い冒頭文です。 ただし、少なくとも、いくつかの指標を設定しておけば、特定の出力をすぐに削除できるため、手動で確認する必要がある出力の数を減らすことができます。

AI を使用して出力を評価する

AI を使用して出力を定性的に評価できるかどうか疑問に思っていますか? 研究によると、GPT-4 は人間の好みと 80% の一致に達することができます。ちなみに、これは人間同士が一致するのと同じレベルです。 ただし、私はこのアプローチだけに依存することには慎重です。なぜなら、私は夏の間、このアプローチを使って独自のテストを行ったのですが、その結果は必ずしも自信を持てるものではなかったからです。

テスト方法: GPT-4 に 1 組のオプションを提示し、どれが特定の音声のより良い例であるかを評価するように依頼しました。 変動を減らすために低温を使用し、同じ選択肢でまったく同じプロンプトを 2 回実行しました。次に、同じ 2 つの選択肢でプロンプトを再実行しましたが、選択肢が与えられる順序を逆にしました。

GPT-4 は合計で、同じ 2 つの選択肢を 4 回比較しました。 これを 274 の異なる組み合わせに対して行ったところ、モデル自体が全会一致で同意したのは、それらの組み合わせのうち 53% のみでした (つまり、選択肢が最初に提示されたか 2 番目に提示されたかに関係なく、モデルは 4 回すべて同じ選択肢を選択しました)。

n = 274

それが上のピンク色のパイです。 2 番目に一般的な結果 (紫色のスライス) は、モデルがペアの各オプションを 2 回選択することで、その選択は完全に任意であることを意味します。

これらの統計は、ペアを評価する際の GPT-4 の一貫性を測定するだけであり、その選択が実際に「正しかった」かどうかについては言及し始めていないことを強調する価値があります。 それが人間の評価者の好みと一致するかどうか。 精度と精度: AI を評価ツールとして使用する場合は、両方が必要です。

これは、AI を使用して自身の出力を判断することが不可能であると言っているわけではありません。 2 つのペアの評価を求めるプロンプトを改善することで、コンセンサスのレベル (精度) を向上させることは間違いありません。そのプロンプトで私自身の選択の例を提供することで、プロンプトを人間の好み (精度) により近づけるのに役立つ可能性があります。 。 ただし、それにはさらに多くの時間とテストが必要です。

結論: AI の評価が A) 一貫性があり、B) 好みと一致していることを確認するために最初に多くの時間を費やすことなく、定性的評価を AI にアウトソーシングした場合、結果はあまり良くありません。

2. 複数の入力でテストする

AI を大規模に使用してコンテンツを作成している場合は、複数の入力でプロンプトをテストする必要があります。 非常に低い温度を使用している場合を除き、LLM は同じ入力に対しても毎回異なる出力を提供し、そのパフォーマンスは入力が異なるとさらに異なります。

また、入力内容がそのプロンプトの使用方法の範囲を表していることも確認してください。 たとえば、複数の異なる業界向けのコンテンツを作成する場合は、テストに使用する入力がすべて 1 つの業界からのものではないことを確認します。 同様に、同じプロンプトを使用して 600 ～ 2000 ワードの範囲の記事のアウトラインを生成する場合は、入力に一定範囲のワード数を含めることになります。 そうしないと、2000 ワードの記事では優れたアウトラインが生成されるが、600 ワードの記事では生成されないプロンプトが表示される可能性があります。

たとえば、アウトラインを作成するプロンプトをテストするには、次のような入力のスプレッドシートを使用します。

6 つの異なる記事の情報を示すスプレッドシート

各行は、異なる入力セットを表します。 同じプロンプトを 6 回実行し、そのたびにプロンプ​​ト内の {topic} や {word_count} などの変数をいずれかの行の実際の値に置き換えます。

私の即時テストプロセス

これらの原則を踏まえて、顧客向けのアウトラインを生成するために 55 の異なるプロンプトをテストした方法を見てみましょう。 改善しようとしていた点、さまざまなプロンプトをテストするために使用したツールとプロセス、結果のメトリクス、および勝ったプロンプトをどのように評価したかについて説明します。

改善したかったこと

私は、顧客向けに生成されていたアウトラインにいくつかの具体的な改善を加えたいと考えていました。

  • アウトラインの短縮: 既存のアウトラインにはセクションが多すぎることが多く、最終的な記事が指定された文字数に対して長すぎます。
  • 幻覚のリスクの軽減:概要に「事例紹介」、「体験談」、「参考文献」などのセクションが含まれている場合、AI は記事を書くときに必然的にその情報を補おうとするため、人間のライターにとっては余分な作業が必要になります。 AI にこれらのセクションがまったく含まれないようにプロセスを改善したいと考えました。
  • フォーマットのアウトラインの改善:たとえば、顧客のトピックが「X のベスト VPN」のようなリストの場合、アウトラインの見出しはそれぞれ、「VPN #1」、「VPN #2」などではなく、特定の VPN にする必要があります。 、これらのセクションが記事の大部分を占めるはずです。 また、読者の意図を念頭に置いて、顧客のキーワードを検索するときに表示されると予想される情報をカバーするアウトラインがより適切に機能することを確認したいと思いました。

コンテンツ自体の品質ではありませんが、カスタマーエクスペリエンスの品質に関する最後の考慮事項は、アウトラインの生成にかかる時間でした。 顧客はアプリ内でアウトラインが表示されるのをリアルタイムで待っており、注文を確定する前にアウトラインを確認して編集できるため、10 秒待つか 1 分待つかは重要です。

私たちは、お客様が望んでいることを確実にカバーできるよう、アウトラインを確認して編集していただきたいと強く思っています。 待たなければならない時間が長ければ長いほど、その可能性は低くなります。

プロセス

Google スプレッドシートと Google Colab は私の親友です。

1 枚のシートで、プロンプト バリエーションの最初のリストを作成しました。 場合によっては、2 つのプロンプトの違いはわずか数語です。 他のものでは、それらはまったく異なって見えるでしょう。 以下に例を示します。

 Prompt variation #1 write an outline for the topic: {topic} word length: {word_count}

ご覧のとおり、LLM が最小限の指示で何を行うかを理解するために、私は非常に単純なことから始めました。 他のバリエーションとして、より洗練されたプロンプト戦略を使用しました。

 Prompt variation #5 You will be writing an outline for a given topic. First, think through how the article should be structured, given the searcher intent for the keyword. Provide these thoughts inside <analysis></analysis> tags. Then, provide the outline itself inside <outline></outline> tags. topic: {topic} keyword: {keyword}

2 番目のシートには、すでに注文されて顧客に届けられた 30 種類の実際の記事の簡単な情報と、それらの記事のために元々生成された概要を保存しました。

Verblio のコンテンツ注文フォームのスクリーンショット
コンテンツ注文フォームは意図的に最小限かつ構造化されていますが、プロンプトでは依然として幅広い入力を考慮する必要があります。

次のステップでは、OpenAI の API を使用します。 コードを書くことに慣れていないが、Make や Zapier などのローコード ツールまたはノーコード ツールにアクセスできる場合は、代わりにその方法で OpenAI のモデルにアクセスできます。 いずれにせよ、ChatGPT ウィンドウからプロンプトや出力をコピー/ペーストするよりもはるかに簡単で、大規模な実際のテストを実行する唯一の実行可能な方法です。

Colab ノートブックで Python プログラムを使用して、モデル (主に GPT-4 または GPT-3.5-turbo) にプロンプ​​トを送信しました。 このプロンプトは、最初のシートのプロンプト バリエーションの 1 つの変数を 2 番目のシートの 30 セットの入力の 1 つで置き換えることによって作成されました。これを、プロンプトと入力のすべての組み合わせでモデルにプロンプ​​トを表示するまで繰り返しました。 次に、プログラムは結果のアウトラインを 3 番目のシートに自動的に保存しました。

Google Colab ノートブック内の Python コードのスクリーンショット
これはコードの主要部分で、2 つの異なるシートから記事の入力とプロンプトのバリエーションを取得し、各プロンプトのバリエーションを通じて各入力のセットを実行しています。

モデルが生成した新しいアウトラインごとに、上記で特定した改善点に基づいて、気になる定量的指標を評価しました。

  • 既存のプロンプト フローを使用して顧客向けに以前に生成したアウトラインと比べて、どれくらい短かったですか?
  • ケーススタディや参考文献など、見たくないセクションは含まれていましたか?
  • 走るのにどれくらいかかりましたか？

これらの指標をプロンプトのバリエーションごとに集計し、全体的な結果を比較しました。

数字だけに頼ることはできなかったので、リストが適切にフォーマットされているか、意味があるかどうかなどを確認するために、アウトラインも手動で確認しました。

次に、最もパフォーマンスの高いプロンプトのバリエーションを繰り返して結果をさらに改善できるかどうかを確認し、同じプロセスを再度実行しました。 そしてまた。 そして、何度も、何度も、何度も。

結果

最終的に、プロンプト、モデル、温度の 55 の異なるバリエーションをテストしました。 それらの一部の結果を以下のグラフに示します。

さまざまなプロンプトのバリエーションをテストした結果を示すスプレッドシート
n = 30

最初のコールアウト: さらに繰り返すにつれて、結果が良くなる (緑が増え、赤が減る) ことがわかります。 だからこそテストが重要なのです。 複数の側面にわたって非常に現実的な改善を行うことができます。これは、数百のケースにわたってこれらのプロンプトを実行するときに、大幅な時間を節約することを意味します。

列 B から E はすべて、新しいアウトラインが以前に生成したものよりどれだけ短いかを示しています。 列 F は、各プロンプト (場合によってはプロンプト チェーン) の実行にかかった時間を示します。これは、顧客がアプリで待機する必要があるおおよその時間です。 列 G は、「ケーススタディ」など、含めるべきではないセクションが新しいアウトラインに含まれていた数を示します。

一貫性が重要

複数の入力 (私の場合は 30) でプロンプトをテストすることが非常に重要な主な理由は、毎回動作が異なるためです。 これは、新しいアウトラインが古いものよりもどれだけ短いかを確認する際に、私たちにとって非常に重要でした。

中央値の減少 (列 B) は一目瞭然ですが、その測定値だけを見ていたら、そのプロンプト変動が入力全体でどの程度一貫しているかについては何も学べなかったでしょう。 最小削減 (列 C) も確認することが重要でした。これは最悪のシナリオを示していたからです。各プロンプトのバリエーションは実際に、少なくとも 1 つのテスト記事で元のアウトラインよりも長いアウトラインをもたらしました。 プロンプト 41 の場合、その最悪のケースは、現在のプロンプトで最初に取得したアウトラインの 2 倍以上の長さのアウトラインを取得することを意味しました。 一方、プロンプト 55 の場合は、最悪のケースは大幅に改善され、新しいアウトラインは元のアウトラインよりも 10% 長いだけでした。

プロンプト 43 の 84 パーセントの削減はおそらく高すぎるものの、特定のパーセントの削減を目指したわけではないため、最大削減 (列 D) は色分けされていません。 プロンプトの動作の一貫性を理解するためにより重要なのは、最小削減量と最大削減量の間の広がりです (列 E)。この数値が低いほど、そのプロンプトからの出力の一貫性が高くなります。これが私たちが望むものです。

実行時

ランタイムに影響を与える 2 つの主な要因 (列 F):

  1. 使用されているLLM
  2. プロンプトの数、つまり。 単一のプロンプトかプロンプト チェーンかどうか

プロンプトの長さも実行時間に影響しますが、その程度はこれら 2 つの要素よりもはるかに小さいです。

トレードオフとして、長いプロンプトまたはプロンプト チェーンを使用すると定性的により良い結果が得られることがよくありますが、その場合、実行にかかる時間が長くなります。 ただし、モデルが異なればランタイムも異なります。 一般に、古くて小さいモデルは高速ですが、GPT-4 のような新しいモデルは、サイズとトラフィック量の両方により遅くなります。

勝利のプロンプト

最終的に、定量的および定性的測定の両方で総合的に最高となったプロンプト バリエーションは、54 位でした。

プロンプト 54 の結果が私の当初の目標を達成したことがわかります。

  • 一貫してアウトラインが短くなり (ただし、短すぎません!)、最小縮小と最大縮小の間の広がりが比較的小さくなりました (列 E)。
  • 実行時間の中央値 15 秒 (列 F) は最低ではありませんでしたが、それでも現在使用しているプロンプトの平均実行時間の半分未満でした。
  • 概要に表示したくないセクション (G 列) が含まれることはありませんでした。
  • アウトラインを手動で確認したところ、品質や形式などの点で私たちが望んでいたものでした。

正確なプロンプト戦略については次の記事で詳しく説明しますが、簡単に言うと、プロンプト 54 が非常にうまく機能する理由は次のとおりです。

  • モデルに「考える」時間を与える
  • 私が望んでいたものの例を提供する
  • (単一のプロンプトではなく) プロンプト チェーンを使用して、特定の要件を満たす精度を向上させますが、実行時間を比較的短く保つために古いモデルでこれを実行します。

もっと迅速なバリエーションを続けて、さらなる改善を見ることができたでしょうか? もちろん。 しかし、ある時点で、本番環境へのプロンプトを改善して、お客様が遅かれ早かれ改善を実感できるようにしたいと考えていました。

この話の教訓: 適度な量をテストしてください。ただし、完璧を善の敵にしないでください。 新しいバリエーションから得られる利益が少なくなってきたら、勝者を宣言して生活を続ける必要があります。

次の記事では、私がテストした具体的なプロンプト戦略と、大規模に機能するプロンプトを作成するためのヒントを共有することで、プロンプト自体の内容について詳しく説明します。 テスト設定、使用した Python コード、またはその他について質問がある場合は、[email protected] にメッセージを送信してください。