評価センターを使用すると、本番環境にデプロイする前にエージェントの品質を検証できます。テストケースのデータセットを作成し、公開されているエージェントに対して実行し、ケースごとの合格/不合格の判定、レイテンシ、トークン使用量を含む定量的なレポートを取得します。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.
エンタープライズ調達レビュー向けに設計されています。すべての結果は監査可能で、再現可能で、永続的に保存されます。
仕組み
各評価実行は、すべてのテストケースに対して3段階のパイプラインを実行します：エージェント実行
実際のReActAgentがテストケースプロンプトを実行します。チャットと同じエンジン：同じモデル、同じツール、同じ指示。モッキングなし、ショートカットなし。出力：answer、latency、token usage。
LLMグレーディング
別の「グレーダー」LLM（高速モデル）が、期待される動作とアサーションに対して答えを判定します。入力：prompt + expected behavior + assertions + answer。出力：
{ verdict: "pass"|"fail", reasoning: "..." }。主要設計決定
| 決定 | 理由 |
|---|---|
| 実際のReActエージェント (モックではない) | ツール呼び出しと複数ステップの推論を含む、実際のエージェント動作をテストする |
| 別個のグレーダーLLM (高速モデル) | 安価で高速。エージェントLLMは実行中にトークンを既に消費している |
asyncio.Semaphore(5) | 同時実行を5に制限し、LLMプロバイダーへのレート制限エラーの殺到を回避する |
| 各ケースは独立している | ケース間に会話履歴なし。各ケースは新しいエージェントインスタンスを取得する |
| バックグラウンド実行 | 実行は非同期タスクとして発火する — APIは即座に戻り、フロントエンドは3秒ごとにポーリングする |
ワークフロー
1. データセットを作成する
Eval Center → Datasets タブに移動して、New Dataset をクリックします。 データセットはテストケースの名前付きコレクションです。わかりやすい名前（例：「カスタマーサポート — Tier 1 質問」）とオプションの説明を付けます。2. テストケースを追加
データセットをクリックしてテストケースを追加します。各ケースには3つのフィールドがあります：| フィールド | 必須 | 説明 |
|---|---|---|
| プロンプト | はい | エージェントに送信される正確な質問または指示 |
| 期待される動作 | はい | 正しい回答がどのようなものかを自然言語で説明 |
| アサーション | いいえ | 特定のチェックのリスト（例：「回答が返金ポリシーに言及している」、「応答が200語以下である」） |
3. 評価を開始する
Eval Runs タブに移動して、New Evaluation をクリックします。以下を選択します：- Agent — 自分が所有するエージェント
- Dataset — 少なくとも 1 つのテストケースを含むデータセット
4. 結果を読む
結果ページには以下が表示されます:- ヘッダー: エージェント名、データセット名、ステータスバッジ、合格率、平均レイテンシ、総トークン数
- プログレスバー: ケースが完了するにつれて埋まります（緑 = 合格の割合）
- 結果テーブル: テストケースごとに1行で以下を表示:
- プロンプト（切り詰め — クリックで展開）
- 判定: 合格（緑）、不合格（赤）、またはエラー（オレンジ）
- エージェントの回答（切り詰め — クリックで展開）
- グレーダーの理由（合格または不合格の理由）
- レイテンシ（ms）とトークン数
テストされる内容
含まれるもの
- 組み込みツール: 計算機、web_search、web_fetch、python_exec、file_ops など
- エージェント指示: エージェントの
extra_instructionsフィールドが渡されます - エージェントの設定済みモデル: エージェントがカスタムモデル設定を持っている場合、そのモデルが使用されます
含まれていないもの（設計上の理由）
- コネクタ: 外部HTTPコネクタはライブの第三者サービスが必要なため、不安定なテストを避けるために評価時にスキップされます
- MCPサーバー: 同じ理由で、外部プロセスの依存関係があります
- 会話履歴: 各ケースは事前のコンテキストなしで独立して実行されます
- ナレッジベース: KB検索ツールは評価モードでは読み込まれません
これは評価結果がエージェントの推論とツール使用能力を反映していることを意味し、外部サービスとの統合ではありません。コネクタテスト機能を使用して、コネクタを個別にテストしてください。
グレーダー
グレーダーはLLM（システムの「高速」モデル）で、4つの情報を受け取り、構造化されたJSON判定を返します： システムプロンプト：あなたは公平なAI評価者です。あなたの仕事は、AIエージェントの回答が与えられたプロンプトに対して期待される動作を満たしているかどうかを判断することです。 厳密かつ公正に判断してください。「合格」には、回答が期待される動作に従ってプロンプトに真摯に対処する必要があります。「不合格」は、回答が間違っている、不完全である、トピックから外れている、または主要な要件を見落としていることを意味します。ユーザーメッセージに含まれるもの：
- 元のプロンプト
- 期待される動作
- アサーションのリスト（または「指定なし」）
- エージェントの実際の回答
structured_llm_callを関数呼び出しで使用してスキーマを強制します。グレーダー自体が失敗した場合（ネットワークエラー、不正な形式の応答）、ケースはerrorとしてマークされます。
ベストプラクティス
データセット設計
- 小さく始める: エージェントのコア使用ケースをカバーする5～10個のケース
- エッジケースをカバーする: 少なくとも2～3個の対立的またはスコープ外のプロンプトを含める
- 期待される動作を具体的に: 曖昧な期待は一貫性のない採点につながる
- ハード要件にはアサーションを使用: 「価格を言及する必要がある」は採点者がそれをキャッチすることを期待するよりも信頼性が高い
結果の解釈
- 80%以上のパス率 は、適切に設定されたエージェントの良好なベースラインです
- 低いパス率と高いレイテンシ は、エージェントが複数ステップの推論に苦戦していることを示唆しています
- エラーステータス は、エージェントまたはグレーダーがクラッシュしたことを意味します — サーバーログで詳細を確認してください
- グレーダーの不一致: グレーダーが間違っていると思う場合は、その推論を読んでください。期待される動作の説明を改善する必要があるかもしれません
再評価のタイミング
- エージェントの指示を変更した後
- エージェントのLLMモデルを切り替えた後
- ツールカテゴリを追加または削除した後
- 本番環境へのデプロイ前（CI/CD統合は将来のリリースで予定）