エージェント評価は、エージェントの構想と設計フェーズから始まり、エージェント展開や回帰検出を経て反復的なプロセスであるべきです。 このテンプレートは評価テストセットを構築するための重要な要素と、エージェントのライフサイクル全体を通じて4段階構造を実装・反復する方法を提供します。
- ステージ1:基礎的な評価テストセットの構築
- ステップ2:ベースラインを確立し、テストセットとエージェント命令を反復・洗練する
- 第3段階:体系的拡張(回帰、変動、診断、エッジケース)を実装する
- 第4段階:継続的な品質改善評価業務の確立
ヒント
編集可能なチェックリストテンプレートをダウンロードしてください。
ステージ1:基礎的な評価テストセットの構築
目標:エージェントのコアシナリオを評価する基礎的な評価テストセットを作成・実行すること。
評価 テストセット とは、テストケースの集合体です。 テストケースとは、エージェントが特定の質問に答えるかどうかを評価するための個別のプロンプトとレスポンスペアのことです。 テストプロンプトと、エージェント命令要件から直接現れるオプションの期待応答(アサーション)が含まれます。 テストケースは、品質を評価するための受け入れ基準と試験方法も明示すべきです。
| エージェントシナリオ1 | テストプロンプト (エージェントへのサンプル質問) |
予想される応答 | 受け入れ基準2 (成功した対応とは何かを定義してください:何が通過し、何が失敗しないか) |
|---|---|---|---|
| 代理人はポリシーに関する知識記事に基づいてポリシー内容に回答すべきです。 | 「従業員は病気休暇を何日取れるのですか?」 | 「30日間。 <引用文献>」 | 回答にはポリシー知識とテキスト照合の正確なテキストが含まれなければなりません。 回答には引用文が含まれなければなりません。 |
| 代理人は保険に関する知識記事以上の質問には答えるべきではありません。 人事の人間サポートへの直接的な回答。 | 「従業員は病気休暇を何日取れるのですか?」 | 「方針文書には病気休暇の日数は明記されていません。 病気休暇の方針については人事に相談してください。」 | 禁止された事例への対応は、人間の人事サポートに回されなければなりません。 |
ヒント
1エージェントシナリオ:基礎テストセットには、エージェントの主要なシナリオやユースケースをカバーするテストケースを含めるべきです。 エージェントのシナリオを指針として使い、エージェントが何を扱うか避けるべきかに焦点を当てましょう。 このプロセスはターゲットを絞ったテストプロンプトのリストを作成するのに役立ち、エージェント命令の開発と密接に連携させるべきです。 適切なテストケース数を決定するには、各主要シナリオに対して1つのテストプロンプトから始めましょう。 まずは少数のテストケースから始め、洞察を得てカバレッジを改善するにつれて反復・洗練させていきます。
2受け入れ基準:成功とは何かを明確に定義すること。 この定義は最初は難しいかもしれませんが、反復を通じて基準を洗練させることを検討してください。 テストプロンプトを実行し、応答を確認し、その質を評価するために「 主要な質問に答えているか?」と問いかけてみてください。正しい情報を使っていますか?トーンやスタイルは適切でしょうか?共有権限は尊重していますか? これらの質問からの洞察は、受理基準の確立や、必要に応じて期待される回答を確立するのに役立ちます。
ステージ2:基準を確立し、改善する
目標:評価を実施し、基準指標を設定してベンチマークし改善すること。
手動で評価を行うことも、専門的なツールを使うことも可能です。 手動評価の場合は、テストプロンプトをエージェントに送信し、応答を確認し、人間の判断で受理基準を満たしているか判断し、結果を記録します。 Microsoftは、 Copilot Studioのエージェント評価機能を含むエージェント評価ツールを提供しています。
基準を確立する
- 基礎テストセットをエージェントに対して実行してください。
- 各テストケースごとに合格か不合格かを文書化します。
- 全体の合格率を計算してください:______%。
- エージェントのバージョンと基準日を記録してください:___________。
根本原因分析と反復
評価結果を確認し、偽陽性と真陰性を特定してさらなる分析を行いましょう。 誤検知とは、合格とマークされているが人間の判断で不合格とされる答えのことです。 真の否定とは、正しく失敗と識別された答えのことです。 失敗した事例を二つの視点から評価します。
- テストケースの問題:テストのプロンプト、期待される答え、または受理基準が失敗の原因か?
- エージェント設計の問題:この失敗はエージェントの指示が不明瞭なのか、知識やツール設定の欠陥を示しているのか?
根本原因を特定し、テストケースの洗練やエージェント設計の改善によって改善しましょう。
ヒント
評価合格スコア:エージェントは確率的な性質のため、同じプロンプトに対して異なる応答を返すことができます。 このばらつきは、受理基準の厳しさによって回答の合格・不合格を左右することがあります。 信頼できる評価を確保するために、各テストセットを複数回実行し、平均成功率を計算してください。 ビジネスのニーズに応じて、現実的な合格率を80〜90%目指しましょう。
第3段階:体系的な拡張を実施する
目標:さまざまなエージェントの品質カテゴリーに関する包括的な評価スイートを構築すること。
第1および第2段階は、エージェントの主要なユースケースの基礎テストセットを確立しました。 次に、さまざまなエージェントの品質カテゴリーを評価するテストセットを作成し、評価範囲を広げましょう。 以下のリストは、品質の異なる側面に対応するカテゴリーを提案しています。
| 品質カテゴリー | 目標 |
|---|---|
| 基礎コア | 「必修」セットです。 展開時の必須応答品質を評価し、運用中に回帰検出を行います。 |
| エージェントのロバスト性 | あるエージェントの従来のソフトウェアに対するコアな価値は、さまざまなユースケースを扱う際の堅牢さにあります。 この価値には以下が含まれます:
|
| アーキテクチャテスト | エージェントの機能的パフォーマンスを評価してください。 寸法には以下が含まれます:
|
| 例外 | エージェントがガードレール付きのエッジケースをどのように扱うべきか。
|
ヒント
カテゴリー目的の参考:
- コアの故障:何かが壊れているか、動作していない。 最近の変更点を調べましょう。
- 堅牢性が失敗した場合:エージェントが厳しすぎる。 特定の表現に過度に焦点を当てているかもしれません。
- アーキテクチャの失敗:特定のコンポーネントやワークフローのデバッグが必要です。
- 例外は例外:ガードレールは改善が必要です。 境界線を強化しましょう。
第4段階:継続的な品質改善評価業務の確立
目標:運用中のエージェント品質を維持するため、継続的な評価モニタリングを確立すること。
一度本番環境にエージェントをデプロイすると、安定状態に入ります。 品質を維持し、製品変更(モデルのアップグレードや知識システムの更新など)や進化するユースケースによる回帰や問題を迅速に検出するために、継続的な評価作業を設定しましょう。 品質保証のために特定のイベントに基づいて定期的な評価ランをスケジュールしたり、実施したりしましょう。
- 定期的な評価メンテナンスのペースを設定しましょう。
- 推奨されるフルスイート評価トリガー:
- モデルの変更
- 主要な知識設定のアップデート
- 新しいツールやコネクタの統合
- 制作上の出来事
ヒント
成功指標:ステークホルダーの懸念に具体的に答えられるとき、単に「エージェントは悪くない」と言うのではなく、運用を成功させることができます。
あなたはこう言っています。「ポリシー遵守率は98%ですが、パーソナライズは87%に落ち込みました。具体的には、テニュアベースのポリシーは適用されていません。 根本原因を特定し、現在は繰り返し改良中です。」