Prompt Engineeringを測る：何が出力を変えるのか

測定に入る前に、この後の半分を静かに説明してくれる事実を1つ。

モデルに記憶はありません。2回の呼び出しの間に、モデルは何も保持しません。あなたの前の質問も、自分の前の回答も、添付したファイルも、あなたがすでに2回尋ねたという事実も保持しません。すべての呼び出しは空の機械から始まり、その機械が知っているのは、あなたが今渡したtoken列だけです。

チャットUIで記憶に見えるものは、クライアントが会話全体を最初から、すべてのturnを再送しているだけです。モデルは毎回、それを最初から読み直します。第13章では、その再読がforward passでどれだけのコストになるかを測りました。第16章では、それを請求書の1行に変えます。ここで重要なのは設計上の帰結です。promptは、状態を持つシステムへのメッセージではありません。promptこそが状態です。

これで一群の混乱は退場します。「モデルが伝えたことを忘れた」は、たいていそれが送られていなかったという意味です。「前の指示を無視した」は、たいてい履歴が切り詰められたときにその指示がwindowから落ちたという意味です。「本番で挙動が違った」は、たいてい本番がテストしたものとは違うpromptを組み立てているという意味です。どれもモデルの問題ではなく、何かを書き換えて直るものでもありません。

「このpromptのほうが良い」という主張は、分布についての主張です。1つの出力を眺めても分布は見えません。必要なのは退屈なものです。正解が分かっているケース、N個のvariants、そして区間です。

harnessは50行のTypeScriptで、第14章のクライアントと同じ形をしています。リクエスト、締め切り、少しの並行処理、集計です。第19章ではretrieverの評価に、第29章ではgolden setとして再登場します。

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

返ってくる数字そのものは結果ではありません。結果はこれです。

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

第4章で論じたことを、この章で現金化します。20件中17件正解は85 %で、その95 %区間は64 %から95 %です。20件中13件正解のvariant、つまり65 %で、明らかに悪く感じるものでも、区間は43 %から82 %です。**この2つの区間は、ほぼ全長にわたって重なっています。**20件では良いpromptと平凡なpromptを見分けられません。そして公開されているprompt助言の多くは、それより少ない件数で検証されています。

この章で使う60件も、まだ多くはありません。大きな効果を見るには十分で、小さな効果が見えないときにそう認めるには十分に正直です。そして以下で何度も、それを認めることになります。

3つのブロック、つまりルールR、チケットT、指示Iを1つのuser messageに連結します。6つすべての順列、byte単位で同一の内容、それぞれ60件です。

最良から最悪まで28.3ポイント差があり、区間は重なっていません。つまり、これはノイズの話ではありません。すべてのarmが同じ60項目で採点されているので、より鋭い問いはpairedなものです。2つのarmが食い違うケースで、その分裂はどれほど偏っているのか。最悪の順序から最良の順序へ移ると、21件が正解に変わり、4件が不正解に変わりました。exact paired probabilityは0.0009です。³

表は勝者ではなく形として読んでください。上位2行はいずれもチケットで終わっています。下位2行は、指示を中央に埋めるか、データの後ろに垂らしています。これはLiuらがLost in the Middleと名付けた現象と同じです。promptの端にある材料は、中央にある材料よりも信頼して使われます。⁴ 第16章はwindowに価格を付け、第24章では長さがある場合にこの効果をきちんと測ります。そこでは説明どおり中央が崩れ、最後尾での回復は再現しません。ここでの実用ルールは自然に出てきます。タスクは上、データは下、重要なものは中央に置かない。

次に、同じ言葉をturnの間で移します。第11章では、chat templateはモデルの周りの飾りではなく、モデルの一部だと示しました。<|im_start|>systemと<|im_start|>userは、fine-tuning中にモデルがまさにその位置で何百万回も見た実tokenです。だから、あなたの指示がそれらのmarkerのどちら側に置かれるかは重要であるはずです。そして実際に重要です。

ルールと指示をtemplate境界の向こうへ移すだけで、21.7ポイントを買えました。19件が改善し、6件が悪化し、paired probabilityは0.0146です。文字は1つも変えていません。これは、system promptとuser promptへの具体的な答えです。これらは同じことを言う2つの方法ではありません。モデルが訓練された構造の中の、2つの異なるtoken位置です。そして会話全体に適用される指示が置かれるべき場所はsystem位置です。

3行目にも注目してください。チケットの後で指示を繰り返す、広く推奨される小技は、一度だけ述べるより低いスコアでした。このモデル、このタスクでは、2回言うことは1回言うことより悪かったのです。

同じprompt、最良の配置、60件です。変わるのは、チケット本文を何で囲むかだけです。

句読点だけで18ポイントの幅です。しかし両端の区間を見てください。[73.9, 91.9]と[54.1, 77.3]です。**重なっています。**雑な読み方、つまりerror barを比べ、触れていたら何も言わない、という読み方では、この表は何も証明していません。

ここではその雑な読み方が間違っています。その理由を理解することは、表そのものより価値があります。すべてのvariantは同じ60件のチケットで採点されているため、2つの測定は独立サンプルではありません。pairedです。各区間の幅の多くは、両方のarmが共有する不確実性、つまりこの60件が代表的かどうかから来ています。そしてその源は、互いに比較すると相殺されます。代わりにpairedな問いを立てると、答えは鋭くなります。二重引用符からXMLタグに変えると、12件が正解に変わり、1件が不正解に変わりました。paired probabilityは0.0034です。これは本物の差です。

そして同じテストが見出しをしぼませます。XMLタグは素のTicket:ラベルを8.3ポイント上回りました。ブログ記事ならタイトルに載せる数字です。pairedでは、6件改善、1件悪化、probability 0.1250。確立されていません。その有名な改善は7件に乗っています。

つまり、2つの問いには2つの異なる道具があります。それらを混同することが、prompt助言を両方向に同時に間違わせます。

一般的な発見、つまりモデルが意味内容を持たないformatting choicesに強く、そして予測不能に敏感であることは新しくありません。Sclarらは、数十のタスクにわたって区切り、空白、大文字小文字だけを変え、公開モデルランキングを逆転させるほど広いaccuracy差を見つけました。⁵ 実用上の帰結は「XMLタグを使え」ではありません。formattingはhyperparameterであり、sweepしてもコストはゼロであり、1つのformatを固定して2つのモデルを比較することは、モデルと同じくらいformatを比較している、ということです。

In-context learning、つまりworked examplesをpromptで見せ、weight updateなしにモデルにそれらから汎化させる能力は、GPT-3を有名にした能力です。⁶ 実用上の問いは、それが機能するかどうかではありません。何個の例にお金を払うべきかです。

例は実際のprior turnsとして、userとassistantを交互に並べて入れます。それがtemplateが訓練された構造だからです。各kは、ラベル付きチケット16件の独立したpoolから5つの異なるrandom drawsで実行されました。

2つの例で7ポイントを買いました。次の6つの例は、測定できるものを何も買いませんでした。83.7、次に81.7、次に83.7で、自分自身のノイズの中を歩き回っています。16個でさらに5.5ポイント買いました。曲線はなめらかに上昇しません。段差、plateau、そして段差です。

もっとも重要なのは最後の列です。k = 8では、たまたま選んだ8つの例がaccuracyを10ポイント動かしました。これは2例から8例へ増やした全体のgainより大きい値です。そして最下行がそのもっとも鋭い形です。k = 16ではpoolを使い切っているため、5回のrunすべてがまったく同じ16例を含み、違うのは並び順だけです。順序だけでaccuracyが8.3ポイント動きました。

これはLuらが報告した結果であり、探されたところではどこでも生き残っています。例の順序は、例の数に匹敵する効果を持つ本物のhyperparameterです。⁷ したがって、few-shot promptingについての正直な助言は数ではありません。こうです。

次は民間伝承です。それぞれ、他は同一のsystem promptの先頭に追加した1文で、同じ60件で測っています。

5つのうち4つは何もしませんでした。「少し効いた」のではありません。60件のpaired casesで見えるものは何もありませんでした。expert personaと賄賂はいずれも手つかずのbaselineを下回り、その低下でさえpaired testを通りません。下向きのノイズです。

じっくり見るべきは3行目です。「これは私のキャリアにとって非常に重要です」はまったく同じaccuracy、60件中46件を生みました。そして60件中10件の答えが変わりました。5件ずつ両方向です。summary statisticは同一でも、挙動は同一ではありません。評価が小さなセット上の単一の数値なら、出力の6分の1を書き換える変更が、何もしなかった変更のように見えることがあります。そしてあなたは、それが無料だったと信じてshipしてしまいます。

そして脅しです。針を動かした唯一の文であり、しかも35ポイント下へ動かし、24件を正解から不正解へ反転させました。これは丸め誤差ではありません。別のモデル挙動です。教訓は「モデルを脅すな」ではありません。感情的なframingは不活性ではない、ということです。それは分布を動かします。ときに大きく、しかも文を読んでも誰にも予測できない方向にです。だからこそ、推論で語るのではなく測らなければなりません。

この章があなたに負っている但し書きがあります。この5文は、1つの小さなモデルと1つのタスクでテストされました。一部には他所での公開された支持があります。「深呼吸して」は、高スコアの指示を発明ではなく探索した論文から出たもので、後に流通した主張とは別の、より良い主張です。⁸ 一般化するのは文そのものではありません。ブログ記事で生き残ったリストと、測定で生き残るリストは別物であり、あなたが手にしているのがどちらかを知る唯一の方法はベンチを走らせることだ、という点です。

誰もが繰り返すルール、つまり望まないことではなく、望むことを言え。いつものように数値はありません。ここに数値があります。同じformat要件を3通りに書き、complianceを観察できるようモデルに自由生成させました。

3つの禁止は1つの指示より悪く、モデルに5倍多くのテキストを書かせました。3つの禁止すべての正反対です。肯定文を戻すと68 %まで救われました。

第8章を思い出せば、仕組みは謎ではありません。モデルは、それ以前のすべてを条件とした分布からnext tokenを選びます。そして禁止は、禁じられたものをそのconditioningの中に置きます。否定の演算子はありません。あるのは、その語がいま現れているcontextです。

これは直接測れます。baseline promptに1行を追加します。Do not use the shipping queue for software problems. 次に、shipping ticketsではない45件だけを見ます。

除外するためにキュー名を挙げると、モデルはそれを3倍多く選び、そのキューに割り当てるprobability massはほぼ3倍になり、overall accuracyは25ポイント失われました。baselineに対して16件悪化、1件改善、paired probabilityは0.0003です。

象のことを考えないでください、を測った結果です。書き換えは常に同じです。禁止を、それを不要にする肯定ルールへ置き換えます。「ソフトウェアの問題にshippingを使わない」ではなく、「物理的な小包が関係するときだけshippingを使う」です。

第12章では、chain of thoughtを正しく組み立てました。まずprompting技術として、⁹¹⁰ 次にverifiable rewardsで訓練されたものとしてです。そして、この章まで先送りした警告で終えました。モデルが自分でreasoningするようになると、step by stepで考えろと命じても助けにならなくなり、害になることがあります。ここでは、その警告に表を添えます。より多く考えるほど良いはずだと想定しやすいタスクです。

両方のarmは、同じ位置で同じinstrumentによって読まれます。違いは、モデル自身が書いたchain of thoughtが先にcontextに入っているかどうかだけです。

accuracyは下がり、コストは上がりました。そしてこの章自身のルールは、この章自身の結果にも適用されます。低下は7件改善に対して10件悪化、paired probability 0.629で、確立されていません。確立されているのは、1呼び出しあたり98個の追加output tokensを生み、それで測定可能なものを何も買えなかったことです。不確実性はすべてbenefit側にあります。請求は確実です。

失敗したchainは、成功したchainより教訓的です。*「あなたのSlack integrationは火曜日以降メッセージの投稿を停止しました」*についてreasoningするよう求めると、モデルはこう書きました。

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

これは有能なトラブルシューティング助言ですが、タスクではありません。考えるよう求められたモデルは、「このサポートチケットについてstep by stepで考える」に訓練データ上もっとも似ているジャンルへ漂流しました。そしてclassification問題に、5百文字の無関係なreasoningを自分自身のcontextに入れてから答えました。chain of thoughtが助けになるのは、計算する価値のある中間状態がある問題です。算術、multi-hop lookup、制約充足です。文を4つのbucketの1つに振り分けることには、中間状態がありません。chainが保持するものは何もないため、最終判断が生き残らなければならないもっともらしいテキストを足すだけです。

実用上の帰結が2つあります。第一に、reasoningするよう訓練されたモデル、第12章のRLVRモデルにとって、この指示は冗長どころか有害になり得ます。モデルが生成したはずの長いchainを、短くprompt風のchainで置き換えてしまうことがあるからです。そしてself-consistencyが行うように、複数のchainをsamplingして投票しても、意見が分かれるものがないタスクは救えません。存在しないtieを解くために、サンプル数だけコストを掛け算するだけです。第12章では、それが当てはまる場面でそのtradeを測りました。第二に、比較の足場そのものが何を犠牲にしたかに注目してください。回答をFinal queue:行に押し込むと、reasoningなしのarmは76.7 %から61.7 %に落ちました。2つのarmを比較可能にするために支払った15ポイントです。あなたの都合のために存在する構造も、無料ではありません。

最後にもう1つ測定します。最初の驚く結果の後で誰もが尋ねる問いだからです。60個のprompt、greedy decoding、繰り返し実行です。

• すべてを固定して同じ呼び出しを繰り返すと、bit-identicalなprobabilitiesが返りました。決定論的です。
• 同じ呼び出しを異なる隣人とbatch化すると、batch sizes 1、4、12、30、60で、probabilitiesは最大0.0128異なりました。選ばれたラベルは60件中0件でしか変わりませんでした。

ラベルが生き残ったのは、余裕があったからです。60件全体で、上位2つのキュー間の最小gapは0.0459で、driftの3.5倍でした。安定性はalgorithmの性質ではありませんでした。marginでした。そしてmarginは尽きます。第17章では、算術上の理由を扱い、それらのgapを広げたり狭めたりするsampling knobsを分解します。ここに植えておく理由は、あらゆるprompt測定が何を意味し得るかに上限を与えるからです。ベンチが測っているのは、許容差までしか再現できないシステムであり、variants間の2ポイント差は、悪い日にはその許容差の内側にあります。

ここまでのすべては、人間がvariantを選び、機械が採点するものでした。明らかな次のステップは、variantの選択も機械に任せることです。

APEはまさにそれを行います。モデルが候補指示を提案し、それらをheld-out examplesで採点し、最良のものが生き残ります。⁸ 見つかる指示は、人間なら書かないものがよくあります。それがポイントです。探索はプロらしく聞こえるものではなく、スコアが出るものを対象にしています。

DSPyはさらに進み、プロダクトにとってより有用な考え方です。¹¹ パイプラインの各ステップが何を受け取り何を返すかを宣言すると、frameworkがそれをpromptsへcompileし、demonstrationsを選び、あなたのmetricに対して指示をoptimiseします。モデルを変えたら、書き換える代わりにrecompileします。promptは誰かが手で調整するsource codeではなくなり、metricに対して生成されたartefactになります。そもそも最初からそうあるべきでした。

どちらもベンチの必要性を消しません。むしろベンチを唯一必要なものにします。metricのないoptimiserは何もoptimiseしないからです。

残るのは規律です。promptsはversion controlの中に、ファイルとして、それを送るコードの隣に置かれるべきです。火曜日に誰かが編集したdatabase rowではありません。生成したすべての出力と一緒に保存されるversion identifierが必要です。そうしなければ、何かがregressした日に何が変わったのか分かりません。CIにベンチが必要です。promptは、vendorが新しいモデルをdeployすることで静かに無効化できる、システム内の唯一の部分だからです。そしてケースが必要です。巧妙な100件ではなく、前四半期に壊れた退屈な20件を、永遠に保持するのです。deliverableはベンチです。promptはその副産物です。

この章のすべてはaccuracyで測られました。それらのvariantsのすべてには価格もあります。

21.7ポイントを買ったsystem promptは、すべての呼び出しで永遠に送られます。7ポイントを買った2つの例は、すべての呼び出しで永遠に送られます。12ポイントを買った16例は、すべての呼び出しで永遠に送られ、ユーザーが実際に尋ねた質問のおよそ10倍の長さです。何も買わなかったchain of thoughtは、1リクエストあたり98個の追加tokensを生成しました。そしてoutput tokensは高価な種類です。

そのどれもaccuracyの表には見えません。そしてそのすべてが請求書には見えます。

第16章は、それらの判断が実際に建て付けられている単位についてです。billing unitとしてのtoken、記憶ではなくbudgetとしてのcontext window、40 turnの会話が最初のturnの40倍をはるかに超えて高くなる理由、prompt cachingが何に支払い何に支払わないのか、そしてpromptの順序がcache hitの有無を決める理由です。これは、安定した材料を先に、可変の材料を最後に置く、まったく別の経済的理由になることが分かります。

ベンチとすべての表は、greedy decoding下でQwen/Qwen2.5-0.5B-Instructを使って作られたため、正確に再現できます。Hugging Faceのchat templates documentationは、第11章のtemplate markersが実際に何へ展開されるか、そして誤ったtemplateを付けて出荷されたモデルが現実の反復的な失敗であることのreferenceです。本番規模でのpositionとformat effectsについては、上の引用がprimary sourcesです。vendorのprompting guidesは例として有用ですが、どれも区間を公開していないことを知ったうえで読むべきです。