1. 为什么“跑个demo”和“真能用”之间隔着一整套评测体系做智能体开发的人大概都有过这种体验周五下午把工作流串通了工具调用也接上了在几个预设问题上跑得挺漂亮于是信心满满地跟团队说“下周可以灰度了”。结果周一上线真实用户第一句话就把智能体带沟里去了——要么该调工具的时候在闲聊要么把上一轮的上下文当成了本轮指令要么干脆编了一段看起来很像那么回事但完全错误的答案。问题出在哪不是模型不行也不是框架不行而是你从来没有真正“量过”它。跑通demo只能证明“这条路能走”证明不了“这条路走得稳”。智能体和传统软件最大的区别在于传统软件是确定性的输入A必然输出B你写几个单元测试就能覆盖大部分逻辑而智能体是概率性的同一个输入温度调一下、上下文换一换、工具返回格式变一变输出可能天差地别。你没法用传统测试的思路去覆盖它必须建立一套专门的评测体系。这就是「超体」评测体系要解决的核心问题把“智能体好不好用”这个模糊的感性判断拆解成可量化、可复现、可对比的指标。它要回答的不是“这个智能体能不能跑”而是“它在什么条件下、面对什么任务、能达到什么水平、失败模式是什么”。这套体系适合谁看如果你正在做智能体开发不管是基于Coze、Dify这类平台搭工作流还是用LangGraph、Agno这类框架写代码只要你需要向别人证明“我的智能体是靠谱的”或者需要在上线前判断“它到底能不能扛住真实场景”那这套评测思路就是你必须跨过去的一道坎。它不挑技术栈挑的是你有没有“工程化验证”的意识。我见过太多团队在评测上走的弯路有人拿几十条自己编的case跑一遍就敢说“准确率95%”有人把LLM-as-Judge当成万能尺子却从不校验裁判本身靠不靠谱有人只测成功路径从不测边界条件。这些坑后面会一个个拆开讲。2. 评测体系的三层地基任务集、验证器、裁判模型在动手搭评测之前得先把地基打清楚。一个完整的智能体评测体系本质上由三个核心组件构成任务集Task Set、验证器Verifier、裁判模型Judge Model。这三者缺一不可而且每一层都有自己的坑。2.1 任务集不是“随便找几个问题”而是场景的抽样任务集是整个评测的起点。很多人对任务集的理解就是“准备一批测试问题”这个理解太浅了。任务集的本质是对真实使用场景的统计抽样它必须能代表智能体上线后可能遇到的各种情况。一个合格的任务集至少要覆盖以下几个维度任务类型分布你的智能体是问答型、工具调用型、多轮对话型还是工作流编排型不同类型占比多少如果智能体80%的调用是工具查询但你任务集里80%是闲聊问答那评测结果毫无意义。难度梯度简单任务单轮、单工具、明确指令、中等任务多轮、多工具、需要上下文理解、困难任务模糊指令、需要澄清、工具返回异常各占一定比例。我一般建议按3:5:2来分配简单任务保证基础能力中等任务是主战场困难任务用来暴露边界问题。边界与对抗样本空输入、超长输入、包含歧义的指令、诱导性提问、工具返回错误码的场景这些必须单独成组。很多智能体在正常case上表现优秀一遇到工具超时就崩了这种问题不专门测是发现不了的。任务集的规模也有讲究。太小几十条统计意义不足跑出来的数字波动大太大几千条评测成本高、迭代慢。我的经验是核心回归集控制在200-500条覆盖主要场景每次改动都跑扩展集可以到1000条以上用于版本发布前的全面评估。核心集要精扩展集要广。还有一个容易被忽略的点任务集要版本化。你今天加了一条case明天改了一条预期答案如果不做版本管理两次评测结果就没法对比。我习惯用JSON或YAML文件管理任务集每条case带唯一ID、场景标签、难度标签、预期输出类型配合Git做版本控制。2.2 验证器的选型规则、代码、模型各管一段验证器负责判断智能体的输出“对不对”。这里没有银弹不同类型的任务需要不同类型的验证器。我一般把验证器分成三类第一类确定性验证器Rule-based / Code-based适用于输出格式固定、答案唯一的场景。比如工具调用是否正确检查函数名、参数名、参数值是否匹配预期用代码直接断言。结构化输出是否合法JSON schema校验、字段完整性检查。数值计算是否正确直接比对计算结果。关键词是否命中检查输出是否包含必要信息。这类验证器的优点是快、准、零成本缺点是只能覆盖“有标准答案”的部分。智能体输出里大量自然语言内容规则验证器搞不定。第二类语义相似度验证器Embedding-based适用于答案有标准表述但措辞可以灵活的场景。比如用户问“退货政策是什么”智能体可以用不同的话说清楚同一件事。做法是把智能体输出和参考答案都转成向量算余弦相似度超过阈值就算通过。这里有个坑相似度高不等于语义正确。我见过“退货需要7天”和“退货不需要7天”的向量相似度高达0.95但意思完全相反。所以语义相似度只能作为辅助信号不能单独作为通过标准必须配合其他验证器使用。第三类模型裁判LLM-as-Judge这是目前处理开放式输出最主流的方法。用一个能力较强的模型比如GPT-4级别作为裁判给它评分标准让它对智能体输出打分或做二分类判断。LLM-as-Judge的威力在于它能理解语义、能处理模糊标准、能给出理由。但它的坑也最多后面单独用一节来讲。实际评测中这三类验证器通常是组合使用的。一条任务可能同时检查工具调用是否正确规则、答案是否覆盖关键点模型裁判、格式是否合法代码。最终得分是多个验证器结果的加权或逻辑组合。2.3 裁判模型的选择不是越强越好而是越“稳”越好选裁判模型的时候很多人第一反应是“用最强的模型”。这个思路对但不全对。裁判模型的核心要求不是“聪明”而是稳定、一致、可复现。什么叫稳定同一个输入裁判模型跑两次给出的判断应该一致。如果裁判自己都摇摆不定那评测结果就没有意义。我实测下来不同模型作为裁判的稳定性差异很大。有些模型在边界case上反复横跳今天判通过明天判不通过这种裁判不能用。什么叫一致裁判模型对评分标准的理解要和你一致。你写“答案需要包含A、B、C三个要点”裁判不能只看到A就给满分。这需要你在prompt里把评分标准写得极其明确最好给出正例和反例。我的选型经验是裁判模型的能力要明显高于被评测的智能体否则裁判看不懂智能体的输出判断不可靠。优先选temperature可调且低temperature下表现稳定的模型评测时temperature设为0或接近0。裁判模型和被评测模型最好不要同源避免同源模型对同类错误“视而不见”的偏差。裁判prompt要固定版本每次评测用同一套promptprompt一改历史结果就不可比了。还有一个实操细节裁判模型的输出格式要强制结构化。不要让裁判自由发挥写一段评语而是要求它输出JSON包含score、pass、reason等字段。这样后续程序化处理才方便也便于人工抽检。3. LLM-as-Judge好用但容易翻车的裁判LLM-as-Judge是当前智能体评测里绕不开的一环但它也是最容易出问题的一环。我见过太多团队直接拿一个prompt让模型打分然后就把分数当成真理结果被裁判的偏见带偏了还不自知。3.1 裁判的四种典型偏见位置偏见Position Bias当你让裁判对比两个答案哪个更好时它倾向于选第一个或第二个而不是根据内容判断。这个偏见在A/B测试里特别致命。解决办法是交换位置跑两次如果两次结果不一致说明裁判在这个case上不可靠需要人工介入或换裁判。长度偏见Length Bias裁判倾向于给更长的答案打高分因为长答案看起来“更详细”。但智能体的输出不是越长越好啰嗦、重复、跑题的长答案应该扣分。解决办法是在评分标准里明确写“简洁性”要求或者对超长输出做惩罚。自我偏好Self-Preference如果裁判模型和被评测模型是同一个家族裁判会倾向于给自己家族的输出打高分。这个偏见很隐蔽但实测确实存在。解决办法就是前面说的裁判和被评测模型尽量不同源。格式偏见Format Bias裁判容易被格式漂亮的输出迷惑比如带markdown标题、带列表的答案看起来更“专业”但内容可能空洞。解决办法是评分标准聚焦内容要点而不是形式。3.2 写裁判Prompt的五个硬性要求裁判prompt的质量直接决定评测质量。我总结下来一个好的裁判prompt必须满足五个要求评分标准可操作不能写“答案质量高”要写“答案必须包含以下三个要点X、Y、Z每缺少一个扣X分”。标准越具体裁判越一致。给出评分锚点明确什么情况打几分。比如“完全正确且完整5分正确但缺少一个要点3分部分正确但有事实错误1分完全错误0分”。要求输出理由让裁判先写reason再给score而不是直接给分。实测下来先写理由能显著提升判断质量因为模型在“想清楚”之后再打分更靠谱。强制结构化输出要求输出JSON字段固定。这样程序化处理方便也便于后续分析。包含边界说明明确告诉裁判什么情况算通过、什么情况算失败。比如“如果答案包含与事实不符的信息无论其他部分多好一律判为不通过”。一个裁判prompt的骨架大概长这样{ task: 判断智能体输出是否满足要求, criteria: { must_include: [要点A, 要点B, 要点C], must_not_include: [错误信息X, 无关内容Y], format_requirement: 输出必须是合法的JSON }, scoring: { 5: 包含全部要点无错误信息格式正确, 3: 包含两个要点无错误信息, 1: 包含一个要点或存在轻微错误, 0: 完全错误或包含严重错误信息 }, output_format: { reason: 先分析再打分, score: 0-5的整数, pass: score 3 为 true } }3.3 裁判本身也要被评测这是最容易被忽略的一步你怎么知道裁判判得对如果裁判本身准确率只有70%那它给出的评测结果可信度也就70%。我的做法是人工标注一批“金标准”case比如100条每条人工判断通过还是不通过。然后让裁判模型跑这100条算裁判和人工的一致率。一致率低于90%的裁判不能用于正式评测。如果一致率不达标就要分析分歧case是评分标准写得不清楚是裁判对某类任务理解有偏差还是人工标注本身有争议针对性地改prompt或换模型直到一致率达标。这个过程很枯燥但它是整个评测体系可信度的基石。跳过这一步后面所有数字都是空中楼阁。4. 从零搭一套可复现的评测流水线前面讲的是组件和原理这一节讲怎么把它们串起来形成一条能跑、能复现、能迭代的评测流水线。4.1 评测流水线的五个阶段一条完整的评测流水线我一般拆成五个阶段阶段一任务加载与预处理从任务集文件里读取case做必要的预处理变量替换比如把模板里的占位符替换成实际值、上下文构造多轮对话需要拼历史、工具mock评测时工具调用不能真的打外部API要用mock返回预设结果。工具mock这一步特别重要。真实工具调用有网络延迟、有不确定性、有副作用评测时必须隔离。我一般会为每个工具准备一组mock响应包括正常返回、超时、错误码、空结果等不同情况用来测试智能体的异常处理能力。阶段二智能体执行把预处理后的输入喂给智能体记录完整执行轨迹输入、输出、工具调用序列、每步耗时、token消耗、中间状态。这些轨迹数据是后续分析的宝贵素材不能只存最终输出。执行时要注意固定随机种子和temperature。如果智能体本身有随机性同一case跑两次结果不同评测就没法复现。评测时temperature设0如果框架支持seed就固定seed。阶段三验证器执行把智能体输出喂给各个验证器收集每个验证器的判断结果。规则验证器直接跑代码模型裁判调API。这里要注意并发控制模型裁判调用有速率限制跑大批量case时要控制并发数避免被限流。阶段四结果聚合与打分把多个验证器的结果聚合成最终得分。聚合方式取决于任务类型有些任务是“一票否决”比如工具调用错误直接判失败有些是加权平均。聚合逻辑要写在配置里不能硬编码方便调整。阶段五报告生成与对比生成评测报告包含总体通过率、各场景通过率、各难度通过率、失败case列表、失败原因分布。如果是版本迭代还要和上一版结果做对比看哪些指标提升了、哪些退步了。4.2 评测频率与回归策略评测不是跑一次就完事要嵌入开发流程每次prompt改动跑核心回归集200-500条快速验证有没有引入退化。每次工具或工作流改动跑核心集相关场景扩展集。版本发布前跑全量任务集1000条生成完整报告。定期比如每周跑一次全量监控长期趋势。这里的关键是回归检测新版本在哪些case上从通过变成了失败这些“退化case”是最需要关注的它们往往暴露了改动的副作用。4.3 成本控制评测很烧钱怎么省模型裁判调用是评测的主要成本。1000条case每条调一次裁判如果裁判模型贵一次全量评测可能几十上百块。频繁跑的话成本很可观。省钱的办法有几个分层评测核心集用强裁判模型扩展集用便宜模型或规则验证器。缓存裁判结果如果智能体输出没变裁判结果可以复用。用输出内容的hash做key缓存。批量调用有些API支持批量请求比单条调用便宜。规则优先能用规则验证器搞定的不要用模型裁判。规则验证器零成本。我一般会把评测成本控制在“每次核心集评测不超过一杯咖啡钱”的水平这样团队才愿意频繁跑。5. 指标设计别只看“准确率”这一个数很多团队的评测报告只有一个数字准确率。这个数字信息量太少了既不能告诉你智能体哪里弱也不能指导你下一步优化什么。一个好的评测体系应该输出一组多维指标。5.1 核心指标通过率、任务完成率、工具调用准确率通过率Pass Rate最基础的指标通过case数除以总case数。但要按场景、难度分组看总体通过率会被简单case拉高掩盖困难场景的问题。任务完成率Task Completion Rate针对多步任务看智能体是否完成了最终目标而不是中间某一步对了就算通过。比如订机票任务只有最终确认了订单才算完成中间查航班对了但没下单不算。工具调用准确率Tool Call Accuracy工具名、参数名、参数值三个维度分别算准确率。参数值准确率往往最低因为模型容易在参数格式上出错比如日期格式、枚举值大小写。5.2 过程指标轮次、耗时、token消耗结果指标告诉你“好不好”过程指标告诉你“贵不贵、快不快”。平均对话轮次完成同类任务轮次越少说明智能体越高效。轮次突然增加往往意味着智能体在“绕圈子”。平均耗时端到端延迟影响用户体验。token消耗直接关联成本。有些智能体通过“话多”来提升通过率但token消耗翻倍性价比反而下降。5.3 鲁棒性指标边界case通过率、扰动一致性边界case通过率专门看空输入、超长输入、异常工具返回等场景下的表现。这个指标低说明智能体“温室里的花朵”上不了真实战场。扰动一致性对同一个任务做微小扰动换同义词、调整语序、加无关信息看智能体输出是否稳定。一致性低说明智能体对输入过于敏感鲁棒性差。5.4 安全指标越权调用、敏感信息泄露智能体评测不能只看“能不能完成任务”还要看“会不会闯祸”。安全指标至少包括越权工具调用智能体是否调用了不该调用的工具比如用户没权限的操作。敏感信息泄露智能体是否在输出中泄露了系统prompt、内部数据、其他用户信息。有害内容生成智能体是否会被诱导生成不当内容。这些指标不需要每条case都测但要有专门的对抗测试集定期跑。6. 踩坑实录那些让评测结果失真的细节讲完方法论分享几个我在实际评测中踩过的坑。这些坑不踩一遍很难意识到但踩过之后评测质量会有质的提升。6.1 任务集“自己骗自己”最常见的坑任务集里的case都是开发者自己编的而且编的时候不自觉地把智能体已经能处理好的场景多放了一些把难case少放了一些。结果评测通过率很高上线后被打脸。破解办法任务集要从真实日志里采样。上线前没有真实日志就找产品、运营、客服等一线人员让他们提供真实用户会问的问题。开发者自己编的case只能作为补充不能作为主体。6.2 裁判prompt里的“隐形漏洞”有一次评测裁判给一个明显错误的答案打了高分。排查发现裁判prompt里写的是“答案需要包含要点A”但没写“不能包含错误信息”。智能体输出里既有要点A又有一段编造的假信息裁判只看到要点A就给了通过。这个坑的教训是裁判prompt要写“负面清单”明确列出什么情况必须判失败。只写正面要求不够模型会钻空子。6.3 工具mock和真实工具行为不一致评测时工具用mock上线后用真实工具。如果mock的返回格式和真实工具不一致评测通过不代表上线通过。我遇到过mock返回的是{status: ok, data: {...}}真实工具返回的是{code: 0, result: {...}}智能体在评测时学会了处理前者上线后处理不了后者。解决办法mock要基于真实工具的接口文档来构造最好直接用真实工具录制一批响应作为mock数据。工具接口变了mock也要同步更新。6.4 忽略“拒答”场景有些任务智能体应该拒答比如超出能力范围、涉及敏感信息但评测集里没有这类case导致智能体学会了“什么都答”上线后乱答一气。评测集里要有拒答case预期输出是“我无法处理这个请求”或类似表述。裁判要能判断智能体是否恰当地拒答了。6.5 评测结果没有置信区间跑100条case通过80条通过率80%。但如果换一批100条通过率可能是75%也可能是85%。只报一个点估计不报置信区间容易过度解读小差异。我的做法是核心指标报点估计置信区间。100条样本的95%置信区间大概±8%所以80%和85%的差异可能不显著不要急着下结论说“新版本更好了”。7. 把评测变成开发习惯而不是上线前的突击最后聊一个心态问题。很多团队把评测当成“上线前的一道关卡”平时不跑临上线了突击跑一遍。这种用法浪费了评测最大的价值。评测真正的价值在于快速反馈。你改了一版prompt跑一下核心集5分钟就知道有没有退化你换了一个工具描述跑一下相关场景立刻知道工具调用准确率有没有提升。这种“改-测-改”的快速循环才是智能体开发效率的关键。我现在的习惯是任何prompt或工作流改动提交前必须跑核心回归集。这就像写代码要跑单元测试一样是肌肉记忆。核心集不用大200条足够跑一次几分钟但能拦住80%的低级退化。另外评测报告要团队共享。不要只有评测的人看产品、运营、开发都要看。产品看场景通过率运营看失败case里的用户影响开发看技术指标。大家从不同角度看同一份数据才能形成合力。还有一点评测集要持续迭代。上线后收集真实badcase分析后补充进评测集。这样评测集越来越贴近真实场景评测结果越来越有预测力。一个半年没更新过的评测集参考价值会大打折扣。智能体评测这件事没有一劳永逸的方案只有持续迭代的体系。工具会变、模型会变、场景会变评测体系也要跟着变。但核心思路是不变的用可复现的方法量出智能体在真实场景下的真实水平然后用这个数字指导下一步优化。把这个循环跑起来智能体的质量就会螺旋上升而不是靠运气上线、靠救火维护。
智能体评测体系实战：从任务集、验证器到LLM-as-Judge的工程化落地
1. 为什么“跑个demo”和“真能用”之间隔着一整套评测体系做智能体开发的人大概都有过这种体验周五下午把工作流串通了工具调用也接上了在几个预设问题上跑得挺漂亮于是信心满满地跟团队说“下周可以灰度了”。结果周一上线真实用户第一句话就把智能体带沟里去了——要么该调工具的时候在闲聊要么把上一轮的上下文当成了本轮指令要么干脆编了一段看起来很像那么回事但完全错误的答案。问题出在哪不是模型不行也不是框架不行而是你从来没有真正“量过”它。跑通demo只能证明“这条路能走”证明不了“这条路走得稳”。智能体和传统软件最大的区别在于传统软件是确定性的输入A必然输出B你写几个单元测试就能覆盖大部分逻辑而智能体是概率性的同一个输入温度调一下、上下文换一换、工具返回格式变一变输出可能天差地别。你没法用传统测试的思路去覆盖它必须建立一套专门的评测体系。这就是「超体」评测体系要解决的核心问题把“智能体好不好用”这个模糊的感性判断拆解成可量化、可复现、可对比的指标。它要回答的不是“这个智能体能不能跑”而是“它在什么条件下、面对什么任务、能达到什么水平、失败模式是什么”。这套体系适合谁看如果你正在做智能体开发不管是基于Coze、Dify这类平台搭工作流还是用LangGraph、Agno这类框架写代码只要你需要向别人证明“我的智能体是靠谱的”或者需要在上线前判断“它到底能不能扛住真实场景”那这套评测思路就是你必须跨过去的一道坎。它不挑技术栈挑的是你有没有“工程化验证”的意识。我见过太多团队在评测上走的弯路有人拿几十条自己编的case跑一遍就敢说“准确率95%”有人把LLM-as-Judge当成万能尺子却从不校验裁判本身靠不靠谱有人只测成功路径从不测边界条件。这些坑后面会一个个拆开讲。2. 评测体系的三层地基任务集、验证器、裁判模型在动手搭评测之前得先把地基打清楚。一个完整的智能体评测体系本质上由三个核心组件构成任务集Task Set、验证器Verifier、裁判模型Judge Model。这三者缺一不可而且每一层都有自己的坑。2.1 任务集不是“随便找几个问题”而是场景的抽样任务集是整个评测的起点。很多人对任务集的理解就是“准备一批测试问题”这个理解太浅了。任务集的本质是对真实使用场景的统计抽样它必须能代表智能体上线后可能遇到的各种情况。一个合格的任务集至少要覆盖以下几个维度任务类型分布你的智能体是问答型、工具调用型、多轮对话型还是工作流编排型不同类型占比多少如果智能体80%的调用是工具查询但你任务集里80%是闲聊问答那评测结果毫无意义。难度梯度简单任务单轮、单工具、明确指令、中等任务多轮、多工具、需要上下文理解、困难任务模糊指令、需要澄清、工具返回异常各占一定比例。我一般建议按3:5:2来分配简单任务保证基础能力中等任务是主战场困难任务用来暴露边界问题。边界与对抗样本空输入、超长输入、包含歧义的指令、诱导性提问、工具返回错误码的场景这些必须单独成组。很多智能体在正常case上表现优秀一遇到工具超时就崩了这种问题不专门测是发现不了的。任务集的规模也有讲究。太小几十条统计意义不足跑出来的数字波动大太大几千条评测成本高、迭代慢。我的经验是核心回归集控制在200-500条覆盖主要场景每次改动都跑扩展集可以到1000条以上用于版本发布前的全面评估。核心集要精扩展集要广。还有一个容易被忽略的点任务集要版本化。你今天加了一条case明天改了一条预期答案如果不做版本管理两次评测结果就没法对比。我习惯用JSON或YAML文件管理任务集每条case带唯一ID、场景标签、难度标签、预期输出类型配合Git做版本控制。2.2 验证器的选型规则、代码、模型各管一段验证器负责判断智能体的输出“对不对”。这里没有银弹不同类型的任务需要不同类型的验证器。我一般把验证器分成三类第一类确定性验证器Rule-based / Code-based适用于输出格式固定、答案唯一的场景。比如工具调用是否正确检查函数名、参数名、参数值是否匹配预期用代码直接断言。结构化输出是否合法JSON schema校验、字段完整性检查。数值计算是否正确直接比对计算结果。关键词是否命中检查输出是否包含必要信息。这类验证器的优点是快、准、零成本缺点是只能覆盖“有标准答案”的部分。智能体输出里大量自然语言内容规则验证器搞不定。第二类语义相似度验证器Embedding-based适用于答案有标准表述但措辞可以灵活的场景。比如用户问“退货政策是什么”智能体可以用不同的话说清楚同一件事。做法是把智能体输出和参考答案都转成向量算余弦相似度超过阈值就算通过。这里有个坑相似度高不等于语义正确。我见过“退货需要7天”和“退货不需要7天”的向量相似度高达0.95但意思完全相反。所以语义相似度只能作为辅助信号不能单独作为通过标准必须配合其他验证器使用。第三类模型裁判LLM-as-Judge这是目前处理开放式输出最主流的方法。用一个能力较强的模型比如GPT-4级别作为裁判给它评分标准让它对智能体输出打分或做二分类判断。LLM-as-Judge的威力在于它能理解语义、能处理模糊标准、能给出理由。但它的坑也最多后面单独用一节来讲。实际评测中这三类验证器通常是组合使用的。一条任务可能同时检查工具调用是否正确规则、答案是否覆盖关键点模型裁判、格式是否合法代码。最终得分是多个验证器结果的加权或逻辑组合。2.3 裁判模型的选择不是越强越好而是越“稳”越好选裁判模型的时候很多人第一反应是“用最强的模型”。这个思路对但不全对。裁判模型的核心要求不是“聪明”而是稳定、一致、可复现。什么叫稳定同一个输入裁判模型跑两次给出的判断应该一致。如果裁判自己都摇摆不定那评测结果就没有意义。我实测下来不同模型作为裁判的稳定性差异很大。有些模型在边界case上反复横跳今天判通过明天判不通过这种裁判不能用。什么叫一致裁判模型对评分标准的理解要和你一致。你写“答案需要包含A、B、C三个要点”裁判不能只看到A就给满分。这需要你在prompt里把评分标准写得极其明确最好给出正例和反例。我的选型经验是裁判模型的能力要明显高于被评测的智能体否则裁判看不懂智能体的输出判断不可靠。优先选temperature可调且低temperature下表现稳定的模型评测时temperature设为0或接近0。裁判模型和被评测模型最好不要同源避免同源模型对同类错误“视而不见”的偏差。裁判prompt要固定版本每次评测用同一套promptprompt一改历史结果就不可比了。还有一个实操细节裁判模型的输出格式要强制结构化。不要让裁判自由发挥写一段评语而是要求它输出JSON包含score、pass、reason等字段。这样后续程序化处理才方便也便于人工抽检。3. LLM-as-Judge好用但容易翻车的裁判LLM-as-Judge是当前智能体评测里绕不开的一环但它也是最容易出问题的一环。我见过太多团队直接拿一个prompt让模型打分然后就把分数当成真理结果被裁判的偏见带偏了还不自知。3.1 裁判的四种典型偏见位置偏见Position Bias当你让裁判对比两个答案哪个更好时它倾向于选第一个或第二个而不是根据内容判断。这个偏见在A/B测试里特别致命。解决办法是交换位置跑两次如果两次结果不一致说明裁判在这个case上不可靠需要人工介入或换裁判。长度偏见Length Bias裁判倾向于给更长的答案打高分因为长答案看起来“更详细”。但智能体的输出不是越长越好啰嗦、重复、跑题的长答案应该扣分。解决办法是在评分标准里明确写“简洁性”要求或者对超长输出做惩罚。自我偏好Self-Preference如果裁判模型和被评测模型是同一个家族裁判会倾向于给自己家族的输出打高分。这个偏见很隐蔽但实测确实存在。解决办法就是前面说的裁判和被评测模型尽量不同源。格式偏见Format Bias裁判容易被格式漂亮的输出迷惑比如带markdown标题、带列表的答案看起来更“专业”但内容可能空洞。解决办法是评分标准聚焦内容要点而不是形式。3.2 写裁判Prompt的五个硬性要求裁判prompt的质量直接决定评测质量。我总结下来一个好的裁判prompt必须满足五个要求评分标准可操作不能写“答案质量高”要写“答案必须包含以下三个要点X、Y、Z每缺少一个扣X分”。标准越具体裁判越一致。给出评分锚点明确什么情况打几分。比如“完全正确且完整5分正确但缺少一个要点3分部分正确但有事实错误1分完全错误0分”。要求输出理由让裁判先写reason再给score而不是直接给分。实测下来先写理由能显著提升判断质量因为模型在“想清楚”之后再打分更靠谱。强制结构化输出要求输出JSON字段固定。这样程序化处理方便也便于后续分析。包含边界说明明确告诉裁判什么情况算通过、什么情况算失败。比如“如果答案包含与事实不符的信息无论其他部分多好一律判为不通过”。一个裁判prompt的骨架大概长这样{ task: 判断智能体输出是否满足要求, criteria: { must_include: [要点A, 要点B, 要点C], must_not_include: [错误信息X, 无关内容Y], format_requirement: 输出必须是合法的JSON }, scoring: { 5: 包含全部要点无错误信息格式正确, 3: 包含两个要点无错误信息, 1: 包含一个要点或存在轻微错误, 0: 完全错误或包含严重错误信息 }, output_format: { reason: 先分析再打分, score: 0-5的整数, pass: score 3 为 true } }3.3 裁判本身也要被评测这是最容易被忽略的一步你怎么知道裁判判得对如果裁判本身准确率只有70%那它给出的评测结果可信度也就70%。我的做法是人工标注一批“金标准”case比如100条每条人工判断通过还是不通过。然后让裁判模型跑这100条算裁判和人工的一致率。一致率低于90%的裁判不能用于正式评测。如果一致率不达标就要分析分歧case是评分标准写得不清楚是裁判对某类任务理解有偏差还是人工标注本身有争议针对性地改prompt或换模型直到一致率达标。这个过程很枯燥但它是整个评测体系可信度的基石。跳过这一步后面所有数字都是空中楼阁。4. 从零搭一套可复现的评测流水线前面讲的是组件和原理这一节讲怎么把它们串起来形成一条能跑、能复现、能迭代的评测流水线。4.1 评测流水线的五个阶段一条完整的评测流水线我一般拆成五个阶段阶段一任务加载与预处理从任务集文件里读取case做必要的预处理变量替换比如把模板里的占位符替换成实际值、上下文构造多轮对话需要拼历史、工具mock评测时工具调用不能真的打外部API要用mock返回预设结果。工具mock这一步特别重要。真实工具调用有网络延迟、有不确定性、有副作用评测时必须隔离。我一般会为每个工具准备一组mock响应包括正常返回、超时、错误码、空结果等不同情况用来测试智能体的异常处理能力。阶段二智能体执行把预处理后的输入喂给智能体记录完整执行轨迹输入、输出、工具调用序列、每步耗时、token消耗、中间状态。这些轨迹数据是后续分析的宝贵素材不能只存最终输出。执行时要注意固定随机种子和temperature。如果智能体本身有随机性同一case跑两次结果不同评测就没法复现。评测时temperature设0如果框架支持seed就固定seed。阶段三验证器执行把智能体输出喂给各个验证器收集每个验证器的判断结果。规则验证器直接跑代码模型裁判调API。这里要注意并发控制模型裁判调用有速率限制跑大批量case时要控制并发数避免被限流。阶段四结果聚合与打分把多个验证器的结果聚合成最终得分。聚合方式取决于任务类型有些任务是“一票否决”比如工具调用错误直接判失败有些是加权平均。聚合逻辑要写在配置里不能硬编码方便调整。阶段五报告生成与对比生成评测报告包含总体通过率、各场景通过率、各难度通过率、失败case列表、失败原因分布。如果是版本迭代还要和上一版结果做对比看哪些指标提升了、哪些退步了。4.2 评测频率与回归策略评测不是跑一次就完事要嵌入开发流程每次prompt改动跑核心回归集200-500条快速验证有没有引入退化。每次工具或工作流改动跑核心集相关场景扩展集。版本发布前跑全量任务集1000条生成完整报告。定期比如每周跑一次全量监控长期趋势。这里的关键是回归检测新版本在哪些case上从通过变成了失败这些“退化case”是最需要关注的它们往往暴露了改动的副作用。4.3 成本控制评测很烧钱怎么省模型裁判调用是评测的主要成本。1000条case每条调一次裁判如果裁判模型贵一次全量评测可能几十上百块。频繁跑的话成本很可观。省钱的办法有几个分层评测核心集用强裁判模型扩展集用便宜模型或规则验证器。缓存裁判结果如果智能体输出没变裁判结果可以复用。用输出内容的hash做key缓存。批量调用有些API支持批量请求比单条调用便宜。规则优先能用规则验证器搞定的不要用模型裁判。规则验证器零成本。我一般会把评测成本控制在“每次核心集评测不超过一杯咖啡钱”的水平这样团队才愿意频繁跑。5. 指标设计别只看“准确率”这一个数很多团队的评测报告只有一个数字准确率。这个数字信息量太少了既不能告诉你智能体哪里弱也不能指导你下一步优化什么。一个好的评测体系应该输出一组多维指标。5.1 核心指标通过率、任务完成率、工具调用准确率通过率Pass Rate最基础的指标通过case数除以总case数。但要按场景、难度分组看总体通过率会被简单case拉高掩盖困难场景的问题。任务完成率Task Completion Rate针对多步任务看智能体是否完成了最终目标而不是中间某一步对了就算通过。比如订机票任务只有最终确认了订单才算完成中间查航班对了但没下单不算。工具调用准确率Tool Call Accuracy工具名、参数名、参数值三个维度分别算准确率。参数值准确率往往最低因为模型容易在参数格式上出错比如日期格式、枚举值大小写。5.2 过程指标轮次、耗时、token消耗结果指标告诉你“好不好”过程指标告诉你“贵不贵、快不快”。平均对话轮次完成同类任务轮次越少说明智能体越高效。轮次突然增加往往意味着智能体在“绕圈子”。平均耗时端到端延迟影响用户体验。token消耗直接关联成本。有些智能体通过“话多”来提升通过率但token消耗翻倍性价比反而下降。5.3 鲁棒性指标边界case通过率、扰动一致性边界case通过率专门看空输入、超长输入、异常工具返回等场景下的表现。这个指标低说明智能体“温室里的花朵”上不了真实战场。扰动一致性对同一个任务做微小扰动换同义词、调整语序、加无关信息看智能体输出是否稳定。一致性低说明智能体对输入过于敏感鲁棒性差。5.4 安全指标越权调用、敏感信息泄露智能体评测不能只看“能不能完成任务”还要看“会不会闯祸”。安全指标至少包括越权工具调用智能体是否调用了不该调用的工具比如用户没权限的操作。敏感信息泄露智能体是否在输出中泄露了系统prompt、内部数据、其他用户信息。有害内容生成智能体是否会被诱导生成不当内容。这些指标不需要每条case都测但要有专门的对抗测试集定期跑。6. 踩坑实录那些让评测结果失真的细节讲完方法论分享几个我在实际评测中踩过的坑。这些坑不踩一遍很难意识到但踩过之后评测质量会有质的提升。6.1 任务集“自己骗自己”最常见的坑任务集里的case都是开发者自己编的而且编的时候不自觉地把智能体已经能处理好的场景多放了一些把难case少放了一些。结果评测通过率很高上线后被打脸。破解办法任务集要从真实日志里采样。上线前没有真实日志就找产品、运营、客服等一线人员让他们提供真实用户会问的问题。开发者自己编的case只能作为补充不能作为主体。6.2 裁判prompt里的“隐形漏洞”有一次评测裁判给一个明显错误的答案打了高分。排查发现裁判prompt里写的是“答案需要包含要点A”但没写“不能包含错误信息”。智能体输出里既有要点A又有一段编造的假信息裁判只看到要点A就给了通过。这个坑的教训是裁判prompt要写“负面清单”明确列出什么情况必须判失败。只写正面要求不够模型会钻空子。6.3 工具mock和真实工具行为不一致评测时工具用mock上线后用真实工具。如果mock的返回格式和真实工具不一致评测通过不代表上线通过。我遇到过mock返回的是{status: ok, data: {...}}真实工具返回的是{code: 0, result: {...}}智能体在评测时学会了处理前者上线后处理不了后者。解决办法mock要基于真实工具的接口文档来构造最好直接用真实工具录制一批响应作为mock数据。工具接口变了mock也要同步更新。6.4 忽略“拒答”场景有些任务智能体应该拒答比如超出能力范围、涉及敏感信息但评测集里没有这类case导致智能体学会了“什么都答”上线后乱答一气。评测集里要有拒答case预期输出是“我无法处理这个请求”或类似表述。裁判要能判断智能体是否恰当地拒答了。6.5 评测结果没有置信区间跑100条case通过80条通过率80%。但如果换一批100条通过率可能是75%也可能是85%。只报一个点估计不报置信区间容易过度解读小差异。我的做法是核心指标报点估计置信区间。100条样本的95%置信区间大概±8%所以80%和85%的差异可能不显著不要急着下结论说“新版本更好了”。7. 把评测变成开发习惯而不是上线前的突击最后聊一个心态问题。很多团队把评测当成“上线前的一道关卡”平时不跑临上线了突击跑一遍。这种用法浪费了评测最大的价值。评测真正的价值在于快速反馈。你改了一版prompt跑一下核心集5分钟就知道有没有退化你换了一个工具描述跑一下相关场景立刻知道工具调用准确率有没有提升。这种“改-测-改”的快速循环才是智能体开发效率的关键。我现在的习惯是任何prompt或工作流改动提交前必须跑核心回归集。这就像写代码要跑单元测试一样是肌肉记忆。核心集不用大200条足够跑一次几分钟但能拦住80%的低级退化。另外评测报告要团队共享。不要只有评测的人看产品、运营、开发都要看。产品看场景通过率运营看失败case里的用户影响开发看技术指标。大家从不同角度看同一份数据才能形成合力。还有一点评测集要持续迭代。上线后收集真实badcase分析后补充进评测集。这样评测集越来越贴近真实场景评测结果越来越有预测力。一个半年没更新过的评测集参考价值会大打折扣。智能体评测这件事没有一劳永逸的方案只有持续迭代的体系。工具会变、模型会变、场景会变评测体系也要跟着变。但核心思路是不变的用可复现的方法量出智能体在真实场景下的真实水平然后用这个数字指导下一步优化。把这个循环跑起来智能体的质量就会螺旋上升而不是靠运气上线、靠救火维护。
