Amazon Bedrock AgentCore Evaluations によるデシジョンモデルの活用

エージェントを評価する際に尋ねる質問の中には、狭くて繰り返し可能なものがあります。この応答はポリシーに従っていたか?このツール呼び出しは承認しても安全か?この回答は取得されたコンテキストと一致しているか?デシジョンモデルはまさにその種の質問に答えます。デシジョンモデルは構造化された状態と許可された回答の固定されたセットを受け取り、実行ごとに信頼度が揺れる自由形式のテキストではなく、それらに対する較正された確率を返します。そのため、ラベルと、しきい値を設定して信頼できる数値が必要となるエージェント評価のスコアリングステップに最適です。

「Amazon Bedrock AgentCore Evaluations」, Amazon Bedrock AgentCore の機能の 1 つであり、エージェントのライフサイクル全体にわたってスコアを評価します。開発中のオンデマンド評価、保存されたセッションに対するバッチジョブ、そして本番トラフィックに対するオンライン評価が可能です。15 種類の組み込み評価ツールに加え、AgentCore Evaluations は LLM-as-a-judge またはコードベースの評価ツールとして定義できるカスタム評価ツールをサポートしています。カスタム LLM-as-a-judge 評価ツールは、Amazon Bedrock のモデルに対して、お客様の指示と評価尺度を適用します。コードベースの評価ツールは、AWS Lambda 関数内でお客様自身のロジックを実行するものであり、そのロジックからは、意思決定モデルを含め、任意の外部システム、モデル、または API を呼び出すことができます。

決定モデルは、情報を持つ人が一目で判断できる、回答が固定された質問(エージェントがリクエストを拒否したかどうか、応答が話題に沿っていたかどうかなど)に適しています。自分のトラフィックで質問を検証した後は、その決定やスコアには決定モデルで十分であり、同じアプローチをポリシーにおける特定の有害性やステレオタイプのカテゴリに拡張できます。両方のバックエンドは1つのリクエストで同じ状態に関する複数の質問に回答できるため、それらを置き換えではなくスクリーニング層として使い、メトリック全体に合否のシグナルを実行して、組み込みの評価ツールによるより深い評価が值得するターンを選択できます。組み込みの評価ツールの説明は、何が問題だったのかを調査するのに役立ちます。

この投稿では、コードベースの評価ツール(evaluator)を通じて、2つの意思決定モデルバックエンドをAgentCore Evaluationsに接続する方法を示します。1つ目は ジェフ。TypeSafeが提供するホスト型の決定モデルです。2つ目は Strands Decider 2Bは、自分で実行できるオープンソースの決定モデルです。この記事を読み終える頃には、AgentCoreエバリュエータの入力を決定モデルのリクエストに変換し、モデルの確率をAgentCoreの評価結果に戻す方法を把握できるようになります。ただ、その前に、カスタムのLLM-as-a-judgeエバリュエータを使うべきのはどのような場合で、どのような場合に決定モデルのほうが適しているのでしょうか。次のセクションでは、決定モデルとは何か、そしてそのトレードオフについて解説します。

決定モデル

決定モデルとは、固定された選択肢の中から選択を行い、自由形式のテキストを生成するのではなく、キャリブレーションされた信頼度スコアを返すように訓練された、小型の特殊化モデルです。汎用の大規模言語モデル（LLM）エバリュエータは、根拠付きでスコアを生成します。決定モデルは代わりに、事前定義された回答に対する確率分布を生成します。これにより、閾値を設定したり、集約したり、プログラムから処理したりできる直接的な信頼度測定が得られます。このため、判断を固定された選択肢の中からの選択として表現できる評価タスクに決定モデルは適しています。たとえば「この応答はグラウンディングされているか？」や「エージェントはユーザーのゴールを達成したか？」などです。

決定モデルが最も有用なのは、バイナリの判断だけでなく、ラベルとともに適切にキャリブレーションされた信頼度スコアが必要な場合です。また、汎用LLMに解釈を任せることなく、特定のルーブリックを一貫して適用したい場合にも適しています。

TypeSafeのホスト型決定モデルであるJevと Strands Decider、Strands Agentsチームによるオープンソースの2 Billionパラメータの決定モデルは、どちらも3種類の質問タイプをサポートしています。A noul 質問はyes/noの質問を提示し、0（no）から1（yes）の間の確率を返します。 choice 質問は最大255の選択肢のうちどれが該当するかを問い、最も確率の高い選択肢と、完全な分布および信頼度を返します。 score 質問は2から10の順序付きレベルのうちどれが該当するかを問い、確率で重み付けされたスコア、レベルごとの分布、および信頼度を返します。多くの評価ルーブリックはこれらのタイプのいずれかに当てはまります。「この応答内のすべての事実はツールの結果によって裏付けられているか？」はyes/noの質問であり、「この応答は4段階のルーブリックでどの程度役に立ったか？」はscoreです。

決定モデル対LLM-as-a-judge

今日のAgentCoreに組み込まれているエバリュエータは、汎用LLMを使ってルーブリックに対するエージェントの応答を評価し、その判断を説明します。これは、評価において証拠の関連付け、欠落情報の特定、あるいは応答の掘り下げた分析が必要なタスク、つまり説明がスコアと同じくらい有用であるタスクにおいて価値があります。決定モデルはLLMエバリュエータの代替ではありません。コードベースのエバリュエータフレームワークによって可能になる追加機能です。組み込みエバリュエータによるより広範な評価と併せて、狭く明確に定義されたチェックに活用してください。

ソリューションの概要

これらの評価器タイプがどのように連携するかを示すために、この投稿では、決定論的なコードベースのチェック、組み込みのLLM-as-a-judge評価器、そしてJevまたはStrands Decider 2Bを基盤とする決定モデル評価器によって評価されるHRアシスタントエージェントのエンドツーエンドの例を構築します。

このエージェントはStrands Agentsで構築され、Amazon Bedrock AgentCoreの機能であるAgentCoreランタイムにデプロイされます。有給休暇(PTO)残高、PTO申請、人事ポリシー、福利厚生、給与明細といった固定のモックデータを返す5つのツールを使用して、従業員の質問に回答します。このコードサンプルでは固定データを使用することで、LLM-as-a-judgeや判断モデルからのエバリュエーターの動作を容易に検証できるようにしています。さらに正解データ(ground truth)があれば、各エバリュエーターが正しい失敗を捉えられているかを確認できます。このコードサンプルは、独自のユースケースにおいてLLM-as-a-judgeと比較した判断モデルのテストフレームワークを構築するのに役立ちます。

図1: コードベースのチェック、組み込み評価器、JevまたはStrands Deciderを基盤とする決定モデル評価器によって評価されるHRアシスタントのエンドツーエンドのアーキテクチャ

前提条件

サンプルをデプロイするには、以下が必要です。

• a 内の AWS アカウント 地域 AgentCore Evaluations が利用可能なリージョンに関する情報です。サンプルのデフォルトは米国西部 (オレゴン) です。
• Amazon CloudWatch Transaction Searchが有効化されました 「アカウント内に。」
• Amazon Bedrock での基盤モデルへのアクセス.
• Python 3.12 以降、AWS Command Line Interface(AWS CLI)、および Docker。
• JevにはTypeSafe APIキーが必要です。 typesafe.ai アクセスの詳細については。
• Strands Decider は、Strands Decider サーバーを実行するホストを必要とします。テスト用にはローカルで実行することも、Lambda 関数からアクセスできるように、仮想プライベートクラウド (VPC) 内の Amazon Elastic Compute Cloud (Amazon EC2) 上で実行することもできます。

実際の動作を見る

完全なコードサンプルは以下で確認できます: AgentCoreサンプルのGitHubリポジトリ。2つのPythonスクリプトがすべてを処理します:

• ../utils/deploy.py HRアシスタントをAgentCoreランタイムにデプロイします。
• evaluate.py 評価者をデプロイし、エージェントを呼び出して、評価モードを実行します。

実行 evaluate.py フラグなしで実行すると、5つのステップが実行されます:

1. Lambda実行ロールを作成し(AgentCoreLambdaEvaluatorRole).
2. 2つの決定論的Lambda評価者をパッケージ化してデプロイします: hr-response-length (エージェントの応答が長さの境界内に収まっているかをチェックするトレースレベルの評価者)と hr-fact-checker (既知のモックデータに対してHRの事実を正規表現で検証するセッションレベルの評価者)。
3. コントロールプレーンを通じて両方をAgentCoreのコードベース評価者として登録します。
4. オンデマンド評価を、5つのラベル付きシナリオにわたって EvaluationClient と OnDemandEvaluationDatasetRunner で実行し、コードベースの評価者と Builtin.Correctness, Builtin.Helpfulness、および Builtin.ResponseRelevance.
5. ライブセッションを100パーセントのサンプリング率で継続的にスコアリングするオンライン評価設定を作成します。

この時点で、決定論的なチェックとLLM-as-a-judgeによるスコアリングを備えた動作する評価パイプラインが完成しています。意思決定モデルの評価器はオプトイン式です。フラグを付けて追加でき、既存のフローを変更することなくベースの評価器と並行して実行されます。フラグ --with-jev --jev-secret-arn <ARN> を使用すると、 jev-evaluator がデプロイされ、3つの評価器が登録されます: JevGroundedness, JevHelpfulness、および JevGoalCompletion。フラグ --with-decider を使用すると、 strands-decider-evaluator がデプロイされ、Strands Decider 2Bをバックエンドとする同じ3つの評価器が登録されます。 --decider-ec2 を追加すると、Amazon EC2インスタンス、セキュリティグループ、IAMロール、Lambda VPC設定を手動のコンソール操作なしで自動プロビジョニングできます。

図2: evaluate.pyによってデプロイされる評価パイプライン。決定論的なチェックから組み込み評価器および意思決定モデルの評価器まで

各意思決定モデルのバックエンドは3つの評価器を提供します:

意思決定モデルで評価器を構築する

フラグの使い方 --with-jev と --with-decider を使うと、評価器として実行したいコードを完全に制御できるカスタムのコードベース評価器を作成できます。AWS Lambda 関数を作成し、その中で意思決定モデルを呼び出してラベルまたは数値を返します。この Lambda 関数は、AgentCore Evaluations のコードベース評価器として登録されます。

評価器として登録された Lambda は、エージェントの OpenTelemetry スパンを受け取ります。 spans.py モジュールは OpenTelemetry コンテンツが到達しうるさまざまな形式を正規化し、意思決定モデルの呼び出しに適した形式へと整形します。トレースレベルの評価では対象ターンと直前の簡単な履歴のみが送信されますが、セッションレベルでは会話全体が含まれます。

図3: コードベース評価器の Lambda が意思決定モデル向けに OpenTelemetry スパンを適合させ、その結果を AgentCore にマッピングし戻す仕組み

アダプタはモデルの確率分布を AgentCore 評価が期待する結果に変換します。 noul の質問では、 true の確率が値となり、最も確率の高い回答がラベルとなります。 score の質問では、値は [0, 1]にスケールされた確率加重の期待レベルとなります。 choice の質問では、事前定義された選択肢の値の加重平均となります。

自分のトラフィックで意思決定モデル評価器を検証する

ルーブリックを意思決定モデルの質問に書き換えるとき、あなたは古い測定のコピーではなく新しい測定を作り出しています。言い換えたルーブリックは、元の意図よりも厳しくなったり緩くなったりすることが多く、実際のセッションと照合して初めてそのズレが見えてきます。リリースゲートに意思決定モデル評価器を使用する前に、新しい測定を検証するのと同じ方法、つまり自分のトラフィックのラベル付きサンプルに対して検証してください。このセクションの目的は、その検証をエンドツーエンドで案内し、自信を持ってしきい値を設定できる評価器を完成させることです。

手順は5つのステップからなります。

ステップ1. ラベル付きサンプルを構築する。エージェントのトラフィックから保存済みセッションのセットを取り出し、関心のある失敗やエッジケースを十分にカバーできるようにします。ハッピーパスのみをカバーするサンプルでは、評価器がどこで壊れるかについて何も分かりません。

ステップ2. 人間による参照ラベルを取得する。質問が測定する特性について、3人の独立したラベル付け担当者に各ターンを採点してもらい、多数決を参照ラベルとします。全員一致だったターンと割れたターンを記録しておいてください。全員一致のターンは明確なケースですが、価値があるのは票が割れたターンです。モデルが目にする前に、ルーブリック自体の曖昧さを明らかにするからです。

ステップ 3. 両方の評価器を同じ入力で実行します。決定モデル評価器と、対応する組み込み評価器を、同じセッションに対して単一のバッチ評価で実行します。同一の入力を採点することこそが、比較を公平（apples to apples）なものにします。

ステップ 4. 結果を3つの視点で読み解きます。多数決ラベルと、易しい/難しいの分割が手元にあれば、評価器の準備が整っているかを判断する3つの問いに答えられます。

• 一致率：人間の判断と一致しているか？各評価器が多数決ラベルと一致する頻度を測定します。ただし質問ごとに測定してください。ある質問の精度は別の質問については何も示さないからです。そのうえで、易しい（全員一致）ケースと難しい（票が割れた）ケースに数値を分けてください。難しいケースでのみつまずく評価器は、人間のラベル付け作業者とよく似た挙動を示しており、それこそが望ましい状態です。
• キャリブレーション：信頼度スコアに意味はあるか？評価器が報告した確率でターンをグループ化し、各グループのラベルとの一致率を比較します。信頼度が高いほど精度も高くなるはずです。さらに、易しいケースが難しいケースより一貫して高い信頼度を示すかを確認します。そうであれば、モデルの不確実性は実際の曖昧さを捉えており、デフォルトの 0.5 に頼る代わりに、それらのグループを使って評価器ごとの決定しきい値を選べます。
• 不一致分析：どこで、なぜ食い違うのか？2つの評価器が互いに食い違うターンを特定し、それが人間が曖昧と判断したのと同じターンかを確認します。そして実際に読んでください。不一致の大半は質問の文言に起因しており、質問を見直せば解消されます。エラーが難しいケースに集中している場合は、問題はモデルではなくルーブリック側にあります。

ステップ 5. 何かが変わったらチェックを再実行します。これは一度きりの関門ではなく、繰り返し可能なチェックとして扱ってください。質問の文言を変更したり、新しいモデルバージョンに移行したりしたときは、そのたびに再実行します。各結果の説明にはそれを生成したモデルバージョンが記録されるため、どのスコアがどのバージョン由来かがわかります。

エージェントに最適な評価器セットの選択

組み込み評価器は、AgentCore Evaluations における幅広い評価戦略の基盤であり続けます。これらは応答をルーブリックとその補助コンテキストに照らして評価し、判断の理由を説明するため、開発者は何が間違っていたのかを調査できます。HR Assistant の場合、faithfulness 評価はツール結果と矛盾する主張を特定でき、helpfulness 評価は、エージェントが残高に関する質問には答えたものの、依頼されたアクションを完了し続けたままにしていることを指摘できます。

忠実性、有用性、正確性を担保するには、エビデンスの関連付け、欠落情報の特定、解法の検証を行うことが必要になる場合があります。プレプリント JEV-as-a-Judge: Accept When Confident, Escalate When Unsure は、関連する区別を「読むことと導出すること」として記述しています。狭範なデシジョンモデルのチェックはターンに注意を向けるためのフラグを立てることができ、一方組み込み評価器は確認に必要なより広範な評価と推論を提供します。デシジョンモデルは、代替ではなくゲートとして扱うときに最も力を発揮します。カスケードパターンは次のように機能します。まず、すべてのセッションのすべてのターンに対して高速で較正済みのデシジョンモデルを実行し、低コストの合格/不合格シグナルを取得します。その後、シグナルがしきい値を下回ったセッションにのみ、フルのLLM評価器を起動します。

図4: カスケードパターン。較正済みのデシジョンモデルがすべてのターンをスクリーニングし、低信頼度のターンのみが組み込み評価器にエスカレーションされる

次のセットアップをお勧めします:

1. 信頼する組み込み評価器を使用してオンライン評価を設定し、エージェント全体の品質の標準的な尺度としてください。
2. ドメイン固有の Yes/No および選択型の質問に対するデシジョンモデル評価器を同じ設定に追加し、さらに正確に計算できるものについては決定論的なコードベースの評価器を追加してください。
3. 毎週、またはリリースサイクルに合った任意のスケジュールで、デシジョンモデルのチェックが失敗した、またはしきい値に近いスコアとなったセッションのオンライン結果を照会し、それらのセッションに対して組み込み評価器によるバッチ評価を実行して説明を取得してください。
4. リリースは、組み込み評価器と、ラベル付きデータに対して検証済みのデシジョンモデル評価器によってゲートし、両者がどの程度一致するかを追跡してください。

クリーンアップ

継続的な課金を避けるため、 cleanup.py を実行してください。これにより、AgentCore ランタイム上にホストされたエージェント、評価器と評価設定、評価器として登録された AWS Lambda 関数、Strands Decider モデルをホストする EC2 インスタンス、AWS Secrets Manager のキー、および CloudWatch 上の関連するロググループが削除されます。

まとめ

この記事では、2つのデシジョンモデルである Jev と Strands Decider を、コードベースの評価器を使って AgentCore Evaluations に接続しました。付属のコードサンプルは、これらのモデルをテストし、評価器としてどこで価値を発揮するかを確認するためのフレームワークを提供します。組み込み評価器は引き続きベースラインです。デシジョンモデルは、しきい値を設定して対処できる一定の確からしさを伴う、狭範で検証済みのチェックを追加します。実践的な前進の道筋は、すでに実行している組み込み評価器と並行してデシジョンモデルのチェックを追加し、自身のトラフィック上で参照ラベルとどの程度一致するかを測定し、それらを信頼できるようになってからのみカバレッジを拡大することです。

始めるには、 Amazon Bedrock AgentCore Evaluations のドキュメントを確認し、カスタム評価器を統合してください。 コードベースの評価ツール を詳しく見ていきます Strands Decider モデルについて。サンプル評価ツールを Amazon Bedrock AgentCore サンプルリポジトリ.

からデプロイすることで、コードサンプルを使い始められます。著者について