人工智能

使用 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 来解释它时，决策模型也同样适用。

Jev，来自 TypeSafe 的托管决策模型，以及 Strands Decider, 来自 Strands Agents 团队的开源 20 亿参数决策模型，都支持三种类型的问题。 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 的对比。

Architecture of the HR Assistant agent on AgentCore runtime, evaluated by code-based, built-in, and decision-model evaluators

图 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 示例 GitHub 仓库. 两个 Python 脚本处理所有事情：

  • ../utils/deploy.py 将 HR Assistant 部署到 AgentCore 运行时。
  • evaluate.py 部署评估器、调用代理并运行评估模式。

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

  1. 创建 Lambda 执行角色（AgentCoreLambdaEvaluatorRole).
  2. 打包并部署两个确定性 Lambda 评估器： hr-response-length （一个跟踪级评估器，用于检查代理的响应是否保持在长度限制内）以及 hr-fact-checker （一个会话级评估器，使用正则表达式对照已知的模拟数据验证 HR 事实）。
  3. 将两者都通过控制平面注册为 AgentCore 基于代码的评估器。
  4. 使用 EvaluationClient 和 OnDemandEvaluationDatasetRunner 在五个带标签的场景中运行按需评估，将基于代码的评估器与 Builtin.Correctness, Builtin.Helpfulness、以及 Builtin.ResponseRelevance.
  5. 创建一个在线评估配置，以 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 配置，无需手动执行控制台步骤。

The evaluation pipeline that evaluate.py deploys, combining deterministic, built-in, and decision-model evaluators across on-demand and online modes

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

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

评估器 级别 问题类型 标签 值
JevGroundedness / DeciderGroundedness TRACE noul 有依据或无依据 P(有依据)
JevHelpfulness / DeciderHelpfulness TRACE score （4 级） 最可能的级别 期望级别，按 0–1 缩放
JevGoalCompletion / DeciderGoalCompletion 会话 choice （三选一） 最可能的选项 概率加权值

使用决策模型构建评估器

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

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

The code-based evaluator Lambda converting OpenTelemetry spans into a decision-model request and mapping the probabilities back to an AgentCore result

图 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：有把握时接受，不确定时上报 将相关区别描述为“阅读与推导”。一个狭窄的决策模型检查可以标记某个轮次以引起注意，而内置评估器则提供审查该轮次所需的更广泛评估和推理。当你把决策模型视为一道闸门而非替代品时，它们才能发挥最大作用。级联模式的工作方式如下。首先，对每个会话的每个轮次运行一个快速、经过校准的决策模型，以获得低成本的通过/失败信号。然后，仅对信号低于阈值的会话调用完整的 LLM 评估器。

The cascade pattern, where a decision model screens every turn and escalates low-confidence turns to a full LLM evaluator

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

标准 作为评判者的LLM 决策模型作为评判者
分数 + 解释；校准概率；延迟 2–10 秒；约数百毫秒（网络）；可定制性有限（固定提示模板）；问题定义；最适合定性细微差别、解释；校准判断。我们推荐以下设置：使用你依赖的内置评估器配置在线评估，作为跨智能体衡量质量的标准。将针对特定领域是/否和选择问题的决策模型评估器添加到同一配置中，同时加入确定性的基于代码的评 分数 + 解释 校准概率
延迟 2–10 秒 约数百毫秒（网络）
可定制 有限（固定提示模板） 问题定义
最适合 定性细微差别、解释 校准判断

我们推荐以下设置：

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

清理

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

结论

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

首先，请查看 Amazon Bedrock AgentCore Evaluations 文档，使用基于代码的评估器接入自定义评估器，并深入了解 Strands Decider 模型。 基于代码的评估器 并深入了解 Strands Decider 模型。通过从 Amazon Bedrock AgentCore 示例仓库部署示例评估器来开始使用代码示例。 Amazon Bedrock AgentCore 示例仓库.

关于作者