AIエージェントをどう評価する？最終回答だけでなく道具の選択と実行過程を見る
AIエージェントの最終回答が正しく見えても、途中で不要な道具を何度も呼んだり、権限のない操作を試したりしていれば、安定した仕組みとは言えない。反対に、外部サービスの一時障害で答えまで届かなかったとしても、正しい道具を選び、安全に停止できたなら評価すべき部分がある。エージェントは答えと実行過程を分けて測る必要がある。
例えば「公開済みの記事から先月最も読まれたものを調べる」という架空の依頼を考える。正しい記事名を返したかだけでなく、対象期間を正しく指定したか、下書きを混ぜなかったか、分析データを取得できないときに推測で埋めなかったかも確認対象になる。
最終回答の評価だけでは原因が分からない
通常の質問応答なら、期待する答えと出力を比較する評価が出発点になる。エージェントでは同じ最終回答へ至る経路が複数あり、偶然正解することもある。誤った検索結果を使ったのに、事前知識だけで正しい記事名を書いた場合、出力だけを見れば成功だが、別の質問では再現しない。
OpenAIのエージェント評価資料は、トレースをモデル呼び出し、道具の呼び出し、ガードレール、引き継ぎを含む一回の実行記録として扱い、正しい道具を選んだか、必要な引き継ぎが起きたか、指示や安全方針に違反しなかったかを評価対象に挙げている。まず一件の実行を読める状態にし、その後に同じ基準を複数例へ広げる。
一回の実行をトレースとして残す
トレースには、依頼を受けてから回答を返すまでの処理を一つのまとまりとして記録する。その中を、モデル呼び出し、検索、道具の実行、再試行などの区間に分ける。各区間には開始時刻、終了時刻、成否、使用したモデルや道具、安定した実行IDを残す。
OpenTelemetryの資料では、一つの操作区間をspanとして表し、生成AI向けの操作名としてモデルとの対話、道具の実行、エージェントの呼び出し、検索などを区別している。共通した名前を使えば、モデル呼び出しだけ遅いのか、外部APIの待ち時間が長いのかを集計しやすい。
入力文や道具の結果をそのまま記録すると、個人情報や秘密値が監視基盤へ流れる可能性がある。OpenTelemetryの生成AI向け属性にも、入出力メッセージには機密情報や個人情報が含まれ得るという警告がある。本文の記録は既定で無効にし、必要な環境だけで伏字、長さ制限、保持期間を定める。評価に全文が不要なら、件数、型、ハッシュ、エラー分類だけを残す。
成功を複数の観点へ分ける
一つの総合点だけでは改善箇所が見えにくい。少なくとも次の観点を分けて判定する。
- 最終結果: 利用者の依頼を満たし、根拠と一致しているか
- 道具選択: 必要な道具を選び、不要または危険な道具を呼んでいないか
- 引数: 対象ID、期間、件数、書き込み内容が正しいか
- 状態遷移: 確認待ちや失敗を飛ばさず、完了済み操作を繰り返していないか
- 安全性: 権限、承認、個人情報、外部送信の条件を守ったか
- 効率: 呼び出し回数、遅延、トークン、費用が許容範囲か
正しさと効率は同じではない。道具を十回呼んで正解した実行と、二回で正解した実行は、品質が同じでも運用負荷が違う。反対に、最短経路だけを求めると、確認を省いて危険な操作へ進むことがある。安全上必要な一手は無駄な呼び出しとして数えない。
実行経路は完全一致だけで採点しない
期待する道具の順序を一つに固定すると、別の正しい経路を失敗にしてしまう。LangSmithの複雑なエージェント評価資料は、期待する段階のうち実際の経路がどこまで満たしたかを評価する例を示している。必須の段階だけ順序付きで定義し、途中に許容できる検索や確認が入ることは認める方法だ。
架空のPV調査なら、「公開記事を特定する」「対象期間のPVを取得する」「最大値を選ぶ」は必須でも、記事一覧と分析データのどちらを先に取得するかは問わない。一方、「PVを取得せず記事名を回答する」「下書きを公開記事として扱う」は明確な失敗にする。書き込みを伴う作業では、承認の前に実行した時点で最終結果に関係なく失敗とする基準も必要だ。
固定データセットで変更前後を比べる
不具合が見つかった実例、通常例、境界例、拒否すべき例を評価データセットへ加える。プロンプト、モデル、道具の説明、経路制御を変更したら、同じ入力で再実行し、最終結果とトレースの両方を比較する。OpenAIの資料も、良い状態を定義できた後は、個別トレースの確認から反復可能なデータセットと評価実行へ移ることを勧めている。
生成には揺らぎがあるため、重要な例は複数回試す。平均点だけでなく、危険な操作を一度でも試みた回数、タイムアウト率、最悪の呼び出し回数を見る。自動採点で差分を広く検出し、書き込みや安全性に関わる失敗は人がトレースを確認する。
本番の監視と事前評価をつなげる
事前評価は既知の例に強く、本番監視は想定外の依頼を見つける。実行成功率、道具別エラー率、再試行回数、処理時間、費用を継続して集計し、異常なトレースを個人情報へ配慮して確認する。見つかった失敗を匿名化して評価データセットへ戻せば、同じ不具合の再発を変更前に検出できる。
エージェント評価の目的は、もっともらしい回答へ点数を付けることではない。どの判断と操作で成功または失敗したかを特定し、安全性と費用を保ちながら改善できる状態を作ることだ。