用决策模型配合 Amazon Bedrock AgentCore Evaluations 做智能体评估

在评估智能体时，你提出的有些问题范围窄且可重复。这个回答是否遵守了策略？这个工具调用是否可以安全批准？这个答案是否与检索到的上下文相符？决策模型正是用来回答这类问题的。它们接收结构化状态和一组固定的允许答案，并返回在这些答案上的校准概率，而不是返回置信度会随每次运行而漂移的自由文本。这使得它们非常适合智能体评估中的评分步骤，因为在这一步你需要一个可以设定阈值并信任的标签和一个数值。

Amazon Bedrock AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项能力，可在智能体的整个生命周期中对其进行评分：开发期间按需评分、针对已存储会话的批处理任务评分，以及针对生产流量的在线评分。除了 15 个内置评估器外，AgentCore Evaluations 还支持自定义评估器，你可以将其定义为 LLM-as-a-judge 或基于代码的评估器。自定义 LLM-as-a-judge 评估器使用 Amazon Bedrock 中的模型来应用你的指令和评分量表。基于代码的评估器在 AWS Lambda 函数中运行你自己的逻辑，该逻辑可以调用你选择的外部系统、模型或 API，包括决策模型。

决策模型适合那些答案固定、知情者一眼就能判断的问题，例如智能体是否拒绝了某个请求，或者某个回答是否切题。在你用自己的流量验证了某个问题之后，决策模型可能就足以做出该判断或评分，并且你可以将同样的方法扩展到策略中特定的有害性或刻板印象类别。由于两种后端都能在单个请求中回答关于同一状态的多个问题，你可以将它们用作筛选层而非替代品，在你的各项指标上运行通过或失败信号，以选出值得由内置评估器进行更深入评估的轮次，内置评估器的解释有助于你调查出了什么问题。

本文展示如何通过基于代码的评估器将两个决策模型后端连接到 AgentCore Evaluations。第一个是 Jev，来自 TypeSafe 的托管决策模型。第二个是 Strands Decider 2B，一个你自己运行的开源决策模型。读完本文后，你将了解如何将 AgentCore 评估器输入转换为决策模型请求，以及如何将模型的概率转换回 AgentCore 评估结果。不过首先，什么时候应该使用自定义 LLM-as-a-judge 评估器，什么时候决策模型更合适？下一节将拆解决策模型是什么以及涉及的权衡。

决策模型

决策模型是一种小型专用模型，经过训练从一组固定选项中进行选择，并返回校准后的置信度分数，而不是生成自由文本。通用大语言模型（LLM）评估器会生成带有理由的分数。决策模型则生成预定义答案上的概率分布。这为你提供了一个直接的置信度度量，你可以设定阈值、聚合并以编程方式据此采取行动。这使得决策模型非常适合那些判断可以表述为在一组固定选项中进行选择的评估任务：“这个回答是否有依据？”或者“智能体是否完成了用户的目标？”

当你希望在标签之外获得一个校准良好的置信度分数，而不仅仅是二元判断时，决策模型最为有用。当你希望一致地执行某个特定评分标准，而不依赖通用 LLM 去解读它时，决策模型也同样适用。

TypeSafe 提供的托管决策模型 Jev，以及 Strands Agents 团队开源的 20 亿参数决策模型 Strands Decider，都支持三种类型的问题。noul 问题提出一个是/否问题，并返回 0（否）到 1（是）之间的概率。choice 问题询问最多 255 个选项中哪一个适用，返回最可能的选项以及完整分布和置信度。score 问题询问 2 到 10 个有序等级中哪一个适用，返回概率加权分数、各等级的分布以及置信度。许多评估标准都符合其中一种类型。“此响应中的每个事实是否都有工具结果支持？”是一个是/否问题，而“按照四级评分标准，此响应的有用程度如何？”是一个分数。

决策模型与 LLM-as-a-judge 的对比

AgentCore 目前的内置评估器使用通用 LLM 根据评分标准评估智能体响应，并解释其判断。当评估需要串联证据、识别缺失信息，或深入分析响应，且解释与分数同样有用时，这种做法很有价值。决策模型并不能取代 LLM 评估器。它们是一种补充，而基于代码的评估器框架使这种补充成为可能。可将它们用于范围狭窄、定义明确的检查，与内置评估器更广泛的评估配合使用。

解决方案概述

为展示这些评估器类型如何协同工作，本文构建了一个端到端示例：一个 HR Assistant 智能体，由确定性代码检查、内置 LLM-as-a-judge 评估器，以及由 Jev 或 Strands Decider 2B 支持的决策模型评估器进行评估。

该智能体使用 Strands Agents 构建，并部署到 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）。它使用五个返回固定模拟数据的工具来回答员工问题，这些数据包括带薪休假（PTO）余额、PTO 请求、HR 政策、福利和工资单。我们在此代码示例中使用固定数据，以便直接验证 LLM-as-a-judge 和决策模型评估器的行为。当你还拥有真实基准时，可以确认每个评估器是否捕获了正确的失败。此代码示例可帮助你搭建框架，以便针对自己的用例测试决策模型与 LLM-as-a-judge 的对比。

图 1：HR Assistant 的端到端架构，由代码检查、内置评估器以及由 Jev 或 Strands Decider 支持的决策模型评估器进行评估

先决条件

要部署此示例，你需要以下条件：

一个位于 AgentCore Evaluations 可用区域的 AWS 账户。示例默认使用美国西部（俄勒冈）。
账户中已启用 Amazon CloudWatch Transaction Search。
可访问 Amazon Bedrock 中的基础模型。
Python 3.12 或更高版本、AWS 命令行界面（AWS CLI）以及 Docker。
Jev 需要 TypeSafe API 密钥。请访问 typesafe.ai 了解获取详情。
Strands Decider 需要一台运行 Strands Decider 服务器的主机。你可以在本地运行它进行测试，也可以在虚拟私有云（VPC）内的 Amazon Elastic Compute Cloud（Amazon EC2）上运行，以便 Lambda 函数能够访问它。

实际运行演示

你可以在 AgentCore samples GitHub 仓库中找到完整的代码示例。两个 Python 脚本负责处理所有事情：

../utils/deploy.py 将 HR Assistant 部署到 AgentCore runtime。
evaluate.py 部署评估器、调用 agent，并运行评估模式。

不带任何标志运行 evaluate.py 会执行五个步骤：

创建 Lambda 执行角色（AgentCoreLambdaEvaluatorRole）。
打包并部署两个确定性 Lambda 评估器：hr-response-length（一个 trace 级评估器，用于检查 agent 的响应是否保持在长度界限内）和 hr-fact-checker（一个 session 级评估器，用正则表达式对照已知的 mock 数据验证 HR 事实）。
通过控制平面将两者注册为基于代码的 AgentCore 评估器。
使用 EvaluationClient 和 OnDemandEvaluationDatasetRunner 在五个带标签的场景中运行按需评估，将基于代码的评估器与 Builtin.Correctness、Builtin.Helpfulness 和 Builtin.ResponseRelevance 结合使用。
创建一个在线评估配置，以 100% 采样率持续对实时会话进行评分。

此时，你已经拥有一个可用的评估流水线，包含确定性检查和 LLM-as-a-judge 评分。决策模型评估器是可选的。你可以通过标志添加它们，它们会与基础评估器一起运行，无需更改现有流程。使用标志 --with-jev --jev-secret-arn <ARN> 会部署 jev-evaluator 并注册三个评估器：JevGroundedness、JevHelpfulness 和 JevGoalCompletion。使用标志 --with-decider 会部署 strands-decider-evaluator 并注册由 Strands Decider 2B 支持的同样三个评估器。添加 --decider-ec2 可自动配置 Amazon EC2 实例、安全组、IAM 角色和 Lambda VPC 配置，无需手动控制台步骤。

图 2：evaluate.py 部署的评估流水线，从确定性检查到内置评估器和决策模型评估器

每个决策模型后端贡献三个评估器：

评估器	级别	问题类型	标签	值
JevGroundedness / DeciderGroundedness	TRACE	`noul`	Grounded 或 Ungrounded	P(grounded)
JevHelpfulness / DeciderHelpfulness	TRACE	`score`（4 级）	最可能的级别	期望级别，缩放到 0–1
JevGoalCompletion / DeciderGoalCompletion	SESSION	`choice`（3 选 1）	最可能的选项	概率加权值

使用决策模型构建评估器

使用标志 --with-jev 和 --with-decider 会创建一个自定义的基于代码的评估器，你可以完全控制要作为评估器运行的代码。我们创建 AWS Lambda 函数，在其中调用决策模型并返回标签或数值。该 Lambda 函数会作为基于代码的评估器注册到 AgentCore Evaluations 中。

注册为评估器的 Lambda 会接收 agent 的 OpenTelemetry span。spans.py 模块会规范化 OpenTelemetry 内容可能出现的各种形状，然后对其进行适当格式化，以便调用决策模型。对于 trace 级评估，只发送目标轮次和简短的先前历史记录，而对于 session 级评估，则包含完整对话。

图 3：基于代码的评估器 Lambda 如何为决策模型适配 OpenTelemetry span，并将结果映射回 AgentCore

适配器会将模型的概率分布转换为 AgentCore 评估所期望的结果。对于 noul 问题，true 的概率成为值，最可能的答案成为标签。对于 score 问题，值是缩放到 [0, 1] 的概率加权期望级别。对于 choice 问题，它是预定义选项值的加权平均值。

在你自己的流量上验证决策模型评估器

当你把评分标准改写为决策模型问题时，你创建的是一个全新的测量工具，而不是旧工具的副本。重新表述的评分标准往往比原本的意图更严格或更宽松，而只有对照真实会话进行检查，你才能发现这种偏移。在用决策模型评估器来把关发布之前，请像验证任何新测量工具一样验证它——用你自己流量中的带标签样本进行验证。本节的目标是带你完整走一遍这个验证流程，让你最终得到一个可以放心设定阈值的评估器。

该流程共有五个步骤。

步骤 1. 构建带标签的样本。从你的智能体流量中抽取一组已存储的会话，确保对你关心的失败案例和边缘情况有足够的覆盖。只覆盖正常路径的样本无法告诉你评估器在哪里会失效。

步骤 2. 获取人工参考标签。让三位独立的标注员针对你的问题所测量的属性对每一轮进行评分，并取多数投票作为参考标签。记录哪些轮次是一致通过的，哪些是存在分歧的。虽然一致通过的轮次是明确无争议的案例，但存在分歧的轮次才是有价值的，因为它们能在模型看到之前就揭示出评分标准本身的模糊之处。

步骤 3. 在相同输入上运行两个评估器。在一次批量评估中，对相同的会话同时运行决策模型评估器和匹配的内置评估器。对完全相同的输入进行评分，才能实现真正的同类对比。

步骤 4. 从三个角度解读结果。有了多数投票标签以及简单/困难案例的划分，你现在可以回答三个问题，来判断评估器是否已经就绪。

一致率：它与人工判断一致吗？衡量每个评估器与多数投票标签的一致频率，并且要按问题分别衡量，因为一个问题的准确率并不能说明另一个问题的情况。然后按简单（一致通过）和困难（存在分歧）案例分别拆解数据。只在困难案例上出错的评估器，其表现与人工标注员非常相似，而这正是你想要的。
校准度：置信度分数有意义吗？按评估器报告的概率对轮次进行分组，并比较每组与标签的一致率。更高的置信度应当对应更高的准确率。然后检查简单案例是否始终比困难案例获得更高的置信度。如果是，说明模型的不确定性确实反映了真实的模糊程度，你可以利用这些分组为每个评估器选择决策阈值，而不是默认使用 0.5。
分歧分析：它们在哪里不同，为什么不同？找出两个评估器彼此不一致的轮次，并检查这些轮次是否正是人工标注员认为存在模糊的轮次。阅读这些轮次。大多数分歧都可以追溯到问题的措辞，修改问题即可消除。当错误集中在困难案例上时，问题出在评分标准而非模型。

步骤 5. 任何变更后重新运行检查。将其视为可重复的检查，而非一次性的关卡。每当你修改问题措辞或迁移到新的模型版本时，都要重新运行。每个结果的解释都会记录产生它的模型版本，这样你就知道某个分数来自哪个版本。

为你的智能体选择最佳评估器组合

内置评估器仍然是 AgentCore Evaluations 中广泛评估策略的基础。它们依据评分标准和支撑上下文来评估响应，并解释判断依据，以便开发者调查问题所在。对于 HR Assistant，忠实性评估可以识别出与工具结果相矛盾的陈述，而有用性评估则可以指出智能体回答了余额问题，却未完成所请求的操作。

忠实性、有用性和正确性可能需要连接证据、识别缺失信息或推导出解决方案。预印本 JEV-as-a-Judge: Accept When Confident, Escalate When Unsure 将一种相关的区分描述为“阅读与推导”。一个范围狭窄的决策模型检查可以标记出需要关注的轮次，而内置评估器则提供审查该轮次所需的更广泛评估和推理。当你将决策模型视为一道关卡而非替代品时，它们才能发挥最大作用。级联模式的工作方式如下。首先，对每个会话的每一轮运行一个快速、经过校准的决策模型，以获得低成本的通过/失败信号。然后，仅对信号低于阈值的会话调用完整的 LLM 评估器。

图 4：级联模式，其中经过校准的决策模型筛查每一轮，只有低置信度的轮次才会升级到内置评估器

标准	LLM 作为评判者	决策模型作为评判者
输出	分数 + 解释	校准后的概率
延迟	2–10 秒	约数百毫秒（网络）
可定制性	有限（固定提示模板）	问题定义
最适合	定性细微差别、解释	校准后的判断

我们推荐以下设置：

使用你所依赖的内置评估器配置在线评估，作为衡量各智能体质量的标准。
将针对特定领域是/否和选择题的决策模型评估器添加到同一配置中，同时为任何可以精确计算的内容添加确定性的基于代码的评估器。
每周，或按照适合你发布周期的任何时间表，查询在线结果中决策模型检查失败或得分接近阈值的会话，并对这些会话使用内置评估器运行批量评估以获取解释。
以内置评估器和你已根据标注数据验证过的决策模型评估器作为发布门槛，并跟踪两者的一致频率。

清理

为避免持续产生费用，请运行 cleanup.py，以删除托管在 AgentCore 运行时上的智能体、评估器和评估配置、注册为评估器的 AWS Lambda 函数、托管 Strands Decider 模型的 EC2 实例、AWS Secrets Manager 密钥以及 CloudWatch 上关联的日志组。

结论

在本文中，你使用基于代码的评估器将两个决策模型 Jev 和 Strands Decider 连接到了 AgentCore Evaluations，随附的代码示例为你提供了一个框架，用于测试这些模型并了解它们作为评估器在哪些方面能增加价值。内置评估器仍然是你的基线。决策模型增加了范围狭窄、经过验证的检查，并带有一种你可以设定阈值并据此采取行动的确信度度量。切实可行的前进路径是，在你已经运行的内置评估器旁边添加决策模型检查，衡量它们在你自己的流量上与参考标签的一致频率，并且只有在你信任它们之后才扩大覆盖范围。

要开始使用，请查阅 Amazon Bedrock AgentCore Evaluations 文档，使用基于代码的评估器集成自定义评估器，并深入了解 Strands Decider 模型。通过从 Amazon Bedrock AgentCore 示例仓库部署示例评估器，即可借助代码示例快速上手。

关于作者

Sungyeon Kim

Sungyeon 是 AWS 的应用科学家，负责为智能体应用开展研究并开发机器学习解决方案。他的研究兴趣包括语言模型训练与评估、生成式 AI 以及智能体系统。他在学术界和工业界均从事过多个 AI 领域的工作，包括计算机视觉、多模态学习和检索系统。

Bharathi Srinivasan

Bharathi 是 AWS 的生成式 AI 数据科学家。她热衷于负责任 AI，以提升 AI 智能体在真实场景中的可靠性。Bharathi 指导内部团队和 AWS 客户践行负责任 AI。她曾在多个机器学习会议上展示自己的研究成果。

Jonathan Buck

Jonathan 是 AWS 的首席工程师。他的工作聚焦于支持 AI 智能体环境与评估的基础设施和工具。Jonathan 与研究团队和工程团队合作，为 AWS 客户塑造下一代 AI 产品与服务的方向。

Haibo Ding

Haibo 是 Amazon 的首席应用科学家兼科学经理，从事智能体 AI 相关工作。他拥有犹他大学博士学位。他的工作聚焦于大语言模型（LLM）和 AI 智能体，领导 LLM 后训练、基准测试、智能体评估和工具优化等领域的研究。他曾担任 AAAI、ACL 等会议的区域主席，此前还担任过 KDD 2025 提示优化研讨会的程序主席。