mcpField
A
agent-evaluation

agent-evaluation

github.com/sickn33テスト・品質48.7k977 回インストール今日更新
リポジトリ

agent-evaluation について

タスク別ケースでエージェントの観測可能な動作を評価するスキルです。エージェント、プロンプト、ツールの変更比較に向け、条件の固定やケース別の不確実性、安全上の重大な失敗の個別報告を重視します。

主な機能

  1. 01ケース、バージョン、予算の固定
  2. 02評価ハーネスの分類確認
  3. 03各実行の記録と分類
  4. 04ばらつきと未解決障害の調査
  5. 05ケース別結果と不確実性の比較
  6. 06修正後の回帰テスト

活用シーン

  1. 01エージェントやプロンプト変更の比較
  2. 02観測された失敗の再現と調査
  3. 03タスク分布における信頼性の推定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill agent-evaluation

インストール後、Claude Code で/agent-evaluationを入力して読み込まれたか確認します。

同梱ファイルreferences/architecture-sketches.md

詳細

エージェント評価

タスク固有のケースに対して、観測可能なエージェントの挙動を評価します。2026-09-05 に AAS メンテナーが、サポートされていないベンチマークの主張を削除し、不確実性・エラーの報告を修正し、任意のアーキテクチャ概要を運用手順から分離するために改訂しました。

使用する場面

変更されたエージェント、プロンプト、またはツール構成を比較する場合、観測された障害を再現する場合、または宣言されたタスク分布における信頼性を見積もる場合に使用します。公開ベンチマークのパーセンテージや一般的なスコアしきい値から製品の readiness を推測しないでください。

前提条件

  • 期待される観測可能な結果と権限境界を伴う、バージョン管理されたケースセット。
  • モデル、プロンプト、ツール、構成、ランタイムのバージョンを含む、既知のベースラインと候補リビジョン。
  • 承認された合成入力または秘匿化された入力、分離されたターゲット、および上限付きのトークン・時間・コスト予算。
  • 誤った結果、期待される安全な拒否、評価者の失敗、インフラストラクチャの停止を区別する検証器。プロバイダーへのアクセスは、宣言された評価がそのプロバイダーを呼び出す場合にのみ必要です。

評価手順

  1. 契約を凍結します。 実行前に、ケース ID とデータセットリビジョン、ベースライン/候補の識別情報、ターゲット環境、繰り返し計画、予算、停止ルール、意思決定基準を記録します。重大な安全性および認可の失敗は、平均的な品質とは分けて扱います。これらはより高いスコアで補償することはできません。
  2. ハーネスを検証します。 既知の合格ケース、既知の不合格ケース、および意図的な検証器/インフラストラクチャ障害を実行します。それぞれが正しく分類され、トレースの保持から認証情報およびプライベートな入力本文が除外されていることを確認します。分類が誤っている場合は、ハーネスを修正し、エージェントを測定する前にこれらのチェックを繰り返します。
  3. 凍結したケースを実行します。 ベースラインと候補に対して同じケース定義と予算を使用し、独立したフィクスチャ状態と記録された実行順序を用います。すべての試行とその実行 ID、結果、理由、レイテンシ、リソース合計を保持します。例外は、安全でないリクエストが安全に拒否された証拠にはなりません。
  4. ばらつきを調査します。 元の失敗を保存します。不一致を、エージェントの挙動、共有状態の汚染、検証器の曖昧さ、または停止として分類します。事前に宣言された繰り返し予算のみを使用します。グリーンになるまで再試行したり、失敗を黙って破棄したり、候補に合わせて期待される結果を変更したりしないでください。未解決のハーネス障害は、影響を受ける結果を結論不能にします。
  5. 比較して判断します。 ケースごとの結果と不確実性、リグレッション、重大な失敗、不完全なケースを報告します。1 つのケースの繰り返し実行は、タスク分布の独立したサンプルではありません。期待の変更には、別途レビューされた契約リビジョンと、ベースラインと候補の両方の再実行が必要です。古い結果は保持します。
  6. 修正して検証します。 上限付きの修正を行い、失敗したケースを再実行してメカニズムを検証し、クリーンな状態から該当する凍結済みリグレッションスイートを再実行します。不一致が続く場合は、宣言された予算で停止します。正確な証拠とともに合格、不合格、または結論不能を記録します。プロジェクトの公開/デプロイ承認境界には別途従ってください。

例: 変更されたツール引数処理

合成エージェントが、読み取り専用の参照でテナント識別子を選択する方法を変更します。3 つのケースを凍結します。承認済みの参照はシードされたフィクスチャを返さなければならず、未承認のテナントはツール呼び出しなしで拒否されなければならず、シミュレートされたツール障害はインフラストラクチャ障害として分類されなければなりません。実際の顧客レコードも本番環境の認証情報も提供しないでください。

ケースごとに 5 回の繰り返しを、新しい状態で事前に宣言し、ベースラインと候補に同じ予算を割り当て、未承認のツール呼び出しに対してはゼロトレランスとします。候補が 5 回の実行すべてで期待される承認済みの結果を返したものの、2 番目のケースで 1 回の未承認呼び出しを行ったとします。この場合、候補は集計の成功率が向上していても、権限契約に違反しています。その実行を保持し、引数の認可を修正し、ネガティブケースを検証して、凍結したスイートを再実行します。障害検出器自体がクラッシュした場合は、そのケースを判定不能としてマークし、バージョンを比較する前に検出器を修復します。これらは例示的な結果であり、測定されたエージェントの結果ではありません。

期待される出力:

contract: case-set revision, rules, repeat plan and budget
versions: baseline, candidate, model, prompt, tool and runtime
runs: one record per attempt, classified outcome and bounded evidence reference
comparison: per-case results, uncertainty, regressions and critical violations
decision: pass | fail | inconclusive; reason; unresolved work

不確実性の算出例

10 回の独立試行で 10 回成功しても、100% の信頼性を実証するものではありません。この依存関係のないヘルパーは、近似 95% Wilson 区間を返します。10/10 の場合、およそ [0.7225, 1] になります。試行回数がゼロの場合、入力を拒否します。

function wilson95(passes, trials) {
  if (!Number.isSafeInteger(passes) || !Number.isSafeInteger(trials)
      || trials <= 0 || passes < 0 || passes > trials) throw new Error('Invalid counts');
  const z = 1.959963984540054;
  const p = passes / trials;
  const denominator = 1 + z * z / trials;
  const center = (p + z * z / (2 * trials)) / denominator;
  const margin = z * Math.sqrt(p * (1 - p) / trials + z * z / (4 * trials * trials)) / denominator;
  return [Math.max(0, center - margin), Math.min(1, center + margin)];
}

期待されるチェック: 0/10 は正の上限を持ち、10/10 は 1 未満の下限を持ち、0/0 は失敗します。繰り返し実行がケースや状態を共有する場合は、ケースレベルまたはクラスター化された不確実性を使用してください。相関する実行を独立した観測としてプールすると、信頼度が過大評価されます。NIST の区間ガイダンスを参照してください。

オプションのアーキテクチャパターン

カスタムハーネスを設計する場合にのみ、同梱のアーキテクチャスケッチの該当セクションを読んでください:

  • 統計的評価: 繰り返しの確率的実行と記述的なレポート。
  • 振る舞い契約: 期待される振る舞いと不変条件。
  • 敵対的テスト: 合成的で承認された境界ケース。キーワード検出器には、レビュー済みの偽陽性と偽陰性の例が必要です。
  • リグレッションパイプライン: ベースライン/候補の成果物の比較。
  • 鋭いエッジ: データセットの不一致、不安定さ、プロキシメトリクス、および起こりうるリーク。

これらのクラスはアプリケーション固有のアダプターを必要とし、コピーして実行できる実装ではありません。記載されているツール、関連するスキル、または委譲は、必須の依存関係ではありません。

制限事項

  • アーキテクチャスケッチに記載されている例示的な 80/90% のしきい値とスコアの重みは、万能のマージ/デプロイ規則ではありません。プロジェクト固有の基準を定義し、重大な失敗は別に扱ってください。
  • 小標本のカイ二乗比較や有意性の欠如は、同等性を証明するものではありません。件数、ペアリング、多重比較に適した手法を使用してください。
  • 例外は自動的な安全拒否ではなく、テストの再試行によって最初の失敗を消してはなりません。
  • 取得された回答との類似性は、正当な RAG の振る舞いである可能性があります。リークは、評価がエージェントに何を知ることを許可するかによって決まります。
  • LLM ジャッジは実際のユーザーフィードバックの代わりにはならず、出力の切り詰めによってプライベートデータが削除されるわけではありません。合成的または承認された編集済みの入力を、保持期間を限定して使用してください。

コメント