当前位置:首页>排行榜>AI评测中的 Rubric:不是越多越好

AI评测中的 Rubric:不是越多越好

  • 更新时间 2026-10-10 21:51:22
AI评测中的 Rubric:不是越多越好
做 Agent 评测不仅要看模型通过率多少、哪个模型领先、哪个版本退化;还要看用来判分的标准是不是靠谱。如果标准漏掉关键约束,模型犯了严重错误也可能通过;如果标准写得过多、过细,同一个问题又可能被重复扣分。于是,Rubric 成为 Agent 评测中最重要、也最容易被误解的一环。
一、先别急着谈 Rubric
一个完整评测 Case 有四部分Rubric 不能孤立存在。一个真正可运行的 Agent 评测 Case,至少包含四部分:
  1. 任务:用户到底想完成什么;
  2. 环境:商品、库存、订单、时间和用户状态是什么;
  3. 工具:Agent 能查询什么、修改什么、执行什么;
  4. Rubric:在上述条件下,哪些行为必须发生,哪些行为不能发生。
  5. 例如,用户让生活服务助手“小美”购买一款商品,Rubric 不能只写“成功下单”。它还取决于环境里有没有库存、是否存在规格差价、是否达到起送金额、是否有可用优惠,以及这类商品是否需要额外确认。
  6. Rubric 不是一份脱离环境的标准答案,而是任务、环境和工具共同决定的验收条件。
  7. 这也是为什么高质量评测不能只写一批自然语言问题。环境不真实、工具能力过浅、任务约束过少,再精细的 Rubric 也测不出真实能力。

二、Rubric 到底是什么?

评测体系通常会先定义若干稳定能力方向,例如理解与推理、个性化、产品交互、情绪沟通、安全和工具效率。这些维度回答的是:我们想评价 Agent 的什么能力?
Rubric 回答的则是:针对当前这道题,Agent 做到什么才算合格?
例如,用户对小美说:帮我点一杯某品牌的招牌奶茶,大杯、少冰、三分糖。
这道题可以拆出以下 Rubric:
  • 正确识别目标商品;
  • 完整保留“大杯、少冰、三分糖”三个规格;
  • 调用正确的查询或下单工具;
  • 工具参数与用户要求一致;
  • 商品不可用时不得擅自替换;
  • 真正提交订单前完成必要确认;
  • 不重复调用已经获得有效结果的工具。
这些标准会映射到不同能力:
  • 商品与规格识别属于需求理解;
  • 下单路径是否合理属于产品交互;
  • 页面、回复和工具参数是否一致属于状态一致;
  • 是否擅自替换或执行属于安全;
  • 重复调用则反映工具效率。
能力维度决定“评什么”,裁判规则决定“怎么打分”,Rubric 决定“这道题具体检查什么”。

三、Rubric 不是越多越好

判断 Rubric 多了还是少了,不能只看条数,而要看它有没有覆盖独立、必要的任务义务。
生成少了:关键错误逃过评测。用户明确要求“少冰、三分糖”,Rubric 却只检查是否找到正确商品。模型即使提交了全糖正常冰,也可能通过。这不是条目少,而是关键约束漏检。
常见漏项包括:用户明确条件没有被检查;工具参数没有被检查;多轮状态没有继承;失败后没有恢复要求;高风险操作缺少确认;模型犯了严重错误却仍能通过全部标准。
判断是否少了,可以问:模型还可能犯哪些重要错误,而现有 Rubric 完全发现不了?
生成多了:同一错误被重复处罚。“必须正确理解商品规格”和“商品规格不能识别错误”其实是同一件事。如果分别计分,就会重复处罚。
但“工具参数必须包含正确规格”可以独立保留,因为它检查的是执行,而不是理解。两条 Rubric 是否独立,关键要看它们使用的证据和可能出现的失败是否不同。
判断是否多了,可以问:删除这条后,会不会放过一种新的、重要的错误?如果不会,只是少扣一次同样的错误,它大概率就是冗余项。

四、评价 Rubric 质量,要看五件事

1 正确性:标准本身是否成立。Rubric 必须符合用户意图、产品规则和系统能力。用户只想浏览,不能要求必须下单;系统没有某种能力,也不能要求必须调用不存在的工具。
2 完整性:关键要求是否被覆盖。重点不是覆盖所有可能性,而是覆盖决定任务成败的核心条件。安全、越权、错误执行等高风险要求,原则上不能漏。
3 原子性:一条只判断一件事。“正确选店、选商品、使用优惠券并准时送达”不是一条好 Rubric。任何一部分失败,都很难判断应该扣多少分,也无法准确归因。更好的方式是拆成证据相互独立的标准。
4 可判定性:能否根据证据稳定判断。“回答要聪明、贴心”无法稳定判分。更好的写法是:“当用户明确表达连续失败后的不满时,回复需要承认已经发生的失败,并给出新的处理路径,不得机械重复原操作。”
5 归因性:失分能否指向具体能力。Rubric 不只是为了判对错,还应该解释问题发生在哪里:是需求解析错了、金额计算错了、异常没有识别,还是订单操作失败。只有能归因,评测结果才能反向指导优化。

五、Rubric 合格率和模型通过率,是两个指标

Rubric 生成合格率:它衡量生成出来的验收标准是否
可直接使用:Rubric 生成合格率 = 合格的题目级 Rubric 集合数 ÷ 抽检题目数。
建议以“一道题的整组 Rubric”为判断单位。只要存在关键漏项、错误要求、严重重复计分或无法判定的标准,这组 Rubric 就不应直接进入正式评测。
模型的 Rubric 满足率:它衡量模型在一组有效标准上的表现:
模型 Rubric 满足率 = 已满足的适用 Rubric 权重 ÷ 全部适用 Rubric 权重。
两者不能混用。模型满足率高,可能是模型真的更强,也可能是题目太简单、Rubric 太宽松。只有先证明 Rubric 有效,模型分数才有解释价值。

六、如何量化 Rubric 本身的质量?

可以先构建一小批人工金标:由两位评测人员独立阅读任务、环境和工具,写出必要 Rubric,再通过讨论形成最终标准。自动生成结果与金标比较,重点看:
  • 精确率:生成的标准中,有多少确实必要;
  • 召回率:金标中的关键要求,有多少被生成覆盖;
  • 严重项召回率:安全、越权、错误执行等要求是否 100% 覆盖;
  • 可判定率:有多少标准具备明确的通过条件、失败条件和证据;
  • 重复率:有多少标准实际在重复检查同一个错误;
  • 维度映射准确率:问题是否被归入正确的能力标签;
  • 人机一致率:人工和自动裁判依据同一 Rubric 时,结论是否一致。
综合分可以用于版本比较,但不能掩盖硬伤。如果高风险要求漏了一条,即使其他指标很好,也应该判为不合格。

七、真正要验证的不只是 Rubric,而是评测集有没有测量能力

仅看 Rubric 文本是否正确还不够。还要把不同模型或同一模型的多个版本放进评测集,观察它是否具备三种能力。
1 区分度
如果所有模型都接近满分,不一定说明大家都很强,也可能说明任务过于线性、约束过少,评测已经触顶。
高质量 Case 应该包含真实决策因素,例如规格、库存、预算、时间、优惠、异常状态和必要确认,让模型必须在多个约束中做出正确选择。
2 稳定性
Agent 执行具有随机性,只跑一次容易偶然。可以让同一模型在同一道题上运行 K 次,同时观察:
  • Avg@K:K 次运行的平均得分,反映总体水平;
  • Pass@K:K 次中至少成功一次的比例,反映能力上限;
  • Pass^K:K 次全部成功的比例,反映稳定交付能力。
“偶尔能做对”和“每次都能做对”是完全不同的产品能力。对真实 Agent 而言,后者往往更重要。
3 可解释性
除了总分,还要按能力标签统计 Rubric 满足率。如果某类基础能力已经普遍饱和,但金额与规格决策、异常识别或多步骤操作仍能拉开差距,下一轮评测集就应该继续加深后者,而不是重复堆积简单题。

八、工具轮次不能简单理解为越少越好

调用少不等于效率高。一个模型可能因为过于“果断”,跳过查询、澄清和校验;另一个模型也可能因为缺乏规划,进行大量无效探索。因此,工具效率应当同时看:
  • 必要工具是否完整调用;
  • 调用顺序是否符合任务依赖;
  • 是否存在重复查询和无效试探;
  • 失败后是否根据新信息调整策略;
  • 相同任务质量下,调用成本是否更低。
工具轮次应该是任务质量约束下的效率指标,而不是独立追求的最小值。

九、一套可落地的 Rubric 生产流程

1 先定义任务边界:明确用户目标、初始状态、可用工具和禁止行为;
2 提取任务义务:把需求、约束、异常分支和安全条件逐项列出;
3 生成原子 Rubric:一条标准只对应一个可观察结果;
4 标记证据:说明应检查回复、工具参数、页面状态还是最终结果;
5 标记严重度:区分高风险、核心成功条件和体验优化项;
6 映射能力标签:保证失分能够回到明确的优化方向;
7 人工校准:通过双人标注建立金标,并处理分歧;
8 模型试跑:检查区分度、稳定性、天花板和异常分布;
9 持续迭代:减少已经饱和的题目,补充能暴露真实短板的高区分度任务。

结语:评测不是给模型出题,而是在定义“什么叫做好”

Rubric 的价值,不是把标准写得越来越多、越来越复杂,而是将模糊的“这个 Agent 好不好”,转化为一组清楚、独立、可验证的判断。
该检查的一个不少,不该检查的一个不多;每一项都能找到证据,每一次失分都能解释原因。
当 Rubric、任务环境和工具系统真正连成一体,评测才能回答比“模型得了多少分”更重要的问题:它为什么失分?短板发生在哪个能力环节?是模型问题、工具问题,还是产品机制问题?下一轮应该优先优化什么?
这才是 AI 产品评测真正有价值的地方。

随机文章