エージェントが動作するのは、ただの第一歩です。著者：elune
記事の編集・出典：ME News
エージェントが動作するのは、ただの第一歩です。
本当に難しいのは、それが安定しているか、正しいか、あるいは一度のプロンプトやモデルの更新によって静かに劣化しているかどうかを判断することである。
以下の10の評価手法は、すべてのAIエンジニアが理解する価値があります。
1. ゴールデンセット｜Golden Set
固定された凍結済みのテストケースを準備してください。
プロンプト、モデル、ツール、またはワークフローを変更するたびに、この一連のケースを再実行し、システムが改善されたか、あるいは特定のシナリオで静かに機能しなくなったかを判断してください。
それはエージェント評価システムにおける最も基本的なベンチマークです。
推奨ツール：OpenAI Evals
繰り返し実行可能なベンチマークセットを構築し、異なるモデルまたはシステムバージョンのパフォーマンスを比較できます。
2. LLM 裁判｜LLM as Judge
別の大規模言語モデルを使用して、事前に定義された評価基準に基づいて開かれた回答を評価します。
タスクに唯一の正解がなく、文字列マッチングや固定出力で正誤を判断できない場合、この方法は特に有効です。
例えば、裁判モデルを使用して、回答が正確で、完全で、関連性があり、ユーザーの要件に従っているかを評価できます。
推奨ツール：OpenEvals
LLMアプリケーション向けに準備済みの評価ツールを提供し、自動化されたレビュープロセスを迅速に構築できます。
3. 多次元評価｜Rubric Scoring
エージェントに単なる「品質スコア」だけを与えないでください。
それぞれ評価すべきです。
- 正確性
- 整合性
- 表現スタイル
- セキュリティ
- 応答速度
- 呼び出しコスト
総合スコアは本当の問題を隠す可能性があります。
たとえば、総点が下がったのは答えが間違っているのではなく、ツール呼び出しのコストが急増したためかもしれない。総点が上がった場合も、セキュリティの低下を伴っている可能性がある。
推奨ツール：DeepEval
カスタム指標の作成をサポートし、異なる品質次元に対して独立したスコアを付与できます。
4. 軌跡評価｜Trajectory Eval
エージェントが最終的に提示した答えだけでなく、タスクを完了するまでの全体のプロセスも評価してください。
含む：
- 正しいツールを選択しましたか？
- ツールを適切な順序で呼び出していますか
- 無効な操作を繰り返していますか
- 必要なステップが見落とされていませんか？
- ツールの結果に基づいて意思決定を適切に調整しましたか
エージェントは最終的に正しい答えに到達する可能性がありますが、そのプロセスは非効率的で脆弱であり、リスクを伴うこともあります。
推奨ツール：AgentEvals
Agentの完全な実行トレースにおけるアクション、意思決定、ツール呼び出しを確認できます。
5. ツール単体テスト｜Tool Unit Tests
エージェントが使用する各ツールに対して独立したテストを記述してください。
固定入力を使用して固定出力を検証し、モデルを関与させない。
これで問題を分割できます：
Agentの推論に問題があるのか、それとも基盤のツール、インターフェース、またはMCPサーバーに問題があるのか？
ツール自体が信頼できるかどうかをまず確認した上で、エージェントがツールを正しく呼び出しているかを評価する意味がある。
推奨ツール：MCP Inspector
MCPサーバー、ツールパラメーター、および返却結果の確認とテストに使用できます。
6. リグレッションテストセット｜Regression Suite
過去の実際の実行ケースを保存し、プロンプト、モデル、またはツールセットを更新するたびに再実行してください。
その後、新旧バージョンの結果を比較して確認してください：
- 原本正しいタスクは失敗しましたか
- 出力形式は変更されますか
- ツールの呼び出しは増加しましたか？
- 遅延とコストは上昇しましたか
- 一部のエッジケースが劣化するかどうか
新しいバージョンの平均的なパフォーマンスが優れているからといって、旧機能を破壊していないとは限らない。
推奨ツール：Promptfoo
繰り返し可能な評価スイートの実行をサポートし、回帰問題を検出、チェックプロセスをCIに統合します。
7. 運用環境でのA/Bテスト｜A/B Testing in Production
実際のユーザーのトラフィックを二つの異なるバージョンにランダムに割り当て、実環境でのパフォーマンスを比較します。
テストできます：
- 二つのプロンプト
- 二つのモデル
- 两种Agentワークフロー
- 異なるツールの組み合わせ
- 異なる返信戦略
オフラインスコアが高いバージョンは、必ずしもユーザーの成功率を高めるとは限りません。
真正に重要なのは、タスク完了率、ユーザー採用率、変換率、人間対応率、および問題解決率などの実際の結果です。
推奨ツール：GrowthBook
機能スイッチ、制御された実験、および製品分析機能を提供します。
8. 人間による審査｜Human Review
定期的に実行記録をサンプリングし、人間の審査者が評価します。
手動監査は、自動評価で見落とされた問題を発見するだけでなく、LLMジャッジのキャリブレーションにも使用できます。
重点チェックが必要：
- モデルのスコアリングは人間の判断と一致していますか
- 評価基準は十分に明確ですか
- 裁判モデルは冗長な回答を好むのでしょうか
- 自動で重大な漏れエラーを評価する
自動評価は人間の判断を完全に置き換えることはできません。
推奨ツール：Argilla
チームが人間のフィードバックを収集し、モデルの出力をレビューして、結果を高品質なデータセットとして蓄積するのを支援します。
9. シャドウラン｜Shadow Run
候補バージョンを実際のトラフィック上で同期して実行し、その出力をユーザーに表示しないでください。
本番環境では依然として旧バージョンを使用しており、新バージョンはバックグラウンドでのみ実行され、両者のパフォーマンスを比較するために使用されます。
この方法は、高リスクの更新に適しています。例えば：
- コアモデルを変更する
- システムプロンプトを書き直す
- 新しい外部ツールを接続
- Agentの意思決定ロジックを変更する
- ツールの権限を拡大
シャドウランニングにより、チームは本番リリース前に実際のトラフィックでの問題を発見しつつ、ユーザーへの直接的な影響を回避できます。
推奨ツール：Langfuse
生産ランの追跡、候補バージョンの比較、および評価結果のモニタリングが可能です。
10. レッドチームテスト｜Red Teaming
攻撃者よりも前に、自システムを攻撃する。
テスト範囲には以下が含まれます：
- ジャイルブレイク攻撃
- プロンプトインジェクション
- 機密情報の漏洩
- 権限バイパス
- ツールの悪用
- 悪意のあるファイルまたはウェブページコンテンツ
- 予期しない外部操作
データベースを呼び出し、メールを送信し、ファイルを変更し、コードを実行し、内部システムにアクセスできるエージェントに対して、レッドチームテストは特に重要です。
推奨ツール：Garak
LLMシステム内のセキュリティ脆弱性と不安全な行動をスキャンできます。
オフライン評価は、システムがテスト環境で正常に動作することを示しています。
オンライン評価は、システムが稼働後も正常に動作することを示しています。
現在、10種類の評価メカニズムをすべて一度に構築する必要はないかもしれません。
より現実的な方法は：
直近のAgent障害を振り返り、事前に問題を発見できた可能性のある2つの評価手法を優先的に導入する。
まずゴールドテストセットを構築し、その後にリグレッションテストや手動チェックを追加すれば、多くの低レベルの事故を回避できる。
保存しておきましょう。