AWS介绍用决策模型为AgentCore评估器打分：先验证再设阈值
AWS机器学习博客介绍如何通过基于代码的评估器，把TypeSafe的Jev与开源的Strands Decider 2B接入Amazon Bedrock AgentCore Evaluations；文中把决策模型定位为内置LLM评估器的补充，并给出在自己流量上验证的步骤。
AI解读：决策模型接收结构化状态和一组固定答案，返回标定过的概率分布，而非自由文本，适合“是否拒绝请求”“是否合规”这类窄而可重复的判断（以上为文章定义）。
AgentCore Evaluations支持按需、批量与在线三种评估方式；除 15 个内置评估器外，还可自定义LLM-as-a-judge或代码型评估器，代码型可在Lambda中调用外部模型，包括决策模型。
文章演示的HR助手用固定mock数据，Jev与Strands Decider 2B各注册三项评估器：groundedness（二选一）、helpfulness（4 级评分）、goal completion（三选一）。
作者建议把决策模型当作筛选层而非替代：先在自有流量的标注样本上核对一致率、校准与分歧，再据此设定阈值；改写问题或更换模型版本后需重跑验证。
AWS机器学习博客发布一篇技术文章，介绍如何通过Amazon Bedrock AgentCore Evaluations的代码型自定义评估器，把两个决策模型——TypeSafe的托管模型Jev和Strands Agents团队开源的 20 亿参数模型Strands Decider 2B——接入agent评估流程。文章作者Sungyeon Kim将决策模型定位为内置LLM评估器的补充，而非替代，并给出在自有流量上验证后再设阈值的方法。
文章称，决策模型针对固定选项集输出经过标定的概率分布，而不是自由生成的文本和解释，因此适合“是否遵守策略”“工具调用是否可安全批准”这类窄而可重复的问题。
AgentCore评估器结构
文章介绍，AgentCore Evaluations是Amazon Bedrock AgentCore的一项能力，可在开发生命周期中按需评估、对存储会话做批量评估，以及对生产流量做在线评估。除 15 个内置评估器外，还支持自定义LLM-as-a-judge评估器（调用Amazon Bedrock中的模型）和代码型评估器（在AWS Lambda中运行自定义逻辑，可调用外部系统、模型或API）。
决策模型通过代码型评估器接入：Lambda接收agent的OpenTelemetry span，转换成决策模型请求，再把概率分布映射回AgentCore期望的结果格式。trace级评估只发送目标轮次和简短历史，session级评估则包含完整对话。
- noul问题：返回 0 到 1 之间的“是”概率，最可能的答案作为标签。
- choice问题：最多 255 个选项中选一个，返回最可能选项、完整分布和置信度。
- score问题：2 到 10 个有序等级中选一个，返回概率加权分数、等级分布和置信度。
示例中的三个决策模型评估器
文章构建了一个用Strands Agents搭建并部署到AgentCore runtime的HR助手示例，使用五类返回固定mock数据的工具（带薪休假余额、休假申请、HR政策、福利、工资单）。示例先用确定性代码评估器（响应长度检查、用正则核对HR事实）和内置的Correctness、Helpfulness、ResponseRelevance评估器跑通流水线，再通过 --with-jev或 --with-decider标志选择性加入决策模型评估器，原有流程不需改动。
两个后端各注册三个评估器：Groundedness为trace级noul问题；Helpfulness为trace级 4 级score问题，价值为按概率加权并缩放到 0 到 1；GoalCompletion为session级三选一choice问题，价值为各选项值的加权平均。
- Jev需要TypeSafe API key；Strands Decider需要单独部署服务端，可在本地运行，或运行在VPC内的EC2上供Lambda访问。
- 加 --decider-ec2标志可自动配置EC2实例、安全组、IAM角色和Lambda的VPC设置。
- 运行示例需要已开通AgentCore Evaluations的区域（默认美国西部俄勒冈）、启用CloudWatch Transaction Search，以及Python 3.12、AWS CLI和Docker。
验证方法与适用边界
文章强调，把评分标准改写成决策模型问题等于创建了一种新测量方式，而不是原标准的副本，重写后往往比原意偏严或偏松，只有用真实会话核对才能发现。作者给出五步验证流程：从存储会话中抽取覆盖失败与边界情况的样本；由三名独立标注者打分并以多数票作为参考标签，记录一致与分歧的轮次；在同一批评估中同时运行决策模型评估器和对应的内置评估器；从一致率、校准和分歧三方面读结果；问题措辞或模型版本变化后重新运行。
文中给出的对比表显示：LLM评委输出分数加解释，延迟约 2 至 10 秒，适合需要定性细微判断和解释的场景；决策模型评委输出标定概率，延迟约数百毫秒（网络因素），问题定义固定，适合可标定的判断。文章引用预印本《JEV-as-a-Judge: Accept When Confident, Escalate When Unsure》把这一区别描述为“阅读与推导”。
作者建议的用法是级联：先在每轮运行决策模型获得低成本的通过/失败信号，仅对低于阈值的会话调用完整LLM评估器获取解释；发布门槛则同时依据内置评估器和已在标注数据上验证过的决策模型评估器，并跟踪两者的吻合程度。这些建议来自文章作者，文中未给出生产环境的效果数据。
- 文章称内置评估器仍是广泛评估策略的基础，决策模型用于窄范围、经过验证的检查。
- 示例使用固定mock数据以便核对评估器行为；文章指出，若另有真实标准答案，可进一步确认每个评估器是否捕捉到正确失败。