評価セットを作成するためのベスト・プラクティス

適切な評価セットを作成すると、評価の効率が向上します。次に、エージェント・チームの評価データ・セットおよびテスト・プロトコルの作成に関するベスト・プラクティスをいくつか示します。

評価を成功させるための基盤は、高品質なデータセットです。このデータ・セットは、ペアの質問または入力、および予想される応答で構成されます。予期されるレスポンスは、ソース・コンテキストで事実上修正され、アースされる必要があります。

データ・セットの例

質問	予想応答
アロマセラピーはカバーされていますか?	いいえ、アロマセラピーはカバーされていません。提供された文脈によると、アロマセラピーは、UnitedHealthcareメディカルプランでカバーされていない「代替治療」の下にリストされています。
温度計は払いますか。	指定されたコンテキストに基づいて、温度計はカバーされません。ドキュメント「MEDICAL SUPPLIES AND APPLIANCES」には、温度計が除外供給としてリストされています。
眼のレーザー手術はカバーされていますか?	提供された状況に基づいて、眼のレーザー手術は発見されません。「VISION」セクションは、レーザー手術を含む近視性を修正する手術が、計画除外の下にリストされていることを示しています。

一般的な評価ガイドライン

これらの原則は、包括的なテストを保証するために、すべてのエージェント・チームに適用されます。

安全および接地: エージェントが安全ポリシーに準拠していることを検証します。幻覚を避ける必要があります。つまり、関連情報が見つからない場合は、推測するのではなく、それを示す必要があります。
あいまいさとマルチパート・クエリー: 曖昧なクエリー、暗黙的な推論、または複数の個別質問を含む単一回転を処理するエージェントの能力を評価します。
ネガティブ・テスト: 範囲外または回答できない質問(使用可能なツールでカバーされていないトピックなど)を紹介し、エージェントが適切な「わからない」またはリダイレクトで応答することを確認します。
マルチターン・ダイアログ: エージェントが会話型の場合、コンテキストと履歴を複数のターンにわたって維持する必要があるテストを設計します。たとえば、前の回答に基づいてフォローアップ質問に回答します。
レイテンシとパフォーマンス: 応答時間と効率を測定します。特に、複数のツールへのコールや複雑な推論を含むシナリオで測定します。

監督者エージェント・チームの評価ガイドライン

スーパーバイザ・タイプのエージェント・チームは、使用するツールに基づいて評価されます。

ツール	ガイドライン
ドキュメント・ツール(RAG)	Retrieval-Augmented Generation (RAG)用に設計された質問は、単純なキーワード検索だけでなく、複雑さを処理するエージェントの機能をテストする必要があります。 Long Range Context: エージェントが、ドキュメントの遠隔セクションまたは複数のページに散在する依存関係を解決できるかどうかをテストします。 Distributed Context: エージェントがドキュメントの複数の非連続部分から情報を集約して、包括的に回答できるようにします。 Concealed Context: テキスト内の特定の不明瞭な詳細を見つけて抽出する機能をテストします。 Reasoning(推論): エージェントが、取得した情報に推論またはロジックを適用して正解を提供できるかどうかをチェックします。表ソース: 文書内の表から正確なデータを解釈およびプルする機能をテストします。
ビジネス・オブジェクト	機能カバレッジ: 評価が、ビジネス・オブジェクトで使用可能なすべてのビジネス機能をテストすることを確認します。パラメータ変動: 異なる角度から、異なるパラメータで同じビジネス機能をテストします。たとえば、ビジネス・オブジェクトでオブジェクトを作成する場合は、様々な入力タイプでテストします。
REST	Endpoint Coverage(エンドポイント・カバレッジ): 評価がRESTツールで使用可能なすべての機能をテストしていることを確認します。シナリオの変動: 異なるペイロード構造や更新タイプの処理など、様々なシナリオおよびパラメータに対して同じRESTツールをテストします。
ディープ・リンク	検証: ディープ・リンクが正しく生成され、適切なシナリオで生成されていることを確認します。
MCP (Model Context Protocol)	ツール選択: 正しいMCPツールが呼び出されたことを確認します。関数の精度: MCPツール内で正しい関数が呼び出されていることを検証します。

ワークフロー・エージェント・チームの評価ガイドライン

ワークフロー・エージェントの評価では、個々のノードの全体的なロジック・フローと堅牢性をテストする必要があります。

ワークフローの構造とロジック

パス・カバレッジ: ワークフローに複数のパスまたはブランチがある場合は、すべてのパスを評価テストします。
シナリオの深さ: 同一パスに対して複数の異なるシナリオをテストして、一貫性を確保します。
サポートされていないシナリオ: ワークフローでサポートされていないシナリオを識別するテストを含めて、正常な障害またはエラー処理を検証します。

ワークフロー・ノード

ワークフローには複数のノード・タイプが含まれており、評価は各タイプに適用可能な主要なシナリオに対応している必要があります。

Node	シナリオ
LLM	LLMプロンプトをテストして、すべてのタイプの質問および書式設定手順を処理できるかどうかを識別します。
コード	堅牢性: コードの安定性をテストする質問を含めます。エッジ・ケース: 異なるエッジ・ケースをカバーするシナリオをテストして、コードがフローを中断しないようにします。
ビジネス・オブジェクト REST	Supervisor.Test型のエージェント・チームに対して、様々な角度から様々なパラメータを使用して指定するのと同じガイドラインを適用します。
RAGドキュメントツール	タイプが「監督者」のエージェント・チームに指定したガイドラインと同じガイドラインを適用します。
文書プロセッサ	フォーマット処理: 様々な添付タイプ(PDF、txtなど)のノードをテストして、一貫したテキスト抽出を保証します。
ベクトルDBリーダー	取得精度: ノードが、入力問合せに基づいて最も意味のあるチャンクを取得するかどうかをテストします。

サポートされている他のノードについては、評価テストでTools、Vector DB Reader、Vector DB Writerなどの他のノードが対象であることを確認してください。