用决策模型构建 Agent 发布前评估

给 Agent 打分，不一定每次都要让大模型写一段评语。AWS 这篇文章展示了另一条路径：把范围明确的问题交给决策模型，让它从固定答案中选择，并返回概率，再接入 Amazon Bedrock AgentCore Evaluations。

关键不只是接上 Jev 或 Strands Decider 2B，而是怎样证明这些分数值得信任。对正在做 AI 应用评测的程序员，最有用的是评测分工和验证流程；文章并没有给出足以证明成本、速度或准确率优势的对照数据。

哪些问题适合让决策模型打分

通用的 LLM-as-a-judge 会根据评分规则阅读回答，给出分数和理由。决策模型则把输出限制在预设选项内，返回各答案的概率。它更适合判断「有没有拒绝请求」「是否偏题」这类边界清晰、知情者看一眼就能判断的问题。

文章介绍的两个后端分别是 TypeSafe 托管的 Jev，以及 Strands Agents 团队开源的、拥有 20 亿参数的 Strands Decider 2B。两者都支持三种问题：

• noul 是 yes/no 问题，返回 0 到 1 的概率，0 对应 no，1 对应 yes。
• choice 最多支持 255 个选项，返回最可能的选项、完整概率分布和置信度。
• score 支持 2 到 10 个有序等级，返回按概率加权的分数、等级分布和置信度。

这些输出方便程序设阈值、做聚合、触发后续处理。不过，「输出概率」和「概率可靠」是两回事。一个模型给出 0.9，并不能单凭这个数字就认定它有九成把握判断正确，还得用标注数据检查。

作者也给出了能力边界：需要串联证据、发现遗漏、推导答案的评测，仍然适合交给通用 LLM。比如回答里的事实是否符合工具结果，以及用户要求的操作是否真的完成，可能需要不同深度的分析。题目能写成 yes/no，不代表判断过程一定简单。

接入 AgentCore，重点是把上下文和分数对齐

AgentCore Evaluations 支持开发阶段按需评测、针对已保存会话的批量评测，以及面向生产流量的在线评测。除了 15 个内置评测器，还能自定义 LLM-as-a-judge，或通过 AWS Lambda 运行代码评测器。决策模型走的是后一条路径。

示例中的 HR Assistant 使用 Strands Agents 构建，部署到 AgentCore runtime，通过五个工具读取固定模拟数据，覆盖带薪休假（PTO）余额、休假申请、人事政策、福利和工资单。固定数据方便核对评测结果，但它不是复杂生产流量的代表。

运行环境需要可用区域内的 AWS 账号，示例默认 US West（Oregon）；还需要启用 Amazon CloudWatch Transaction Search、获得 Amazon Bedrock 基础模型访问权限，并准备 Python 3.12 或更高版本、AWS CLI 和 Docker。Jev 需要 TypeSafe API key，Strands Decider 则需要一个 Lambda 能访问的模型服务。

../utils/deploy.py 负责部署 Agent，evaluate.py 负责部署评测器并运行评测。不带参数执行后者，会创建 AgentCoreLambdaEvaluatorRole，部署两个确定性检查：

hr-response-length 在 trace 层检查回答长度；hr-fact-checker 在 session 层用正则表达式核对已知 HR 事实。随后，脚本通过 EvaluationClient 和 OnDemandEvaluationDatasetRunner 跑五个带标签场景，同时使用 Builtin.Correctness、Builtin.Helpfulness、Builtin.ResponseRelevance，并创建采样率为 100% 的在线评测配置。

决策模型是可选项。加入 --with-jev --jev-secret-arn <ARN>，会部署 jev-evaluator，注册 JevGroundedness、JevHelpfulness、JevGoalCompletion。加入 --with-decider，则部署 strands-decider-evaluator，由 Strands Decider 2B 提供对应的三项评测。额外使用 --decider-ec2，还能自动配置 EC2、安全组、IAM role 和 Lambda VPC 配置。

真正的适配工作发生在 Lambda 内。spans.py 将 Agent 的 OpenTelemetry spans 统一成模型输入：trace 级评测只发送目标轮次和简短历史，session 级评测发送完整对话。

返回值也需要转换。noul 用 true 的概率作为 value，以最可能答案作为 label；score 将概率加权后的预期等级缩放到 [0, 1]；choice 则按预设选项数值计算加权平均。最后一种尤其需要明确映射规则，否则最终分数可能很难解释。

能不能卡发布，要先用自己的数据证明

把评分规则改写成决策问题，就是引入了一把新尺子。

原有评测器和决策模型都叫「有帮助」，并不代表测量的是同一件事。问题措辞可能让标准变严或变松，光看名称发现不了偏差。作者给出的验证流程比接入步骤更值得保留。

先从真实会话里抽样，覆盖失败和边界情况；再由三名独立标注者逐轮打标签，以多数票作为参考，同时保留全票一致和存在分歧的区别。接着，让决策模型与对应内置评测器在同一次批量评测中处理相同输入。

结果要从三个角度看。第一是与人工标签的一致率，而且要逐问题统计，并区分明确案例和争议案例。第二是校准情况：按输出概率分组，检查更高概率是否对应更高准确程度，再选择阈值，不能默认 0.5 就合适。第三是分歧分析：两种评测器意见不同时，回看原始会话，确认问题出在措辞、规则还是模型。

作者认为，错误集中在人工也有争议的案例时，应该优先检查评分规则。不过，这只是排查方向，不能据此排除模型能力不足。每次改写问题或切换模型版本，都应重跑验证；示例会在结果的 explanation 中记录模型版本，方便追溯。

文章还提出级联模式：先让决策模型筛查所有轮次，再把未通过或接近阈值的会话交给完整 LLM 评测器解释。这里要分清两件事：评测分数低，可能表示回答质量差；置信度低，表示模型拿不准。实现分流时需要明确用哪个字段，原文没有展开具体触发条件。

我的判断

我认同它把确定性代码、决策模型和通用 LLM 分工使用的方向。长度、格式、已知字段这类能精确计算的指标，直接写代码更容易核对；范围窄的语义判断，可以尝试决策模型；需要解释证据和遗漏的任务，继续保留 LLM 评测器。

但「更便宜、更快、经过校准」在这篇文章里缺少可复核的对照结果。作者没有给出 Jev 与 Strands Decider 2B 的延迟、费用、人工一致率或校准曲线。示例证明的是接入流程可运行，不能替一般团队证明收益。

级联也不会自动省钱。如果内置评测器继续全量在线运行，再新增决策模型，评测调用反而增加。文章的实际建议仍然保留内置评测作为质量基线，并定期对筛出的会话做批量分析。因此，接入额外检查和减少完整评测调用，是两项需要分别验证的决策。

自托管还有运维成本。--decider-ec2 能自动建资源，但服务容量、可用性和网络访问仍需团队负责。示例结束后应执行 cleanup.py，清理 runtime 中的 Agent、评测器与配置、Lambda、EC2、Secrets Manager 密钥及相关 CloudWatch 日志组，避免持续计费。

能拿来做什么

• 给 AI 助手拆分评测指标时，先把长度和可精确核对的事实交给代码，再挑一两个边界清楚的语义问题试接决策模型，保留内置评测器作为比较基线。
• 在接入发布门禁之前，用自己的失败会话和边界样本完成三人独立标注，逐问题核对一致率与概率分组结果，再决定阈值。
• 给日常 Agent 调试流程增加分歧回看：集中检查决策模型未通过、接近阈值或与内置评测器意见不同的会话，用完整评测解释定位问题。
• 修改决策问题或升级模型时，把重新验证纳入发布流程，并保存模型版本，避免不同测量标准产生的分数被直接放在一起比较。