Codex use case
AI アプリケーションへの評価の追加
Codex を使って、期待される動作を Promptfoo 評価スイートに変換します。
Codex に AI アプリケーションを調査させ、評価対象の動作を特定し、実行可能な Promptfoo 評価スイートを追加してもらいます。
最適な用途
- プロンプト、モデル呼び出し、ツール、検索、エージェント、プロダクト要件のいずれかはすでにあるものの、反復可能な評価スイートがない AI アプリケーション
- モデル、プロンプト、検索、エージェントの変更を準備しており、Pull Request がマージされる前にリグレッションテストを行いたいチーム
- 繰り返し行う手動チェックを、リポジトリにコミットする評価ケースへ移行する必要がある品質レビュー
Contents
AI アプリケーションへの評価の追加
Codex を使って、期待される動作を Promptfoo 評価スイートに変換します。
Codex に AI アプリケーションを調査させ、評価対象の動作を特定し、実行可能な Promptfoo 評価スイートを追加してもらいます。
Codex に AI アプリケーションを調査させ、評価対象の動作を特定し、実行可能な Promptfoo 評価スイートを追加してもらいます。
関連リンク
最適な用途
- プロンプト、モデル呼び出し、ツール、検索、エージェント、プロダクト要件のいずれかはすでにあるものの、反復可能な評価スイートがない AI アプリケーション
- モデル、プロンプト、検索、エージェントの変更を準備しており、Pull Request がマージされる前にリグレッションテストを行いたいチーム
- 繰り返し行う手動チェックを、リポジトリにコミットする評価ケースへ移行する必要がある品質レビュー
スキルとプラグイン
- 評価スイートの作成、接続、実行、品質確認に使用する `$promptfoo-evals` と `$promptfoo-provider-setup` を含むプラグインです。
| Skill | Why use it |
|---|---|
| Promptfoo | 評価スイートの作成、接続、実行、品質確認に使用する `$promptfoo-evals` と `$promptfoo-provider-setup` を含むプラグインです。 |
開始用プロンプト
はじめに
AI アプリケーションを構築したり、既存のアプリケーションを変更したりするときは、想定どおりに動作することを確認する必要があります。評価は、一連のシナリオを体系的にテストし、リリース前にリグレッションを検出するための手段です。
Promptfoo を使って AI アプリケーションの評価を実行し、Codex を使って評価の作成と保守を支援できます。
利用方法
Codex で Promptfoo プラグインの $promptfoo-evals スキルを使用し、AI アプリの 1 つの動作を反復可能な評価スイートに変換します。アプリに使用可能な Promptfoo ターゲットがまだない場合は、$promptfoo-provider-setup を使って、テスト対象のアプリケーションパスにスイートを接続できます。
Codex はアプリを調査し、有用性の高いケースを提案し、Promptfoo の構成とテストデータを追加して、スイートをローカルで実行できます。さらに、継続的に使えるコマンドも提示します。
このユースケースは、対象の動作が具体的であるほど効果的です。たとえば、サポート回答の品質、検索結果に基づくグラウンディング、分類器のラベル、ツール呼び出し、JSON の構造、ビジネスルール、プロンプトやモデルを安心して移行できるかどうかなどです。
最初の段階では、レビュー可能なコードとテストデータを用意することが重要です。具体的には、promptfooconfig.yaml または同等の構成ファイル、小規模な evals/ ディレクトリ、テストケース、アプリを呼び出すために必要なターゲットアダプター、npm run evals のようなローカルコマンドを用意します。
評価対象の選択
まず、ユーザー向けに保証している動作を 1 つ選びます。一度に AI システム全体を評価するよう Codex に依頼するのは避けてください。小規模なスイートの方が、信頼性を確かめやすく、レビューと継続実行も容易です。
最初の評価対象として適しているものは、次のとおりです:
- 正確性: 分類、抽出、要約、ルーティング、変換
- グラウンディング: 取得したドキュメントや引用元に基づくべき回答
- ツールの使用: 適切なツールの選択、有効な引数の受け渡し、ツールエラーへの対処
- 形式またはビジネスルール: JSON スキーマ、フィールド名、ビジネスルールによる制限、UI 向け文言の仕様
- プロンプトまたはモデルの移行: 新しいプロンプト、モデル、システムメッセージ、検索設定によって重要なケースに問題が生じないことの確認
プロダクト要件、バグレポート、サポート部門からのエスカレーション、またはチームが安心してリポジトリにコミットできるようサニタイズした例から始めます。
評価プランの作成を依頼
Codex には編集前に調査させます。対象のパス、フィクスチャ、アサーション、アダプター、コマンドを明記したプランを依頼してください。これにより、ファイルを追加する前に、対象の誤りや不十分なテストケースに気づけます。
実装前にプランをレビューしてください。プランには、Promptfoo が呼び出すアプリのパスまたはエンドポイント、最初のシードケース、アサーション、Codex が作成するファイル、ローカルコマンド、必要なシークレットやサービスを明記する必要があります。ユーザーがアクセスするアプリケーションパスではなく、モデル自体を直接テストするプランになっている場合は、それが意図したものか Codex に確認してください。
実装、実行、反復的な改善
プランに問題がなければ、Codex に実装を依頼します。最初の実装は、あえてシンプルなものにします。構成、ケース、フィクスチャ、必要に応じたターゲットアダプター、コマンド、そのコマンドが実行された証拠だけを含めます。
アプリを実際に呼び出す小規模なスイートは、次のようになります:
evals/
promptfooconfig.yaml
tests/
cases.yaml
providers/
provider.js # only if the built-in provider cannot call the app directly
動作を変更する前にスイートを実行してください。ベースラインを確認すれば、アプリが対象のケースですでに失敗しているのか、アサーションの調整が必要なのか、ターゲットアダプターが誤っているのかを判断できます。アサーションが変更に弱すぎる場合や曖昧すぎる場合は調整します。ただし、実際のプロダクト不具合まで見えなくならないようにしてください。
初回実行後は、スイートを使って、リリース前にアプリの変更前後を比較します。バグ、ローンチ要件、プロダクトレビューを通じて、今後も安定させたい動作が見つかるたびに、新しいケースを追加してください。ローカルコマンドが安定したら、そのコマンドを CI またはリリースチェックリストに追加するよう Codex に依頼します。