AIエージェント評価は、version管理したタスクを明示的な期待値に対して実行し、エージェントが正しいツールを選び、制約を守り、タスクを完了し、禁止された効果を避けたか記録します。有用な評価セットは、決定論的assertion、必要に応じた反復試行とmodel judge、見解が分かれるケースの人間によるレビューを組み合わせます。
最初のケースは、本番環境と無関係な雑学問題の一覧ではなく、実際の失敗と影響の大きいワークフローから作ります。
OpenAIのエージェント構築実践ガイドは、評価baselineを確立し、エージェントが複雑になるにつれて評価を使うことを推奨しています。以下のscoring設計は、その助言を具体化します。
scorerを選ぶ前に振る舞いを定義する
各ケースには次が必要です。
- sanitize済み入力と初期状態
- 表示されるツール、ドキュメント、権限
- 期待する、または許容できるツール選択
- 必須の事実またはタスク結果
- 禁止されたアクションとデータ露出
- scoring方法とthreshold
- model、prompt、tool、policy、fixtureのversion
注文状態を扱うエージェントなら、決定論的scorerはget_orderを呼び、update_orderを呼ばず、認証済み注文IDを渡し、正式な状態を返したとassertできます。model judgeは明瞭さを評価できますが、traceで正確に判断できる禁止書き込みの有無まで決めるべきではありません。
主張にscorerを合わせる
決定論的assertion
ツール名、引数schema、policy decision、structured field、database change、latency ceiling、禁止された呼び出しにはコードを使います。これらのチェックは再現でき、デバッグも容易です。
参照またはrubricによるscoring
複数の回答が有効な場合、範囲を限定したrubricを使います。必須の事実、許容できない主張、toneの制約、エージェントが使える証拠を明示します。「品質を1〜10で」のような曖昧な単一スコアは避けます。
model judge
コード化が難しいセマンティックな性質にはjudgeを使い、人間のlabelに対してcalibrateします。treatment名をjudgeから隠し、構造化された説明を要求し、不一致を追跡します。judge modelはdriftしたり、テスト対象システムと同じbiasを持ったりするため、セキュリティや金銭的効果を判断する唯一のgateにはできません。
人間によるレビュー
新しい分類、judgeの不一致、影響の大きい失敗を人間へ回します。裁定を記録し、安定した判断をより明確なassertionまたはrubricへ変えます。
非決定論的ケースを繰り返す
一度の合格では信頼性を推定できません。モデルの選択、確率的なretrieval、変化するツールが関係するケースは繰り返します。割合だけでなく、試行数、成功数、不確実性を報告します。
release比較用に中核セットを固定します。新しい振る舞いには別のdiscovery setを追加し、prompt構成の変更を傾向として見せかけないようにします。これは本番prompt監視でも重要です。テストする質問が変わると、システム自体の変化よりも見かけのvisibilityや成功率が大きく変わる可能性があります。
段階を分けて評価する
タスク全体のスコアでは、失敗がどこで入ったか隠れます。次を個別に評価します。
- retrievalまたはコンテキスト選択
- ツール選択
- 引数と認可
- 実行と復旧
- 最終回答と引用
- 観測可能な場合はビジネス成果
誤ったツールの失敗では実行を固定し、まず選択をテストします。重複書き込みでは隔離バックエンドを使い、操作を中断します。誤ったツールのデバッグガイドと本番チェックリストに具体的なケースがあります。
offline評価とonline評価を分ける
offline suiteはrelease前にfixture、mock、隔離リソースに対して実行します。比較と安全な障害注入に使えます。online評価はデプロイ後に実際のtraceをsampleし、trafficの変化とoffline setが見落としたケースを検出します。
online judgeから重大なアクションを自動で始めてはいけません。本番データをredactし、文書化されたポリシーでsampleし、疑わしいregressionをレビューまたは制御されたrollback processへ回します。
適切なsliceで変更をgateする
model、prompt、tool、schema、retrieval、policy、retry behavior、provider versionを変更したら評価を実行します。同じケースと反復試行で、candidateと現在のbaselineを比較します。
release gateでは、禁止アクション0件、決定論的regressionなし、評価された品質またはコストの変化が制限内であることを要求できます。安定した平均値が一つのワークフローの重大なregressionを隠す場合があるため、task familyごとに結果を分けます。
本番の証拠から評価セットを増やす
オブザーバビリティで失敗を見つけたら、sanitize済みtrace、初期状態、期待する振る舞いを保存します。バグ修正前にケースを追加し、後のmodelまたはprompt変更で同じ問題が再発することを防ぎます。
オブザーバビリティガイドでは、そのfixtureを再構築するために必要なtrace fieldを説明しています。
最初の評価は小さく難しくする
曖昧なプロンプトを数百件用意するのではなく、代表的な10ケースから始めます。通常経路、コンテキスト不足、未認可リクエスト、ツール衝突、プロバイダーtimeout、結果不明の書き込み、敵対的な取得content、ツールを呼ぶべきでないリクエストを含めます。
以下のプロンプトは、リポジトリを編集せずに既存の失敗を完全なケースへ変換します。assertionの信頼性を確認できれば、実装は定型作業になり、チームは具体的なregression gateを得られます。