本文编译自 Microsoft Community Hub 的文章 Auto-Generated Rubric Evaluators: Building Context-Aware Evaluators for AI Agents，原作者 Shuo Qiu 等人。我读完之后觉得这套验证方法挺扎实，就顺手整理成中文，把里面的数据和结论都留了下来。

预置评估器有个老毛病：它们太通用了，一旦碰到真实业务里的智能体，往往不够贴身。Microsoft Foundry 里的自动生成 Rubric 评估器就是冲着这个问题去的——你手头已经有的上下文，它拿来生成一个针对具体任务的 Rubric 评估器。团队从四个方面做了验证，结论是：在测试条件下，用推荐配置跑出来的评估器，有效性和可靠性都站得住。

为什么你的智能体需要一个专属评估器

先讲个场景。一家电信公司的客服智能体，客户发消息过来，想换套餐，顺便要求退掉上个月多扣的钱。这时候智能体得先核验客户身份，确认新套餐，然后才能结束对话。要是漏了身份核验这一步，那就不是服务问题，而是安全事故了。你看，这套成功标准是这一个场景独有的，换个业务就不适用。

自动生成 Rubric 评估器想解决的正是这件事：把你已经有的上下文喂进去，生成一个针对该任务的评估器，它会给出一个加权分数，还附带每个维度的解释，之后可以在多轮迭代里反复用。

他们是怎么验证评估器质量的

验证从四个方面展开：

  • 判定有效性 —— 对真实案例的判断，是否和一个称职的审阅者会得出的结论一致。
  • Rubric 有效性 —— 生成的 Rubric 能不能抓住任务要求和失败模式。
  • 人工质量抽检 —— 真实案例的判断，在人看来是否合理。
  • 可靠性与可分性 —— 判断在重复运行下稳不稳定，能不能把强弱不同的候选智能体区分开。

验证结果

1. 与可信参考信号的一致性

第一步是端到端地验证：先用 Rubric 生成器产出各个维度，再用 Rubric 评估器拿这些维度给每个案例打分。生成器和评估器都用 GPT-5.4。

要问的第一个问题很朴素——这些端到端的分数，会不会跟着团队本来就信任的信号一起动？说白了，失败的案例分数会不会更低，成功的会不会更高？为此他们挑了几个社区已经当作参照的基准：

数据集 考察什么
JSON Editing 确定性的结构化编辑任务，输出可以精确校验。
TauBench Telecom 客服智能体任务，要求遵守策略、调用工具、完成任务。
The Agent Company 长周期的职场智能体任务，涉及多步工具调用。这里用的是 InspectAI 的 10 个案例子集。
BFCL 多轮工具调用 真实工具使用场景下的多轮函数调用行为。
LiveClawBench 开放式的 Web 智能体任务，需要浏览、交互和判断。
Retail-Agent 客服 真实的、生产环境风格的零售客服对话。

接着让生成流水线为每个场景生成 Rubric 评估器，测量评估器分数和可信参考信号之间的相关性。对于那三个带有逐案例参考信号的数据集，可以直接看评估器是不是给成功案例打了比失败案例更高的分。

他们还从不同的候选智能体那里生成轨迹。这些实验里，每个候选智能体用的是同样的任务设置和提示词，只是底层模型不同，这样就得到了一组从强到弱、可控的智能体行为。

因为评估器返回的是连续分数，当可信的案例级信号能被读成"成功 vs 失败"时，他们用 ROC AUC（受试者工作特征曲线下面积）。这个指标衡量的是：拿一个成功案例和一个失败案例比，评估器给成功案例更高分的频率有多高。

ROC AUC 结果

结果是，生成的 Rubric 评估器在案例级别上和可信信号对得挺齐：TauBench Telecom 上 ROC AUC 是 0.794，The Agent Company 是 0.869，JSON Editing 是 0.972。

评估还有一个重要目标：那些在参考信号上表现更好的候选智能体，评估器也应该给它们更高的分。这一点在候选智能体之间做选择时更直接相关，而且它对一致性的要求相对宽松，因为聚合后的分数对单个判断里的噪声没那么敏感。

衡量它用的是聚合的候选智能体 Spearman ρ，看评估器给候选智能体的排序，和 oracle 排序是否一致。ρ 为 1.0 表示评估器的排序和 oracle 完全对齐，0 表示没有关系。BFCL 和 LiveClawBench 的 oracle 排序来自它们官方排行榜的分数。

候选智能体 Spearman ρ

在聚合的候选智能体层面，五个基准上的 Spearman ρ 从 The Agent Company 的 0.69 到 JSON Editing 的 0.98 不等。聚合把逐案例的噪声压下去了，所以当目标是挑智能体的时候，候选智能体排序才是更值得看的那个视角。

2. GDPVal 上的 Rubric 质量

GDPVal 是一个衡量 AI 模型在真实、有经济价值的工作上表现如何的基准，覆盖政府、制造、技术服务等行业。这个基准每个任务都带一个由领域专家撰写的 Rubric，正好可以拿来测 Rubric 的有效性。

做法是：让 Rubric 生成器为每个测试案例产出一个 Rubric，再用一个独立的匹配判官，把生成的维度和专家维度对上。由此得到两个指标：

  • 召回率。 对每个人工标注的维度，是否至少有一个生成的维度表达了类似的要求？
  • 精确率。 对每个生成的维度，是否至少有一个标注维度表达了类似的要求？

在这个设置下，生成的 Rubric 在 GDPVal 任务上对着专家维度拿到了 72.1% 的召回率和 86.4% 的精确率。

GDPVal Rubric 质量

3. 零售客服对话上的人工质量抽检

对着一个真实的零售客服数据集，他们生成了一个六维度的 Rubric，然后拿它给 12 段对话打分，再逐一人工核查每一个"案例 × 维度"的判断。

零售客服人工抽检

这是个小样本（12 段对话），72 个"案例 × 维度"判断里，审阅者只对其中一个有异议。大多数中性案例都是适用性上的问题——评估器在"这个维度到底适不适用"上标注得不太一致。

零售客服判断分布

可靠性与可分性

还有个关键问题：评估器的分数到底有多可靠？这里看两样东西。可靠性，指的是同一个案例明天再打分，还能不能得到一样的分；可分性，指的是评估器能不能有把握地把两个候选智能体分出高下。

可靠性

明天再给同一个案例打一次分，分数还一样吗？他们用两种方式衡量。单测度组内相关系数 ICC(3,1)，看分数的方差里有多少来自案例本身的真实差异，而不是重复运行的噪声；Kendall’s W 则衡量重复运行之间的排名可靠性，1.0 意味着评估器每次都以同样的顺序给案例排序。

可靠性结果

JSON Editing 上，ICC(3,1) 是 0.852，Kendall’s W 是 0.767，意思是在这个实验设置下，对同一个案例重复跑评估器，拿到的数字比较接近。TauBench Telecom 表现类似，同样的推荐配置下 ICC(3,1) 是 0.85，Kendall’s W 是 0.89。

可分性

可分性衡量的是分数够不够果断：把两个候选智能体摆在一起，评估器能不能有底气地说哪个更好。

他们报告的是平均成对自助置信度，用来衡量排名的稳定性。对每一对候选智能体，重采样案例、重新算每个智能体的平均评估分。这一对的置信度，就是支持那个更常见排序的自助样本占比：接近 0.5 说明排序不稳，接近 1.0 说明评估器能稳定地把这一对分开。把所有候选智能体对上的这个值取平均，就得到最终结果。

JSON Editing 和 TauBench Telecom 上，候选智能体的区间都很紧。平均成对自助置信度在 JSON Editing 上是 0.96，在 TauBench Telecom 上是 0.95。

上手试试

自动生成 Rubric 评估器的结果会随任务设计、输入质量和评估设置而变化。我的建议是：先在 prompt 字段里给出一个清晰、定义明确的评估描述，把尽量多的高质量上下文塞进去，比如智能体的定义和示例，然后在正式用之前，认真看一遍生成的 Rubric。拿它跑一小批你已知好的和已知坏的案例，你就能摸清分数是怎么反映不同失败模式的。

到 Foundry 门户 里试一下这套流程，跟着 Rubric 评估器教程 走一遍。想看 Rubric 在更完整的可观测性工作流里怎么用，可以看 Build 的分会场 From observability to ROI for AI agents on any framework。Build 2026 上关于可观测性的完整公告，都在这篇里：Build 2026: From observability to ROI for AI agents on any framework。