「試したときはよさそうだった」というのが、プロンプトのリグレッションの大半が本番に届く経路です。プロンプトのテストと評価は、それを証拠に置き換えます。固定された入力のセット、正しい出力の定義、そしてプロンプトが変わるたびに実行されるチェックです。
この 2 つの用語は重なります。評価とは、プロンプトやその出力がどれだけ良いかを測ることです。テストとは、その測定を自動で実行し、しきい値に届かなければ失敗させることです。
評価できる 2 つのもの
プロンプト自体。 書かれたままで、明確で、完全で、一貫していて、安全か。これは静的解析です。モデルの呼び出しが不要なので、即時で、無料で、毎回同じ結果になります。
モデルの出力。 このプロンプトとこの入力で、答えは正しいか。これにはモデルの呼び出しと、結果を判定する手段が必要です。
両者は別の問題を捉えるので、優れたプロセスでは両方を使います。静的チェックはキー入力のたび、コミットのたびに実行します。出力の評価は、変更が挙動に影響しうるときに実行します。
第 1 層：プロンプトの静的チェック
静的チェックはプロンプトのテキストを読み、既知の欠陥を探します。
- 目的が書かれていない、または出力形式がない。
- 曖昧な言葉や、数値のないサイズ指定。
- 互いに矛盾する、または重複する指示。
- 区切られていないテンプレート変数。
- インジェクションの文言、認証情報、個人データ。
- トークン数が予算を超えている。
これが PromptFlowEngine のプロンプト評価の行うことです。スコアは 100 から、検出 1 件あたりの固定ペナルティ（重大は 30、警告は 10、情報は 3）を引いたもので、重大な検出が 1 つでもあれば 50 が上限となり、8 つの各ディメンションで同じ計算を行います。計算式が公開されているため、スコアの変化は必ず特定の検出に遡れます。
静的スコアは、モデルの答えが正しいかどうかは教えてくれません。プロンプトがモデルに公平な機会を与えているかどうかを教えてくれます。
第 2 層：テストセット
テストセットは、期待値付きの入力のリストです。小さく始めましょう。
| ケースの種類 | 理由 |
|---|---|
| 典型的な入力 | 主要な経路が動くことを確認する |
| エッジケース | 空、非常に長い、言語違い、形式不正 |
| 敵対的な入力 | 指示を上書きしようとする試み |
| 過去の失敗 | 見つかったバグはすべて恒久的なテストになる |
よく選んだ 20 件は、ほぼ重複する 200 件に勝ります。可能なら、個人データを除いた実際のトラフィックから選びましょう。
第 3 層：出力が合格かどうかの判断
その性質を判定できる、最も安価な方法を使います。
コードによるアサーション。 決定的で無料です。可能な限り使いましょう。
- JSON としてパースでき、スキーマに合致する。
- 特定の文字列を含む、または含まない。
- 長さが範囲内に収まる。
- ラベルが期待するラベルと等しい。
- 数値の答えが許容範囲内にある。
参照との比較。 既知の良い答えと、完全一致または類似度で比較します。抽出や分類には向きますが、自由記述には弱いです。
モデルによる採点。 2 つ目のモデルが、ルーブリックに照らして出力を判定します。コードでは確認できない性質、つまり出典への忠実さ、トーン、網羅性に使います。
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
モデルによる採点者自体もプロンプトであり、独自の失敗モードがあります。各ルーブリックは 1 つの問いに絞り、判定の前に根拠を出させ、信頼する前に人間の判断のサンプルと照らして採点者を確認します。
人間によるレビュー。 基準となる方法で、最もコストがかかります。自動の方法を較正し、本番出力のサンプルをレビューするのに使います。
追跡する価値のある指標
| 指標 | 分かること |
|---|---|
| 合格率 | 期待を満たしたテストケースの割合 |
| 形式の妥当性 | パースできた出力の割合 |
| 忠実性 | 与えられた文脈で裏付けられた回答の割合 |
| 拒否の正確さ | 断るべきものを断り、答えるべきものに答える |
| 一貫性 | 同じ入力を繰り返し実行したときの一致度 |
| トークンと遅延 | 得ている品質のコスト |
合格率は、ケース数と一緒に報告します。10 件中の「90%」は、失敗 1 件です。
非決定性への対処
同じプロンプトと入力でも、異なる出力が出ることがあります。次のように対処します。
- 一貫性が必要なタスクでは、温度を低く設定する。
- 各ケースを複数回実行し、単一の結果ではなく合格率を報告する。
- 正確なテキストではなく、性質（「返金期間に触れている」）に対してアサートする。
- モデルのバージョンを固定し、変わったらスイートを再実行する。
CI でのリグレッションテスト
テストは、自動で実行されて初めてあなたを守ります。
コミットごと： 静的チェック。高速で、API キーも不要です。プロンプトテストゲートは、プロンプトファイルが最低スコアを下回る、トークン上限を超える、あるいは漏えいしたキーのような重大な検出を含む場合に、プルリクエストを失敗させます。
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
プロンプトやモデルの変更時： 合格率のしきい値付きの、出力テストセット。
スケジュールで： プロバイダー側の変更を捉えるため、本番のモデルに対して全セットを実行。
PromptFlowEngine は、このうち最初のものをカバーします。モデルに対してプロンプトを実行することはしません。出力の評価には、独自のテストランナーとモデルへのアクセスが必要です。
2 つのバージョンを比べる
草稿を比べて選ぶときは、同じ入力で比較し、合計だけでなく何が変わったかを見ます。どのケースが合格から不合格に変わったか、トークンがどう動いたか、新しい問題が加わっていないか、です。ワークスペースの比較ビューは、2 つのプロンプト間の品質、トークン、コストの差を報告し、各バージョンが解消または新たに生じさせた検出を一覧にします。
始めるための最小限のプロセス
- 静的チェックを実行し、警告を修正する。
- 期待値付きのテストケースを 20 件書く。
- 形式と必須の内容に対するコードのアサーションを追加する。
- ベースラインの合格率を記録する。
- 静的チェックでプルリクエストをゲートする。
- プロンプトまたはモデルが変わるたびに、テストセットを再実行する。
これらの結果をプロンプトの改善に使う方法は、プロンプトの最適化を参照してください。バージョンと結果を整理しておく方法は、プロンプト管理を参照してください。