评估从黄金指标到 Rubric丨AgentLoop 数据飞轮实践三上周做了一次内部评估体系复盘恰好落到一个让我纠结了很久的问题上为什么我们的 Agent 在任务成功率、平均轮次、响应延迟这些黄金指标上全绿可一线的用户反馈和客服工单却不怎么好看。这个系列前面两篇分别讲了数据回流的管道搭建和策略迭代的闭环今天这篇想认真聊聊评估这件事。单独看Agent 的评估是数据飞轮里最容易被低估的一环——很多人觉得“跑几个指标不就行了吗”但真正把 AgentLoop 跑起来之后你会意识到飞轮转得快不快、转得稳不稳取决于评估反馈的分辨率和可信度。一个只有“通过/不通过”两种状态的评估体系是没有能力告诉你下一步该往哪儿修的。我在这篇里把我们从“黄金指标依赖症”过渡到“Rubric 多维评估”的完整过程、踩过的坑、调过的参都整理出来了。内容偏向实战适合正在搭建 Agent 评估体系、或者觉得“指标都达标了但 Agent 就是不好用”的团队参考。1. 为什么评估成了数据飞轮里最难搞的一环1.1 一个反直觉的现象全绿指标的 Agent 上线后翻车了先说个真实案例。我们内部有个企业知识库问答 Agent当时看板上的数字非常漂亮任务成功率 96%单轮解决率 80%平均响应时间 1.8 秒用户主动点“有帮助”的比例也在 70% 以上。当时全组都觉得稳了于是推到了更大的业务范围。结果上线后两周客服的工单量翻了一倍用户主要在抱怨两类事情一是“它是不是忘了我之前说的话”二是“同一个问题昨天和今天答案完全不一样”。仔细复盘之后发现这两个问题在黄金指标上完全无感。用户的“追问被忽略”并不影响任务成功率——因为系统把每个用户问题当成独立请求来处理第二次提问只要检索到内容、成功返回了答案就算“任务完成”。而“答案不一致”的问题在被归纳成用户反馈之前根本不会反映在任何一个自动化指标上。这个例子特别典型黄金指标只能回答“任务有没有完成”回答不了“完成得好不好、用户体感如何、失败的原因到底是什么”。1.2 飞轮的“转动力”来自高分辨率的反馈信号AgentLoop 数据飞轮的基本逻辑很简单把线上产生的交互数据收回来做评估和归因再把评估结果转化成语料、示例、策略约束重新喂给 Agent然后继续跑、继续收数据。这听起来像一个标准的闭环但真正决定这个闭环能不能加速的不是数据量的大小而是每一条反馈里包含的信息密度。你可以把反馈信号想象成飞轮的“转动力”。如果评估只输出一个“0 或 1”飞轮就只能做最简单的二分类选择——这个样本是好的那个是不好的那你顶多能拿好的去凑 few-shot 示例。但如果评估能告诉你“这个样本在指令遵循上得了 2 分、在上下文利用上得了 4 分、工具选择环节直接崩了”那你能做的事情就完全不一样了你可以针对工具调用的短板去修策略可以把“上下文利用不足”的样本单独做成训练数据可以按维度去追踪每次发版到底是变好了还是变坏了。用体温计和体检报告来类比比较合适体温计只能告诉你“发烧了/没发烧”但一套完整的体检报告能告诉你哪个器官有异常、严重程度如何、该去挂哪个科。数据飞轮需要的恰恰是体检报告级别的信息而不是体温计级别的二元判断。2. 黄金指标的局限数字达标不等于体验达标2.1 任务成功率只能描述终点不能描述过程任务成功率可能是 Agent 评估里用得最多、也最容易误导人的指标。它的本质是二元的——这个任务最终有没有成功完成。但这个指标严重丢失了过程中的信息。举个例子三个不同的 Agent 版本任务成功率都是 95%但失败的模式可能完全不同。版本 A 的失败集中在工具调用超时因为某个外部 API 在高峰期响应特别慢版本 B 的失败集中在检索结果为空因为某些长尾 query 在知识库里根本没有对应文档版本 C 的失败集中在多轮语义漂移Agent 在第三轮之后开始遗忘用户的初始意图。这三个问题的修复方向完全不同但在成功率的单一指标下你看到的只是同一个数字。更麻烦的是如果只看成功率你会发现它涨到 95% 之后就很难再往上走了但产品体验的提升空间其实还很大。这时候如果还把成功率当唯一的北极星指标团队很容易进入一种“不知道往哪儿优化”的迷茫状态。我在实践中的体会是成功率适合做宏观监控但完全不适合做诊断工具。2.2 延迟与成本指标容易被“指标游戏”操纵还有一类黄金指标是延迟和成本。它们当然重要但一旦它们成为团队考核的 KPI就会触发“指标游戏”——大家会想办法让数字变好看而不是让产品变好用。我见过最典型的例子是为了把平均对话轮次降下来产品直接砍掉了 Agent 的主动追问机制。表面数据确实好看了——单次任务的平均轮次从 2.8 降到了 1.6但用户不得不花更多力气手动补充背景信息还有团队为了压延迟把底层模型从旗舰版换成轻量版延迟降了 40%但回答质量在稍微复杂的任务上肉眼可见地下降。这类操作的隐蔽性在于它不会立刻体现在成功率这一类的指标上而是要等用户抱怨积累到一定程度才暴露。指标游戏在 Agent 场景下比传统软件项目更危险因为 Agent 的中间链路很长——意图识别、检索、上下文组装、工具调用、答案生成任何一个环节被“优化”都可能影响最终体验而这些影响都很难用少数几个高维指标捕捉到。2.3 用户反馈指标的滞后性困局有人可能会说那就用更真实的指标比如用户满意率、留存率、推荐率。这些指标确实更贴近真实体验但它们有两个致命问题。第一个问题是滞后性。一个迭代版本从上线到积累足够量的用户反馈往往需要一到两周。在两周的窗口期内飞轮的其他环节都在空转你无法及时知道这次改动是变好还是变坏。第二个问题是噪声太大。用户反馈很容易受到版本窗口、新功能新鲜感效应、抽样群体偏差的影响。新功能上线第一周用户满意度普遍偏高但这种“蜜月效应”很快就会消退如果你刚好在 A/B 实验里抽到了高活跃用户群体反馈也会整体偏正面但这并不能说明你的 Agent 真的变好了。所以在 AgentLoop 实践里我逐渐形成了一个判断线上真实反馈必须看但它更多是“滞后校验”真正的日常迭代不能靠它驱动必须有一套可以即时执行的、能给出可操作信号的评估体系。这就是我们转向 Rubric 的根本原因。3. Rubric 评估体系的设计从“评判好坏”到“定义好坏”3.1 Rubric 不是评分表是评估标准的“公约数”Rubric 这个词在教育领域用得最多简单说就是一套“提前公布评分标准”的评估框架。它包含三个核心元素评估维度从哪些角度评价、等级量表每个维度分几档、行为描述每个等级到底长什么样。Rubric 的价值在于它把“这个回答好不好”这种高度主观的判断拆解成若干个可对齐、可讨论、可复现的子问题。我第一次接触这个概念时觉得有点绕但后来想通了Rubric 的本质是一个团队或一个系统对“好坏”达成的公开的、可争议的共识。没有 Rubric 的时候两个标注员对同一份 Agent 回答的评分可能相差 2 分你觉得“不够专业”我觉得“已经不错了”吵半天也没有结论。有了 Rubric大家至少能在同一个维度和等级框架下来对齐分歧。用在 Agent 评估上Rubric 把原来“这个交互好不好”的全方位主观判断转化成了对几个具体能力项的分项打分每一分都有明确的行为锚点。3.2 我为 Agent 评估设计的五个 Rubric 维度在 AgentLoop 的实践里我一开始设计的 Rubric 有七个维度后来删繁就简收敛到五个。这五个维度基本覆盖了对话式 Agent 的核心能力而且相互之间尽量保持独立避免维度重叠导致评估者尤其是 LLM Judge分不清该在哪个维度扣分。维度评价重点低分典型表现高分典型表现指令遵循是否按用户要求执行包括格式、约束、边界遗漏约束条件输出格式跑偏完整满足全部约束输出规范上下文利用是否充分利用对话历史、检索片段、用户画像无视前置信息重复提问准确引用历史关键信息回答有连续性工具选择与调用工具选型是否正确参数传递是否合理选错工具、参数缺失或类型错误工具选择精准参数完整且语义正确逻辑连贯性多步推理链路是否完整、有无矛盾跳步、自相矛盾、结论无依据推理链完整步骤之间有清晰因果关系答案质量最终输出的准确性、信息密度、可执行性空泛、啰嗦、关键信息缺失准确、结构化、可以直接落地执行这里有个经验五个维度是“评估开销”和“信息量”之间的平衡点。维度太少分项评分退化成整体印象分失去了诊断意义维度太多人工标注成本和 LLM Judge 的稳定性都会成为问题。五个维度的量级适合大多数任务型 Agent。3.3 行为锚定Rubric 有效性的生死线设计 Rubric 最容易犯的错误是只写了维度名和分数档位却没有写每个档位的行为描述。这种 Rubric 落地必失败——因为评估者不管人还是模型拿到手里仍然不知道“2 分和 3 分到底差在哪”。行为锚定的核心是把抽象的量表转化为可以被观察和判断的具体行为。拿“指令遵循”来举例我们内部早期的标准是“1-5 分分数越高越好”结果两个标注员因为“这个算 3 分还是 4 分”能吵半小时。后来我们把每个分数档位都写上了行为描述5 分完整执行所有用户指令输出格式与约束全部正确没有任何遗漏。4 分执行全部核心指令但忽略了个别次要约束例如要求输出为 Markdown 表格实际给了纯文本。3 分执行了大部分指令但遗漏了至少一个核心约束且遗漏内容明显影响用户体验。2 分只执行了少数指令大量约束被忽略输出与用户需求严重偏离。1 分未执行用户任何指令输出完全偏离需求方向。有了这种行为锚定评估者可以按“匹配描述”的方式来打分而不是凭主观印象“估分”。更重要的是同一份 Rubric 可以被同时用于人工标注和 LLM-as-Judge这为后面大规模自动评估打好了地基。4. AgentLoop 数据飞轮里评估如何真实落地4.1 评估数据的来源构成线上日志优先合成数据兜底Rubric 体系设计出来之后第一步要考虑的是“评估什么数据”。在 AgentLoop 实践中评估样本不是一次性批量造出来的而是从线上日志里持续回流、持续更新。我这边实际把评估数据的来源分成三层。第一层是线上日志自动抽样。核心原则是“不能只抽成功的样本也不能只抽失败的样本”。我们当时按用户 ID 做散列抽样确保同一用户的多轮对话要么全部被抽到、要么全部不被抽到避免同一用户的多条相似对话同时进入评估集导致数据冗余。抽样比例通常控制在每日任务的 1%-2%积累到一周就能形成一份容量可观的评估集。第二层是失败任务和低分任务的近因过采样。线上抽样拿到的是典型的“自然分布”但自然分布里失败样本占比往往较低不足以支撑细致的失败归因。所以我们会单独捞一批“成功率低的任务类型”“工具调用报错的任务”“用户标记为无用回答的任务”按近因窗口加权后并入评估集。第三层是针对新场景和边界 case 的合成样本。这类数据用来补足长尾覆盖。举个例子当我们要上线一个新的外部工具比如新增了一个日历查询 API系统里几乎不会有这条链路的真实日志这时候就需要人工构造一批模拟用户指令来测试 Agent 的适配情况。注意合成数据永远替代不了真实数据它只能作为兜底和补充。4.2 LLM-as-Judge 与人工标注的协作分工有了评估数据集之后下一步就是实际打分。全部靠人工标注在 Agent 场景下完全不现实——每天评估集可能有几百上千条样本每条样本又包含多轮对话和工具调用记录标注员根本忙不过来。我们的做法是LLM-as-Judge 大规模初筛 人工处理边界样本。LLM-as-Judge 说白了就是让一个强模型比如 GPT-4-class 的模型拿着我们设计的 Rubric 去给 Agent 的表现打分。这套方案在实践中要能跑通有几个前提条件一是 Judge 的 prompt 必须把行为锚定描述原样给进去不能让它自己发挥二是 Judge 的 temperature 必须固定为 0我后面在踩坑部分会详细讲为什么三是必须定期用“校准集”来测试 Judge 的稳定性校准集里是人工已经打过分、答案已知的样本。人工标注员在这个体系里不是“主力打分者”而是“边界仲裁者”。他们处理的样本有三类LLM Judge 给出分数但置信度低的样本不同模型作为 Judge 时打分分歧较大的样本评估集里被抽样策略特意标记出来的疑难样本。实践中你会发现虽然 Judge 解决了 80% 的评估工作量但人工仲裁那 20% 恰恰决定了整套评估体系的可信度。4.3 评估结果要回流到飞轮的具体动作评估本身不是目的评估结果是用来驱动飞轮旋转的燃料。很多人做完评估就完事了把分数表一导出、汇报一写、归档一放数据飞轮根本转不起来。在我们的实践里评估结果回流有三个关键动作。第一个动作是按维度分布识别系统短板。如果“工具选择与调用”这个维度的平均分连续两周走低那就要去查是工具描述不清晰、参数 schema 不合理还是 Agent 的工具选择 prompt 有 bug。第二个动作是按场景聚类失败模式。比如把所有“工具调用报错”的评估样本聚到一起看看是否集中在某个特定工具上如果是那大概率不是 Agent 的问题而是工具本身的问题——这种归因能力在单一黄金指标下是根本不可能做到的。第三个动作是将典型样本转化为训练数据。高分样本进 few-shot 示例库低分样本经人工修正后进微调数据池边界样本进规则约束的回归测试集。这四个环节——收集、评估、归因、回流——合在一起才构成完整的数据飞轮。其中评估环节的“分辨率”直接决定后续归因和回流的精准度。这也是我反复强调 Rubric 而非黄金指标的原因。5. 实测中踩过的坑和调整记录5.1 LLM-as-Judge 的“宽松漂移”和随机波动用 LLM 当 Judge最大的坑不是它不够聪明而是不稳定。我实际遇到的最典型问题是“宽松漂移”——同一个 Judge 模型在几个月的评估周期里平均分会慢慢往上走。一开始我还以为是 Agent 真的在变好后来发现是模型供应商升级了底层版本Judge 的判断标准悄然发生了漂移。解决办法有三个层次。第一是把 Judge 的 temperature 固定为 0并且用快照方式固定模型版本不能让它跟随上游版本自动升级。第二是每次评估跑批时都带上一组“校准样本”——校准样本是人工提前打好分的基准集如果 Judge 在基准集上的分数产生明显偏移就需要对整批评估结果做去偏处理或者重新生成 Judge 输出。第三是定期人工复核 Judge 的输出质量尤其是那些“接近边界”的样本确保它没有在 Rubric 的理解上产生语义偏移。随机波动是另一个问题。即使 temperature 设为 0某些模型在某些 prompt 下依然会出现输出不稳定。比如同一份样本同一份 Rubric跑两次 Judge一次给 4 分一次给 3 分的现象我遇到过不止一次。对这种问题的处理方式是关键样本用多模型投票或者多次采样取众数来稳定结果。5.2 Rubric 版本更新后不要全量重标Rubric 不是一锤子买卖它必须随着对 Agent 能力要求的提高而迭代。但这里有一个特别容易踩的坑每次 Rubric 更新要不要把历史评估数据全部按新 Rubric 重新标注一遍我最早的想法是“必须全量重标不然新旧分数没有可比性”。结果试了一次之后立刻放弃了——几千个评估样本人工重标根本做不完全交给 LLM Judge 又会产生新的不稳定因素而且新版 Rubric 和旧版 Rubric 之间的语义差异可能只集中在某一个维度其他维度完全没必要重标。后来我们改成了一种更务实的策略每次 Rubric 大版本更新时选定一个“关键样本集”通常是几百条覆盖各场景的固定样本只对这批样本做重标。这组样本相当于团队内部的“标准答案”用于验证新旧 Rubric 之间的分数映射关系。其他历史评估数据保留旧版评分并在元数据里记录每个样本对应的 Rubric 版本号。后续做趋势分析时只比较同一个 Rubric 版本区间内的数据跨版本比较只在“关键样本集”层面进行。这样既保住了评估数据的连续性又没有背上全量重标的沉重负担。5.3 评估治理最终交付的是“可追溯性”走到后期我对 Agent 评估体系的理解发生了一个重要变化分数本身不是资产可追溯性才是。也就是说任何一个评估分数都要能回答“为什么是这个分数”这个问题。如果做不到这一点飞轮越转越快但方向是否对根本没人能判断。为了让每个分数都可追溯我给每个评估样本挂了完整的元数据输入输出轨迹、每一轮的工具调用记录、检索片段清单、评估用的 Rubric 版本号、评估者身份人工还是具体哪个模型、评估时间、置信度。现在如果产品经理跑过来问“为什么这周的‘答案质量’分数比上周降了 0.3”我可以直接拉出对应的几十个案例样本逐条打开看当时的交互轨迹和评分明细而不是给出一句“综合来看略有下降”的空话。可控的、高分辨率的、可追溯的评估反馈才配得上“数据飞轮”这个概念本身。黄金指标适合对上汇报Rubric 适合对内改进两者定位不同但千万别把前者当成后者的替代品。最后补充一个非常实用的经验Rubric 设计完成后不要立刻投入大规模评估先拿 20-30 条覆盖不同难度的样本跑一轮“试标注”人工标一遍LLM Judge 标一遍把两边的分歧整理出来逐条讨论。这个动作能在一周内帮你把 Rubric 从“看起来合理”打磨到“实际可用”几乎是前期投入产出比最高的一步。评估体系这种东西设计方案再漂亮落到真实标注数据上能不能收敛才是最终检验标准。