决策模型作为智能体评估的校准筛网：从级联模式到验证流程

当你在评估一个智能体时，有些问题窄而可重复：这条回复是否偏离了策略？这个工具调用是否可以安全批准？回答是否与检索到的上下文一致？决策模型恰好回答这类问题。它们接收一个结构化状态和一组固定允许的答案，返回一个校准概率分布，而不是每次运行置信度都会漂移的自由文本。这使它们成为评估打分步骤的合适选择——你需要一个标签和一个可以设阈值、可以信任的数字。

Amazon Bedrock AgentCore Evaluations 支持两种自定义评估器：LLM-as-a-judge 和代码评估器。代码评估器在 AWS Lambda 中运行你自己的逻辑，可以调用外部系统、模型或 API，包括决策模型。这篇文章展示了如何通过代码评估器连接两个决策模型后端——TypeSafe 的托管模型 Jev 和开源的 Strands Decider 2B——并说明何时该用哪种评估器。

决策模型与 LLM 评估器的核心区别在于输出形态。通用大语言模型评估器产出一个分数加一段解释；决策模型产出一个预定义答案上的概率分布。这给了你一个直接的置信度度量，可以设阈值、聚合、程序化地采取行动。决策模型适合判断可以表述为固定选项之间选择的评估任务：回复是否有据可依？智能体是否完成了用户目标？它们支持三种问题类型：noul（是/否，返回 0 到 1 的概率）、choice（最多 255 个选项，返回最可能选项及完整分布）、score（2 到 10 个有序级别，返回概率加权分数）。

文章提出的核心架构是级联模式。第一步，对每个会话的每一轮运行一个快速、校准的决策模型，得到一个廉价的通过/失败信号。第二步，仅当信号低于你的阈值时，才调用完整的 LLM 评估器。延迟差异是这个模式成立的基础：LLM 评估器需要 2 到 10 秒，决策模型只需几百毫秒的网络往返。决策模型不是 LLM 评估器的替代品，而是代码评估器框架使能的补充层。

但文章同时强调一个关键警告：当你把一个评分标准改写为决策模型问题时，你创建的是一个新测量，而不是旧测量的副本。改写后的标准往往比原意更严格或更宽松，在对照真实会话之前你不会看到这种漂移。因此文章给出五步验证流程：构建覆盖失败和边缘情况的标注样本；请三个独立标注者对每轮打分并取多数票作为参考标签；在同一输入上同时运行决策模型评估器和匹配的内置评估器；从三个角度读结果——一致率、校准度、分歧分析；任何变化后重新运行检查。

验证流程中最有操作价值的细节是对分歧的处理。多数票一致的轮次是明确案例，而投票分裂的轮次才是有价值的——它们在模型看到之前揭示了评分标准本身的歧义。如果决策模型只在困难案例上出错，它的行为与人类标注者一致，这正是你想要的。如果错误聚集在困难案例上，问题出在评分标准而非模型。大多数分歧可以追溯到问题的措辞，修改问题措辞就能消除它们。

文章建议的实际部署路径是：在线评估配置中保留内置评估器作为跨智能体的标准质量度量；为领域特定的是/否和选择题添加决策模型评估器，同时为可以精确计算的部分添加确定性代码评估器；每周查询在线结果中决策模型检查失败或接近阈值的会话，对这些会话运行批量评估以获取解释；将发布门槛设在内置评估器和你已对照标注数据验证过的决策模型评估器上，并追踪两者的一致频率。

需要指出的是，这篇文章来自 AWS 官方博客，属于平台方的技术指南。它提供了完整的代码示例和架构说明，但没有给出在生产流量上验证决策模型与 LLM 评估器一致率的具体数字。级联模式的成本效益主张——用决策模型做廉价筛选以节省 LLM 评估器的调用——在逻辑上成立，但文章本身未报告实际节省比例或阈值设定后的漏检率。读者在采用此模式时，需要用自己的标注数据完成文章建议的五步验证，才能确定阈值和信任度。