做 Agent 类产品有一段时间的朋友大概率都有过这样一种体验模型换了一个版本你觉得效果明显变好了可一到线上用户反馈还是一堆问题你有评测集每天都跑分数明明在涨可那些头疼的 bad case 翻来覆去还是那几个。问题出在哪多半不是模型不行而是你的评估体系太粗了——粗到只能告诉你“整体好不好”却完全说不清“哪里不好、为什么不好、怎么改”。这篇文章是 AgentLoop 数据飞轮实践系列的第三篇专门讲评估环节。前两篇我们聊了数据怎么收集、怎么清洗、怎么构造训练样本这一篇要把飞轮里最关键的“阀门”掰开揉碎讲清楚如何从只看黄金指标过渡到用 Rubric评测量表来做细粒度评估。这个过渡做好了数据飞轮才真正开始转起来做不好你辛辛苦苦攒的数据就只是一堆躺在存储里的死数据。适合正在搭 Agent 评估体系、每天被 eval 分数和线上表现对不上困扰的工程师、算法同学和技术负责人阅读下面直接进入正题。1. 为什么“评估”是数据飞轮的发动机1.1 数据飞轮闭环里最容易卡住的一环数据飞轮这个概念本质上是一个增强回路系统在真实使用中产生数据数据经过筛选和处理变成高质量样本样本用来训练或微调模型模型上线后表现更好、吸引更多使用于是又产生更多数据循环往复。听上去很顺但真正操作过的人都知道这个闭环里有一个环节特别容易卡住就是“评估”。为什么因为这个环节表面上看是一个技术问题实际上它是一个标准问题。数据清洗有规则可循样本构造有模板可套模型训练有框架可用唯独“这个输出到底好不好”这件事没有标准答案。你觉得这个回答准确他觉得不够全面你这个场景认为应该简洁换个场景又要求详细。没有统一标准后面所有环节都会跟着晃。我在 AgentLoop 上做数据飞轮实践的第一感受是工具链其实不缺缺的是你对“好”和“坏”的定义能力。平台能帮你管理数据、跑评测、记录版本但如果你自己说不清楚评估维度再强大的平台也只是个高级记录本。数据飞轮转不起来的团队十有八九不是模型不行而是评估这关没打通。1.2 从“看着不错”到“可量化”黄金指标的定位大多数团队一开始做评估都是从黄金指标入手的。黄金指标是什么简单说就是那种能反映系统整体健康度的核心度量数量不宜多三五个足矣要一眼能看出系统是不是在朝正确的方向演进。在 AgentLoop 的实践中我们最早定义的黄金指标大概是这样的任务完成率用户发起的任务里有多大比例被成功完成、单任务平均轮次模型和用户之间一来一回的对话轮数轮次过多往往意味着理解能力不足、无效输出率模型输出了一批完全没用、需要用户反复纠正的内容的占比、用户二次确认率用户是否需要对模型结果做额外确认。这几个指标组合在一起基本能回答“整个系统在宏观上是变好了还是变差了”这个问题。黄金指标的价值在于它给你提供了一个全局视角。你会知道这周上线的新版本比上周强还是弱会知道某个策略改动是不是造成了整体回退。它能触发告警、能追踪趋势、能让你对上汇报时心里有底。但这里我必须泼一盆冷水黄金指标只管“发现”不管“诊断”。它就像一个仪表盘上的发动机故障灯亮了你知道出问题了但它不会告诉你究竟是火花塞坏了还是油路堵了。1.3 黄金指标在 Agent 场景下的局限性如果你做的是传统推荐系统或者搜索排序黄金指标的表现力其实相当强因为那些场景的反馈链路非常短用户点没点、看了多久、买没买都是明确的信号。但 Agent 类产品不一样它的交互是多轮、开放、非结构化的。一次任务可能跨越十几轮对话你很难说清楚到底哪一轮的哪句话导致了最终的成功或失败。举个我们在 AgentLoop 上真实遇到的例子。某个智能客服 Agent 的任务完成率一直稳定在 78% 左右怎么优化都上不去。黄金指标显示一切正常没有明显回退但就是停滞不前。后来我们做了细粒度的 tracing 分析才发现问题集中在“多条件查询”这类复杂任务上模型在单条件场景下表现很好但只要用户一次问两三个条件模型就开始丢信息不是漏了一个维度就是错误合并了条件。这类问题靠任务完成率根本发现不了因为整体指标被大量简单任务稀释了。这就是黄金指标在 Agent 场景下最大的局限——它是滞后且平均的。它只能告诉你系统整体处在一个什么水平却无法定位问题到底发生在哪类技能、哪类任务、哪一轮对话、哪种输出模式上。没有定位能力就没有迭代方向。你需要一把更细的尺子这就是 Rubric。2. 认识黄金指标先解决“看全局”2.1 黄金指标怎么定义北极星指标 vs 护栏指标讲 Rubric 之前我想先把黄金指标这件事说透因为很多人连黄金指标本身都定义不明白就直接跑去搞 Rubric结果两头都做不好。黄金指标内部其实应该分两层一层叫北极星指标一层叫护栏指标。北极星指标负责回答“我们的系统做得够不够好”它的特点是必须和产品核心价值强绑定。比如你做的是代码生成 Agent北极星指标可能就是“生成的代码被用户采纳并合入工程的比例”你做的是数据分析 Agent北极星指标可能是“用户在最少干预下拿到正确结论的比例”。北极星指标不能多一个就够多了你就分不清到底该优化什么。护栏指标则负责守住底线回答的是“系统有没有闯祸”。在 Agent 场景里护栏指标至少要有这几类有害内容率模型有没有输出歧视、暴力、违法等不安全内容、越权操作率Agent 有没有执行超出权限范围的操作、幻觉率模型有没有一本正经地编造不存在的功能或数据。北极星指标决定你能飞多高护栏指标决定你能活多久。一个只追求效果但频繁闯祸的 Agent上线一周就会被投诉淹没。在 AgentLoop 里配置这些指标时我的建议是北极星指标要跟业务方、运营、老板一起定死不要自己闷头拍。护栏指标则要跟安全合规团队逐条对齐宁可指标定义得严苛一些也不要为了好看而放松标准。黄金指标的制定不是技术活是管理活它的本质是在帮团队统一“什么是对的”这个最基本的问题。2.2 AgentLoop 里的黄金指标体系实例光说概念太虚我直接拿 AgentLoop 上一个企业知识库问答 Agent 的黄金指标体系来举例。这个 Agent 的核心场景是员工问答比如“年假制度是什么”“报销流程怎么走”当时我们定义的指标体系长这样指标类型指标名称定义目标值北极星指标一次性解决率用户在单轮交互内获得满意答案的比例≥ 70%北极星指标平均任务完成时长从用户发问到任务闭环的平均时间≤ 45 秒护栏指标知识幻觉率答案中与知识库原文冲突的比例≤ 2%护栏指标越权信息泄露率输出包含权限外敏感文档的比例0%过程指标检索命中率检索模块返回结果包含正确文档的比例≥ 85%过程指标澄清率模型主动向用户澄清模糊问题的比例10% ~ 20%这套指标体系一跑起来团队内部立刻有了共同语言。产品经理说优化体验算法问优化哪里产品经理直接说“把一次性解决率从 68% 拉到 70%”对话清晰多了。这在我看来就是黄金指标最大的价值——它不是一个冷冰冰的数值它是团队成员之间沟通效率的催化剂。不过我必须要提醒一点过程指标和结果指标要区分开。检索命中率这类过程指标很重要但不能替代结果指标。有些团队把检索命中率刷得很高用户实际体验却没什么变化原因就是召回正确文档不等于最终给出正确回答中间还有推理、归纳和生成的环节。过程指标是帮你诊断问题的不能拿来做北极星。2.3 黄金指标的问题能发现车坏了但不知道哪个零件坏了黄金指标的积极意义讲完了接下来要直面它的短板。我总结下来有四个比较突出的问题。第一个问题是滞后性。Agent 产品通常不是一次性交付就完了而是持续迭代的。你今天部署一个新版本黄金指标要积累一到两天的线上数据才能反映真实水平。等你发现指标掉了再回滚半天时间已经过去了。对于增长期的产品来说这个反应速度太慢了。第二个问题是归因困难。线上指标是整体数据混入了大量用户行为差异、样本偏差、时间波动。任务完成率从 78% 掉到 74%可能是因为模型真的变差了也可能是因为今天来了一批特别刁钻的新用户还可能是某个上游数据源临时出了问题。黄金指标只会告诉你“掉”了不会告诉你为什么掉。第三个问题是覆盖不全。黄金指标再精简也不可能覆盖所有场景维度。你的 Agent 可能有十几个技能查天气、订会议室、答政策、写周报……每个技能的难度和表现都不一样。一个平均值 80% 的指标背后可能是一个技能 95%、另一个技能 40%。你盯着那个 80% 自我感觉良好用户却已经在 40% 的技能上骂骂咧咧了。第四个问题也是和 Rubric 最直接相关的问题——黄金指标无法给出可操作的改进建议。它告诉你“检索命中率 85%”然后呢你要优化哪个查询哪个文档的片段切分有问题针对什么样的问法需要优化这些问题的答案必须到更细的评估粒度里去找。这四个问题叠加在一起结论就很清晰了黄金指标是必要的但远不够。它负责让你站在高处看清全局趋势而你还需要一套能落地到具体样本层面的评估工具来支撑每天的实际迭代决策。3. 从黄金指标走向 Rubric评价体系的一次升维3.1 Rubric 是什么从打分到分维度定标Rubric 这个词在教学评价领域用得很久翻译成“评分准则表”或者“量规”都比较贴切。它本质上是一张表把你要评估的对象拆成几个关键维度每个维度设定明确的等级描述评标人或者模型再按照描述给分。把它搬到 Agent 评估里核心思想就是不要再问“这个回答是好还是坏”而要问“这个回答在准确性上几分在完整性上几分在格式规范性上几分在语气风格上几分”。从给一个笼统的分数变成对多个维度分别打分这就是评估体系的一次升维。为什么说是“升维”因为黄金指标和 Rubric 解决的是不同层级的问题。黄金指标是系统级的、汇总的、偏宏观健康的Rubric 是样本级的、分维度的、偏微观诊断的。黄金指标告诉你“系统健康度下降了”Rubric 告诉你“具体是哪个样本、在哪个维度、以什么形式出了问题”。没有 Rubric你对系统的理解就停留在黑盒层面有了 Rubric系统在你眼前就变成了半透明的。我在 AgentLoop 实践里有一个很明显的体会一旦开始用 Rubric 评估团队的讨论质量会立刻上一个台阶。以前评一个坏 case大家只会说“这个回答不对”“这个答案很烂”都是一堆模糊的形容词。有了 Rubric 之后讨论变成“这个回答的准确性可以给到 3 分但完整性只有 1 分因为用户问了三个条件它只覆盖了两个”这样的讨论才有产出才是数据飞轮真正需要的养分。3.2 为什么 Agent 评估比传统 ML 评估更需要 Rubric有人可能会问传统机器学习评估也有精确率、召回率、F1 这些指标为什么 Agent 就非得用 Rubric这个问题的答案在于Agent 的输出天然不具备“标准答案”的确定性。传统分类任务label 是明确的狗就是狗猫就是猫对错判定清晰。但 Agent 是生成式的一个用户问“帮我写一封给客户的道歉邮件”模型输出的答案根本不存在唯一的正确标准。你可以写三封风格完全不同的邮件每封都是好答案。这时候你拿什么当标准答案拿什么算对、算什么错Rubric 的价值正在于此它把“什么是好的”这个不可判定的问题转换成“哪些维度可以被观察、被描述、被评估”这个可判定的问题。另外Agent 的交互是链式的一个完整任务里有计划、有工具调用、有中间推理、有最终回复。这就意味着评估对象不只是“最终回答好与坏”还包括“工具调用是否选对”“中间步骤是否遗漏”“上下文利用是否充分”“指令遵循是否严格”。这一串评估诉求靠单一的匹配式判断完全无法覆盖只有分维度的 Rubric 才能承载这种复杂度。在 AgentLoop 上我们常把 Agent 输出展开成一条完整的轨迹trajectory然后对轨迹的每一个关键节点做 Rubric 打分。这不只是评估最终结果更是在评估过程质量。你会发现有些 case 最终结果是对的但过程走了弯路这样的 case 如果只看结果会被判对长期来看却是在积累坏数据。有了过程级 Rubric这类问题就藏不住了。3.3 Rubric 的设计原则维度拆分、权重、等级锚定Rubric 设计得好不好直接决定评估体系有没有用。这里我总结了几条设计原则都是实践中踩过坑换来的。第一维度要正交避免语义重叠。我曾经设计过一个 Rubric里面同时有“内容准确性”和“信息正确性”两个维度结果标注员集体崩溃这两个维度根本分不清。维度之间应该有清晰的边界每个维度描述一个独立的能力侧面比如准确性关心“有没有说错”完整性关心“有没有说全”结构化程度关心“组织是否清晰”。维度重叠会导致标注一致性暴跌你的评估数据就废了。第二等级描述要具体到可以被观察而不是抽象到只能靠感觉。差的等级描述是“回答质量较高”这种描述等于没说每个人对“较高”的理解都可能不同。好的等级描述应该是这样3 分表示“回答完整覆盖用户明确提出的所有约束条件且无事实性错误”1 分表示“回答遗漏了两个以上关键约束或存在至少一处事实性错误”。一旦等级描述落到可观察的行为上不同标注者之间的评分一致性会大幅提升。第三权重配置要服务于当前阶段的优化目标。早期阶段准确性权重应该拉满先保障不犯错中期阶段可以重点提升完整性和条理性到了打磨体验阶段再考虑语气、风格、交互感这些偏主观的维度。权重不是一成不变的每个迭代周期都应该重新审视一遍看看当前优化重心是不是还跟产品阶段匹配。第四Rubric 最好分层设计粗粒度的一层给机器自动评细粒度的一层给人评。机器受限于模型能力虽然快但精度有限适合做大批量的粗筛人力虽然慢但判断精准适合做小样本的深度分析。两层结合既保吞吐量又保质量。4. 在 AgentLoop 中落地 Rubric 评估的完整实操4.1 第一步定义评估对象与评估场景开始搭 Rubric 之前先想清楚你要评估什么。很多团队上来就搭一个“万能 Rubric”想一个模板套所有场景结果就是哪个场景都评不准。Agent 的每类技能、每个业务场景都应该有自己的 Rubric 变体。在 AgentLoop 中我们的做法是先给 Agent 的能力域做一张地图。比如一个客服 Agent能力域包括常见问题解答、订单查询、退换货处理、投诉安抚、多轮信息收集。每个能力域的输入模式、判定重点、常见失败模式都不一样。退换货处理看重规则遵循和流程完整性投诉安抚看重共情表达和风险控制多轮信息收集看重记忆保持和澄清能力。你不可能用同一套维度去公平评估这些差异巨大的任务。定义评估场景时还要明确两个边界用户是谁、输入是什么形态。用户是内部员工还是外部消费者输入是纯文本还是带附件单轮提问还是多轮对话这些差异都会影响 Rubric 的维度设计。我在 AgentLoop 上做第一个 Rubric 时就犯过错误拿内部员工问答场景的 Rubric 去评外部客户咨询 Agent结果很多维度完全不适用白白浪费了一轮标注预算。场景定义完之后我建议把每个场景的典型输入、期望输出、可能失败模式整理成一份说明文档挂在 Rubric 后面作为附录。这能帮助标注人员快速进入状态也方便后来接手的人理解为什么评估维度是这样设计的。4.2 第二步设计 Rubric 维度与等级标准场景定义清楚后进入 Rubric 的核心设计环节。这里我直接给一个我们在 AgentLoop 上实际制定过的 Rubric 雏形用来评估企业知识库问答类的 Agent你可以直接拿去做参考框架。这个 Rubric 分为五个维度每个维度四级评分从 1 分到 4 分下面列出关键维度和等级的浓缩版本维度权重4 分优秀2 分及格1 分不合格事实准确性35%所有陈述与权威来源完全一致无虚构信息存在少量非关键信息偏差但不影响核心答案存在关键事实错误或明显幻觉指令遵循25%完整覆盖用户所有明确约束和隐形意图遗漏非关键约束或对约束的理解略有偏差明显偏离用户核心指令回答完整性20%覆盖问题所有层面并主动补充相关必要信息覆盖主要层面遗漏次要细节遗漏核心层面答案明显不完整逻辑结构10%组织清晰结论在前论证层次分明结构可读但存在少量重复或跳跃结构混乱关键信息难以定位交互适配10%语气、详略、格式高度匹配用户身份和场景风格基本适配偶有不当表达语气、格式与场景明显不匹配这个表里每个等级之间其实还应该有更细的描述文字我这里为了篇幅做了精简。实际设计时每个维度、每个等级都要用至少一到两句话描述清楚最好配上正反案例。比如事实准确性的 2 分可以先描述为“核心答案正确但辅助信息中有一处表述不够精确”再附上一个具体例子标注者看了例子就懂。权重方面事实准确性和指令遵循占了 60%这和我们这个 Agent 当前阶段的目标一致先保证不犯错、不乱来。如果你的 Agent 还处于“答不全”的阶段完整性权重就应该往上调如果已经进入体验打磨期交互适配的权重可以适当提高。权重比例建议团队内多轮讨论后定别一个人拍脑袋。整个设计过程大概需要两三轮迭代第一版多半会暴露维度边界不清、等级描述模糊的问题。不要怕改Rubric 本身就是个活文档它应该随着你对问题理解的加深而持续演进。4.3 第三步采集样本与标注流程Rubric 设计完之后最耗时间的环节来了样本采集和标注。这里的核心矛盾是样本质量与数量之间的平衡。数量太少没有统计意义质量太差则直接污染评估结论。样本采集的源头主要有三个。第一个是线上真实日志这是最宝贵的样本来源因为它是真实用户在不同场景下产生的真实交互最能反映系统在野外的表现。第二个是人工构造的测试集适合覆盖线上暂未出现的边界情况比如极端长文本、刁钻提问方式、多条件组合查询。第三个是回归测试集从历史 bad case 里筛选出来的、曾经暴露出问题的样本用来防止模型迭代后旧问题复发。样本数量方面我的经验是每个评估场景、每个版本迭代人工标注的样本量至少要在 100 条以上低于这个量很难做出有效判断。如果条件允许200 到 400 条是最舒服的量级。AgentLoop 平台本身支持样本池管理和标注任务分配我们一般会把线上日志按场景分层采样确保每个能力域都有足够的样本覆盖而不是随机抽一批导致个别冷门场景完全没有数据。标注流程里我强烈建议引入双人标注加仲裁机制。每一条样本至少由两个标注者独立打分不一致的样本由更资深的同学仲裁。这不仅仅是质量控制更是一个发现 Rubric 设计缺陷的过程。如果两个标注者在某个维度上频繁不一致说明这个维度的描述一定有问题需要改写。我们实践中会把标注一致率用 Cohen‘s Kappa 计算作为标注体系健康度的指标低于 0.6 就必须停下来修 Rubric。标注人员的能力要求经常被低估。最好的标注者不是最懂模型的人而是最懂业务场景的人。我们的经验是让过去经常处理真实用户反馈的产品同学参与标注效果会明显好于只让算法同学标注。因为产品同学对“用户的真实期待是什么”更有体感他们分出来的 4 分和 1 分更有业务参考价值。4.4 第四步把 Rubric 接入数据飞轮闭环Rubric 设计好了、样本标注完了接下来就要让评估结果真正转起来这是整个数据飞轮实践里最关键的一步。如果 Rubric 评估只是为了出一份报告、贴在一个文档里再也不看那前面所有功夫都白费了。在 AgentLoop 上我们把 Rubric 评估做成了三个持续运转的闭环。第一是单版本内诊断闭环。模型新版本上线前先拿统一样本池跑一遍 Rubric 评分按维度、按场景、按技能分组对比基线版本找出哪些维度提升了、哪些维度回退了。这一步能在一两个小时内完成等于是给上线加了一道保险。第二是跨版本回归闭环。每个版本评过的样本、对应的分数都会沉淀到样本池里。下一版本评估时把新版本在历史样本上的表现拉出来对比任何一个维度的连续回退都能被及时捕捉。这个闭环做久了你对模型演进方向会建立起一种直觉知道改动哪些数据会产生哪些维度的波动这对后续数据构造有极强的指导意义。第三是线上持续监控闭环。线上真实流量按一定比例采样自动送进评估管道用已经校准过的模型版本来做粗粒度例行评分。分数低于阈值的样本会被挑出来送入人工复核队列成为下一轮迭代的新训练数据。这一步是飞轮真正“自我供能”的关键——坏的输出变成改进的依据改进后的模型减少坏输出同时在新的 bad case 上又开始新一轮积累。写到这里我想强调一个认知Rubric 不只是评估工具它是数据飞轮的“数据筛选器”。一个带着高质量评估标注的样本比一万条未经标注的原始日志更有训练价值。很多团队花大量成本收集数据却忽略了对数据做细粒度的评估标注这等于买了上等食材却不洗不切直接下锅最后能做出什么菜可想而知。5. 踩坑实录Rubric 落地时最常见的 6 个问题Rubric 这件事听着简单做起来坑非常多。我把我们在 AgentLoop 实践里遇到过的典型问题整理成一张速查表然后挑几个重点展开说说。问题现象根本原因排查方向解决方案标注一致率长期低于 0.6Rubric 维度描述过于抽象检查等级描述是否落到可观察行为重写等级描述附真实正反案例评估结果与线上表现对不上评估样本与线上分布偏差大检查采样方式是否随机分层采样确保各场景覆盖均衡Rubric 改了之后历史结果无法对比版本管理缺失检查 Rubric 是否有版本记录建立 Rubric 版本管理变更时保留旧版结果模型自动评分与人工评分偏差大自动评分模型校准不足检查自动评分模型是否存在系统偏差定期用人工标注结果校准自动评估模型权重长期不动导致优化偏科权重未随阶段目标调整检查权重与产品阶段是否匹配每迭代周期重新审视权重配置标注好的数据被闲置评估结果没有反哺迭代检查评估与训练链路是否打通建立数据回流通道把低分样本送入待优化队列第一个要重点说的是“评估结果与线上表现对不上”这个问题它最打击团队信心。我们曾经遇到过Rubric 评分明明是提升的结果线上投诉率反而涨了。后来一查问题出在采样环节——我们当时的测试样本大量来自较为简单的常见问题而线上新增的用户需求偏向复杂长尾场景。简单场景本来就做得好再评也是 4 分掩盖了复杂场景的严重退化。这个问题直接推动我们建立了场景分层采样机制而且每次评估都单独输出各场景子分数而不是只看一个“平均分”。第二个常见坑是“Rubric 版本管理混乱”。Rubric 一旦修改维度定义、等级描述都变了新旧版本打分结果没有可比性。有一次我们的评估报告被质疑数据异常结果发现是 Rubric 中途加了维度权重也调了但基线的分数没有重新计算前后数据根本不该放在一起比较。后面我们强制要求每次 Rubric 变更都记录版本更换评估标准时重新评估历史基线样本报表里也会标注评估版本号。第三个值得说的是 LLM 自动评分的校准问题。很多人图省事直接拿大模型当标注员把 Rubric 塞給 Prompt 里让它打分。速度确实快但盲信结果风险很大。模型评估器会有自己的偏好误差有的偏向打高分有的对长文本有系统性宽容。我的经验是自动评分一定要隔一段时间跟人工标注结果对标一次算一下相关性和分布偏移一旦发现偏差超过阈值就要重新校准提示词或者微调评估模型。把自动评估当成完全可信的信号源早晚会出事。这些问题如果你在落地过程中遇到了不要慌这些都是正常路径上的坑。关键是出了问题要有排查思路而不是推翻整套体系重来。Rubric 体系本身就是一个需要持续迭代打磨的工程制品越用越顺手越改越贴合业务。6. 从评估到改进飞轮转起来的最后一公里6.1 评估结果如何反哺数据和模型优化Rubric 评估本身不是目的改进才是。在 AgentLoop 的数据飞轮实践里我们把评估结果分成了三条“反哺路径”每一条都有明确的流向。第一条是样本筛选路径。Rubric 打出的低分样本尤其是维度特征清晰的样本是构造训练数据的最佳素材。比如一批“完整性不足”的低分样本通过改写和补全就能变成“完整性优秀”的正样本拿去微调模型。这比从零写数据高效得多因为真实 bad case 的多样性和难度是人工凭空构造很难模拟出来的。第二条是指令优化路径。很多 Agent 的行为问题根源不在模型能力而在系统提示词或指令模板设计不当。Rubric 在“指令遵循”维度上的持续低分往往说明指令的表达方式和模型的理解习惯存在错位。把低分样本按失败模式聚类你会发现一些规律比如“指令里同时给了三个约束时模型只执行了前两个”或者“否定式表述经常被忽略”。针对这些规律去重写指令效果立竿见影。第三条是评测基准扩充路径。人工复核中确认的高质量 bad case会有节奏地加入回归测试集成为长期防线的一部分。这个路径的重要性在于它让评测集有了生命力。很多团队的评测集是死的一年不更新模型的分数刷得毫无意义。让 Rubric 评估中发现的坏样本流入评测集你的“好模型”的定义才会跟着真实世界一起进化。这三条路径跑通之后评估就不再是一个“事后验尸”的环节而是变成驱动飞轮持续旋转的燃料泵。你会发现模型迭代的节奏变快了因为每次改动的方向都有数据支撑不再靠拍脑袋。6.2 人机协同在评估中的权重分配关于评估环节的人机分工我想单独说一说。很多团队面对大量标注需求时第一反应是“全自动”全部交给大模型来评。这个思路短期看没毛病但长期看会埋雷。反过来全部人力标注也不现实成本太高、速度太慢。真正稳妥的做法是分层协同。第一层是全量自动粗筛。用已经校准的模型评估器对所有待评估样本跑一遍 Rubric 打分把明显优秀和明显不合格的样本筛出去。这一层处理的样本占比大概在 70% 左右目标是快速分段。第二层是人工精细复评。剩下 30% 处于中间模糊地带的样本以及自动评分与历史分布明显不一致的样本进入人工复核队列由人工按完整的 Rubric 重新打分。第三层是专家仲裁。针对人工复核中分歧较大的样本由业务专家和技术负责人共同裁定同时反推 Rubric 是否有需要修正的地方。这个三层结构里最怕的是把人力浪费在那些一眼就能判死刑或一眼就完美的样本上。好的分层机制要让人的精力集中在机器判断不了的部分。我们实践中有一个直观的经验人机协同跑顺之后人工标注量只需要覆盖全量的 20%30%但标注质量和对迭代的指导价值会比纯人力或纯自动都高出一大截。我还有个体会是评估环节一定要保留一定比例的人工复核哪怕成本高也要留。因为标注人员在长期接触样本后会形成一种对“好回答”的直觉这种直觉在产品评审、需求讨论中非常有价值。全自动评估虽然省事但会让你跟真实的用户感受脱节这种脱节的代价往往要在更远的地方才能发现。6.3 从离线评估到在线评估的进阶路径当我们把离线 Rubric 评估体系跑稳之后自然就会往在线评估方向探索。离线评估解决的是“这个版本能不能上”的问题在线评估解决的则是“上了之后表现如何”的问题两者不可互相替代。AgentLoop 实践下来我们的在线评估体系分了三个层级。基础层是线上黄金指标监控7×24 小时实时刷新这是底线保障。中间层是抽样 Rubric 评分线上流量按场景、按策略标签做分层采样样本进入评估管道打分大约有一天的延迟用来捕捉黄金指标监控不到的细粒度问题。最高层是用户反馈聚合线上用户点赞、点踩、投诉、要求转人工这些信号跟 Rubric 评分做关联分析用来校准自动评分和发现新问题。离线评估和在线评估之间存在一种微妙的落差这个落差恰恰是优化空间。如果一个版本离线 Rubric 评分很高线上表现却平平说明你的测试样本覆盖有问题正在偏离真实分布如果一个版本离线有回退线上却有用户反馈变好那也要警惕可能是评估维度跟你真实用户在意的东西不在一个频道上。这两种情况都是值得深入分析的线索。这里我补充一个我们在实践中确认有效的做法把所有线上的坏反馈用户投诉、反复纠正、直接放弃都映射到 Rubric 维度上去做根因分析。比如用户反复纠正 Agent 的格式问题那你的“交互适配”维度权重可能定低了用户要求转人工通常是“事实准确性”或者“共情能力”出了严重问题。把用户的语言翻译成 Rubric 的语言你就有了一个从用户体验倒推系统优化的完整链条。至于更进阶的在线强化学习、基于评估反馈的自动数据筛选这些是后续版本的话题了。但现在把离线 Rubric 评估体系打好地基以后接入任何更高级的优化策略都会顺手很多。数据飞轮这个东西想一步到位是不可能的但每一步走扎实了后面的路会越走越宽。我个人在实际操作中体会最深的一点是做 Agent 评估真正难的不是技术而是你能不能跟团队在“什么是好回答”这件事上达成共识。Rubric 之所以价值巨大不只是因为它能打分更是因为它把模糊的“好”变成了可讨论、可对齐、可迭代的具体描述。这个共识一旦建立起来数据飞轮就有了最坚实的地基。每个维度、每个等级定义都是团队对产品质量认知的一次显式化表达这种表达本身就是你最重要的工程资产。