AI エージェントの評価: テスト結果、トレース、および繰り返し実行

信頼性はタスクの成功よりも広い範囲にあります

2026 年 2 月のプレプリントでは、一貫性、堅牢性、予測可能性、安全性を含む信頼性の側面が提案されています。 Anthropic のエージェント評価ガイダンスでは、成績チェックと成績証明書の評価も区別されています。これらはテスト スイートの設計に役立つレンズであり、スイートがすべての展開リスクをカバーすることを保証するものではありません。

証拠: AI エージェントの信頼性の科学に向けて [1]AI エージェントの eval をわかりやすく説明する [2]

許可された終了状態を定義する

何が変更される可能性があり、何が変更されない必要があるか、何が完了を構成するのかについて説明します。スケジュール エージェントにとって、これは、無関係なイベントはそのままにしつつ、要求された出席者を含むイベントを 1 つだけ作成することを意味する場合があります。コーディング エージェントの場合、テスト、アーティファクトの動作、リポジトリの制約が含まれる場合があります。

各トライアルを既知の状態から初期化します。以前の実行でデータが残っている場合、後の結果では、エージェントの品質ではなく、テスト環境の汚染が測定される可能性があります。ツールのバージョン、権限、外部依存関係、およびタスクを再現するために必要なシミュレートされた応答を記録します。

結果チェックとプロセス チェックを別々に使用する

Rubrex は、タスクが許可する場合には常に正確な状態アサーションを推奨します。記録は存在していたのでしょうか？その識別子は正しかったでしょうか?操作が重複していませんか?シーケンス、認可、または通信に依存する要件については、トレース レビューを使用します。複数の有効なパスが契約を満たす場合、1 つの正確なツール パスを要求することは避けてください。

不完全な実行、タイムアウト、および再試行を評価レコードに保持します。失敗を取り除くハーネスは、見かけ上の成功を誇張する可能性があります。ユーザー シミュレータが関与する場合は、シミュレータの動作も評価します。シミュレータにより、隠された情報が明らかになったり、誤った結果が受け入れられたり、実際の使用よりもタスクが簡単になったりする可能性があります。

説明例: 成功メッセージ、不在レコード

エージェントはサポート チケットを作成したと言っています。ツールのリクエストは失敗しました。チケットは存在しません。言語のみの採点者は、簡潔な完了メッセージを評価する場合があります。状態ベースのチェックにより、失敗した結果が正確に識別されます。

次に、チケットが作成されたが応答が失われた場合のタイムアウトをテストします。正しい動作は、再試行する前に状態を調整することかもしれません。どちらのケースも部分的なトレースでは似ていますが、異なる回復アクションが必要です。それらを別のシナリオとして含めて、エージェントが入手可能な証拠を区別できるかどうかを検査します。

信頼性プロファイルを報告する

完了、不正な変更、重複アクション、回復の成功、およびトライアル間のばらつきを表示します。リソースの使用状況と代表的な障害トレースを含めます。候補者は、予測可能性が低くなったり、より深刻な失敗を引き起こしたりしながら、より多くのタスクを完了できる可能性があります。そのトレードオフを明示的に報告します。

• 初期状態をフリーズし、試行の間にリセットします。
• 完了までの許容可能な代替パスを定義します。
• テストの中断と部分的なツールの障害。
• 平均が改善された場合でも、重大な障害を可視化したままにします。

検査できる AI エージェント評価フレームワーク

実用的なエージェント評価フレームワークには、タスク定義、リセット可能な環境、反復試行、結果チェック、およびアクションと結果を結び付けるトレースが必要です。サポート エージェントの場合は、実行前に許可されるレコードの変更を定義します。その後、会話だけでなく実際の記録も検査します。試みられた作業がレポートに反映されるように、失敗したトライアルや中断されたトライアルを保持します。

AI エージェントの評価指標について、Rubrex は、未承認の変更、重複アクション、回復結果、完了したタスクごとのコストと併せて、タスクの完了を報告することを推奨しています。各タスクの試行回数を示し、一貫性のない結果を個別に示します。エージェント評価では、ツールの失敗や曖昧なリクエストもテストする必要があります。システムは強制的に完了するのではなく、停止するか説明を求める必要がある場合があります。

よくある質問