将决策模型与 Amazon Bedrock AgentCore Evaluations 结合使用

一项具体变化是：Amazon Bedrock AgentCore Evaluations 的代码评估器可以通过 AWS Lambda 调用决策模型，并将模型返回的概率分布转换为评估标签和数值。这样，评估系统除了使用通用大语言模型给出“分数＋解释”，还能为范围明确的判断提供可设阈值的置信度。据 AWS 官方资料，AgentCore Evaluations 目前包含 15 个内置评估器，并支持开发期按需评估、批量评估和线上评估。

把窄判断变成可执行信号

决策模型不生成自由文本，而是从预设选项中选择，并返回概率分布。它适合三类问题：

• 二元问题：返回“否”或“是”的概率，例如回答是否有工具结果支持。
• 评分问题：对有序等级进行概率加权，例如四级帮助度评分。
• 选择问题：从多个固定选项中返回最可能项及完整分布，例如是否完成用户目标。

资料展示了两类后端：TypeSafe 托管的 Jev，以及由 Strands Agents 团队开源、可自行运行的 Strands Decider 2B。两者均可通过代码评估器接入 AgentCore Evaluations。

适合做筛查层，而非替代深度评估

当问题可以写成固定选项，并且判断所需信息就在当前状态中时，决策模型适合检查策略合规、回答是否切题、事实是否受工具结果支持等。代码评估器接收代理产生的 OpenTelemetry spans，将目标轮次及必要上下文转换为模型请求，再把结果映射为 AgentCore 所需格式：二元问题输出标签和概率，评分问题输出缩放至 0 至 1 的加权值，选择问题输出按预设价值计算的加权结果。

这类模型适合先筛查所有会话，再把低置信度或未通过的轮次交给内置评估器深入分析。后者能结合证据、指出缺失信息并解释判断，因此更适合作为广泛质量评估的基础。

上线前先验证新的“尺子”

改写评分规则会形成一项新测量，不能默认它与原有评估等价。AWS 建议在真实流量上完成以下验证：

• 建立覆盖正常、失败和边界情况的标注样本。
• 由三名标注者独立评分，以多数票作为参考，并保留分歧样本。
• 让决策模型评估器和对应内置评估器处理完全相同的输入。
• 分别检查与人工标签的一致率、概率校准程度及双方分歧原因。
• 问题措辞或模型版本变化后重新运行验证。

性能收益与限制都需要实测

AWS 提供的对照中，通用大语言模型评估耗时为 2 至 10 秒，决策模型约为数百毫秒，并标注了网络因素。这是厂商资料中的场景性数据，不构成所有部署的性能保证；实际延迟仍取决于后端位置、网络、模型与请求内容。Jev 需要 API 密钥和外部服务访问，Strands Decider 需要自行提供可被 Lambda 访问的运行环境。

决策模型的优势是输出固定、置信度明确且便于自动执行；限制是问题定义必须清晰，难以替代需要语义推理和解释的任务。更稳妥的组合是：用确定性代码检查可精确计算的项目，用决策模型处理领域内的二元或有限选项问题，再由内置大语言模型评估器承担深入的定性判断与故障分析。

资料来源：Use decision models with Amazon Bedrock AgentCore Evaluations（2026-11-04）。