今も通用するプロンプトエンジニアリングの基本

プロンプトエンジニアリングには評判の問題があります。ネット上の助言の半分は俗説です。一度あるモデルで効いた魔法の言い回しや儀式が、法則へと一般化されたものです。残りの半分は本当に有用で、そして退屈です。本ガイドはその退屈な半分、すなわちモデルやリリースを越えて通用し続ける基本についてのものです。なぜなら、それらはこれらのシステムが実際にあなたの与えたテキストをどう使うかを反映しているからです。

なぜ基本はトリックに勝るのか

言語モデルは、コンテキストにあるすべて、すなわちあなたの指示、例、入力を条件として応答を生成します。「プロンプティング」とは、最ももっともらしい続きがあなたの望む答えになるよう、そのコンテキストを配置する技にすぎません。特定のモデルの癖に結びついたトリックは、モデルが変わると壊れます。基本、すなわち明確であること、例を与えること、タスクを構造化することは、どんな有能なモデルにとっても望む出力をより起こりやすくするので、通用し続けます。基本に最適化すれば、トリックはめったに必要ありません。

1. タスクと出力について具体的であること

最もよくある失敗は、指定不足です。「これを要約して」は、十数の決定をモデルに委ねます。どれくらいの長さで、誰のために、どんなトーンで、何に焦点を当てて。指定されていない決定はそれぞれコイン投げです。実際に望むものを言いましょう。「これを、非技術系のマネージャー向けに三つの箇条書きで、コストとリスクに焦点を当てて要約して」。具体性は冗長さではありません。コイン投げを取り除くことです。

同じことが出力形式にも当てはまります。特定の構造、すなわちリスト、表、JSON、特定のフィールドの集合が必要なら、それを明示し、形を示しましょう。モデルは、内容についてと同様、形式についてもあなたの心を読めません。

2. 語るのではなく、見せる

例は、プロンプティングにおいて最も大きな効果を持つ道具です。入力と望ましい出力の組を一つか二つ示すだけで、段落いくつ分の指示よりも多くを伝えます。パターンを記述するのではなく実演するからです。これはしばしば数ショットプロンプティングと呼ばれ、単純な理由で機能します。明快な例が、目標とするパターンを当然の続きにするのです。

実務上の注意が二つ。例を、厄介なケースも含めて、実際の入力を代表するものにしましょう。簡単な道筋しか扱わない例は、簡単な道筋を教えます。そして例どうしを一貫させましょう。矛盾する例は、助けるよりも混乱させます。

3. モデルに考える余地を与える

推論を伴うもの、すなわち多段階の問題、分析、判断については、答えを即座に求めると、まず考え抜くよう求めるよりも悪い答えになることがよくあります。最終的な答えにコミットする前に段階を追って推論させると、まさに品質を出しにくいタスクで品質が向上する傾向があります。仕組みは直感的です。最初のトークンで答えにコミットするモデルは修正できませんが、まず推論するモデルはできます。

実用版はこうです。難しいタスクには、結論だけでなく、推論とそれに続く結論を求めましょう。簡単なタスクには省きましょう。推論の段階はトークンとレイテンシを消費し、単純な参照にはそれは要りません。

4. 指示を効く場所に置く

構造が重要です。指示を入力から明確に分けましょう。見出し、区切り記号、ラベル付きのセクションを使えば、何が命令で何が処理すべきデータかをモデルが見分けられます。プロンプトが指示とコンテンツを一枚の文章の壁に混ぜ込むと、モデルはどちらがどちらかを推測しなければならず、ときに推測を誤ります。少しの構造が、その曖昧さを取り除きます。

システムレベルの指示（役割、ルール、制約）は、一般に冒頭に、平易に述べるのが適切です。処理すべき入力は、入力として明確に印を付けるのが適切です。この分離は、入力中のコンテンツが誤って指示として読まれる種類の失敗に対する防御にもなります。

5. 失敗の振る舞いを制約する

モデルは、答えるべきでないときでも答えます。タスクに「答えなし」のケース、すなわち情報が存在しない、依頼が範囲外、というケースがあるなら、明示しましょう。「テキストに答えが含まれていなければ、記載がない旨を返答して」。その指示がないと、モデルはもっともらしい推測で隙間を埋めます。望む失敗の振る舞いに名前を与えることが、自信たっぷりの捏造を、正直な「見つかりませんでした」に変えます。

6. 実例に対して反復する

俗説とエンジニアリングの最大の違いは、計測です。一つの印象的な出力でプロンプトを判断してはいけません。実際の多様な入力を一握り集め、すべてに対してプロンプトを実行し、結果を読みましょう。一度に一つだけ変えましょう。一度きりの最良のデモを生んだものではなく、セットでより良い成績を出すバージョンを残しましょう。これは華やかではなく、そしてそれがすべてです。実際の二十のケースで勝つプロンプトは、一度だけ目を奪ったものに勝ります。

ほぼ無視してよいこと

出回っている助言の多くはノイズです。明確さなしに長さを足す手の込んだ「ペルソナ」、迷信的な言い回し、無関係なタスク間でコピーされた硬直したテンプレート。どれも信頼できません。ある手法が望む出力をより起こりやすくするという観点で説明できないなら、自分自身の評価で証明されるまでは俗説として扱いましょう。

まとめ

良いプロンプティングはトリックの袋ではありません。明確さ（何をどんな形で望むかを正確に言う）、実演（例を見せる）、構造（指示を入力から分ける）、そして計測（実例に対して反復する）です。これらの基本は、システムがコンテキストを使うやり方に逆らうのではなく沿って働くので、何世代ものモデルを生き延びてきました。よく習得すれば、それより凝ったものはめったに必要ありません。