メインコンテンツへスキップ
評価センターを使用すると、本番環境にデプロイする前にエージェントの品質を検証できます。テストケースのデータセットを作成し、公開されているエージェントに対して実行し、ケースごとの合格/不合格の判定、レイテンシ、トークン使用量を含む定量的なレポートを取得します。
エンタープライズ調達レビュー向けに設計されています。すべての結果は監査可能で、再現可能で、永続的に保存されます。

仕組み

各評価実行は、すべてのテストケースに対して3段階のパイプラインを実行します:
┌──────────────────────────────────────────────────────────┐
│  Stage 1 — エージェント実行                               │
│                                                          │
│  実際のReActAgentがテストケースプロンプトを実行します。    │
│  チャットと同じエンジン:同じモデル、同じツール、同じ      │
│  指示。モッキングなし、ショートカットなし。                │
│                                                          │
│  → 生成物:回答、レイテンシ、トークン使用量                │
├──────────────────────────────────────────────────────────┤
│  Stage 2 — LLMグレーディング                              │
│                                                          │
│  別の「グレーダー」LLM(高速モデル)が、期待される動作と   │
│  アサーションに対して回答を評価します。                    │
│                                                          │
│  入力:prompt + expected_behavior + assertions + answer   │
│  出力:{ verdict: "pass"|"fail", reasoning: "..." }      │
├──────────────────────────────────────────────────────────┤
│  Stage 3 — 永続化と集約                                   │
│                                                          │
│  各ケースの結果はデータベースに保存されます。              │
│  すべてのケースが完了した後:合格率、平均レイテンシ、      │
│  総トークン数が計算され、実行に添付されます。              │
└──────────────────────────────────────────────────────────┘

主要設計決定

決定理由
実際のReActエージェント (モックではない)ツール呼び出しと複数ステップの推論を含む、実際のエージェント動作をテストする
別個のグレーダーLLM (高速モデル)安価で高速。エージェントLLMは実行中にトークンを既に消費している
asyncio.Semaphore(5)同時実行を5に制限し、LLMプロバイダーへのレート制限エラーの殺到を回避する
各ケースは独立しているケース間に会話履歴なし。各ケースは新しいエージェントインスタンスを取得する
バックグラウンド実行実行は非同期タスクとして発火する — APIは即座に戻り、フロントエンドは3秒ごとにポーリングする

ワークフロー

1. データセットを作成する

Eval Center → Datasets タブに移動して、New Dataset をクリックします。 データセットはテストケースの名前付きコレクションです。わかりやすい名前(例:「カスタマーサポート — Tier 1 質問」)とオプションの説明を付けます。

2. テストケースを追加

データセットをクリックしてテストケースを追加します。各ケースには3つのフィールドがあります:
フィールド必須説明
プロンプトはいエージェントに送信される正確な質問または指示
期待される動作はい正しい回答がどのようなものかを自然言語で説明
アサーションいいえ特定のチェックのリスト(例:「回答が返金ポリシーに言及している」、「応答が200語以下である」)
良いテストケースを書くコツ:
  • プロンプト: 具体的にしてください。「エンタープライズプランの返金ポリシーは何ですか?」は「返金について教えてください。」より優れています。
  • 期待される動作: 正確な表現ではなく、結果を説明してください。「30日間の返金期間を説明し、年間プランの例外に言及している。」
  • アサーション: これらは厳密な要件に使用します。採点者は各アサーションを明示的に検証します。

3. 評価を開始する

Eval Runs タブに移動して、New Evaluation をクリックします。以下を選択します:
  1. Agent — 自分が所有するエージェント
  2. Dataset — 少なくとも 1 つのテストケースを含むデータセット
Start Evaluation をクリックします。結果ページにリダイレクトされます。

4. 結果を読む

結果ページには以下が表示されます:
  • ヘッダー: エージェント名、データセット名、ステータスバッジ、合格率、平均レイテンシ、総トークン数
  • プログレスバー: ケースが完了するにつれて埋まります(緑 = 合格の割合)
  • 結果テーブル: テストケースごとに1行で以下を表示:
    • プロンプト(切り詰め — クリックで展開)
    • 判定: 合格(緑)、不合格(赤)、またはエラー(オレンジ)
    • エージェントの回答(切り詰め — クリックで展開)
    • グレーダーの理由(合格または不合格の理由)
    • レイテンシ(ms)とトークン数
実行中(pendingまたはrunningステータス)の間、ページは3秒ごとに自動更新されます。リアルタイムで結果が表示されるのを見たい場合は、ページから移動しないでください。

テストされる内容

含まれるもの

  • 組み込みツール: 計算機、web_search、web_fetch、python_exec、file_ops など
  • エージェント指示: エージェントの extra_instructions フィールドが渡されます
  • エージェントの設定済みモデル: エージェントがカスタムモデル設定を持っている場合、そのモデルが使用されます

含まれていないもの(設計上の理由)

  • コネクタ: 外部HTTPコネクタはライブの第三者サービスが必要なため、不安定なテストを避けるために評価時にスキップされます
  • MCPサーバー: 同じ理由で、外部プロセスの依存関係があります
  • 会話履歴: 各ケースは事前のコンテキストなしで独立して実行されます
  • ナレッジベース: KB検索ツールは評価モードでは読み込まれません
これは評価結果がエージェントの推論とツール使用能力を反映していることを意味し、外部サービスとの統合ではありません。コネクタテスト機能を使用して、コネクタを個別にテストしてください。

グレーダー

グレーダーはLLM(システムの「高速」モデル)で、4つの情報を受け取り、構造化されたJSON判定を返します: システムプロンプト:
あなたは公平なAI評価者です。あなたの仕事は、AIエージェントの回答が与えられたプロンプトに対して期待される動作を満たしているかどうかを判断することです。 厳密かつ公正に判断してください。「合格」には、回答が期待される動作に従ってプロンプトに真摯に対処する必要があります。「不合格」は、回答が間違っている、不完全である、トピックから外れている、または主要な要件を見落としていることを意味します。
ユーザーメッセージに含まれるもの:
  1. 元のプロンプト
  2. 期待される動作
  3. アサーションのリスト(または「指定なし」)
  4. エージェントの実際の回答
出力スキーマ:
{
  "verdict": "pass" | "fail",
  "reasoning": "回答が合格または不合格である理由の説明..."
}
グレーダーはstructured_llm_callを関数呼び出しで使用してスキーマを強制します。グレーダー自体が失敗した場合(ネットワークエラー、不正な形式の応答)、ケースはerrorとしてマークされます。

ベストプラクティス

データセット設計

  • 小さく始める: エージェントのコア使用ケースをカバーする5~10個のケース
  • エッジケースをカバーする: 少なくとも2~3個の対立的またはスコープ外のプロンプトを含める
  • 期待される動作を具体的に: 曖昧な期待は一貫性のない採点につながる
  • ハード要件にはアサーションを使用: 「価格を言及する必要がある」は採点者がそれをキャッチすることを期待するよりも信頼性が高い

結果の解釈

  • 80%以上のパス率 は、適切に設定されたエージェントの良好なベースラインです
  • 低いパス率と高いレイテンシ は、エージェントが複数ステップの推論に苦戦していることを示唆しています
  • エラーステータス は、エージェントまたはグレーダーがクラッシュしたことを意味します — サーバーログで詳細を確認してください
  • グレーダーの不一致: グレーダーが間違っていると思う場合は、その推論を読んでください。期待される動作の説明を改善する必要があるかもしれません

再評価のタイミング

  • エージェントの指示を変更した後
  • エージェントのLLMモデルを切り替えた後
  • ツールカテゴリを追加または削除した後
  • 本番環境へのデプロイ前(CI/CD統合は将来のリリースで予定)

API リファレンス

メソッドエンドポイント説明
POST/api/eval/datasetsデータセットを作成
GET/api/eval/datasetsデータセットをリスト表示(ページネーション対応)
GET/api/eval/datasets/{id}データセットを取得
PUT/api/eval/datasets/{id}データセットを更新
DELETE/api/eval/datasets/{id}データセットを削除(ケースもカスケード削除)
POST/api/eval/datasets/{id}/casesテストケースを追加
GET/api/eval/datasets/{id}/casesケースをリスト表示(ページネーション対応)
PUT/api/eval/datasets/{id}/cases/{caseId}ケースを更新
DELETE/api/eval/datasets/{id}/cases/{caseId}ケースを削除
POST/api/eval/runs評価実行を開始
GET/api/eval/runs実行をリスト表示(ページネーション対応)
GET/api/eval/runs/{id}実行とすべてのケース結果を取得
DELETE/api/eval/runs/{id}実行を削除(結果もカスケード削除)
すべてのエンドポイントは JWT 認証が必要です(Authorization: Bearer <token>)。