テストデータ
プロンプトのテストケース
Prompt test case
意味
プロンプトをチェックするために使用される、定義された入力、コンテキスト、期待される動作、および評価ルール。
使用場面
通常のリクエスト、エッジケース、あいまいな入力、および予期される拒否のケースを作成します。
活用例
入力: アカウントIDがありません。期待される動作: IDを推測せずに、IDを要求する。生成AIエンジニアリング
プロンプトテストケースの構築、制御されたバリアントの比較、失敗の分析、回帰の防止、および品質、遅延、およびコストのバランスの取り方を学習します。
16 件
テストデータ
Prompt test case
プロンプトをチェックするために使用される、定義された入力、コンテキスト、期待される動作、および評価ルール。
通常のリクエスト、エッジケース、あいまいな入力、および予期される拒否のケースを作成します。
入力: アカウントIDがありません。期待される動作: IDを推測せずに、IDを要求する。テストデータ
Golden dataset
代表的なテスト入力と、信頼できる期待される結果またはスコアリングガイドラインをまとめたコレクション。
リリース全体でプロンプトの変更を一貫して比較するために使用します。
実際の利用状況の変化に合わせてデータセットを更新し、安定した回帰サブセットを維持します。
期待されるカテゴリ、必要な情報、および禁止事項を含む、レビュー済みのサポートケースを200件保持します。実験
Baseline prompt
比較の参照点として使用される現在の、または最も単純なプロンプト。
最適化する前に記録することで、改善点が測定可能になります。
Baseline v12 は、プロダクションモデル、デフォルトパラメータ、および変更されていない検索設定を使用します。実験
Prompt variant
基準となるものに対してテストされる、代替プロンプトの表現、構造、サンプルセット、モデル、または推論設定。
結果を再現および安全にプロモーションできるように、名前とバージョンのバリエーションを使用します。
Variant Bでは、制約をソースの後に移動させ、1つの負の例を追加します。実験
Controlled experiment
関連する入力と設定を一定に保ちながら、意図された要素を1つ変更する比較。
観察された違いを、モデル、データ、またはサンプリングではなく、プロンプトの変更に帰属させるために使用します。
指示の表現のみを変更し、データセット、モデルのバージョン、温度、および評価器は固定します。実験
A/B test
類似したトラフィックまたはテストサンプルに対して、2つのプロンプトまたは構成のバージョンを比較する実験。
プロダクションの動作とユーザーの結果を比較する必要がある場合は、オフラインチェック後に使用します。
資格ルール、監視、および停止条件によってユーザーを保護します。リスクの高いワークフローは、レビューなしには公開しないでください。
資格のあるリクエストをランダムに A または B にルーティングし、タスクの成功率、修正、レイテンシ、およびコストを比較します。実験
Prompt ablation
貢献度を測定するために、プロンプトのコンポーネントを1つ削除または置き換えます。
品質を向上させずにコストがかかる、不要な指示、例、またはコンテキストを特定するために使用します。
3番目の例を削除し、他のすべてのコンポーネントは変更しません。評価
Batch evaluation
準備された多くのケースに対してプロンプトを実行し、ケースごとの結果と全体的な結果を集計します。
手動でのスポットチェックが、代表的なパフォーマンスと誤認される前に使用します。
すべてのプロンプトバリエーションを固定評価セットで実行し、ケースごとの失敗をエクスポートします。評価
Prompt regression
以前は機能していた動作が、プロンプト、モデル、検索、ツール、またはポリシーの変更によって悪化するもの。
安定したテストスイートを使用して追跡し、リリースごとに結果を比較します。
新しい簡潔な形式は、長さを改善しましたが、必要なソースIDを含めることができなくなりました。信頼性
Robustness test
現実的な変動、ノイズ、言語、およびエッジケースにおいて、許容可能な動作が維持されるかどうかをテストする。
パラフレーズ、並べ替えられたコンテキスト、タイプミス、欠落したフィールド、および敵対的に混乱させる入力を試します。
同じ意図を、フォーマル、会話的、スペルミスのある、および多言語の表現でテストします。信頼性
Sensitivity test
入力または構成の詳細がわずかに変化したときに、出力がどの程度変化するかを測定するテスト。
テキスト、例の順序、温度、コンテキストの配置、およびモデルのバージョン変更に使用します。
同じ証拠を、最初から中間に移動し、引用の正確性を比較します。信頼性
Failure taxonomy
プロンプトの失敗をラベル付けおよび分析するために使用される、一貫したカテゴリのセット。
大規模な評価を行う前に、これを定義することで、チームは失敗の数を数えるだけでなく、原因を特定することができます。
ラベル:事実の欠落、サポートされていない主張、スキーマエラー、誤ったツール、危険な情報開示、過度の遅延。評価
Acceptance threshold
プロンプトのバージョンがリリースされる前に満たす必要がある、あらかじめ定義されたスコアまたはルール。
リスクに基づいて閾値を設定し、必ず失敗しないケースを含め、平均値だけに依存しないようにします。
必須フィールドの精度が98%以上で、重要なプライバシーの問題が発生しない場合にのみリリースします。評価
Model and parameter matrix
モデルのバージョンと推論設定間でプロンプトを比較する計画されたグリッド。
モデルの移行やパラメータ変更後、プロンプトの動作が異なる可能性がある場合に、使用します。
サポートされている2つの温度設定で、モデルAとBでプロンプトv8を評価します。効率
Quality, latency, and cost comparison
各候補のタスク品質、応答時間、およびリソース使用状況に関する総合的なビュー。
わずかに優れたプロンプトを選択することを避け、そのプロンプトがワークロードに対して遅すぎたり高価すぎたりしないようにするために使用します。
合格率、p95レイテンシ、入力トークン数、出力トークン数、および成功したタスクあたりの推定コストを比較する。効率
Prompt optimization loop
目標の定義、ベースラインのテスト、失敗の分析、プロンプトの変更、および再テストの反復サイクル。
小さな、実証に基づいた変更を使用し、各イテレーションでバージョン管理された結果を保持してください。
Define metric -> run baseline -> label failures -> change one component -> rerun -> review regressions.| ステップ | 必要な証拠 |
|---|---|
| ターゲットを定義する | ユーザーの成果、品質基準、リスク、レイテンシ、およびコスト制限 |
| ベーラインを確立します。 | バージョン管理されたプロンプト、モデル、設定、データセット、およびケースごとの結果。 |
| 変更をテストする | 制御されたバリエーション、必要に応じて繰り返し実行、および失敗ラベル |
| リリースまたは拒否 | 許容閾値、回帰レビュー、人間の承認、およびロールバック計画 |
わずかな例では、一般的な失敗、エッジケース、バリエーション、および回帰が見逃される可能性があります。 結論を導く前に、代表的なケース、安定したスコアリングルール、ケースごとのレビュー、およびバッチ結果を使用してください。
いいえ。必要な事実、groundedness、形式の有効性、安全性、堅牢性、レイテンシ、トークン使用量、コスト、および人間の修正の労力など、タスクを反映するメトリックを選択してください。
因果的な診断を行う場合は、一度に主要な要因を1つずつ変更します。 より広範な候補の比較では、いくつかのコンポーネントを変更できますが、これにより、どのコンポーネントが違いを引き起こしたかではなく、どの完全な候補が優れているかがわかります。
プロンプトエンジニアリングを、定義された目的と体系的な評価を持つ、テスト主導型、反復的なワークフローとして説明する公式ガイド。
代表的なデータに対する制御されたプロンプトのバリエーションをテストし、測定可能な結果を比較するための公式ガイド。
明示的な指示、例、制約、出力スキーマ、および分解されたワークフローから始めます。
プロンプト固有の実験を、システム全体の品質、人間のレビュー、ベンチマーク、および運用メトリックと連携させる。
バージョンテスト済みの候補を選択し、承認された変更のみを適用します。
プロンプトインジェクション、プライバシー、有害なコンテンツ、公平性、およびレッドチームのケースをテスト戦略に含めます。