AWS发布AEM评估指标 可按对话轮次定位多轮智能体的首个错误
AWS Machine Learning博客介绍Agent Evaluation Metric（AEM），将智能体正确性拆分为真实性与完整性两个子指标，逐轮评估并区分根因失败与级联失败。
AI解读：多轮智能体出错的麻烦之处在于，前面某一轮的小错误会悄悄污染后面每一轮。只检查最终结果的任务级评估只能告诉你整段对话失败了，却说不出该修哪一轮。
AEM的思路是把智能体质量拆开：正确性分为真实性和完整性。真实性看工具调用的参数值和自然语言回答是否符合事实，完整性看该给的参数和该答的信息有没有缺。两者都按轮打分，再合成为一个总分。
它最实用的部分是错误归因：一个轮次如果是因为消费了前面已失败的输出才失败，会被标为prior_action_failed，只有真正起源的轮次算根因。这样团队修一个参数，后面几轮的失败往往自己就消失了。
目前这套指标只实例化了正确性这一个维度，且这篇博客只用它处理二值通过或失败。安全、指令保持等维度说可以按同样的分解-评估-组合模式扩展，但尚未给出实测效果数据。
AWS Machine Learning博客发布Agent Evaluation Metric（AEM），一种面向多轮对话智能体的可分解、按轮次评估的质量指标。博客首篇只实例化其中的正确性维度，用真实性和完整性两个子指标逐轮打分，并区分根因失败与级联失败。
博客给出的例子是五轮的企业助手对话：用户要求创建销售报告再逐步修改，第2轮智能体选对了动作，却把参数写成“profit”而不是“revenue”，这个错误随后贯穿第3至第5轮。任务级评估只会把整段对话标为失败，无法指出只有一轮需要修。
AEM的评分规则是：一个轮次的正确性按通过或失败二值处理，并附带具体失败原因，注明是哪个子指标、哪个字段出错；整段对话的AEM分数是通过轮次的比例。
为什么现有指标定位不了级联错误
博客称多数智能体评估工具在任务或回答层面做整体评分，提供目标完成度打分和LLM-as-judge质量评估，部分还加入轨迹级根因分析。这些工具把智能体质量当作单一信号，而不是拆成可独立追踪的部分。
博客列出三个缺口：任务级指标只知道任务是否完成，不知道哪一维质量崩了；单轮指标在孤立语境下评估回答，不考虑错误如何跨轮传播；整体分数分不清事实错误和缺失必填字段，也没有清晰路径在不重构评估的情况下加入安全、指令保持等新维度。
- 目标完成度70%无法说明失败是事实错误、信息缺失还是工具选错
- 单轮的真实性、有用性评分不考虑错误在轮次之间的传播
- 新增评估维度需要重新设计评估架构
正确性如何拆成两个子指标
博客把正确性定义为两个可分别测量的子指标：真实性判断智能体产出的值是否与预期在事实上一致，同时适用于工具调用的参数值和自然语言回答中的陈述；完整性判断所有必需元素是否齐备，没有缺参数，也没有遗漏用户所要求信息的半截回答。
对回答轮，完整性问的是回复是否覆盖完整提问，真实性问的是内容是否事实一致。对动作轮，完整性检查参数键是否齐全，真实性检查参数值语义是否正确；两者都建立在工具和动作选择正确的结构检查之上。
两个子指标都用语义比较而非精确字符串匹配。“New York City”和“NYC”、“Q3 2024 revenue”和“third quarter revenue figures for 2024”被视为语义等价。评分器可以是基于嵌入的相似度检查，速度快、成本低；也可以是LLM-as-judge调用，更细致但评分不易直接检查。博客中的0.5阈值是中性默认起点，不是调优后的值，实际取值取决于业务对误报和漏报的容忍度。
评估完整性在回答轮走语义检查，在动作轮走结构检查：计算缺失参数集合和多出参数集合，两者都为空才算通过。非空的缺失集合产生missing_parameters失败，非空的多出集合产生extra_parameters失败，能直接指出是哪些参数出了问题。
组合分数与失败分类
分解产生按子指标、按轮次的判定，组合再把它变成一个数字。博客采用的默认组合规则是通过轮次的未加权平均值，但强调组合函数是可插拔的：加权平均可以给出错代价更高的轮次更大权重，门控规则可以让某个关键轮次的失败直接给总分封顶，按子指标设阈值可以给每个维度单独设线。
失败分类覆盖两类轮次。回答轮的失败包括inconsistent_response（真实性）和incomplete_response（完整性）。动作轮的失败包括tool_mismatch（工具选错）、action_mismatch（工具对、操作错）、missing_parameters和extra_parameters（完整性），以及inconsistent_parameter_values（参数值语义错误）。另有prior_action_failed标签，适用于两类轮次，表示不是根因，而是前一轮已经造成的问题。
prior_action_failed的判定依据依赖关系：失败起源于本轮的是根因，仅仅因为消费了已失败轮次输出而失败的是级联。在上面的例子里，只有第2轮是根因，第3至5轮继承该标签。指标还追踪动作链长度，分为单次调用、两步和复杂的三步以上序列。
- 回答轮失败：inconsistent_response、incomplete_response
- 动作轮失败：tool_mismatch、action_mismatch、missing_parameters、extra_parameters、inconsistent_parameter_values
- 两类轮次通用：prior_action_failed
评估流程与黄金数据集
评估流程从带标注的对话开始，产出单个可分解的AEM分数，可归因到每一轮，并贯穿智能体开发生命周期。黄金数据集要求人工标注正确回答和正确工具调用，或从更强模型引导后人工复核，因为这套参考定义了每一轮什么算对。每段对话由多轮组成，每轮把黄金输出与预测输出配对。
博客给出的样例中，第1轮是回答轮：黄金回复问“报告应覆盖哪个地区”，预测回复措辞不同但语义等价，因此通过；第2轮是动作轮：黄金参数为metric: revenue、region: EU，预测为metric: profit、region: EU，真实性错误落在metric值上，该轮失败。样例还带OrderInvariant_filter标签，当多个工具调用以任意顺序都有效时，评估器按合法顺序检查，不会因顺序不同而扣分。
五轮销售报告例子的流程输出为：success_rate 0.2，test_pass false，first_failure_turn 2，root_cause inconsistent_parameter_values，root_cause_count 1，cascading_count 3。博客评论说，这意味着修好第2轮的参数，第3至5轮很可能自动解决。
生产监控与Strands Agents SDK集成
生产环境中持续追踪整体正确性分数，博客列出的用途包括：按发布版本看正确性，用于发现最新模型更新是否拉低轮次成功率；按链路长度看正确性，观察复杂多步链路是否随时间退化；看失败原因分布，判断模型切换后tool_mismatch是否增加；以及看延迟相关性，即累积延迟更高的对话是否正确性更低。框架输出结构化JSON，可接入监控看板。对金融计算或合规相关回答这类高代价错误，博客建议把分解后的子指标分数与人工或黄金标签做相关性分析，例如Pearson或Spearman，以确认自动评分是否跟得上人工判断，以及该在哪里引入人工复核。
方法论不绑定框架，可通过自定义评估器集成进Strands Agents evaluation SDK，与团队已有的目标完成度和LLM-as-judge评估跑在同一条流水线里。这些内置评估器报告的是整条轨迹的整体信号，AEM作为补充，提供按轮次、可归因到具体子指标的正确性分数。
博客给出的CorrectnessCustomEvaluator代码继承Evaluator类，接收threshold和name参数，在evaluate中对评估用例跑逐轮的真实性和完整性检查，返回成功轮次比例作为score，并给出test_pass以及失败轮次列表组成的reason。评估逻辑作为可移植的自定义代码，Strands Agents提供运行器、轨迹采集和报告；每次运行产出逐轮轨迹（工具调用和模型调用的span）和结构化报告，可导出JSON到自有看板和告警。博客称该包装器可在一次运行中与其他评估器并行执行，包括它将在后续篇章介绍的安全评估器。