評価とモニタリング

12のハザードカテゴリにわたってAIシステムの応答を測定する本番運用可能な安全性評価フレームワークで、デプロイ判断のための標準化されたテストプロトコルを備える。

オリジナルのAgentBench研究は、公開されたモデル一覧を8つの多様な環境およびマルチターンでオープンエンドな設定にわたって評価した。

ソフトウェアエンジニアリング企業で通常は複数の職務ロールが担うような、影響の大きい現実世界のタスクでLLMエージェントをベンチマークする。

トップクラスのML学会に由来するオープンエンドな機械学習研究タスクでAIエージェントを評価する包括的なベンチマーク。

12-factorアプリの原則を、スケーラブルで保守しやすいエージェントシステム向けに適応させた本番運用可能な方法論で、包括的なモニタリングと評価を備える。

エージェント能力向けに拡張されたStanford CRFMのHolistic Evaluation of Language Models。詳細な実例は過去時点のベンチマークのスナップショットであり、現在のモデル推奨ではない。

LLMベースのエージェントを人間参加型で評価・改良するためのフレームワークで、エンジニアが開発の各段階でエージェントの性能を導き、評価できるようにする。

自律型およびマルチエージェント環境におけるLLMエージェントのセキュリティリスクを評価するための、Metaによる包括的なサイバーセキュリティベンチマーク。

フロンティアモデルを用いたエージェントが ML 研究エンジニアリングのタスクで発揮する性能を測定し、人間の専門家の能力と比較するためのベンチマーク。

SWE-bench、SWE-bench Verified、SWE-bench Live を含むソフトウェアエンジニアリングのベンチマークスイート。例で比較対象として挙げられているモデルは、当時のベースラインです。

オリジナルの GAIA ベンチマークは、推論、マルチモーダル処理、ウェブ閲覧、ツール利用を評価しました。比較対象として挙げられたモデルは、論文当時のベースラインです。

エージェントを 5 つのドメインにわたり、20 のタスクと 3K+ 個のプロンプトで評価する包括的なベンチマーク。例では、公開当時のモデル構成をそのまま残しています。

WebArena、VisualWebArena、WorkArena を含む、Web エージェントの包括的な評価。サンドボックス環境で現実的な Web 操作をテストします。

リスクベースの分類、GPAI モデルへの要件、EU 域内での展開に必須のコンプライアンスを定める、AI エージェント評価のための欧州連合の規制枠組み。

フロンティア AI システムを対象とした AI Safety Institute の包括的な評価フレームワーク。政府標準のセーフティ評価のため、NIST の AI セーフティに関する取り組みと連携しています。

12 の言語にわたってエージェントの性能とセキュリティを評価する多言語ベンチマーク。この例は現時点でのモデル推奨ではなく、当時のベンチマークのスナップショットです。

憲章的な原則に基づいて AI の安全性を評価する Anthropic のフレームワーク。ジェイルブレイク耐性のテストや無害性の評価を含みます。

本番環境でのステップ単位のトレーシング。すべてのモデル呼び出し、ツール呼び出し、ワークフローのステップ、サブエージェントを、単一の実行ツリー内のスパンとして記録し、トークン・レイテンシ・コストのメトリクスを付与します。OpenTelemetry GenAI のセマンティック規約（gen_ai.* 属性）で標準化され、LangSmith、Braintrust、Datadog といったプラットフォームで可視化されます。デプロイ前に挙動を採点するオフラインのベンチマークとは異なり、本番環境で非決定的な障害をデバッグするためのリアルタイムのシグナルです。

エージェントを、シミュレートされた人間のユーザーとドメイン API 群（小売、航空）の間に置き、書かれたポリシー文書に従わせるベンチマーク。単一の応答をチェックするのではなく、会話全体が終わった後のデータベースの最終状態を目標状態と比較します。特徴的な指標は pass^k で、同じタスクを k 回独立に試行してすべて成功する確率を表し、平均化された pass@1 のスコアでは見えない一貫性の欠如を明らかにします。

エージェントとプロンプトを、まず eval（評価）に対して構築するという開発ライフサイクルの規律。厳選されたゴールデンデータセット（既知の失敗モードに重み付けした、およそ 50〜500 件のケース）をプロンプトとともにバージョン管理し、プルリクエストごとに回帰テストスイートとして実行し、マージや昇格はメトリクスのしきい値でゲートします。パイプラインはモデルと judge のバージョンを固定するため、プロバイダー側でモデルが黙って更新されても、それがひそかに吸収されるのではなく回帰として検出されます。また、変更をマージできるようになる前に、lint、次にオフライン eval、次にコストゲートという順でチェックを段階的に実行します。実行時のテレメトリであってマージ前のゲートではない agent-observability-tracing とは異なり、また、CI 内でチームが所有する回帰スイートではない固定の公開ベンチマークとも異なります。

エージェントやプロンプトの新バージョンを安全に本番投入するための、デプロイ側の手法。候補はまずシャドウモードで動作し、実際の本番トラフィックに対して実行されますが、その出力はユーザーには見せず、稼働中のバージョンとオフラインで比較されます。次に、ライブトラフィックの 1〜5 パーセントを対象とするカナリアへと進み、対照群に対してオンライン eval で採点され、続いて段階的なランプアップへと進みます。監視対象のメトリクスが悪化した瞬間に、自動でロールバックされます。オンライン eval（ライブトラフィックをその場で採点）とオフライン eval を組み合わせることで、静的なゴールデンセットでは予測できないロングテールの障害を捕捉できます。マージ前にオフラインで変更をゲートする eval-driven-agent-development とは異なり、こちらはマージ後のオンラインでのランプアップを統制します。

LLM で駆動されるユーザーシミュレーターを、混乱している、敵対的である、せっかちである、目標を途中で変えるといった多様なペルソナでパラメータ化し、会話型エージェントを多数のマルチターン対話へと自律的に導くテストハーネスとして用います。こうしたシミュレーション対話を大規模に実行することで、実ユーザーが遭遇する前にコンテキストの欠落、ポリシー違反、ハルシネーションを表面化させ、静的なシングルターンのゴールデンケースでは到達できない対話ツリーの分岐を探索します。実ユーザーよりも従順に振る舞う単一の協力的なシミュレーターという盲点を避けるため、意図的なペルソナの多様性と目標の整合が必要です。単一のユーザーシミュレーターを組み込んだ固定ベンチマークである tau-bench とは異なり、また、ゴールデンが静的なシングルターンのケースである eval-driven-agent-development とも異なり、この手法は動的なマルチターンのトラフィックを生成します。