决策模型处理评估任务的方式不同于生成自由文本的模型。它不是写出一段不受限制的回答，而是从固定选项集合中作出选择，并为预先定义的答案返回经过校准的置信度分数或概率分布。对于范围明确、能够重复提出的评估问题，这种结构尤其直接：每一种输出都具有事先确定的含义，也能够被转换成一致的评估结果。

AWS 的文章说明了如何把这种方法带入 Amazon Bedrock AgentCore Evaluations。AgentCore Evaluations 支持三种使用方式：开发期间按需运行评估，对已经保存的会话执行批量评估，以及对生产流量进行在线评估。它提供十五个内置评估器，同时允许定义自定义评估器。自定义评估器可以采用由大语言模型充当裁判的形式，也可以采用基于代码的形式。

通过 Lambda 连接决策模型

基于代码的评估器会在 AWS Lambda 中执行自定义逻辑。这段逻辑能够调用外部系统、模型或应用程序接口，其中也包括决策模型。因此，它可以充当 AgentCore Evaluations 与决策模型后端之间的连接层。文章展示了两个后端：一个是 TypeSafe 托管的 Jev 模型，另一个是自行托管的开源 Strands Decider 2B 模型。

Jev 与 Strands Decider 支持三类问题。第一类是 noul 型的是非问题，答案为“是”或“否”；第二类是选择问题，最多可以包含二百五十五个选项；第三类是评分问题，可以设置二到十个按顺序排列的等级。这些格式把某项评估标准表达成边界清晰的决定，不要求模型生成开放式文字。

固定的答案空间并不意味着只保留一个最终标签。模型还会返回各个预定义答案对应的置信信息或概率分布。后续的映射逻辑可以利用这些信息形成数值结果，使评估输出既具有明确标签，也保留模型对不同答案的相对判断。

HR Assistant 示例中的多层评估

文章中的示例评估一个 HR Assistant。该助手使用 Strands Agents 构建，并部署到 AgentCore runtime。它的评估方案不是只依靠一种检查，而是组合了确定性检查、内置的大语言模型裁判评估器，以及由 Jev 或 Strands Decider 2B 支持的决策模型评估器。

示例里的 evaluate.py 脚本会部署两个确定性的 Lambda 评估器，并把它们注册为基于代码的评估器。随后，脚本会针对五个已经标注的场景运行按需评估，并在这次评估中使用三个具名的内置评估器。脚本还会创建在线配置，对百分之百的实时会话进行采样。

决策模型评估器是可选项。使用 --with-jev 时，脚本会注册 JevGroundedness、JevHelpfulness 和 JevGoalCompletion。使用 --with-decider 时，它会注册对应的三种评估器，但后端改为 Strands Decider 2B。两种选项承担相同类型的评估角色，只是连接到不同的决策模型后端。

这个安排让不同检查承担不同职责。确定性检查适合精确条件；内置评估器提供较广的基础覆盖；决策模型评估器则针对预先界定的问题给出带概率信息的答案。文章提出的方案把它们放在同一套 AgentCore Evaluations 流程中，而不是把其中任何一种视为其他检查的自动替代品。

从 OpenTelemetry 数据到评估结果

基于代码的评估器首先接收 OpenTelemetry span，然后对数据进行规范化，并把相关内容整理成决策模型可用的格式。发送多少上下文取决于评估层级。在轨迹级评估中，评估器会发送需要判断的目标对话轮次，并附带简短的先前历史；在会话级评估中，它会发送完整对话。

决策模型返回结果后，基于代码的评估器还需要把该输出映射回 AgentCore 所需的结果结构。不同问题类型采用不同的转换方法，因此问题的定义不仅决定模型可以选择哪些答案，也决定概率分布如何成为最终的数值与标签。

是非、评分与选择问题的映射

对于 noul 型的是非问题，结果中的数值采用“真”这一答案的概率，标签则采用概率最高的答案。这样，标签表达模型最终倾向于哪一侧，而数值表达模型为“真”分配了多少概率。

对于具有有序等级的评分问题，评估器会根据每个等级的概率计算概率加权的期望等级，再把该结果缩放到零到一的区间。由于问题可以包含二到十个有序等级，这个计算会利用整个等级分布，而不只是概率最高的单个等级。

对于选择问题，每个预定义选项可以对应一个预先设定的数值。评估器使用模型返回的概率作为权重，对这些选项值计算加权平均。由此得到的数值能够进入 AgentCore 结果，同时标签或选项仍然来自事先界定的答案空间。

三种映射方式共同体现了相同原则：模型负责在固定答案中分配概率，代码评估器负责按照问题类型把这些概率转换成 AgentCore 可接收的结果。转换保留的内容多于单独的获胜标签，因为最终数值会反映概率分布中的相对权重。

用于发布门禁之前先验证

技术上成功连接决策模型并不等于该检查已经适合控制发布。文章给出的验证流程从真实流量中构建一份已标注样本开始。样本由三名彼此独立的标注者进行判断，再通过多数票得到参考标签。这个参考集合为后续比较提供共同标准。

接下来，应当让决策模型评估器和与之匹配的内置评估器处理完全相同的输入。分析不能只看最终标签是否一致，还应研究三方面内容：评估器与参考标签之间的一致程度，模型输出的校准情况，以及发生分歧的具体案例。分歧案例需要作为独立对象查看，因为总体数字不能说明每一次不同判断发生在什么输入上。

验证也不是只做一次。只要决策问题的措辞发生变化，或者所使用的模型版本发生变化，就应重新执行检查。按照这一流程，问题文本与模型版本都属于已经验证的评估配置组成部分；改变其中任意一项，都需要重新观察一致性、校准和分歧。

推荐的组合方式

文章推荐保留内置评估器作为覆盖面较广的基线，并在此基础上加入经过验证的决策模型检查以及精确的确定性检查。这样的结构并没有把所有判断压缩到单一机制中，而是让广泛评估、边界明确的概率判断和严格的确定性条件共同存在。

对于失败的会话或结果接近阈值的会话，可以通过批量评估重新检查。AgentCore Evaluations 对已存储会话的批量评估能力，使这些需要进一步审视的会话能够从在线流量中被拿出来再次分析。与此同时，在线配置可以观察实时会话，示例配置会采样全部实时会话。

发布门禁应当受到更严格的限制。推荐做法是只依靠内置评估器，以及已经使用标注数据验证过的决策模型评估器。决策模型能够输出固定答案上的概率，但在它的判断被用于阻止或允许发布之前，仍需通过真实流量样本、独立标注、多数票参考答案以及一致性和校准分析建立验证依据。

因此，完整流程包含多个相互衔接的环节：先把 OpenTelemetry span 整理为适合目标评估层级的上下文，再向 Jev 或 Strands Decider 2B 提出边界明确的问题，随后依据问题类型把概率输出映射成零到一范围内或其他预定义方式的 AgentCore 结果，最后用带参考标签的数据检查这些结果是否适合进入发布判断。若问题措辞或模型版本改变，验证环节随之重新执行。

这一方案的重点不只是增加新的模型后端，而是明确每类结果如何产生、如何比较以及何时可以被用于更重要的决定。内置评估器提供基础，确定性检查处理精确条件，经过标注数据验证的决策模型评估器回答有限选项问题；失败或临界会话则通过批量评估得到进一步审视。