プロンプトをコードのようにテストする

プロンプトは本番で走り、ユーザーが目にするものを形作るロジックの一片です。一度だけ、一つの入力で走らせ、出力を目視して良しと宣言する関数を、私たちが出荷することは決してないでしょう。ところが、ほとんどのプロンプトはまさにそのように開発されます。言い回しを微調整し、目の前の例で試し、何か良さそうなものを見て、出荷する。本ガイドは、私たちがすでにコードに使っている規律——テストケース、ベースライン、回帰チェック——をプロンプトに適用することについてです。なぜなら、プロンプトはそれに値し、それなしには壊れるからです。

なぜデモはあなたに嘘をついているのか

プロンプト作業で最も危険な習慣は、一つの印象的な出力でプロンプトを判断することです。プロンプトを書き、選び抜いた入力で走らせ、すばらしい答えを得て、終わった気になる。しかしその一つの入力は、実際のユーザーが送ってくるものの幅を代表していません。次の入力——別の言い回し、欠けたフィールド、より長い、より奇妙な——はゴミを生むかもしれず、ユーザーが代わりに見つけてくれるまであなたは気づきません。

デモが誤解を招くのは、一回のパスがコードで誤解を招くのと同じ理由です。それはあなたが念頭に置いた幸せな道筋をテストするだけで、念頭になかったケースはテストしません。プロンプトはとくにこれに陥りやすい。なぜなら、出力は間違っているときでさえ流暢で自信に満ちており、悪い結果ももっともらしく読めるからです。唯一の防御は、個々の出力を信頼するのをやめ、実際に現実に似た入力の集合にわたって振る舞いを測定し始めることです。

現実に似たテストセットを作る

プロンプトのテストは、代表的な入力の集合——テストケースに相当するもの——を組み立てることから始まります。実利用があるならそこから引き、その集合が実際に見る多様性をまたぐようにしましょう。典型的なリクエストだけでなく、短いもの、不正な形のもの、エッジケース、そして「良い答えが存在しない」ケースも。簡単な入力ばかりのテストセットは、あなたのプロンプトが簡単な入力を扱えると告げるだけで、それはすでに知っていたことです。

入力ごとに、良い出力とはどのようなものかを決めましょう。ときには正確にチェックできる単一の正解があります。より多くの場合、「良い」は性質の集合です。正しい形式、関連する事実が含まれていること、何も捏造していないこと、失敗ケースが正しく扱われていること。何かを走らせる前に良いとは何かを書き留めることが、「良さそう」を本物の合否判断へと変えます。テストセットとその成功基準が、具体化されたプロンプトの仕様です。

出力をどう採点するかを決める

コードのテストはたいてい正確な等価性をチェックします。プロンプトの出力にはめったに唯一の正解がないため、それに合った採点アプローチが必要です。構造化された出力——特定の形式、必須フィールド、固定集合からの値——については、プログラムでチェックできます。パースできるか、フィールドがあるか、値が妥当か。これらのチェックは安く、自動化する価値があります。アプリケーションで最も重要な機械的な失敗を捕まえるからです。

オープンエンドな出力については、採点は判断に基づきます。答えが要点を押さえているか、捏造を避けているか、正しいトーンを当てているか。これは読むことで行えますし、小さな集合では読むことで十分で、過小評価されています。より大きな規模では、書いたルーブリックに対してモデルに出力を採点させるのが一般的なアプローチです——有用ですが、ルーブリックの良さに左右されるだけで、自分自身の読みに照らしてスポットチェックする価値があります。要は、「良さそう」に逃げ込むのではなく——それは手法ではありません——採点手法を意図的に選ぶことです。

何かを変える前にベースラインを確立する

プロンプトの改善を始める前に、現在のプロンプトを全テストセットに対して走らせ、その出来を記録しましょう。そのスコアがあなたのベースライン——あらゆる変更が測られる対象——です。ベースラインがなければ、あなたは盲目で飛んでいます。変更を加え、一つの出力が改善するのを見て、プロンプトが全体として良くなったのか悪くなったのか見当もつきません。一つのケースを直しつつ静かに三つを壊す変更は、進歩のように見えてその逆です。

ベースラインこそが、プロンプト作業をランダムウォークではなく累積的なものにします。各候補の変更は同じ集合に対して走らせ、ベースラインと比較されます。集合全体でより良ければ、それが新しいベースラインになります。より悪ければ、たとえ気に入った出力を一つ生んだとしても、破棄します。これが核となるループで、コードのリファクタリングを安全にするのと同じループです。いつでも照合できる、既知の良い基準点なのです。

一度に一つだけ変える

プロンプトの出来が悪いとき、半分を一度に書き直したくなります——新しい指示、新しい例、新しい形式、すべて一緒に。結果が良ければ、どの変更が効いたか分かりません。悪ければ、どの変更が害したか分かりません。どちらにせよ、転用できることは何も学べていません。一つの変数を変え、テストセットを走らせ、ベースラインと比較し、結果を記録する。それから次を変える。

これは反復あたりは遅く、全体としてははるかに速い。なぜなら、プロンプトが何に反応するかについての本物の知識を積み上げるからです。この例が形式の問題を直した、この指示が捏造を減らした、この再構成は何もしなかった、と学びます。その知識はプロジェクトをまたぎ、将来のプロンプトをまたいで複利で効きます。対照的に、散弾的な書き直しは、誰も理由を理解しておらず、後で誰も安全に変更できないプロンプトを生みます。

変更を出荷する前に毎回セットを再実行する

最後の一片は、テストセットを回帰スイートとして扱うことです。モデルは更新され、要件は移り、動いていたプロンプトが静かに失敗し始めることがあります——かつて扱えていたケースでさえ。プロンプトを変えるたび、そして理想的には変えていなくても定期的に、全セットを再び走らせ、何も後退していないことを確認しましょう。新しいケースを改善しつつ古いケースを壊す変更は回帰であり、それを捕まえる唯一の方法は古いケースを走らせ続けることです。

これは、土台のモデルが変わるときにもあなたを守ります。テストセットはあなたが実際に依存する振る舞いを符号化しているため、再実行すれば、新しいモデルバージョンが依然として要件を満たすのか、それとも静かに何かを壊したのかが即座に分かります。テストセットは持続的な資産になります——モデルの変化、チームの変化、そしてプロンプトがなぜそう書かれたかという記憶の緩やかな侵食を生き延びる、「動いている」の定義です。

まとめ

プロンプトを、それが実際にそうである本番コードのように扱いましょう。エッジケースも含めて実利用に似たテストセットを作り、入力ごとに良い出力が何を意味するかを書き留めること。採点手法を意図的に選び、何かを変える前にベースラインを確立し、そのベースラインに対して集合全体で測りながら、一度に一つの変数だけプロンプトを改善すること。セットを回帰スイートとして保ち、変更のたび、モデル更新のたびに再実行すること。プロンプトの民間伝承とプロンプトエンジニアリングの違いは、まさにこれです。一方は一つのデモで判断し、もう一方は集合にわたって測る——そして入力やモデルや要件が動いても動き続けるのは、後者だけなのです。