智能体评测体系实战：从主观感受到可量化结论的四层架构

智能体这东西做出来容易说清楚它到底行不行难。过去大半年我经手过好几个智能体项目的验收最头疼的从来不是功能跑不通而是“怎么证明它跑得好”。你说它答得不错我说它胡编乱造最后往往变成谁嗓门大谁有理。这套「超体」评测体系就是在这个背景下折腾出来的——它要解决的核心问题只有一个把“好不好用”这种主观感受变成可复现、可对比、可追溯的量化结论。不管你是刚搭完第一个智能体工作流的新手还是正在为团队建立质量门禁的工程负责人这套思路都能直接拿去改改用。1. 为什么智能体评测不能照搬传统软件测试1.1 确定性输入输出假设的崩塌传统软件测试的根基是确定性给定输入A必然得到输出B断言写死就行。但智能体的输出是概率性的同一个问题问两遍措辞可能完全不同甚至结论都有细微漂移。我早期犯过一个典型错误——给一个问答智能体写了200条精确匹配的测试用例结果上线后通过率只有六成团队一度以为模型有问题。后来才发现那六成里有一大半是“意思对了但措辞不同”被误判为失败。这个教训让我彻底放弃了精确匹配的思路。智能体的评测对象不是字符串而是意图、事实和行为的组合。它可能用三种不同句式回答同一个问题只要核心事实正确、没有幻觉、格式符合要求就应该算通过。这意味着评测体系必须从“比对文本”转向“判断语义”这是整个体系设计的第一个分水岭。1.2 多轮交互带来的状态爆炸更麻烦的是多轮场景。一个订票智能体第一轮问出发地第二轮问时间第三轮确认舱位每一轮的状态都依赖前序对话。传统测试可以枚举所有分支但智能体的对话路径是指数级增长的——用户可能中途改主意、可能答非所问、可能突然切换话题。我见过一个客服智能体在第五轮突然“失忆”把前面确认过的订单号忘了这种问题单轮测试根本测不出来。所以评测体系必须包含轨迹级评估不能只看最终回复还要看中间的工具调用序列、状态维护是否正确。这就像考驾照不能只看车停没停进库还要看打灯、观察、换挡的顺序对不对。1.3 评测成本与标注质量的死结人工评测最准但贵且慢。一个中等规模的智能体跑一轮完整回归测试可能要几千次调用全请人打分根本不现实。用模型当裁判LLM-as-Judge便宜但裁判本身也会犯错而且不同裁判模型的口味还不一样。我试过用同一个裁判模型给同一批回复打分间隔一周再跑有大约8%的样本分数发生了翻转。这个抖动幅度在关键决策场景里是不可接受的。所以「超体」体系的核心设计原则是分层评测、交叉验证、人工兜底。便宜快速的自动指标做粗筛LLM裁判做细评人工只介入争议样本和高风险场景。这样既控制了成本又保证了关键结论的可靠性。2. 「超体」评测体系的四层架构拆解2.1 第一层规则断言层——快、硬、但不全面这一层处理的是那些“对就是对错就是错”的硬性要求。比如输出必须是合法JSON、必须包含某个必填字段、响应时间不能超过3秒、不能出现敏感词。这些用代码直接断言零成本、零延迟、零歧义。我通常会把规则断言分成三类格式类JSON schema校验、字段完整性、安全类敏感词过滤、越权检测、性能类首token延迟、总耗时。这三类加起来能拦住大约40%的明显问题而且完全不消耗模型调用额度。很多团队一上来就搞复杂的语义评测反而忽略了这层最便宜的防线属于典型的用力用错地方。注意规则断言层不要写得太细。我见过有人把“回复必须包含‘您好’两个字”写成硬断言结果智能体用了“你好”就被判失败。规则层只卡那些真正不能妥协的底线措辞类的偏好放到后面几层去评。2.2 第二层LLM-as-Judge——便宜但有脾气这一层是主力。核心思路是让一个能力足够强的模型扮演裁判按照给定的评分标准rubric给智能体的回复打分。听起来简单但实操里有几个坑必须提前填。裁判模型的选择很关键。我的经验是裁判模型的能力至少要等于或高于被评测的智能体所用模型否则会出现“裁判看不懂智能体在说什么”的尴尬。另外裁判模型最好和被评测模型不是同一个避免自我偏袒。实测下来用不同厂商的模型做交叉裁判一致性会明显好于同源模型。评分标准的设计决定了评测的天花板。我习惯把评分拆成几个正交维度每个维度独立打分而不是给一个笼统的总分。比如事实准确性、指令遵循度、表达清晰度、安全合规性每个维度1到5分最后加权汇总。这样即使总分相同也能看出问题出在哪个维度。2.3 第三层验证器与工具调用校验——看行为不看嘴智能体区别于普通聊天机器人的核心特征是它会调用工具、执行动作。一个说“我已经帮你订好了”但实际没调用订票接口的智能体比直接说“我做不到”的智能体危险得多。所以这一层专门校验行为轨迹。具体做法是拦截智能体的工具调用日志检查调用序列是否符合预期。比如用户问天气智能体应该调用天气查询工具而不是直接编一个温度。如果它没调工具就给出了具体数值直接判为幻觉。如果它调了工具但参数传错了比如城市名拼错也要扣分。这一层还能检测冗余调用和循环调用。我遇到过智能体在某个边界条件下反复调用同一个工具十几次最后超时崩溃。这种问题在最终回复里看不出来只有看轨迹才能发现。2.4 第四层人工评审与争议仲裁——贵但必要前面三层跑完会有一批“争议样本”——自动评测拿不准、分数卡在及格线附近、或者多个裁判结论不一致的。这些样本才需要人工介入。我的做法是只把争议样本和高风险场景比如涉及金额、医疗建议、法律条款送人工通常只占总量的5%到10%成本可控。人工评审也不是随便看看要用结构化的评分表和LLM裁判用同一套rubric这样人工结论才能和自动结论对齐用于校准裁判模型。我一般会定期拿人工标注的结果去回测LLM裁判如果发现某个维度的偏差超过阈值就调整裁判的prompt或者换裁判模型。层级覆盖比例单次成本主要作用典型工具规则断言100%极低卡底线、拦明显错误代码断言、JSON SchemaLLM裁判80%中语义质量细评裁判模型评分prompt轨迹校验100%低行为正确性日志拦截、序列比对人工评审5%-10%高仲裁争议、校准裁判标注平台评分表3. 基准构建从零搭一套能用的测试集3.1 测试用例的来源与配比评测体系是尺子基准测试集就是被测物。没有好的测试集再精密的尺子也量不出东西。我构建测试集通常从三个来源取料真实用户日志脱敏后、领域专家构造、对抗性生成。三者的配比大概是5:3:2。真实日志最宝贵因为它反映了用户真实的表达习惯和边界情况。专家构造的用例覆盖核心业务场景保证关键路径不漏测。对抗性用例专门用来“找茬”比如故意诱导智能体产生幻觉、故意输入超长文本、故意在对话中途切换语言。这部分用例往往能挖出最隐蔽的问题。测试集不是一次性的要持续迭代。每次线上发现新的bad case就把它补进测试集形成回归防线。我习惯给每个用例打上标签场景、难度、风险等级这样跑评测时可以按标签切片分析快速定位是哪类场景退化了。3.2 评分标准Rubric的写法Rubric写得好不好直接决定评测结果有没有参考价值。我见过太多团队写的rubric是“回答得好给5分回答得不好给1分”这种废话。好的rubric必须做到维度正交、描述具体、锚点清晰。以事实准确性为例我会这样写锚点5分表示所有事实陈述均可验证且正确4分表示核心事实正确但存在无关紧要的细节偏差3分表示有一个非核心事实错误2分表示有核心事实错误但未造成误导1分表示存在明显幻觉且可能误导用户。每个分数都有具体的行为描述裁判模型才能稳定执行。另外rubric要针对具体场景定制。一个代码生成智能体的rubric和一个客服智能体的rubric维度权重完全不同。代码场景里“可运行性”权重最高客服场景里“语气友好度”和“问题解决率”更重要。不要指望一套通用rubric打天下。3.3 基准的版本管理与防污染测试集一旦公开或反复使用就有被“刷分”的风险。模型可能在训练数据里见过这些题目导致评测分数虚高。防污染的手段有几个保留私有测试集不公开、不用于调优、定期换题每次评测替换20%左右的用例、动态生成用模板随机参数实时生成用例。我还会给测试集打版本号每次评测记录用的是哪个版本。如果发现某个版本上分数异常高先怀疑是不是题目泄露了而不是急着庆祝。这个习惯帮我避免过好几次误判。4. 实操跑通一轮完整评测的步骤4.1 环境准备与依赖安装先把评测框架搭起来。我用的是Python生态核心依赖包括评测调度、裁判调用、结果统计三块。下面是一个最小化的依赖清单pip install pandas numpy openai tqdm pyyaml jsonschema其中jsonschema用于规则断言层的格式校验tqdm用于进度显示pyyaml用于管理评测配置。裁判模型的调用我建议单独封装一个客户端类方便切换不同厂商的模型也方便加缓存——同一批回复重复评测时缓存能省下大量调用成本。配置文件用YAML管理把裁判模型、评分维度、权重、测试集路径都写进去这样换实验条件时不用改代码只改配置。4.2 评测执行的核心流程整个流程分四步加载测试集 → 逐条调用智能体 → 逐条送裁判打分 → 汇总统计。听起来线性但中间有几个细节决定成败。第一步加载测试集时要校验用例格式确保每条都有输入、预期行为描述、场景标签。第二步调用智能体时要记录完整的交互轨迹包括每轮输入输出、工具调用、耗时。第三步送裁判时要把智能体的回复和rubric一起塞进prompt让裁判输出结构化的JSON分数。第四步汇总时除了算总分还要按场景标签、难度等级切片统计这样才能看出问题分布。import json from judge_client import JudgeClient def evaluate_single_case(case, agent, judge): # 调用智能体记录轨迹 trajectory agent.run(case[input]) # 规则断言 rule_pass check_rules(trajectory, case.get(rules, [])) # 裁判打分 scores judge.score( questioncase[input], answertrajectory[final_output], rubriccase[rubric] ) return { case_id: case[id], rule_pass: rule_pass, scores: scores, trajectory: trajectory }这段代码的关键在于trajectory要完整保留不能只存最终输出。后面排查问题时轨迹是唯一的证据链。4.3 结果统计与可视化跑完一轮原始数据是一堆JSON需要聚合成人能看懂的报表。我通常输出三张表总分表各维度平均分、通过率、切片表按场景/难度分组的分数、失败案例表规则失败和低分样本的明细。总分表看整体健康度切片表看短板在哪失败案例表用来做根因分析。三张表配合着看基本能定位到具体是哪个环节出了问题。可视化我一般用简单的柱状图和热力图不搞花哨的重点是信息密度。提示评测报告里一定要保留原始样本的索引。看到某个维度分数异常能一键跳回具体用例去复现这个能力在排查阶段能省下大量时间。5. 踩坑实录那些让我返工三次的评测陷阱5.1 裁判模型的“位置偏见”这是最隐蔽的坑。当你让裁判模型对比两个回复哪个更好时它会系统性地偏向第一个或第二个具体偏向哪个取决于模型和prompt。我做过实验同一个裁判模型把A和B的顺序换一下有将近30%的样本结论翻转。这个偏差如果不处理评测结果基本不可信。解决办法是双向评测把A和B评一遍再把B和A评一遍两次结论一致才算数不一致的送人工。虽然成本翻倍但结论可靠。另一个办法是让裁判同时看到两个回复明确要求它忽略顺序但实测下来效果不如双向评测稳。5.2 评分标准的“中间塌陷”裁判模型有个通病喜欢打中间分。1分和5分很少给大量样本挤在3分附近。这导致区分度极差两个质量差距明显的智能体平均分可能只差0.1。我一开始以为是模型能力问题换了更强的裁判模型发现还是这样。根因是rubric的锚点描述不够极端。后来我把5分的描述改成“完美无可挑剔可以直接交付给最挑剔的用户”把1分改成“存在严重错误可能造成实际损失”中间分的描述也写得更具体裁判的分数分布才拉开。所以rubric的措辞强度直接影响分数的区分度这是个反直觉但很重要的经验。5.3 测试集泄露导致的“虚高”有一次我们内部评测某个智能体分数高得离谱团队差点直接上线。我多了个心眼把测试集里的题目拿去问智能体“你见过这个问题吗”结果它准确复述出了标准答案。这说明测试集在某个环节泄露了可能是训练数据混入也可能是调优时不小心用了。从那以后我立了个规矩任何评测分数异常高的情况先做泄露检测再谈其他。泄露检测的方法很简单把测试题改几个字换数字、换实体名如果分数断崖式下跌基本就是泄露了。5.4 多轮评测的“上下文漂移”单轮评测跑得好好的一上多轮就崩。排查下来发现是评测框架的问题每轮对话之间没有正确传递历史上下文导致智能体“失忆”。这个坑很蠢但很常见。评测框架的对话管理逻辑必须和线上环境一致否则测出来的结果没有参考价值。我的做法是评测框架直接复用线上的会话管理模块不自己另写一套。虽然耦合度高一点但能保证评测环境和生产环境的行为一致这个一致性比解耦更重要。6. 让评测体系持续进化的几个习惯6.1 建立bad case回流机制线上每发现一个bad case就把它脱敏后补进测试集同时标注它属于哪个维度的问题。这个动作坚持做测试集会越来越“毒”能挖出的问题也越来越深。我带的项目里测试集从最初的200条涨到后来的1500多条其中最有价值的用例几乎都来自线上回流。回流不是简单堆砌要定期做去重和归类。同类问题保留最有代表性的几条就行否则测试集臃肿跑一轮成本高收益还递减。6.2 定期校准裁判模型裁判模型不是设好就不管了。模型厂商会更新版本你的rubric也可能调整这些都会影响裁判的稳定性。我一般每两周做一次校准拿一批人工标注过的样本让裁判重新打分算一下和人工结论的一致率。如果一致率跌破阈值我设的是85%就排查原因是prompt需要调还是裁判模型该换了。校准数据要单独存放不能混进测试集否则就失去了校准的意义。6.3 评测结果要能追溯到具体样本这个前面提过但值得再强调。评测报告如果只给一个总分没有任何可追溯性那这个报告就是废纸。每个分数背后都要能点回到具体用例、具体回复、具体轨迹。我见过太多团队拿着一个总分开会讨论半天谁也说不清问题到底出在哪最后不了了之。可追溯性还有一个好处当有人质疑评测结果时你能立刻拿出证据。这在跨团队协作里特别重要能省下大量扯皮时间。6.4 把评测纳入CI/CD流水线智能体的迭代速度很快今天改个prompt明天换个工具如果没有自动化评测卡着质量会悄悄滑坡。我的做法是把核心测试集通常是精简版200条左右挂到CI上每次代码合并前自动跑一遍分数跌破基线就阻断合并。基线不是固定的随着智能体能力提升基线也要相应上调。但上调要有依据不能因为“这次分数低就调低基线”那就本末倒置了。7. 关于评测成本的一点实在话整套体系跑下来成本主要花在裁判调用上。一个1500条的测试集每条平均调用裁判2次双向评测单次调用按中等长度算一轮下来大概几千次模型调用。如果每天都跑成本不小。我的优化策略是全量评测每周一次增量评测每天只跑核心集。核心集覆盖最高频、最高风险的场景200条左右成本可控又能起到日常监控的作用。另外裁判调用一定要加缓存。同一批回复在调prompt的过程中会被反复评测缓存命中率能到60%以上省下的成本很可观。缓存key用“回复内容rubric版本”的哈希简单有效。还有个省钱的办法是用小模型做初筛。先用便宜的小模型跑一遍把明显没问题的样本过滤掉只把边界样本送大模型裁判。实测下来能省一半左右的调用量代价是漏判率略微上升但配合人工抽检可以接受。这套「超体」评测体系不是什么高深的东西核心就是把“感觉不错”拆成可量化的维度用分层的手段控制成本和可靠性再用持续的校准和回流保持它的生命力。我自己的体会是评测体系的价值不在于分数本身而在于它逼着团队把“好”的定义想清楚、写下来、对齐掉。这个过程本身往往比评测结果更有价值。