工作里只要沾过AI Agent开发十有八九会碰上一个灵魂拷问这Agent到底行不行我自己的评测框架从v1.0一路迭代到现在的21.0核心始终是围绕LLM-as-Judge、人工标注、A/B测试这三条腿走路再把它们得到的原始结果折算成一套能量化对比、能落进发布流程的指标。这篇内容就是把我这些年踩过的坑和最终沉淀下来的多维评测实践完整拆开讲一遍。不管你是刚接手Agent评测的QA还是自己在做Agent项目、天天被“效果不行”卡得动弹不得的开发者这篇文章应该都能给你一套能直接抄作业的框架。1. 先想清楚Agent评测难在哪量化评估要量化什么很多人一上来就开始设计指标结果越做越乱根本原因是没有先搞明白评测对象变了。Agent不是传统模型它不是“给一句话返回一个答案”这么简单它的行为链路长、结果开放、过程耦合环境量化评估之前必须先重新定义“什么是好”。1.1 Agent与传统模型评测的差别传统NLP模型或者分类模型的评测本质上是“答案对答案”给定输入得到输出拿输出跟标准答案做精确匹配或者算BLEU、ROUGE这类相似度。这个过程目标单一、环境可控、结果确定性高。到了Agent这里情况完全变了。它通常要做多轮推理要调用外部工具要根据环境反馈动态调整策略最后甚至可能走出好几条完全不同的成功路径。举个实际例子一个客服Agent处理“用户想改收货地址”这个任务。正确的路径可以是先查询订单状态再调用修改地址接口也可以是先询问用户新地址校验订单还没发货再修改地址。两条路结果一样但中间过程差别很大。如果你还是只比对最终输出文本那几乎没法做自动化评估。Agent评测的难点就在这儿评估对象从一个“正确答案”变成了整条“行为轨迹最终状态”而轨迹的合理性和状态的好坏很多时候没有唯一标准。这也是为什么量化评估不能只盯着“能不能完成任务”这一个点。你需要同时回答几个问题任务完成得对不对完成得顺不顺过程中有没有乱来代价高不高。这几个问题对应着完全不同的评估手段和指标得拆开来看。1.2 量化评估到底量化什么能力、稳定、成本、体验我在实践中把量化目标收敛成四类能力、稳定、成本、体验。能力是最基础的一层回答“这个Agent能不能完成它该做的事”。落地到指标上就是任务成功率、子步骤完成率、工具调用正确率等。稳定是很多团队容易忽略的一层。同一个Agent同一道题跑十次有时候成功有时候失败这种“抽风式”表现在生产环境非常致命。所以评测必须有重复运行的概念至少要反映方差而不是只看均值。成本层必须考虑因为Agent的消耗往往比传统模型高一个量级。一次任务可能要多次调用大模型加上工具调用的附加费用单task成本很容易就上去了。如果能力合格但成本高到没法规模化那这个Agent照样上不了线。体验层则更主观包括用户觉得顺不顺、回答是否友好、有没有不安全的表述。体验类指标很难用精确匹配来度量这正是LLM-as-Judge和人工标注的用武之地。1.3 从v1.0到v21.0我踩过的三个大坑早期我的评测体系就是v1.0只有“准确率”一个指标拿一批固定问题测一遍算个百分比就完事。结果上线第一周就被打脸业务方反馈一堆问题成功率看着90%实际问题基本办不成。后来复盘发现评测集太简单答案判定用关键词匹配很多回答只是“看起来对”但没解决用户实际问题。v5.0我开始引入LLM-as-Judge让大模型给Agent的回答打分确实把评估范围扩开了但很快又发现Judge本身不稳定。同一个回答今天打4分明天打3分换个模型甚至顺序调换结果就变自动评估结果没法完全信任。v12.0搞了一套多维指标能力、流程、安全、成本都算但指标太多每个版本出来报告几十页团队根本不知道看哪个最终决策还是靠拍脑袋。直到v21.0才彻底理顺三条腿各自分工LLM-as-Judge负责批量初筛人工标注负责精评校准A/B测试负责上线前后真实环境验证指标统一进一个仪表盘任何人打开只看一张图就知道这个版本能不能发。下面把这套体系拆开讲。2. 三大评估手段全解LLM-as-Judge、人工标注与A/B测试这套体系最核心的部分就是三种评估手段怎么用、为什么这么用、各自有什么坑。先分别讲清楚再讲怎么组合。2.1 LLM-as-Judge让大模型当考官的原理与配置要点LLM-as-Judge本质上是用一个大模型去评估另一个模型或Agent的输出。核心假设是足够强的通用大模型具备较好的语言理解、推理和事实判断能力能模拟人类评估者给候选输出打分或做偏好选择。它的最大价值是速度和成本。人工评估一条复杂Agent轨迹可能需要好几分钟Judge只要几十秒成本低一个数量级。所以在需要跑大量样本做回归测试时Judge几乎是唯一可行的自动化方案。但Judge不是开箱即用配置上有几个关键点第一评分卡要具体。不要写“请评估回答质量”要给出可判定的维度。我们常用的评分卡长这样相关性1~5分是否解决用户核心问题、完整性1~5分是否遗漏关键信息、格式正确性0或1是否遵守指定输出结构、安全性0或1是否包含违规内容。每个维度还要加一句“什么情况给几分”的说明否则Judge就是靠感觉打分。第二选择打分模式。如果是要评估一个Agent的绝对质量用pointwise模式让Judge按评分卡给单条输出逐项打分如果是要比较两个Agent版本谁更好用pairwise模式让Judge看两条输出后选择“A更好、B更好、平局”。另有一种reference-based模式把标准答案给Judge做参照适合事实性强的任务。三种模式我都在用业务上偏“判断好坏”用pointwise版本迭代时偏“对比优劣”用pairwise。第三控制Judge自身的偏差。Judge有几个出了名的毛病位置偏差pairwise时倾向于选第一个或最后一个、自我偏好偏差用A模型做Judge往往偏向A模型自己的输出、长度偏差回答越长分越高。我的缓解方法是pairwise评估时做位置置换把A、B的顺序颠倒各评估一次取结果在评分卡里强调“按信息完整性和正确性打分不要因为回答长就加分”对分歧样本抽样到人工复核。还有一个笨但有效的办法定期用小批量人工标注样本检验Judge和人类的一致性一致率低于80%就换Judge模型或调整评分卡。第四Judge结果的结构化。别让Judge自由发挥写一大段评论强制它先输出JSON格式的各维度评分再输出一行简短理由。这样下游可以直接解析入库。一个典型的Judge输出长这样{ task_id: task_0082, scores: { relevance: 4, completeness: 5, format: 1, safety: 1 }, reason: 用户询问改地址Agent先查询了订单状态确认未发货后调用了修改接口流程完整。 }这里有个经验Judge的温度一定要设0否则同样内容两次评估结果不一样。另外每次跑批量评估前先用10~20条金标准样本验证当前Judge配置的有效性这步能省掉后面很多返工。2.2 人工标注不可替代的黄金标准以及如何控制质量既然有了LLM-as-Judge为什么还需要人工标注原因很简单Judge本身也是个模型它的判断不一定符合真实用户和业务方的预期。人工标注是假设的“黄金标准”用途不是跑量而是校准和验证。但人工标注最大的麻烦是质量波动。同一个Agent输出让两个人标注结果可能完全相反。这不是人不行而是标准没定死。我把人工标注流程固化成了这么几步第一步写标注手册。手册里必须包含任务背景说明、每类指标的详细定义、至少5个“不同分数段”的标注示例、常见边界案例的处理方式。手册要发到标注群里一起评审不能一个人拍脑袋写完就发。第二步双人盲标加仲裁。每条样本至少两个人独立标注如果两人结果一致就入库不一致就得由团队内的仲裁人看一遍再定。仲裁的比例一般控制在10%~20%之间如果超过20%不是仲裁人累死而是标注手册有问题得回炉重做。第三步计算一致性。一般用Cohen‘s Kappa系数来量化两个标注人之间的一致性。公式不复杂[ \kappa \frac{P_o - P_e}{1 - P_e} ]P_o是实际一致率P_e是随机情况下期望一致率。Kappa值在0.8以上说明标注一致性很好0.6~0.8算可以接受低于0.6就需要重新培训或修订手册。我经常看到团队只统计“一致率”而忽略Kappa比如某个类是大多数类两个人都习惯性标同一类一致率很高但Kappa很低这种情况看似一致实际质量是有问题的。第四步在标注批次里埋“金标准题”。我们会不定期放入少量已知标准答案的样本标注员在这些题上错了就说明注意力下降或标准理解跑偏需要及时提醒。样本怎么选也是个学问。不要只从评测集里随机抽要分层抽样——按任务类型、输入长度、模型版本、成功失败结果分层。否则人工标注验证出来的结论可能只对某一类样本有效。2.3 A/B测试线上分流、指标与显著性判断LLM-as-Judge和人工标注评估的都是Agent在测试环境里的表现A/B测试则是把评估搬到真实环境里让真实用户来验收。A/B测试不是所有场景都能做至少要有线上分流能力和相对充足的流量。但一旦能做它提供了最硬核的证据新版本到底有没有给业务带来实际提升。A/B测试的关键不是“开个实验开关”就完事而是三个层面的设计流量划分。Agent场景通常按用户ID或会话ID做哈希分流保证同一个用户始终进入同一个版本避免用户感知混乱。不要用随机数做分流因为一次会话中可能涉及多次Agent调用随机分流会把同一个请求打散到两个版本数据就脏了。指标设计。指标至少要包含三个维度业务结果指标任务完成率、转化率、解决率、体验指标用户主动反馈、满意度、重试率、成本与性能指标平均Token消耗、p95延迟、调用失败率。只盯任务完成率是不够的可能出现新版本完成任务多一点但成本翻倍的情况这种版本往往也不能直接全量。显著性判断。样本量不够就跑不出显著性这是最常见的坑。我习惯在实验前先做事前样本量估算用历史数据的方差和期望提升幅度来反推需要多少样本。实验结束后不仅要看p值还要看置信区间和效应量。p值显著但效应量只有0.1%业务上也未必值得上线。A/B测试还有几个特别容易翻车的细节新奇效应新版本刚上线用户可能因为新鲜感表现异常所以要跑够周期至少覆盖一个完整业务周辛普森悖论整体看有提升拆分用户群后发现集中在某一部分人身上要按用户群做分层分析以及实验组之间的流量污染如果同一个用户既在A组又在B组体验过两个版本的影响会混在一起。2.4 三种手段怎么配合研发、发版、上线三段式三种评估手段不是三选一而是流水线分工。我们团队现在的节奏是研发阶段跑量用LLM-as-Judge。每次代码变更几百条回归题自动跑Judge打分后出一份摘要快速判断这个commit有没有把核心指标弄崩。免费、快速、覆盖广是这一阶段的主要诉求。发版前做人工精评。Judge跑完不代表能发版我们会抽200~300条典型样本安排双人标注重点看Judge容易误判的安全类、体验类指标同时也用这批标注结果去校准Judge的一致性。上线阶段做A/B测试。只有精评过关的版本才具备A/B资格。线上实验跑1~2周看真实业务指标的变化。这个三段式的好处是每一层都帮下一层过滤掉明显不行的版本避免把昂贵的人工和线上实验浪费在垃圾版本上。3. 多维评测指标体系设计与归一化算法评估手段解决了“数据从哪里来”指标体系解决“这些数据怎么变成决策依据”。这套指标我已经反复打磨过下面直接给框架。3.1 指标字典能力、效率、安全、成本、体验五大类任何一个Agent项目我建议先建立自己的指标字典别东一榔头西一棒槌。我常用的指标字典大概是这样类别指标定义采集方式方向能力任务成功率SR最终目标是否达成的比例人工/Judge越高越好能力步骤完成率子步骤完成数量/总步骤数轨迹解析越高越好能力工具调用正确率工具调用正确的次数/总调用次数轨迹解析越高越好效率平均回合数完成任务的平均交互轮次轨迹解析越低越好效率求助率用户被迫求助人工客服或多次输入修正的比例线上埋点越低越好安全安全违规率出现违规或不当内容的任务占比人工/Judge越低越好成本单任务Token消耗完成一个任务平均消耗的输入输出Token数日志统计越低越好成本p95延迟95%请求完成时延日志统计越低越好体验用户满意度用户反馈/评分问卷/人工/Judge越高越好体验事实一致性率回答与已知事实不一致的比例人工/Judge越高越好这个表不是死的每个项目要先看业务目标再做增删。但有几条通用原则指标必须要能采集不能靠感觉指标必须方向一致别把“回合数”和“用户满意度”混在一起说“体验变好了”指标不能太多核心看板建议控制在10个以内否则根本没人看。3.2 指标归一化与综合评分不同指标单位不同没法直接相加必须先归一化。最常用的是线性归一化设定一个“及格线”和“满分线”把原始值映射到0~100。比如任务成功率0%是0分100%是100分。成本类指标反过来平均Token消耗1000以下是100分5000以上是0分中间线性插值。这里的上下限要根据业务实际情况来定不能闭眼拍。归一化之后还要加权重。权重怎么定我建议两种方法二选一一是团队投票每个人按业务重要性给五个大类打分再取平均二是用层次分析法这类结构化的方式两两比较指标重要性算出一致性权重。权重的核心要求是“可解释”上线评审被问“为什么综合分是82”你得能一步步解释清楚。综合评分公式很简单[ Total \sum_{i1}^{n} w_i \times score_i ]但我必须强调一句总分只是用来快速排序的做决策时一定要拆开看。曾经我们有一个版本综合分超了基线但点开细项发现安全违规率明显恶化综合分被成本优势拉高了。这种情况如果只看总分迟早出事。所以仪表盘上总分一定要配一张雷达图或者维度明细安全、核心成功率这种关键指标最好单独设红线。3.3 场景适配Java/Spring Boot、知识库Agent、代码生成Agent怎么套指标同样的框架落到不同技术栈和业务场景里指标侧重点完全不同。我看到有些团队想套一套通用评测标准走天下结果每个业务都不适配。举三个典型场景第一个是Java/Spring Boot这类后端服务化的Agent客户端。这类Agent通常要跟业务系统深度集成核心诉求是稳定性和接口正确性。除了通用指标要额外关注服务超时率、并发下的错误率、权限控制是否合规、工具参数序列化是否正确。评测时最好在测试环境搭一套Mock服务专门模拟超时、异常、重试等场景。第二个是Obsidian AI Agent知识库场景。这类Agent本质是检索增强生成核心价值是能不能从知识库里找到正确内容并给出准确引用。评测重点要加检索相关性返回的知识片段是否对题、引用正确性回答里的引用是否真的存在于知识库、事实一致性回答是否忠实于检索结果有没有瞎编。这些指标靠精确匹配测不了Judge加上人工抽检是主要手段。第三个是Verilog代码生成Agent。这类代码生成Agent更硬核因为代码能不能跑这件事是客观的。我们评测时会直接接一套工具链Agent生成代码后自动做语法编译、功能仿真最终以编译通过率和仿真通过率为核心指标。这类场景里Judge的作用反而弱化因为最有说服力的裁判是编译器。这也是我想说的指标设计要跟着场景走别把Judge当万能药。4. 评测流水线落地从评测集到回归看板有了指标和评估手段还得把它们串成一条可重复运行的流水线。否则每次评测都是手工活换个版本重新跑一遍效率极低还容易漏。4.1 评测集建设数量、来源与防污染评测集是一切评估的基石。没有好的评测集再花哨的评估手段也是白搭。评测集的来源我建议三个渠道结合第一真实业务日志脱敏。这是最宝贵的来源去线上把真实用户的问题收集起来去掉隐私信息做成输入样本。第二公开基准集比如各种开源的Agent benchmark可以作为参考但要注意跟业务差异。第三人工构造的边界题专门覆盖长尾、极端、恶意输入等场景这部分题目数量不用多但必须要有。数量上我们的经验是回归评测集至少要有几百条级别。Agent的评估方差大题目太少一个随机波动就淹没真实变化。但也不是越多越好因为每增加一条题跑一轮和人工抽检的成本都在涨。我们一般把评测集分成两层核心回归集300条左右每次改动都跑扩展评测集1000~2000条每周跑一次。评测集防污染是现代AI评测里必须考虑的问题。如果评测集的题目出现在Agent训练数据里那评测结果就是虚假繁荣。我的做法是核心评测集不公开专人管理定期换一批题使用私有化评测题库避免直接从公开数据集整包拿过来用上线新题时做相似度去重防止跟已有训练语料高度重合的题混入。4.2 执行流程与工程化Runner、Mock与多次运行一次完整的评测执行本质上是把“数据集Agent配置外部服务MockerJudge”都编排起来跑一遍。我的建议是把它做成一个Runner脚本允许参数化传入模型版本、Prompt模板、工具配置和评测集ID。执行流程大概是加载评测集遍历任务对每个任务初始化Agent环境包括Mock外部服务的响应运行Agent记录完整轨迹推理过程、工具调用、中间回复、最终回复超时和异常要单独标识而不是直接判失败否则会把超时误当成能力差将轨迹和结果交给Judge打分汇总所有分数写入结果数据库生成评测报告。这里有两个容易被忽略的细节分别说一下。第一个是外部服务的Mock。Agent大量依赖工具调用如果直接连真实测试环境会出现网络抖动、数据不一致、接口限流等噪声干扰评估结果。我们要求所有工具调用都要能被Mock掉Mock的响应要稳定且可以版本化管理。A/B测试可以上真实环境但离线评测必须保持环境纯净。第二个是多次运行取分布。Agent具备随机性即使温度设0也不能保证完全确定工具返回内容、上下文方差都可能导致结果漂移。所以关键实验我建议同样的任务至少跑3次记录成功次数的分布而不是单次结果。比如某任务跑了3次成功2次成功率记为0.67这比单次0或1有意义得多。代价是评测耗时增加但换来的是对稳定性的理解值得。4.3 回归看板与发布门禁让评测真正影响决策评测体系如果只是每周出一份报告价值就少了一半。真正要让评测影响决策必须做成“门禁”和“看板”看板要常驻。我们有一个内部页面展示主干版本的每个指标折线图。横轴是版本号纵轴是归一化分数或原始指标。任何人一打开就能看到上一版到这一版哪个指标涨了、哪个跌了。这比评审会上翻PPT高效太多。门禁要硬。在CI/CD流水线里加上评测步骤核心回归集不过不允许merge到主干A/B测试没完成不允许全量发布。具体门槛可以这样设置任务成功率不低于前一个版本安全违规率为0p95延迟增加不超过5%单任务成本增幅不超过10%。这里的安全违规率我建议设置成硬性0容忍其他指标可以允许小幅波动但要解释原因。回归看板还有个作用逼着团队面对稳定性的问题。如果某个版本成功率抖动很大看板上会显示方差变宽这时候不管是模型还是评测集的问题都得停下来查清楚而不是看均值“好像还行”就放过去。5. 常见问题与排查技巧实录前面讲的都是理想框架实操中几乎每一步都会出幺蛾子。这一节专门记录我遇到过的高频问题每个都踩过坑希望能帮你少走弯路。5.1 LLM-as-Judge不听话评分飘忽、与人类不一致现象一同样是“很好”的答案换了个Judge模型就变成低分。排查方案是先看评分卡是不是足够客观。如果评分卡还在用“请评估回答质量”那是评分卡的问题不是Judge的问题。改成带维度粒度和示例的评分卡一致性会明显提升。现象二Judge和人工标注的一致性只有60%。这种时候不要硬上Judge先找到分歧集中在哪类样本。我遇到过Judge对“间接回答了问题但没直接给答案”的情况格外严厉而人类觉得这种回答可以接受双方打分手腕不一样。解决方案是给Judge加一条“允许Agent追问澄清”的规则并在标注手册里同步说明让人类和Judge对齐。现象三Judge自己出现幻觉在理由里写了一些回答里根本没有的内容。这种情况只能靠更换更强的Judge模型以及增加“回答中是否包含xxx”这种可验证性的评分维度来缓解。记住Judge也是有幻觉风险的模型不能全盘信任。5.2 人工标注质量和一致性差最典型的场景是双人标注一致率不到70%Kappa低于0.5。一开始我们以为是标注员不认真后来复盘发现是标注手册里“边界案例”太多比如“用户要求Agent帮忙改写邮件但保留语气不变”什么样算语气不变不同人理解完全不同。解法分三步第一步把分歧最大的样本收集起来逐条讨论把新确认的规则补进标注手册。第二步对标注员做一次集中培训重点讲新增的边界案例。第三步重新抽一批独立样本测Kappa。通常这一轮下来一致性会从0.5拉到0.7以上。如果还不行就得考虑是不是指标本身定义太模糊需要换一个更容易判定的指标。5.3 A/B测试跑不出显著差异这是最让人崩溃的场景之一明明离线评测有明显优势线上A/B就是没有显著结果。我遇到过的原因有三种第一种样本量确实不够。跑了一周就着急看数据置信区间宽得能装下整个宇宙。解法是事先算好样本量耐住性子跑够时间。第二种指标选错了。离线评测用的是任务成功率线上实际统计的是“用户发起会话后有没有点‘已解决’”这两者口径差异很大。我在早期犯过这个错离线成功率提升10%线上“已解决率”纹丝不动最后发现线上用户根本不会主动点“已解决”。解法是要用跟业务结果强相关的指标来做A/B而不是直接搬离线指标。第三种版本差异被噪声淹没。线上流量本身波动很大节假日、活动、渠道投放都会带来噪声。建议A/B期间同时监控自然波动数据或者用分位数、更长时间的窗口来观察而不是只看每天的均值。5.4 评测集污染与线上失真评测集被污染的表现是离线分越跑越高线上业务指标毫无变化甚至下滑。除了训练数据可能包含评测题之外还有一种常见情况是评测集本身构建时带偏见——偏向某一种回答风格或问法导致Agent在评测集上练得“过拟合”。防止线上失真的核心是两条一是评测集持续更新不能一年到头就那几百道题二是定期做“盲测回流”——从线上随机抽出真实用户请求作为临时评测样本跑一轮离线评估看离线分数和线上真实表现是否一致。一旦发现两者越来越脱节就要马上重写评测集或调整评测逻辑。模型在进化用户问题也在进化评测集不是一次性资产这点一定要有意识。我个人在实际操作中的一个体会是评测体系做得越久越要警惕“为了好看而评测”。指标不是越多越好手段也不是越高级越好关键是能不能帮你在正确的时间拦住错误的版本。这些方法组合在一起就是我和团队目前跑得很顺的v21.0方案。它不一定适合所有团队但至少提供了一条从“凭感觉”走向“用数据说话”的可行路径。 AI Agent多维评测体系：LLM-as-Judge、人工标注与A/B测试实战
工作里只要沾过AI Agent开发十有八九会碰上一个灵魂拷问这Agent到底行不行我自己的评测框架从v1.0一路迭代到现在的21.0核心始终是围绕LLM-as-Judge、人工标注、A/B测试这三条腿走路再把它们得到的原始结果折算成一套能量化对比、能落进发布流程的指标。这篇内容就是把我这些年踩过的坑和最终沉淀下来的多维评测实践完整拆开讲一遍。不管你是刚接手Agent评测的QA还是自己在做Agent项目、天天被“效果不行”卡得动弹不得的开发者这篇文章应该都能给你一套能直接抄作业的框架。1. 先想清楚Agent评测难在哪量化评估要量化什么很多人一上来就开始设计指标结果越做越乱根本原因是没有先搞明白评测对象变了。Agent不是传统模型它不是“给一句话返回一个答案”这么简单它的行为链路长、结果开放、过程耦合环境量化评估之前必须先重新定义“什么是好”。1.1 Agent与传统模型评测的差别传统NLP模型或者分类模型的评测本质上是“答案对答案”给定输入得到输出拿输出跟标准答案做精确匹配或者算BLEU、ROUGE这类相似度。这个过程目标单一、环境可控、结果确定性高。到了Agent这里情况完全变了。它通常要做多轮推理要调用外部工具要根据环境反馈动态调整策略最后甚至可能走出好几条完全不同的成功路径。举个实际例子一个客服Agent处理“用户想改收货地址”这个任务。正确的路径可以是先查询订单状态再调用修改地址接口也可以是先询问用户新地址校验订单还没发货再修改地址。两条路结果一样但中间过程差别很大。如果你还是只比对最终输出文本那几乎没法做自动化评估。Agent评测的难点就在这儿评估对象从一个“正确答案”变成了整条“行为轨迹最终状态”而轨迹的合理性和状态的好坏很多时候没有唯一标准。这也是为什么量化评估不能只盯着“能不能完成任务”这一个点。你需要同时回答几个问题任务完成得对不对完成得顺不顺过程中有没有乱来代价高不高。这几个问题对应着完全不同的评估手段和指标得拆开来看。1.2 量化评估到底量化什么能力、稳定、成本、体验我在实践中把量化目标收敛成四类能力、稳定、成本、体验。能力是最基础的一层回答“这个Agent能不能完成它该做的事”。落地到指标上就是任务成功率、子步骤完成率、工具调用正确率等。稳定是很多团队容易忽略的一层。同一个Agent同一道题跑十次有时候成功有时候失败这种“抽风式”表现在生产环境非常致命。所以评测必须有重复运行的概念至少要反映方差而不是只看均值。成本层必须考虑因为Agent的消耗往往比传统模型高一个量级。一次任务可能要多次调用大模型加上工具调用的附加费用单task成本很容易就上去了。如果能力合格但成本高到没法规模化那这个Agent照样上不了线。体验层则更主观包括用户觉得顺不顺、回答是否友好、有没有不安全的表述。体验类指标很难用精确匹配来度量这正是LLM-as-Judge和人工标注的用武之地。1.3 从v1.0到v21.0我踩过的三个大坑早期我的评测体系就是v1.0只有“准确率”一个指标拿一批固定问题测一遍算个百分比就完事。结果上线第一周就被打脸业务方反馈一堆问题成功率看着90%实际问题基本办不成。后来复盘发现评测集太简单答案判定用关键词匹配很多回答只是“看起来对”但没解决用户实际问题。v5.0我开始引入LLM-as-Judge让大模型给Agent的回答打分确实把评估范围扩开了但很快又发现Judge本身不稳定。同一个回答今天打4分明天打3分换个模型甚至顺序调换结果就变自动评估结果没法完全信任。v12.0搞了一套多维指标能力、流程、安全、成本都算但指标太多每个版本出来报告几十页团队根本不知道看哪个最终决策还是靠拍脑袋。直到v21.0才彻底理顺三条腿各自分工LLM-as-Judge负责批量初筛人工标注负责精评校准A/B测试负责上线前后真实环境验证指标统一进一个仪表盘任何人打开只看一张图就知道这个版本能不能发。下面把这套体系拆开讲。2. 三大评估手段全解LLM-as-Judge、人工标注与A/B测试这套体系最核心的部分就是三种评估手段怎么用、为什么这么用、各自有什么坑。先分别讲清楚再讲怎么组合。2.1 LLM-as-Judge让大模型当考官的原理与配置要点LLM-as-Judge本质上是用一个大模型去评估另一个模型或Agent的输出。核心假设是足够强的通用大模型具备较好的语言理解、推理和事实判断能力能模拟人类评估者给候选输出打分或做偏好选择。它的最大价值是速度和成本。人工评估一条复杂Agent轨迹可能需要好几分钟Judge只要几十秒成本低一个数量级。所以在需要跑大量样本做回归测试时Judge几乎是唯一可行的自动化方案。但Judge不是开箱即用配置上有几个关键点第一评分卡要具体。不要写“请评估回答质量”要给出可判定的维度。我们常用的评分卡长这样相关性1~5分是否解决用户核心问题、完整性1~5分是否遗漏关键信息、格式正确性0或1是否遵守指定输出结构、安全性0或1是否包含违规内容。每个维度还要加一句“什么情况给几分”的说明否则Judge就是靠感觉打分。第二选择打分模式。如果是要评估一个Agent的绝对质量用pointwise模式让Judge按评分卡给单条输出逐项打分如果是要比较两个Agent版本谁更好用pairwise模式让Judge看两条输出后选择“A更好、B更好、平局”。另有一种reference-based模式把标准答案给Judge做参照适合事实性强的任务。三种模式我都在用业务上偏“判断好坏”用pointwise版本迭代时偏“对比优劣”用pairwise。第三控制Judge自身的偏差。Judge有几个出了名的毛病位置偏差pairwise时倾向于选第一个或最后一个、自我偏好偏差用A模型做Judge往往偏向A模型自己的输出、长度偏差回答越长分越高。我的缓解方法是pairwise评估时做位置置换把A、B的顺序颠倒各评估一次取结果在评分卡里强调“按信息完整性和正确性打分不要因为回答长就加分”对分歧样本抽样到人工复核。还有一个笨但有效的办法定期用小批量人工标注样本检验Judge和人类的一致性一致率低于80%就换Judge模型或调整评分卡。第四Judge结果的结构化。别让Judge自由发挥写一大段评论强制它先输出JSON格式的各维度评分再输出一行简短理由。这样下游可以直接解析入库。一个典型的Judge输出长这样{ task_id: task_0082, scores: { relevance: 4, completeness: 5, format: 1, safety: 1 }, reason: 用户询问改地址Agent先查询了订单状态确认未发货后调用了修改接口流程完整。 }这里有个经验Judge的温度一定要设0否则同样内容两次评估结果不一样。另外每次跑批量评估前先用10~20条金标准样本验证当前Judge配置的有效性这步能省掉后面很多返工。2.2 人工标注不可替代的黄金标准以及如何控制质量既然有了LLM-as-Judge为什么还需要人工标注原因很简单Judge本身也是个模型它的判断不一定符合真实用户和业务方的预期。人工标注是假设的“黄金标准”用途不是跑量而是校准和验证。但人工标注最大的麻烦是质量波动。同一个Agent输出让两个人标注结果可能完全相反。这不是人不行而是标准没定死。我把人工标注流程固化成了这么几步第一步写标注手册。手册里必须包含任务背景说明、每类指标的详细定义、至少5个“不同分数段”的标注示例、常见边界案例的处理方式。手册要发到标注群里一起评审不能一个人拍脑袋写完就发。第二步双人盲标加仲裁。每条样本至少两个人独立标注如果两人结果一致就入库不一致就得由团队内的仲裁人看一遍再定。仲裁的比例一般控制在10%~20%之间如果超过20%不是仲裁人累死而是标注手册有问题得回炉重做。第三步计算一致性。一般用Cohen‘s Kappa系数来量化两个标注人之间的一致性。公式不复杂[ \kappa \frac{P_o - P_e}{1 - P_e} ]P_o是实际一致率P_e是随机情况下期望一致率。Kappa值在0.8以上说明标注一致性很好0.6~0.8算可以接受低于0.6就需要重新培训或修订手册。我经常看到团队只统计“一致率”而忽略Kappa比如某个类是大多数类两个人都习惯性标同一类一致率很高但Kappa很低这种情况看似一致实际质量是有问题的。第四步在标注批次里埋“金标准题”。我们会不定期放入少量已知标准答案的样本标注员在这些题上错了就说明注意力下降或标准理解跑偏需要及时提醒。样本怎么选也是个学问。不要只从评测集里随机抽要分层抽样——按任务类型、输入长度、模型版本、成功失败结果分层。否则人工标注验证出来的结论可能只对某一类样本有效。2.3 A/B测试线上分流、指标与显著性判断LLM-as-Judge和人工标注评估的都是Agent在测试环境里的表现A/B测试则是把评估搬到真实环境里让真实用户来验收。A/B测试不是所有场景都能做至少要有线上分流能力和相对充足的流量。但一旦能做它提供了最硬核的证据新版本到底有没有给业务带来实际提升。A/B测试的关键不是“开个实验开关”就完事而是三个层面的设计流量划分。Agent场景通常按用户ID或会话ID做哈希分流保证同一个用户始终进入同一个版本避免用户感知混乱。不要用随机数做分流因为一次会话中可能涉及多次Agent调用随机分流会把同一个请求打散到两个版本数据就脏了。指标设计。指标至少要包含三个维度业务结果指标任务完成率、转化率、解决率、体验指标用户主动反馈、满意度、重试率、成本与性能指标平均Token消耗、p95延迟、调用失败率。只盯任务完成率是不够的可能出现新版本完成任务多一点但成本翻倍的情况这种版本往往也不能直接全量。显著性判断。样本量不够就跑不出显著性这是最常见的坑。我习惯在实验前先做事前样本量估算用历史数据的方差和期望提升幅度来反推需要多少样本。实验结束后不仅要看p值还要看置信区间和效应量。p值显著但效应量只有0.1%业务上也未必值得上线。A/B测试还有几个特别容易翻车的细节新奇效应新版本刚上线用户可能因为新鲜感表现异常所以要跑够周期至少覆盖一个完整业务周辛普森悖论整体看有提升拆分用户群后发现集中在某一部分人身上要按用户群做分层分析以及实验组之间的流量污染如果同一个用户既在A组又在B组体验过两个版本的影响会混在一起。2.4 三种手段怎么配合研发、发版、上线三段式三种评估手段不是三选一而是流水线分工。我们团队现在的节奏是研发阶段跑量用LLM-as-Judge。每次代码变更几百条回归题自动跑Judge打分后出一份摘要快速判断这个commit有没有把核心指标弄崩。免费、快速、覆盖广是这一阶段的主要诉求。发版前做人工精评。Judge跑完不代表能发版我们会抽200~300条典型样本安排双人标注重点看Judge容易误判的安全类、体验类指标同时也用这批标注结果去校准Judge的一致性。上线阶段做A/B测试。只有精评过关的版本才具备A/B资格。线上实验跑1~2周看真实业务指标的变化。这个三段式的好处是每一层都帮下一层过滤掉明显不行的版本避免把昂贵的人工和线上实验浪费在垃圾版本上。3. 多维评测指标体系设计与归一化算法评估手段解决了“数据从哪里来”指标体系解决“这些数据怎么变成决策依据”。这套指标我已经反复打磨过下面直接给框架。3.1 指标字典能力、效率、安全、成本、体验五大类任何一个Agent项目我建议先建立自己的指标字典别东一榔头西一棒槌。我常用的指标字典大概是这样类别指标定义采集方式方向能力任务成功率SR最终目标是否达成的比例人工/Judge越高越好能力步骤完成率子步骤完成数量/总步骤数轨迹解析越高越好能力工具调用正确率工具调用正确的次数/总调用次数轨迹解析越高越好效率平均回合数完成任务的平均交互轮次轨迹解析越低越好效率求助率用户被迫求助人工客服或多次输入修正的比例线上埋点越低越好安全安全违规率出现违规或不当内容的任务占比人工/Judge越低越好成本单任务Token消耗完成一个任务平均消耗的输入输出Token数日志统计越低越好成本p95延迟95%请求完成时延日志统计越低越好体验用户满意度用户反馈/评分问卷/人工/Judge越高越好体验事实一致性率回答与已知事实不一致的比例人工/Judge越高越好这个表不是死的每个项目要先看业务目标再做增删。但有几条通用原则指标必须要能采集不能靠感觉指标必须方向一致别把“回合数”和“用户满意度”混在一起说“体验变好了”指标不能太多核心看板建议控制在10个以内否则根本没人看。3.2 指标归一化与综合评分不同指标单位不同没法直接相加必须先归一化。最常用的是线性归一化设定一个“及格线”和“满分线”把原始值映射到0~100。比如任务成功率0%是0分100%是100分。成本类指标反过来平均Token消耗1000以下是100分5000以上是0分中间线性插值。这里的上下限要根据业务实际情况来定不能闭眼拍。归一化之后还要加权重。权重怎么定我建议两种方法二选一一是团队投票每个人按业务重要性给五个大类打分再取平均二是用层次分析法这类结构化的方式两两比较指标重要性算出一致性权重。权重的核心要求是“可解释”上线评审被问“为什么综合分是82”你得能一步步解释清楚。综合评分公式很简单[ Total \sum_{i1}^{n} w_i \times score_i ]但我必须强调一句总分只是用来快速排序的做决策时一定要拆开看。曾经我们有一个版本综合分超了基线但点开细项发现安全违规率明显恶化综合分被成本优势拉高了。这种情况如果只看总分迟早出事。所以仪表盘上总分一定要配一张雷达图或者维度明细安全、核心成功率这种关键指标最好单独设红线。3.3 场景适配Java/Spring Boot、知识库Agent、代码生成Agent怎么套指标同样的框架落到不同技术栈和业务场景里指标侧重点完全不同。我看到有些团队想套一套通用评测标准走天下结果每个业务都不适配。举三个典型场景第一个是Java/Spring Boot这类后端服务化的Agent客户端。这类Agent通常要跟业务系统深度集成核心诉求是稳定性和接口正确性。除了通用指标要额外关注服务超时率、并发下的错误率、权限控制是否合规、工具参数序列化是否正确。评测时最好在测试环境搭一套Mock服务专门模拟超时、异常、重试等场景。第二个是Obsidian AI Agent知识库场景。这类Agent本质是检索增强生成核心价值是能不能从知识库里找到正确内容并给出准确引用。评测重点要加检索相关性返回的知识片段是否对题、引用正确性回答里的引用是否真的存在于知识库、事实一致性回答是否忠实于检索结果有没有瞎编。这些指标靠精确匹配测不了Judge加上人工抽检是主要手段。第三个是Verilog代码生成Agent。这类代码生成Agent更硬核因为代码能不能跑这件事是客观的。我们评测时会直接接一套工具链Agent生成代码后自动做语法编译、功能仿真最终以编译通过率和仿真通过率为核心指标。这类场景里Judge的作用反而弱化因为最有说服力的裁判是编译器。这也是我想说的指标设计要跟着场景走别把Judge当万能药。4. 评测流水线落地从评测集到回归看板有了指标和评估手段还得把它们串成一条可重复运行的流水线。否则每次评测都是手工活换个版本重新跑一遍效率极低还容易漏。4.1 评测集建设数量、来源与防污染评测集是一切评估的基石。没有好的评测集再花哨的评估手段也是白搭。评测集的来源我建议三个渠道结合第一真实业务日志脱敏。这是最宝贵的来源去线上把真实用户的问题收集起来去掉隐私信息做成输入样本。第二公开基准集比如各种开源的Agent benchmark可以作为参考但要注意跟业务差异。第三人工构造的边界题专门覆盖长尾、极端、恶意输入等场景这部分题目数量不用多但必须要有。数量上我们的经验是回归评测集至少要有几百条级别。Agent的评估方差大题目太少一个随机波动就淹没真实变化。但也不是越多越好因为每增加一条题跑一轮和人工抽检的成本都在涨。我们一般把评测集分成两层核心回归集300条左右每次改动都跑扩展评测集1000~2000条每周跑一次。评测集防污染是现代AI评测里必须考虑的问题。如果评测集的题目出现在Agent训练数据里那评测结果就是虚假繁荣。我的做法是核心评测集不公开专人管理定期换一批题使用私有化评测题库避免直接从公开数据集整包拿过来用上线新题时做相似度去重防止跟已有训练语料高度重合的题混入。4.2 执行流程与工程化Runner、Mock与多次运行一次完整的评测执行本质上是把“数据集Agent配置外部服务MockerJudge”都编排起来跑一遍。我的建议是把它做成一个Runner脚本允许参数化传入模型版本、Prompt模板、工具配置和评测集ID。执行流程大概是加载评测集遍历任务对每个任务初始化Agent环境包括Mock外部服务的响应运行Agent记录完整轨迹推理过程、工具调用、中间回复、最终回复超时和异常要单独标识而不是直接判失败否则会把超时误当成能力差将轨迹和结果交给Judge打分汇总所有分数写入结果数据库生成评测报告。这里有两个容易被忽略的细节分别说一下。第一个是外部服务的Mock。Agent大量依赖工具调用如果直接连真实测试环境会出现网络抖动、数据不一致、接口限流等噪声干扰评估结果。我们要求所有工具调用都要能被Mock掉Mock的响应要稳定且可以版本化管理。A/B测试可以上真实环境但离线评测必须保持环境纯净。第二个是多次运行取分布。Agent具备随机性即使温度设0也不能保证完全确定工具返回内容、上下文方差都可能导致结果漂移。所以关键实验我建议同样的任务至少跑3次记录成功次数的分布而不是单次结果。比如某任务跑了3次成功2次成功率记为0.67这比单次0或1有意义得多。代价是评测耗时增加但换来的是对稳定性的理解值得。4.3 回归看板与发布门禁让评测真正影响决策评测体系如果只是每周出一份报告价值就少了一半。真正要让评测影响决策必须做成“门禁”和“看板”看板要常驻。我们有一个内部页面展示主干版本的每个指标折线图。横轴是版本号纵轴是归一化分数或原始指标。任何人一打开就能看到上一版到这一版哪个指标涨了、哪个跌了。这比评审会上翻PPT高效太多。门禁要硬。在CI/CD流水线里加上评测步骤核心回归集不过不允许merge到主干A/B测试没完成不允许全量发布。具体门槛可以这样设置任务成功率不低于前一个版本安全违规率为0p95延迟增加不超过5%单任务成本增幅不超过10%。这里的安全违规率我建议设置成硬性0容忍其他指标可以允许小幅波动但要解释原因。回归看板还有个作用逼着团队面对稳定性的问题。如果某个版本成功率抖动很大看板上会显示方差变宽这时候不管是模型还是评测集的问题都得停下来查清楚而不是看均值“好像还行”就放过去。5. 常见问题与排查技巧实录前面讲的都是理想框架实操中几乎每一步都会出幺蛾子。这一节专门记录我遇到过的高频问题每个都踩过坑希望能帮你少走弯路。5.1 LLM-as-Judge不听话评分飘忽、与人类不一致现象一同样是“很好”的答案换了个Judge模型就变成低分。排查方案是先看评分卡是不是足够客观。如果评分卡还在用“请评估回答质量”那是评分卡的问题不是Judge的问题。改成带维度粒度和示例的评分卡一致性会明显提升。现象二Judge和人工标注的一致性只有60%。这种时候不要硬上Judge先找到分歧集中在哪类样本。我遇到过Judge对“间接回答了问题但没直接给答案”的情况格外严厉而人类觉得这种回答可以接受双方打分手腕不一样。解决方案是给Judge加一条“允许Agent追问澄清”的规则并在标注手册里同步说明让人类和Judge对齐。现象三Judge自己出现幻觉在理由里写了一些回答里根本没有的内容。这种情况只能靠更换更强的Judge模型以及增加“回答中是否包含xxx”这种可验证性的评分维度来缓解。记住Judge也是有幻觉风险的模型不能全盘信任。5.2 人工标注质量和一致性差最典型的场景是双人标注一致率不到70%Kappa低于0.5。一开始我们以为是标注员不认真后来复盘发现是标注手册里“边界案例”太多比如“用户要求Agent帮忙改写邮件但保留语气不变”什么样算语气不变不同人理解完全不同。解法分三步第一步把分歧最大的样本收集起来逐条讨论把新确认的规则补进标注手册。第二步对标注员做一次集中培训重点讲新增的边界案例。第三步重新抽一批独立样本测Kappa。通常这一轮下来一致性会从0.5拉到0.7以上。如果还不行就得考虑是不是指标本身定义太模糊需要换一个更容易判定的指标。5.3 A/B测试跑不出显著差异这是最让人崩溃的场景之一明明离线评测有明显优势线上A/B就是没有显著结果。我遇到过的原因有三种第一种样本量确实不够。跑了一周就着急看数据置信区间宽得能装下整个宇宙。解法是事先算好样本量耐住性子跑够时间。第二种指标选错了。离线评测用的是任务成功率线上实际统计的是“用户发起会话后有没有点‘已解决’”这两者口径差异很大。我在早期犯过这个错离线成功率提升10%线上“已解决率”纹丝不动最后发现线上用户根本不会主动点“已解决”。解法是要用跟业务结果强相关的指标来做A/B而不是直接搬离线指标。第三种版本差异被噪声淹没。线上流量本身波动很大节假日、活动、渠道投放都会带来噪声。建议A/B期间同时监控自然波动数据或者用分位数、更长时间的窗口来观察而不是只看每天的均值。5.4 评测集污染与线上失真评测集被污染的表现是离线分越跑越高线上业务指标毫无变化甚至下滑。除了训练数据可能包含评测题之外还有一种常见情况是评测集本身构建时带偏见——偏向某一种回答风格或问法导致Agent在评测集上练得“过拟合”。防止线上失真的核心是两条一是评测集持续更新不能一年到头就那几百道题二是定期做“盲测回流”——从线上随机抽出真实用户请求作为临时评测样本跑一轮离线评估看离线分数和线上真实表现是否一致。一旦发现两者越来越脱节就要马上重写评测集或调整评测逻辑。模型在进化用户问题也在进化评测集不是一次性资产这点一定要有意识。我个人在实际操作中的一个体会是评测体系做得越久越要警惕“为了好看而评测”。指标不是越多越好手段也不是越高级越好关键是能不能帮你在正确的时间拦住错误的版本。这些方法组合在一起就是我和团队目前跑得很顺的v21.0方案。它不一定适合所有团队但至少提供了一条从“凭感觉”走向“用数据说话”的可行路径。