> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 評価センター

> テストデータセットと自動LLM採点を使用してエージェントを定量的にベンチマークします。

評価センターを使用すると、本番環境にデプロイする**前に**エージェントの品質を検証できます。テストケースのデータセットを作成し、公開されているエージェントに対して実行し、ケースごとの合格/不合格の判定、レイテンシ、トークン使用量を含む定量的なレポートを取得します。

<Info>
  エンタープライズ調達レビュー向けに設計されています。すべての結果は監査可能で、再現可能で、永続的に保存されます。
</Info>

## 仕組み

各評価実行は、すべてのテストケースに対して**3段階のパイプライン**を実行します：

<Steps>
  <Step title="エージェント実行">
    実際のReActAgentがテストケースプロンプトを実行します。チャットと同じエンジン：同じモデル、同じツール、同じ指示。モッキングなし、ショートカットなし。

    出力：**answer**、**latency**、**token usage**。
  </Step>

  <Step title="LLMグレーディング">
    別の「グレーダー」LLM（高速モデル）が、期待される動作とアサーションに対して答えを判定します。

    入力：prompt + expected behavior + assertions + answer。出力：`{ verdict: "pass"|"fail", reasoning: "..." }`。
  </Step>

  <Step title="永続化と集約">
    各ケースの結果がデータベースに保存されます。すべてのケースが完了した後：**pass rate**、**avg latency**、**total tokens**が計算され、実行に添付されます。
  </Step>
</Steps>

### 主要設計決定

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

## ワークフロー

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

**Eval Center → Datasets** タブに移動して、**New Dataset** をクリックします。

データセットはテストケースの名前付きコレクションです。わかりやすい名前（例：「カスタマーサポート — Tier 1 質問」）とオプションの説明を付けます。

### 2. テストケースを追加

データセットをクリックしてテストケースを追加します。各ケースには3つのフィールドがあります：

| フィールド       | 必須  | 説明                                               |
| ----------- | --- | ------------------------------------------------ |
| **プロンプト**   | はい  | エージェントに送信される正確な質問または指示                           |
| **期待される動作** | はい  | 正しい回答がどのようなものかを自然言語で説明                           |
| **アサーション**  | いいえ | 特定のチェックのリスト（例：「回答が返金ポリシーに言及している」、「応答が200語以下である」） |

<Tip>
  **良いテストケースを書くコツ：**

  * **プロンプト**: 具体的にしてください。「エンタープライズプランの返金ポリシーは何ですか？」は「返金について教えてください。」より優れています。
  * **期待される動作**: 正確な表現ではなく、*結果*を説明してください。「30日間の返金期間を説明し、年間プランの例外に言及している。」
  * **アサーション**: これらは厳密な要件に使用します。採点者は各アサーションを明示的に検証します。
</Tip>

### 3. 評価を開始する

**Eval Runs** タブに移動して、**New Evaluation** をクリックします。以下を選択します：

1. **Agent** — 自分が所有するエージェント
2. **Dataset** — 少なくとも 1 つのテストケースを含むデータセット

**Start Evaluation** をクリックします。結果ページにリダイレクトされます。

### 4. 結果を読む

結果ページには以下が表示されます:

* **ヘッダー**: エージェント名、データセット名、ステータスバッジ、合格率、平均レイテンシ、総トークン数
* **プログレスバー**: ケースが完了するにつれて埋まります（緑 = 合格の割合）
* **結果テーブル**: テストケースごとに1行で以下を表示:
  * プロンプト（切り詰め — クリックで展開）
  * 判定: **合格**（緑）、**不合格**（赤）、または**エラー**（オレンジ）
  * エージェントの回答（切り詰め — クリックで展開）
  * グレーダーの理由（合格または不合格の理由）
  * レイテンシ（ms）とトークン数

<Warning>
  実行中（`pending`または`running`ステータス）の間、ページは3秒ごとに自動更新されます。リアルタイムで結果が表示されるのを見たい場合は、ページから移動しないでください。
</Warning>

## テストされる内容

### 含まれるもの

* **組み込みツール**: 計算機、web\_search、web\_fetch、python\_exec、file\_ops など
* **エージェント指示**: エージェントの `extra_instructions` フィールドが渡されます
* **エージェントの設定済みモデル**: エージェントがカスタムモデル設定を持っている場合、そのモデルが使用されます

### 含まれていないもの（設計上の理由）

* **コネクタ**: 外部HTTPコネクタはライブの第三者サービスが必要なため、不安定なテストを避けるために評価時にスキップされます
* **MCPサーバー**: 同じ理由で、外部プロセスの依存関係があります
* **会話履歴**: 各ケースは事前のコンテキストなしで独立して実行されます
* **ナレッジベース**: KB検索ツールは評価モードでは読み込まれません

<Info>
  これは評価結果がエージェントの**推論とツール使用能力**を反映していることを意味し、外部サービスとの統合ではありません。コネクタテスト機能を使用して、コネクタを個別にテストしてください。
</Info>

## グレーダー

グレーダーはLLM（システムの「高速」モデル）で、4つの情報を受け取り、構造化されたJSON判定を返します：

**システムプロンプト：**

> あなたは公平なAI評価者です。あなたの仕事は、AIエージェントの回答が与えられたプロンプトに対して期待される動作を満たしているかどうかを判断することです。
>
> 厳密かつ公正に判断してください。「合格」には、回答が期待される動作に従ってプロンプトに真摯に対処する必要があります。「不合格」は、回答が間違っている、不完全である、トピックから外れている、または主要な要件を見落としていることを意味します。

**ユーザーメッセージに含まれるもの：**

1. 元のプロンプト
2. 期待される動作
3. アサーションのリスト（または「指定なし」）
4. エージェントの実際の回答

**出力スキーマ：**

```json theme={null}
{
  "verdict": "pass" | "fail",
  "reasoning": "回答が合格または不合格である理由の説明..."
}
```

グレーダーは`structured_llm_call`を関数呼び出しで使用してスキーマを強制します。グレーダー自体が失敗した場合（ネットワークエラー、不正な形式の応答）、ケースは`error`としてマークされます。

## ベストプラクティス

### データセット設計

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

### 結果の解釈

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

### 再評価のタイミング

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