エージェントを評価するときの問いには、範囲が狭く繰り返し確認できるものがあります。この応答はポリシーに従っているか、このツール呼び出しは承認して安全か、回答は取得したコンテキストと一致しているか、といった問いです。決定モデルはまさにこうした問いに適しています。構造化された状態と固定された許容回答の集合を受け取り、実行ごとに揺らぐ自由記述テキストではなく、較正された確率分布を返します。そのため、閾値を設定して信頼できるラベルと数値が欲しいエージェント評価のスコアリング段階に向いています。
Amazon Bedrock AgentCore EvaluationsはAmazon Bedrock AgentCoreの機能で、開発中のオンデマンド評価、保存済みセッションに対するバッチジョブ、本番トラフィックに対するオンライン評価など、エージェントのライフサイクル全体を通じてスコアリングを行います。15個の組み込み評価器に加え、LLM-as-a-judgeまたはコードベースの評価器として定義するカスタム評価器もサポートします。カスタムのLLM-as-a-judge評価器はAmazon Bedrockのモデルで指示と評価スケールを適用します。コードベースの評価器は独自のロジックをAWS Lambda関数で実行し、そのロジックは決定モデルを含む任意の外部システム、モデル、APIを呼び出せます。
決定モデルは、エージェントが要求を拒否したか、応答が話題から外れていないかなど、事情に通じた人が一目で判断できる固定の回答集合を持つ問いに適します。自社トラフィックで問いを検証した後であれば、決定モデルはその判断やスコアに十分な精度を持ち、同じ手法をポリシー内の特定の有害性やステレオタイプのカテゴリにも広げられます。両方のバックエンドは同一リクエストで同じ状態に関する複数の問いに答えられるため、置き換えではなくスクリーニング層として使えます。各指標に合否シグナルを出して、組み込み評価器による詳細評価に値するターンを選び出し、その説明を使って何が問題だったかを調査できます。
本記事では、2つの決定モデルバックエンドをコードベースの評価器を通じてAgentCore Evaluationsに接続する方法を示します。1つはTypeSafeのホスト型決定モデルJev、もう1つは自分で運用するオープンソースの決定モデルStrands Decider 2Bです。読み終える頃には、AgentCore評価器の入力を決定モデルのリクエストに変換し、モデルの確率をAgentCoreの評価結果に戻す方法が分かります。その前に、カスタムのLLM-as-a-judge評価器をいつ使い、決定モデルがより適するのはどんな場合かを整理します。
決定モデルは、固定された選択肢から選び、自由記述ではなく較正された信頼度スコアを返すように訓練された小型の専門モデルです。汎用の大規模言語モデル（LLM）評価器は根拠付きのスコアを出しますが、決定モデルは事前定義された回答上の確率分布を出します。これにより、閾値設定、集約、プログラムによる処理が可能な直接的な信頼度指標が得られます。このため決定モデルは、「この応答は根拠に基づいているか」「エージェントはユーザーの目標を達成したか」のように固定の選択肢の中の選択として表現できる評価タスクに適しています。
決定モデルは、単なる二値判断ではなくラベルとともに十分に較正された信頼度スコアが欲しい場合に最も有用です。また、汎用LLMに解釈を任せず、特定の評価基準を一貫して適用したい場合にも適しています。
TypeSafeのホスト型決定モデルJevと、Strands Agentsチームによるオープンソースの20億パラメータ決定モデルStrands Deciderは、どちらも3種類の問いをサポートします。noul質問ははい・いいえの問いを提示し、0（いいえ）から1（はい）の確率を返します。choice質問は最大255個の選択肢のうちどれが当てはまるかを尋ね、最も確率の高い選択肢と分布全体、信頼度を返します。score質問は2〜10個の順序付きレベルのうちどれが当てはまるかを尋ね、確率で重み付けしたスコア、レベルの分布、信頼度を返します。多くの評価基準はこのいずれかに当てはまります。「この応答のすべての事実はツール結果に支持されているか」ははい・いいえの問いであり、「この応答は4段階評価でどれほど役立ったか」はscoreです。
AgentCoreの現在の組み込み評価器は、汎用LLMを使って評価基準に対するエージェント応答の評価と判断の説明を行います。根拠をつなぎ合わせる必要がある場合、不足情報を特定する場合、説明がスコアと同じくらい有用な場合には価値があります。決定モデルはLLM評価器の代替ではなく、コードベース評価器の枠組みによって可能になる追加手段です。組み込み評価器のより広い評価と並行して、狭く明確に定義されたチェックに使います。
これらの評価器の種類がどう連携するかを示すため、本記事では決定論的なコードベースチェック、組み込みのLLM-as-a-judge評価器、そしてJevまたはStrands Decider 2Bに支えられた決定モデル評価器で評価されるHRアシスタントのエンドツーエンド例を構築します。このエージェントはStrands Agentsで構築され、AgentCore runtimeにデプロイされます。有給休暇の残日数、休暇申請、HRポリシー、福利厚生、給与明細といった固定のモックデータを返す5つのツールで従業員の質問に答えます。サンプルで固定データを使うのは、LLM-as-a-judgeと決定モデルの評価器の挙動を検証しやすくするためです。さらに正解データがあれば、各評価器が正しい失敗を捉えているかを確認できます。
サンプルをデプロイするには、AgentCore Evaluationsが利用可能なリージョンのAWSアカウント（既定は米国西部オレゴン）、Amazon CloudWatch Transaction Searchの有効化、Amazon Bedrockの基盤モデルへのアクセス、Python 3.12以降、AWS CLI、Dockerが必要です。JevにはTypeSafe APIキーが必要で、Strands DeciderはLambda関数から到達できるホストでStrands Deciderサーバーを動かす必要があります。ローカルでテスト実行するか、VPC内のAmazon EC2上で運用できます。
完全なコードサンプルはAgentCore samplesのGitHubリポジトリにあり、2つのPythonスクリプトがすべてを担います。deploy.pyはHRアシスタントをAgentCore runtimeにデプロイし、evaluate.pyは評価器のデプロイ、エージェントの呼び出し、評価モードの実行を行います。フラグなしでevaluate.pyを実行すると5つの手順が走ります。まずLambda実行ロールを作成し、次に2つの決定論的Lambda評価器をパッケージしてデプロイします。hr-response-lengthはエージェント応答が長さの範囲内かを確認するtraceレベルの評価器、hr-fact-checkerは既知のモックデータに対して正規表現でHRの事実を検証するsessionレベルの評価器です。続いて両者をコントロールプレーン経由でAgentCoreのコードベース評価器として登録し、EvaluationClientとOnDemandEvaluationDatasetRunnerで5つのラベル付きシナリオに対するオンデマンド評価を、コードベース評価器と組み込みのCorrectness、Helpfulness、ResponseRelevanceを組み合わせて実行します。最後に、ライブセッションを100%のサンプリング率で継続的にスコアリングするオンライン評価設定を作成します。
この時点で、決定論的チェックとLLM-as-a-judgeスコアリングを備えた評価パイプラインが動作しています。決定モデル評価器はオプトインで、フラグを付けると既存フローを変えずに並行して動作します。--with-jev --jev-secret-arnを使うとjev-evaluatorがデプロイされ、JevGroundedness、JevHelpfulness、JevGoalCompletionの3つの評価器が登録されます。--with-deciderを使うとstrands-decider-evaluatorがデプロイされ、Strands Decider 2Bに支えられた同じ3つの評価器が登録されます。--decider-ec2を加えると、EC2インスタンス、セキュリティグループ、IAMロール、LambdaのVPC設定がコンソール操作なしで自動的に用意されます。
各決定モデルバックエンドが提供する評価器は次のとおりです。Groundednessはtraceレベルのnoul質問で、ラベルはGroundedまたはUngrounded、値はP(grounded)です。Helpfulnessはtraceレベルの4段階score質問で、ラベルは最も確率の高いレベル、値は0〜1にスケールした期待レベルです。GoalCompletionはsessionレベルの3択choice質問で、ラベルは最も確率の高い選択肢、値は確率で重み付けした値です。
--with-jevと--with-deciderを使うと、評価器として実行するコードを完全に制御できるカスタムのコードベース評価器が作成されます。AWS Lambda関数を作成し、その中で決定モデルを呼び出してラベルまたは数値を返し、この関数をAgentCore Evaluationsのコードベース評価器として登録します。評価器として登録されたLambdaはエージェントのOpenTelemetryスパンを受け取ります。spans.pyモジュールはスパンの内容が取り得る形を正規化し、決定モデルへの呼び出しに適した形式に整えます。traceレベルの評価では対象のターンと短い直前履歴のみを送り、sessionレベルでは会話全体を含めます。アダプタはモデルの確率分布をAgentCore評価が期待する結果に変換します。noul質問では真の確率が値となり、最も確率の高い回答がラベルになります。score質問では値は[0,1]にスケールした確率加重の期待レベル、choice質問では事前定義された選択肢値の加重平均です。
評価基準を決定モデルの問いに書き換えると、元の尺度のコピーではなく新しい測定を作ることになります。書き換えた基準は意図より厳しくなったり緩くなったりすることが多く、そのずれは実際のセッションと照らし合わせるまで分かりません。決定モデル評価器をリリース判定に使う前に、あらゆる新しい測定と同様、自社トラフィックのラベル付きサンプルに対して検証してください。手順は5段階です。まず、関心のある失敗やエッジケースを十分に含む保存済みセッションを抽出します。正常系だけのサンプルでは評価器が破綻する箇所は分かりません。次に、3人の独立したラベラーが各ターンを測定対象の性質について採点し、多数決を参照ラベルとします。どのターンが全員一致でどれが割れたかを記録します。全員一致は明確なケースですが、票が割れたターンこそ価値があり、モデルが目にする前に評価基準自体の曖昧さを明らかにします。第3に、同じ入力に対して決定モデル評価器と対応する組み込み評価器を1回のバッチ評価で実行します。同一入力のスコアリングが比較の土台となります。