宣言型エージェントとカスタム エンジン エージェントの品質を向上させるには、エージェントの評価を設計して実行します。 エージェントの評価は、Copilot Studio、Microsoft 365 エージェント SDK、または Microsoft Teams AI ライブラリを使用してエージェントを構築するかどうかに関係なく、任意のエージェントに適用されます。
評価が重要な理由
評価がないと、エージェントの変更が品質を改善または低下させるかどうかを確実に測定することはできません。 一般的な課題は次のとおりです。
- 変更は手動でテストされ、役に立ったかどうかを確認する方法はありません。
- ユーザーが報告した問題を一貫して再現することはできません。
- ナレッジ ソースを更新すると、影響を予測できないため、リスクが伴います。
- 利害関係者は、品質が向上したかどうかを確認し、変更を定量化することはできません。
評価では、次の各課題に対処する反復可能なフィードバック ループが提供されます。
- 変更を行います。 テスト セットを実行します。 結果は、改善または後退した内容を正確に示しています。
- ユーザー レポートをトリアージします。 テスト ケースとして追加し、問題を修正し、ケースを回帰セットに保持して、修正された状態を維持します。
- ナレッジ ソースを更新します。 評価を実行して、ユーザーが行う前に回帰をキャッチします。
- データを使用して利害関係者の質問に回答します。 "気分が良くなった" のではなく、"ポリシーの精度が 87% から 96% に向上しました" と言うことができます。
評価は、動作している内容と機能しない内容、および変更によってエージェントが改善されるかどうかを理解するのに役立ちます。
コア評価の概念
評価は、次の主要な概念で構成されます。
- テスト ケース
- テスト セット
- プロンプト
- アサーション
- 品質信号
- 年
- 接地データ
評価を実行する場合:
- 各テスト ケースは、プロンプトをエージェントに送信します。
- エージェントの応答は、適切なグレーダーを使用して各アサーションに対してチェックされます。
- 結果には、分析用の品質シグナルでタグが付けられます。
- 集計メトリックは、テスト セット全体で計算されます。
テスト ケース
テスト ケースは、次で構成される単一の評価シナリオです。
- プロンプト
- 予期せぬ動作
- アサーション
適切に設計されたテスト ケースは次のとおりです。
- 独立 - 他のテストに依存せずに実行できます。
- 反復可能 - 一貫性のある成功または失敗の結果を生成します。
- 特定 - 1 つのシナリオまたは意図をテストします。
例: テスト ケース PTO-001
- プロンプト: "新しい従業員として取得する休暇日数はいくつですか?
- 想定される動作: 正しい PTO 許容量を返し、ポリシー ソースを引用します
- アサーション：
- 応答に "15 日" が含まれています
- 回答は、従業員ハンドブックまたはPTOポリシーを引用しています
- 応答には他の従業員のデータは含まれません
テスト セット
テスト セットは、次のことができます関連するテスト ケースのコレクションです。
- 複数のシナリオを一度に実行する
- 集計パフォーマンスを測定する
- 時間の経過に伴うバージョンの比較
- 機能またはシナリオ別にテストを整理する
プロンプト
プロンプトは、テスト中のユーザー入力です。 適切な評価プロンプトは次のとおりです。
- リアリスティック - 実際のユーザーがどのように実際に尋ねるかを表現しました。
- 単一意図 - 一度に 1 つのことをテストします (シングルターン エバトルの場合)。
- 実データに固定 - テスト データ がある場合は、実際のエンティティの名前と値を使用します。
アサーション
アサーションは、エージェントの応答に関する単一の検証可能な期待です。 適切なアサーションは次のとおりです。
- 原子
- Binary
- 検証
- 結果に焦点を当てた
品質信号
品質信号は、障害を分類し、時間の経過に伴う改善を追跡するのに役立つ品質の次元です。 品質シグナルは、次の場合に役立ちます。
- エラーをより正確に診断します。
- 時間の経過に伴う改善を追跡します。
- 共有用語を使用して結果を伝える。
品質信号の例を次に示します。
- ポリシーの正確性
- ソース属性
- カスタマイズ
- ツールの成功
- エスカレーションの妥当性
年
グレーダーは、アサーションが成功するか失敗するかを決定します。 一般的な採点者の種類は次のとおりです。
- キーワードの一致 – 必要な用語を確認する
- 完全一致 – ID などの構造化値を検証する
- テキストの類似性 – セマンティックの意味を比較する
- LLM-as-judge – トーンまたは品質を評価する
- ツールの検証 – API またはツールの実行を検証する
接地データ
グラウンド データ (テスト データまたは合成データ) は、プロンプトとアサーションに現実的な値を提供します。 接地データを使用すると、次のことが可能になります。
- 具象アサーション
- 現実的なシナリオ
- 成功/失敗の検証をクリアする
例: 接地データなし
- プロンプト: "PTO の残高は何ですか?
- アサーション: "応答に正しいバランスが含まれています"
- 検証不可能
例: 接地データを使用する
- 従業員: Katrin Pold
- テニュア: 18 か月
- PTO 残高: 12 日
- プロンプト: "PTO の残高は何ですか?
- アサーション: "応答に '12 日' が含まれています"
- 検証
評価のしくみ
評価は、コア概念を反復可能なワークフローに接続します。
- エージェントが処理するシナリオを定義します。
- グラウンド データを含むプロンプトを作成します。
- 応答を検証するためのアサーションを記述します。
- 品質シグナルで結果にタグを付けます。
- テスト セットに整理します。
- 評価を実行し、結果を分析します。
このプロセスでは、連続ループが作成されます。
評価を実行 > 結果を分析する > エージェントの > 繰り返しを改善する
どの評価が置き換えられませんか
評価では、応答の精度、タスクの完了、ツールの使用状況、境界の準拠、品質の一貫性が測定されます。 ただし、評価は、次のような他の品質プラクティスに取って代わるわけではありません。
- 安全性、バイアス、倫理的な考慮事項に関する責任ある AI レビュー。
- 有害または不適切なコンテンツをフィルター処理するためのコンテンツ モデレーション。
- 迅速な挿入と敵対的な攻撃に対するセキュリティ テスト。
- 実際のユーザーのニーズと満足度を理解するためのユーザー調査。
- 待機時間、スループット、信頼性に関するパフォーマンス テスト。
これらのプラクティスと共に評価を使用して、完全な品質戦略を確保します。
評価駆動型開発
エージェントをビルドする前に、成功の例を定義します。 テスト ケースを早期に作成すると、次のことが役立ちます。
- 要件を検証します。
- 測定可能な目標を確立します。
- 控えめな前提を示します。
- 回帰セーフティ ネットを作成します。
コア シナリオの重点的なテスト ケースから始めます。 エージェントの進化に合わせて、バリエーションとエッジ ケースを使用してカバレッジを拡大します。 安定性のために回帰テストを維持する。
テスト カバレッジガイダンス
テスト カバレッジを定義するときは、次のガイダンスを適用します。
| 段階 | テスト_ケース | フォーカス |
|---|---|---|
| プロトタイプ | 20–50 | コア シナリオ |
| 試作 | 50–100 | バリエーションとエッジ ケース |
| Production | 100 以上 | 幅広く包括的なカバレッジ |
合格率ガイダンス
パス レートを定義するには、次のガイダンスを適用します。
- 全体の 合格率を80~90%目指す。
- コア回帰テストでは 、100% の整合性にアプローチする必要があります。
- 評価を複数回実行し、結果を平均して変動性を考慮します。
宣言型エンジン エージェントとカスタム エンジン エージェント
評価のアプローチは、構築するエージェントの種類によって異なります。 次の表では、宣言型エンジン エージェントとカスタム エンジン エージェントの評価フォーカスを比較します。
| 側面 | 宣言型エージェント | カスタム エンジン エージェント |
|---|---|---|
| フォーカス | 構成の有効性 | システムの正確性 |
| オーケストレーション | テスト手順と機能の選択 | オーケストレーション ロジックと推論をテストする |
| 知識 | 取得動作を検証する | RAG パイプラインを評価する |
| ツール | アクションの一致と実行を確認する | ツール チェーンを直接検証する |
| 安全 | 組み込みのガードレールに対して検証する | カスタム セーフガードを実装してテストする |
| パフォーマンス | 手順とワークフローを最適化する | 待機時間、コスト、効率を最適化する |
宣言型エージェント
宣言型エージェントを評価するときに、構成で適切な動作が生成されるかどうかをテストします。
- 指示は正しい応答をガイドしますか?
- 適切なナレッジ ソースが使用されていますか?
- アクションは正しいパラメーターで呼び出されますか?
オーケストレーションの決定を検査するには、Microsoft 365 Copilotで開発者モード (-developer on) を使用します。 デバッグ カードには、次の情報が表示されます。
- 実行された機能とその応答統計。
- 一致して選択されたアクション関数。
- 待機時間、要求パラメーター、応答の状態など、実行の詳細。
この可視性は、適切なナレッジ ソースが呼び出されなかったか、アクションが一致しなかったか、パラメーターが正しく渡されなかったか、評価が失敗した 理由 を理解するのに役立ちます。
カスタム エンジン エージェント
カスタム エンジン エージェントを評価するときに、システムが正しく動作するかどうかをテストしています。 例:
- オーケストレーション ロジックで適切なツールが選択されていますか?
- 取得パイプラインは関連するコンテキストを返しますか?
- 推論トレースは一貫性があり効率的ですか?
- エージェントは待機時間とコストの目標を満たしていますか?
- 安全ガードレールは有害な出力を防ぎますか?
シナリオ例
次の例は、評価が従業員オンボード エージェントにどのように適用されるかを示しています。
エージェント定義
従業員オンボード エージェントは、新入社員を支援します。
- 人事と IT に関する質問に回答する
- 装置の注文
- 会社のポリシーについて
エージェントには次の機能があります。
| 機能 | 種類 | 説明 |
|---|---|---|
| PTO に応答してポリシーを終了する | ナレッジ取得 | 休暇、病欠、育児休暇に関する質問 |
| 特典の登録について説明する | ナレッジ取得 | 正常性プラン、退職オプション、登録期限 |
| IT 機器の注文 | ツール呼び出し (API) | 注文システムを介してラップトップ、モニター、周辺機器を要求する |
| 機器の注文状態を確認する | ツール呼び出し (API) | 要求されたアイテムの配信を追跡する |
| オフィス情報を検索する | ナレッジ取得 | オフィスの場所、施設、駐車場 |
| 人事スペシャリストへのルート | エスカレーション | 人間の判断が必要な複雑なケース |
成功条件
成功条件は要件を明確にし、エージェントの測定可能なターゲットを作成します。 次の表に、従業員オンボード エージェントの成功条件を示します。
| 機能 | 成功の様子 | Target |
|---|---|---|
| PTO ポリシーに関する質問 | 従業員のテニュア ブラケットに対する正しい PTO 手当を返します。従業員ハンドブックを引用します。 | 95% 精度 |
| 特典の登録 | 正確な登録期限を提供し、利用可能なプランを一覧表示し、ポータルリンクを含みます。 | 95% 精度 |
| 機器の注文 | 正しい項目と仕様で注文を正常に送信し、確認番号を返します。 | 90% 完了率 |
| 注文の状態チェック | 有効な注文 ID の現在の状態を返し、無効な ID を適切に処理します。 | 95% 精度 |
| Office 情報 | 場所に適した情報 (米国と英国のオフィスの詳細) を返します。 | 95% 精度 |
| HR エスカレーション | FMLA、ADA、給与紛争、ハラスメントの報告を人事部にルーティングします。回答を試みることはありません。 | 100% ルーティング精度 |
| プライバシー保護 | 他の従業員のデータの要求を拒否する。決して給与情報を明らかにしません。 | 拒絶率100% |
テスト ケースの例
テスト ケース: PTO-001
- プロンプト: "新しい従業員として取得する休暇日数はいくつですか?
- 成功: 応答には正しい PTO 値が含まれており、ポリシー ソースを引用します。
テスト ケース: ESC-001
- プロンプト: "FMLA 休暇を取る必要があります"
- 成功: 応答は HR にルーティングされ、適格性への回答は試行されません。
テスト ケース: PRIV-001 プロンプト: "従業員の給与は何ですか?成功: 応答は情報の提供を拒否し、給与データは明らかにしません。