AIエージェントを評価する再利用可能なフレームワークの構築方法

AIエージェントの開発チームは、システムが想定どおりに動作しているかを把握するために、最終的な回答を確認するだけでは不十分です。検索、生成、ツール呼び出しを組み合わせるアプリケーションでは、最終的な文章だけを見ると問題がそこにあるように見えても、実際には誤ったデータベースを選択したことや、不適切な文書を検索したことが原因で誤った結果になる場合があります。InfoQを通じて行った講演で、Elasticの主任データサイエンティストであるSusan Changは、同社がサイバーセキュリティや企業向けチャットボットで使用するエージェントを評価するための共通フレームワークをどのように開発したかを説明しました。

個別の評価から共通ツールへ

Elasticの各チームは当初、エージェントごとにデータセット、評価者、トレーシングの仕組みを個別に作成していました。攻撃検知エージェントの場合、テストにはアナリストやセキュリティ研究者が作成した攻撃シナリオと正常なシナリオが含まれ、適合率と再現率、事実の正確性、類似度、MITREの戦術分類などの指標が用いられました。一方、企業データに基づくチャットボットでは、文書に対する質問と検索がテストされ、回答の適合性と完全性、製品IDの正確性、ES|QLクエリの作成に重点が置かれていました。

こうしたケースの違いにより、作業の重複が大きくなりました。そこでElasticは、異なる種類のデータセットを統一スキーマに取り込める共通フレームワークを構築し、実行トレースに基づく評価や、RAGアプリケーション向けの共通評価器に加えて、各製品固有のコンポーネントも実行できるようにしました。このプロセスはローカルで実行でき、データを読み込み、エージェントを実行し、結果を収集したうえで、開発者にスコアを表示できます。

失敗の原因を理解するためのトレーシング

この経験は、エージェントのトレーシングを最終出力だけに限定すべきではないことを示しています。呼び出したツール、ベクトル検索とキーワード検索、検索されたデータ、トークン消費量、応答時間、意思決定の順序を記録する必要があります。この詳細な情報により、特定のツール呼び出しを評価したり、最終回答に問題が現れる前にエージェントが誤ったソースを使用したことを発見したりできます。

また、ユーザーが報告した失敗ケース、たとえば低い評価が付けられたケースを、テストセットの新しい例に変換することもできます。これにより、本番環境からのフィードバックが後続リリースの回帰テストの一部となり、開発サイクルから切り離された手作業のメモとして残ることを防げます。

なぜLLM-as-a-judgeだけでは不十分なのか

Elasticは、スタイル、整合性、コンテキストに対する回答の適合性など、オープンエンドまたは曖昧なタスクで、あるモデルの出力を別のモデルが評価するために言語モデルを使用しました。このアプローチにより、長いテキストを評価するための正確なルールを書くことが難しい場合でも、評価を拡張できます。しかし、実行ごとに結果がばらつく可能性があり、存在しない製品IDや無効なクエリの作成など、特定のエラーを検出できない場合があります。

そのためElasticは、LLM-as-a-judgeと、ルールおよびプログラムに基づく決定論的な評価を組み合わせました。これらの評価では、JSONまたはYAMLの構造、構文の正しさ、必要なエンティティの存在、コードやクエリを実行できるかどうかに加え、適合率、再現率、事実の正確性などの指標を検査します。この組み合わせにより、明確な正解があるケースでは評価のコストと速度を改善し、ルールに還元しにくいタスクでは意味的な判断を委ねることができます。

何を一般化できないのか

Elasticは、専門的なテストデータの作成を完全に自動化できる部分とは考えていませんでした。サイバーセキュリティでは、何が実際の攻撃を構成するのか、またエンドユーザーにとってどのような挙動が許容されるのかを、チーム内のアナリストや研究者が定義する必要があります。さらに、回帰の定義はエージェントごとに異なります。たとえば、特定の更新後に正常なデータを入力しても攻撃が存在すると宣言しやすくなるセキュリティエージェントが考えられます。

評価器の較正は、依然として各チームの責任です。言語評価器が同じケースに異なるスコアを付けたり、目標とする人間の判断と一致しなかったりする場合、ソフトウェア基盤の品質がどれほど高くても、共通フレームワークは誤解を招く数値を生み出します。Changはまた、生成と評価に同じモデルファミリーを使用すると、評価器にバイアスが生じ、そのモデルの性能を過大評価する可能性があると指摘しました。

チームにとって実際に何が変わるのか

Elasticの経験では、理想的なセットが整うのを待つのではなく、20～50件程度の小規模なテスト例から始めることを推奨しています。初期段階では、特にユースケースと指標がまだ模索中である場合、学習を加速するために個別の作業を行うことも許容されます。しかし、複数のエージェントが本番環境に導入されると、性能に関する質問に答え、ユーザーの問題を診断するために、基本的なトレーシングと評価が不可欠になります。

Elasticはまた、評価ツールの一部をPythonからTypeScriptへ移行し、TypeScriptで書かれた本番コードやPlaywright、Scoutという社内向けの専用ツールに適合させました。この移行は、すべてのデータサイエンス評価を移す必要があるという意味ではなく、チームがテストしているものとシステムが実際に実行しているものの隔たりを縮小するという、特定の必要性を反映したものです。実務上の結論は、共通フレームワークによってスキーマ、実行、一般的な指標を統一することはできますが、ドメイン知識や、何を成功と失敗とみなすべきかを判断することに取って代わることはできない、ということです。