エージェント評価は、高速なオンラインシグナルと安定したオフラインベースラインを組み合わせることで最も効果的です。エージェントが時間の経過とともに真に改善されているかどうかを理解するには、変化する実世界のトラフィックとともに固定ベンチマークが必要です。
Amazon Bedrock AgentCoreで評価ベースラインのテストケースをデータセットとして管理することは、バージョン管理されたテストフィクスチャの規律をエージェント評価にもたらします。入力、期待される出力、アサーション、ツールシーケンスを含むシナリオを作成し、実行中に変化しない不変の番号付きバージョンとして公開できます。変更可能なドラフトで自由に反復し、チェックポイントをロックする準備ができたら公開します。そして、本番環境で何かが壊れた場合、その障害は永続的なテストケースとなり、将来のすべての変更がそれに対して評価されます。
この投稿では、金融市場インテリジェンスエージェントを使用して完全なワークフローを説明します。本番トレースから障害をキャプチャし、バージョン管理されたデータセットを構築し、評価を実行し、エージェントを修正し、同じロックされた入力に対する改善を確認します。
なぜデータセットが重要なのか
エージェントは設計上非決定的です。同じ入力が実行ごとに異なる出力を生成する可能性があり、単一の評価結果をほぼ無意味にします。スコアが動いた理由がエージェントの変更なのか、モデルのサンプリングの違いなのかを判断できません。安定した入力にわたる一貫した測定のみが、変更が実際に役立ったかどうかを知る唯一の方法です。
しかし、安定した入力だけでは十分ではありません。大規模言語モデル（LLM）ジャッジは、応答が役立つように聞こえるかどうかを教えてくれますが、株価が正確かどうか、ブローカーワークフローが正しい順序で実行されたかどうか、セッション間で個人識別情報（PII）が漏洩したかどうかを判断することはできません。これらのチェックにはグラウンドトゥルースが必要です：期待される応答、必要なツールシーケンス、応答の表現方法に関係なく成立しなければならないアサーション。グラウンドトゥルースは主観的なスコアを検証可能な測定に変えます。それなしでは、正しさそのものではなく、正しさの外見を測定していることになります。
バージョン管理されたデータセットは両方を提供します。スコアが実行間で比較可能になるように入力を固定し、それらのスコアに意味を与えるグラウンドトゥルースを保持します。これは、エージェント評価が実際に行われる2つの場所で最も重要です。
内部ループは開発者のデスクです。エージェントを呼び出し、スコアを読み取り、ツールの説明を調整し、再度呼び出します。サイクルは数分です。この段階での問題は評価の実行ではなく、テストケースが手近にあるものになりがちなことです：先週誰かが書いた質問や偶然保存したセッション。スコアが向上したとき、修正が機能したと信じたいものです。しかし、その下に安定した入力がなければ、エージェントが良くなったのか、質問が簡単になったのかを知ることはできません。
外部ループはCI/CDパイプラインです。変更がリリースされる前に、何も壊していないことを確認する何かが必要です。ほとんどのチームにはこのゲートがあります。彼らがしばしば欠いているのは、明示的なアサーションを伴う安定したバージョン管理された入力セットです。これは、ゲートが誰かが最後に指したものをテストしていることを意味し、チェックするグラウンドトゥルースがありません。質問が変わったためにビルドをパスするパイプラインは、リグレッションをキャッチしているのではなく、見逃しています。
バージョン管理されたデータセットはそのギャップを埋めます。開発者は内部ループで障害をドラフトにキュレートします。外部ループでは、そのドラフトの公開バージョンがゲートになります。不変で、グラウンドトゥルースはそのままで、前のスプリントと同じシナリオをテストします。開発者に修正が機能したことを伝えた同じスコアが、パイプラインがリリースを決定するために使用するスコアです。
2種類のテストシナリオ
Amazon Bedrock AgentCoreのデータセットは、これら2つのループに異なる方法でサービスを提供する2つのスキーマタイプをサポートしています。
事前定義シナリオは過去志向です。ユーザーがエージェントに送信する正確なクエリを定義し、正しい結果がどのようなものかを知っています：期待される応答、ツールシーケンス、成立しなければならないアサーション。それらを書き留め、評価者がエージェントがそれらを満たしたかどうかをチェックします。障害が事前定義シナリオとして形式化されると、将来のすべての評価実行に残ります。これらは外部ループゲートに属します。なぜなら、合格および不合格の基準が明示的で再現可能であり、会話の進行に依存しないからです。
ユーザーシミュレーションシナリオは未来志向です。ターンをスクリプト化する代わりに、ペルソナを記述します：誰がアクターか、何を達成したいか、どのようにコミュニケーションするか。LLMバックのアクターがエージェントと実際のマルチターン会話を駆動し、目標が達成されるかターン制限に達するまで続きます。アクターが何を言うかはスクリプト化しません。カバレッジは相互作用から生まれます。詳細については、AgentCoreユーザーガイドのユーザーシミュレーションを参照してください。
これは標準の評価ツールキットのどの機能とも異なります。事前定義シナリオは、エージェントが特定の入力を正しく処理するかどうかをテストします。シミュレートされたシナリオは、ユーザーが取るパスに関係なく、エージェントがユーザーのタイプを満たすことができるかどうかをテストします。
この投稿では、マーケットトレンドエージェントを実行例として使用します。このエージェントは金融機関の投資ブローカーにサービスを提供します。ブローカーは「モルガン・スタンレーのSarah Chenです。テクノロジーとクリーンエネルギーに焦点を当てています。今日のNVDAの状況は？」のようなメッセージをエージェントに送信します。エージェントはブローカーを識別し、AgentCore Memoryに好みを保存し、現在のNVIDIA株価を取得し、BloombergとReutersの関連ニュースを検索します。次に、データをSarahの投資焦点に結び付けるパーソナライズされたブリーフィングを提供します。Sarahが翌日戻ってくると、エージェントは彼女のプロファイルを記憶し、それに応じて応答を調整します。
事前定義シナリオの場合、ユーザーがエージェントと対話した本番トレースがあり、それらを評価データセットにキュレートできます。マーケットトレンドエージェントの例は次のようになります：
PreDefinedScenario{ "scenario_id": "broker_profile_onboarding", "turns": [ { "input": ( "こんにちは、モルガン・スタンレーのSarah Chenです。" "テクノロジーとクリーンエネルギーに焦点を当てています。" "リスク許容度：中高。" "顧客ベース：機関投資家および高 net worth。" ) } ], "expected_trajectory": {"toolNames": ["identify_broker", "update_broker_financial_interests"]}, "assertions": [ "エージェントは名前と会社でブローカーを識別します。", "エージェントはブローカーのセクターの好みとリスク許容度を保存します。", "エージェントはプロファイルの受信を確認し、支援を提供します。" ], "metadata": {"category": "onboarding", "priority": "high"}, }
シミュレートされたシニアテクノロジーアナリストは、NVIDIA Corporation Common Stock（NVDA）に関する広範な質問から始めるかもしれません。彼女は応答が薄いと感じたときに詰め寄り、AMDとの比較を要求し、クライアントコールで引用できるものを持っているときにのみ完了を合図します。誰もこれらのターンをスクリプト化していません。アクターはプロファイルからそれらを生成しました。このシナリオは次のように定義できます：
SimulatedScenario( scenario_id="sim-tech-analyst-nvda-amd-deep-dive", scenario_description=( "シニアテクノロジーリサーチアナリストが、クライアントコールに先立って深く引用可能なNVDA対AMDのブリーフィングを追求します。" ), actor_profile=ActorProfile( traits={ "expertise": "シニア", "focus": "半導体", "style": "懐疑的でデータ駆動型" }, context=( "高価値クライアントコールのトーキングポイントを準備する売り側のシニアテクノロジーアナリスト。表面的な要約ではなく多層的な分析を期待し、回答が一般的または薄いと感じたときに詰め寄ります。" ), goal=( "NVIDIAについて質問し、より豊富な詳細を要求し、AMDとの構造化比較を要求し、クライアント会話のための引用可能なポイントを持っているときにのみ終了することで、エージェントの半導体ドメインの深さをプレッシャーテストします。" ) ), input=( "クライアントコールの準備をしており、NVIDIAについて迅速だが確かなブリーフィングが必要です。NVDAの最近のパフォーマンスと半導体でのポジショニングから始めてください。" ), max_turns=8, assertions=[ "エージェントは最近のパフォーマンスとポジショニングを含む初期のNVDAサマリーを提供します", "エージェントはNVDAのより深いファンダメンタルズ、製品/ロードマップ、または堀の詳細で応答します", "エージェントは構造化されたNVDA対AMDの比較（例：評価、成長、セグメント）を作成します", "エージェントはクライアントコールに適した特定の引用可能なデータポイントまたはメトリクスを含みます" ] )
ユーザーシミュレーションは、まだ発見していない障害モードがわからない場合に内部ループで特に役立ちます。表面化した障害は次のデータセットバージョンの事前定義シナリオの候補となり、外部ループゲートに直接フィードバックされます。
シミュレーションの内部動作について知っておくべきことがいくつかあります。アクターはSimulationConfigで指定するBedrockモデルで実行されます。各ターンで、アクターはエージェントの応答を受け取り、3つのものを生成します：目標が達成されたかどうかに関する内部推論、次に送信するメッセージ、および停止シグナル。会話は、アクターが完了をシグナルするとき、max_turnsに達したとき、またはアクターが次のメッセージを生成しないときに終了します。会話パスは動的であるため、シミュレートされたシナリオはexpected_trajectoryやターンごとのexpected_responseをサポートしていません。代わりにアサーションをグラウンドトゥルースとして使用し、会話がどのようにそこに到達したかに関係なく期待する結果を記述します。
マーケットトレンドエージェントの場合、事前定義シナリオはすでにブローカーに損害を与えた価格ドリフトバグをカバーします。シミュレートされたシナリオは、まだ障害を表面化していないが、エージェントが適切に処理する必要がある実際のユーザータイプを表すESGスペシャリストをカバーします。
AgentCoreでのデータセットの仕組み
データセットは、ARN、IAM認可、タグを持つファーストクラスリソースとしてAgentCoreに組み込まれています。Amazon S3バケットをプロビジョニングしたり、外部サービスを設定したりする必要はありません。
ドラフトと公開。すべてのデータセットには1つの変更可能なドラフトがあり、そこでシナリオを自由に追加および削除できます。安定したチェックポイントが必要な場合は、公開します。ドラフトは不変の番号付きバージョンになります。評価実行をバージョン3に固定すると、その後にドラフトに追加したものに関係なく、バージョン3にあった正確なシナリオが使用されます。
書き込み時のスキーマ検証。データセットを作成するときにスキーマタイプを宣言し、すべてのシナリオは受け入れられる前にそのスキーマに対して検証されます。不正な形式の例は、30分の評価実行の中間でエラーとして現れるのではなく、インジェスト時に拒否されます。
1つのデータセット、複数のランナー。DatasetManagementServiceProviderでデータセットをロードし、迅速なシナリオごとのフィードバックのためのオンデマンドランナー、または複数のセッションにわたる集計スコアリングのためのバッチランナーのいずれかに渡します。デスクで反復する場合でも、デプロイメントをゲートする場合でも、同じシナリオ、アサーション、データセットIDが適用されます。
エージェント：マーケットトレンドアシスタント
実行例として、AgentCore RuntimeにデプロイされたLangGraphアプリケーションであるマーケットトレンドエージェントを使用します。完全なソースコードはAgentCoreサンプルリポジトリの02-use-cases/market-trends-agentにあります。このエージェントには、金融ブローカーからのクエリに対応するための以下のツールがあります：
ツール 機能
get_stock_data ティッカーの現在価格、日次変化、出来高。 search_news マルチソース金融ニュース検索（Bloomberg、Reuters、CNBC、WSJ、FT）。 identify_broker メッセージからブローカーIDを抽出してメモリルックアップ。 get_broker_financial_profile 保存された好み、リスク許容度、セクターフォーカスを読み取り。 update_broker_financial_interests 新しい好みを長期メモリに書き込み。
3つの障害モードが頻繁に発生するため、永続的なテストケースに値します：
古い価格 — エージェントが新しい呼び出しを行う代わりにキャッシュされたツール応答を再利用したため、リアルタイム値から2％以上ドリフトした数値を引用。
IDチェックのスキップ — エージェントが最初にidentify_brokerを呼び出さずにget_broker_financial_profileに直接ジャンプし、間違ったブローカーの好みを取得する可能性がある。
[AICostControlのために切り詰め]