智能体评测体系实战：从基准构建到LLM-as-Judge的完整指南

1. 为什么“跑个分”这件事在智能体时代彻底失效了

如果你在过去一年里搭过智能体，大概率经历过这样的场景：demo 演示时行云流水，老板看了直点头，结果一上真实流量，用户随便换个问法就翻车。更尴尬的是，你明明改了一版提示词，感觉“应该更好了”，但上线之后投诉量反而涨了。问题出在哪？出在你根本没有一把靠谱的尺子。

传统软件测试那套东西——单元测试、断言、覆盖率——放到智能体身上基本失灵。原因很简单：智能体的输出是自然语言，是概率性的，是带工具调用的多步决策链。你没法用assert result == "预期值"去判断一段回答到底好不好。一个智能体可能答对了内容但语气冒犯，可能调用工具的顺序错了但最终结果蒙对了，也可能在第三步就悄悄偏离了用户意图却一路“自信”地跑到底。

这就是「超体」评测体系要解决的核心问题：给智能体建立一套可量化、可复现、可迭代的衡量标准。注意，我说的是“衡量”而不是“测试”。测试追求的是通过/不通过，衡量追求的是“在哪个维度上、好了多少、差在哪里”。这个区别决定了整套方法论的设计方向。

这篇文章适合三类人看：一是正在做智能体产品、被“效果玄学”折磨的开发者；二是需要向业务方证明智能体价值的团队负责人；三是想系统理解评测体系怎么从零搭起来的技术同学。我会把基准构建、LLM-as-Judge、验证器设计、指标拆解这些环节拆开讲透，中间穿插我自己踩过的坑和实测有效的做法。读完你至少能搭出一套跑得通、说得清、能指导迭代的评测流水线。

2. 拆解智能体的“能力维度”：评测到底该测什么

2.1 从“单轮问答”到“多步任务”的评测视角切换

很多人做智能体评测，第一反应是拿一批问题去问，然后看回答对不对。这个思路停留在单轮问答的层面，对真正的智能体来说远远不够。一个完整的智能体任务通常包含：理解意图、规划步骤、调用工具、处理中间结果、生成最终回复。任何一个环节出问题，最终表现都会打折，但如果你只看最终回复，根本定位不到病灶。

我习惯把评测维度拆成四层，从下往上依次是：

• 基础能力层：语言理解、指令遵循、格式输出稳定性。这一层用传统 NLP 指标加人工抽检就能覆盖。
• 工具使用层：工具选择是否正确、参数填充是否准确、调用顺序是否合理、异常处理是否到位。这一层是智能体区别于普通对话系统的关键。
• 任务完成层：多步任务的整体成功率、步骤效率、是否出现死循环或无效重试。
• 交互体验层：回复的连贯性、主动性、安全合规性、对模糊指令的澄清能力。

这四层不是并列关系，而是递进关系。基础能力不过关，上层评测没有意义；工具使用层出问题，任务完成率一定上不去。实际评测时，我会给每一层分配不同的权重，具体权重取决于产品形态。比如一个客服智能体，交互体验层的权重会拉高；一个数据分析智能体，工具使用层和任务完成层是重中之重。

2.2 任务完成率不是唯一指标：引入“过程分”的必要性

只看任务完成率有个致命问题：它是个二值指标，要么完成要么没完成。但现实中大量任务是“部分完成”的——智能体查到了正确数据但格式错了，或者完成了主体步骤但漏了一个收尾动作。如果只记 0 分，你丢失了大量有价值的信号。

我的做法是引入过程分（Process Score）。具体来说，把每个任务拆成若干关键节点，每个节点单独打分，最后加权汇总。举个例子，一个“帮用户退订某服务并发送确认邮件”的任务，可以拆成：

这样即使最终任务没完成，你也能看到智能体卡在了哪一步。是意图识别就错了，还是工具调用参数填错了？过程分让评测从“黑盒判断”变成“白盒诊断”，对迭代的指导价值完全不是一个量级。

2.3 不同场景下的评测侧重点差异

评测体系不能一刀切。我做过几类不同场景的智能体评测，侧重点差异很大：

客服类智能体：最看重意图识别准确率和安全合规。工具调用相对简单（查订单、改地址），但对话轮次多，需要评测多轮上下文保持能力。这类场景我会把“答非所问率”和“违规话术触发率”作为一级指标。

代码类智能体：工具使用层是核心。代码生成质量可以用编译通过率、测试用例通过率来量化，但更关键的是它会不会乱改文件、会不会引入安全漏洞。我通常会加一个“破坏性操作检测”维度，专门看它有没有执行危险命令。

数据分析类智能体：任务完成层权重最高。重点看它能不能正确理解分析需求、选对数据源、写出正确的查询语句、给出合理的结论。这类场景的评测需要构造带标准答案的数据集，否则没法判断结论对错。

多智能体协同场景：除了单体的能力，还要评测通信效率、任务分配合理性、冲突解决机制。这个复杂度最高，我一般建议先把单体评测做扎实再碰多体。

3. 基准构建：从零搭一套能用的评测集

3.1 评测集的三个来源与各自的坑

搭评测集这件事，听起来简单做起来要命。我总结下来无非三个来源，每个都有坑：

来源一：真实用户日志。这是最理想的来源，因为分布最真实。但坑在于：日志里大量是简单重复问题，直接拿来用会导致评测集严重偏斜。我的做法是先做聚类，每个意图簇抽 3-5 条代表样本，再人工补充边界 case。另外日志涉及用户隐私，脱敏必须做干净，否则后患无穷。

来源二：人工构造。可控性最强，但容易“想当然”。我见过太多团队构造的评测集全是理想路径，智能体跑出来 95 分，一上真实流量就崩。构造时一定要刻意加入：模糊指令、多意图混合、中途改需求、工具返回异常、超长上下文。这些才是真实世界的常态。

来源三：对抗生成。用另一个模型来生成刁钻问题，或者对现有问题做扰动（换同义词、改语序、加干扰信息）。这个方式能快速扩充评测集，但要注意生成质量，我一般会人工审核 20% 左右的样本，发现系统性偏差就调整生成策略。

提示：评测集不是越大越好。我见过有人搞了几万条，结果跑一次评测要几个小时，迭代节奏全被打乱。我的经验是：核心评测集控制在 200-500 条，覆盖主要场景和边界情况；回归测试集可以精简到 50-100 条，每次改动必跑。

3.2 标注规范：让不同人标出一致的结果

评测集的质量取决于标注质量。如果两个人对同一条样本的判断不一致，那这个评测集就是废的。我制定标注规范时会明确三件事：

第一，评分标准要可操作。不要说“回答质量高”，要说“回答包含用户问题的所有关键信息点，且无事实错误，且格式符合要求”。每个维度都要有明确的判定条件，最好配上正例和反例。

第二，边界情况要有裁决规则。比如“智能体回答正确但语气生硬”算几分？“工具调用成功但多调用了一次无关工具”扣不扣分？这些模糊地带必须提前定好规则，否则标注时必然扯皮。

第三，定期做一致性校验。我会让两个标注员独立标同一批 50 条样本，算 Cohen's Kappa 系数。低于 0.7 就说明规范有问题，需要重新对齐。这个步骤很多人省掉，结果评测结果忽高忽低，根本没法用。

3.3 评测集的版本管理与防“过拟合”

评测集用久了会“失效”——不是评测集本身坏了，而是你的智能体在它上面过拟合了。你根据评测结果调提示词、改流程，调着调着评测分数上去了，但真实效果没变。这是典型的“对评测集过拟合”。

我的应对策略是评测集分池：

• 开发池（Dev Set）：日常迭代用，可以频繁跑，允许一定程度的“针对性优化”。
• 验证池（Val Set）：每周跑一次，不直接用于调参，只用来观察趋势。
• 测试池（Test Set）：每月或每个大版本跑一次，严格保密，不参与任何调优决策。

三个池子的样本不重叠，但分布要一致。测试池的分数才是对外汇报的分数。如果开发池涨了但测试池没涨，说明你在过拟合，得停下来反思。

另外，评测集本身也要迭代。产品功能变了、用户分布变了，评测集就得更新。我一般每季度做一次评测集审查，淘汰过时样本，补充新场景。

4. LLM-as-Judge：用模型当裁判的正确姿势

4.1 为什么人工评测撑不住，模型裁判又不可全信

人工评测是金标准，但成本太高。一条样本从阅读到打分至少 2-3 分钟，500 条就是 20 多个小时。你不可能每次改个提示词就全量人工评一遍。所以 LLM-as-Judge 成了必然选择——用一个大模型来给智能体的输出打分。

但这里有个根本矛盾：裁判模型本身也是概率性的。它可能被冗长的回答迷惑，可能偏好某种表达风格，可能对某些领域知识判断不准。我见过裁判模型给一个明显错误的回答打高分的案例，原因是那个回答“看起来很自信”。

所以我的原则是：LLM-as-Judge 用来做大规模初筛和趋势监控，关键决策仍然需要人工抽检校准。两者不是替代关系，是配合关系。

4.2 裁判提示词的设计要点：评分标准要“可执行”

裁判提示词写得好不好，直接决定评测结果有没有参考价值。我踩过的坑包括：评分标准太模糊导致裁判模型自由发挥、评分维度太多导致模型顾此失彼、没有给示例导致模型理解偏差。

现在我的裁判提示词模板包含这几个部分：

JUDGE_PROMPT = """ 你是一个严格的评测裁判。请根据以下标准对智能体的回答进行评分。 ## 任务背景 用户问题：{question} 智能体回答：{answer} 参考答案（如有）：{reference} ## 评分维度与标准 1. 事实准确性（0-5分）： - 5分：所有事实陈述正确，无幻觉 - 3分：主体正确，有轻微不准确但不影响核心结论 - 1分：存在明显事实错误 - 0分：完全错误或答非所问 2. 完整性（0-5分）： - 5分：覆盖用户问题的所有关键点 - 3分：覆盖主要关键点，遗漏次要信息 - 1分：只覆盖少量关键点 - 0分：未回答核心问题 3. 工具使用合理性（0-5分，如适用）： - 5分：工具选择正确，参数准确，顺序合理 - 3分：工具选择正确但有参数小错或多余调用 - 1分：工具选择错误或关键参数缺失 - 0分：未调用必要工具或调用完全错误 ## 输出格式 请先逐维度分析，最后输出 JSON： {{"accuracy": <score>, "completeness": <score>, "tool_use": <score>, "reason": "<简要说明>"}} """

关键点：每个分数档位都要有明确的行为描述，不能只说“好/中/差”。另外，要求裁判模型先分析再打分，比直接让它输出分数准确率更高——这相当于让它做一次 chain-of-thought。

4.3 裁判模型的偏差校准与一致性验证

裁判模型有几种已知偏差，必须校准：

位置偏差：对比两个回答时，模型倾向于偏好第一个或第二个。解决办法是交换顺序跑两次，取平均。

长度偏差：长回答容易得高分，因为“看起来更详细”。解决办法是在评分标准里明确“简洁且准确”不扣分，或者在预处理时截断过长回答。

自我偏好：用 GPT 系模型当裁判时，它可能偏好 GPT 系智能体的输出。解决办法是换不同家族的模型做裁判，或者用多个裁判取平均。

校准方法是：拿 100 条人工已标注的样本，让裁判模型跑一遍，算它和人工评分的一致性。如果某个维度的相关性低于 0.6，说明这个维度的评分标准需要重新设计。我一般会迭代 2-3 轮，直到各维度相关性都在 0.7 以上才正式启用。

5. 验证器设计：让自动化评测真正可信

5.1 规则验证器与模型验证器的分工

验证器是评测流水线的执行单元。我把它分成两类：

规则验证器：用确定性逻辑做检查。比如：输出是否是合法 JSON、是否包含敏感词、工具调用参数是否符合 schema、数值计算结果是否正确。这类验证器快、准、便宜，能覆盖的尽量用规则。

模型验证器：用 LLM 做判断。比如：回答是否切题、语气是否合适、多步推理是否逻辑自洽。这类验证器处理规则覆盖不了的语义问题，但慢、贵、有偏差。

分工原则很简单：能用规则解决的绝不交给模型。我见过有人用 LLM 去判断“输出是否是合法 JSON”，这纯属浪费。规则验证器应该承担 60%-70% 的检查量，模型验证器只处理剩下的语义判断。

5.2 工具调用链的验证：比结果更重要的是过程

智能体评测里最容易忽略的是工具调用链的验证。很多团队只看最终输出对不对，不看中间过程。这会导致一个严重问题：智能体可能用错误的方式得到了正确的结果，下次换个场景就崩了。

我设计工具调用验证器时，会检查这几个点：

• 工具选择：该调 A 工具的时候有没有调 B？有没有该调而不调的情况？
• 参数准确性：参数值是否正确？必填参数是否齐全？参数类型是否符合接口要求？
• 调用顺序：有依赖关系的工具是否按正确顺序调用？
• 调用次数：有没有重复调用同一个工具？有没有陷入无效重试循环？
• 异常处理：工具返回错误时，智能体是合理降级还是直接崩溃？

实现上，我会给每个任务定义一个“期望调用序列”，然后用编辑距离或序列匹配算法来比对实际调用序列。完全匹配得满分，部分匹配按比例给分，出现危险调用（如删除操作）直接判负。

5.3 验证器组合策略与置信度加权

单个验证器的判断都可能出错，所以最终分数应该是多个验证器的加权组合。我的做法是：

• 规则验证器权重高（0.7-0.9），因为确定性高。
• 模型验证器权重低（0.1-0.3），且需要多个模型交叉验证。
• 如果规则验证器和模型验证器结论冲突，以规则验证器为准，但记录冲突样本供人工复查。

另外，我会给每个验证器输出一个置信度。比如规则验证器发现格式错误，置信度 1.0；模型验证器判断“回答不够完整”，置信度 0.6。最终分数按置信度加权，低置信度的判断不会对总分产生过大影响。

6. 指标拆解与看板：让评测结果指导迭代

6.1 从总分到归因：建立指标树

只有一个总分是没用的，你需要一棵指标树。我的指标树通常长这样：

• 总分
  • 任务完成层
    • 端到端成功率
    • 平均步骤数
    • 步骤效率比（实际步骤/最优步骤）
  • 工具使用层
    • 工具选择准确率
    • 参数填充准确率
    • 异常处理成功率
  • 基础能力层
    • 意图识别准确率
    • 格式合规率
    • 幻觉率
  • 交互体验层
    • 多轮上下文保持率
    • 澄清提问合理性
    • 安全合规率

每个叶子指标都要能追溯到具体的验证器。这样当总分下降时，你能快速定位是哪个环节出了问题。比如总分掉了 5 分，一看是工具选择准确率从 92% 掉到 85%，那就去查是不是最近加了新工具导致选择困难。

6.2 评测看板的设计：让非技术同学也能看懂

评测结果最终是要给团队看的，包括产品、运营、甚至老板。所以看板设计要遵循“一屏看懂”原则：

• 顶部：总分趋势图，按天/周展示，标注版本发布节点。
• 中部：各维度得分雷达图，一眼看出短板在哪。
• 底部：失败案例 Top 10，按失败类型分组，附上原始输入和智能体输出。

我还会加一个“对比模式”，可以选两个版本做 diff，直接看到哪些指标涨了、哪些跌了、哪些案例从通过变失败。这个功能在 A/B 测试时特别有用。

提示：看板上的分数要带置信区间。如果两个版本的分数差异在置信区间内，不要急着下结论说“新版更好”。我见过太多团队被噪声误导，改了一版又改回去，白白浪费迭代周期。

6.3 评测驱动迭代的闭环流程

评测的最终目的是驱动迭代。我跑通的闭环流程是：

1. 跑评测：新版本上线前跑全量评测集。
2. 看归因：如果总分没涨或下降，看指标树定位问题维度。
3. 查案例：从失败案例里找典型，分析是提示词问题、工具问题还是流程问题。
4. 做修改：针对性修改，一次只改一个变量。
5. 回归验证：跑回归测试集，确认修改没有引入新问题。
6. 全量评测：回归通过后跑全量，确认整体提升。
7. 上线监控：上线后持续监控真实流量指标，和评测分数做相关性分析。

这个闭环跑顺了，迭代效率会大幅提升。以前改一版心里没底，现在改一版能看到明确的分数变化和归因分析，决策有依据。

7. 实测中的几个反直觉发现

7.1 评测分数涨了，线上效果不一定好

这是我踩过最大的坑。有一次评测分数从 78 涨到 86，团队都很开心，结果上线后用户投诉反而多了。排查后发现：评测集里的样本偏简单，智能体在简单场景下确实变好了，但在复杂场景下反而因为“过度自信”而更容易出错。评测集的分布和真实流量分布不一致，导致评测分数失去了代表性。

解决办法：定期做评测集和真实流量的分布对齐。具体做法是拿真实流量跑一遍意图聚类，看评测集在各簇上的覆盖比例是否和真实分布一致。不一致就补充样本。

7.2 裁判模型也会“偷懒”

LLM-as-Judge 跑多了之后，我发现裁判模型有“偷懒”倾向：对于长回答，它经常只看了开头和结尾就给分，中间的错误直接忽略。对于格式复杂的输出，它可能只检查了格式而没检查内容。

应对方法：在裁判提示词里强制要求“逐段分析”，并且对长回答做分段评分再汇总。另外，定期用“陷阱样本”测试裁判模型——故意在回答中间插入一个明显错误，看裁判能不能发现。如果发现不了，说明裁判提示词需要加强。

7.3 工具调用评测比想象中难

工具调用的评测难度远超预期。难点在于：同一个任务可能有多种正确的工具调用路径。比如“查天气”可以调天气 API，也可以调搜索引擎。你没法预设一个“唯一正确”的调用序列。

我的处理方式是定义“可接受调用集合”而不是“唯一正确序列”。只要智能体的调用路径在可接受集合内，就判正确。同时，对于明显低效的路径（比如调了 5 个工具才完成一个简单任务），即使结果正确也要扣分。

7.4 小样本评测的统计显著性陷阱

评测集只有 100 条时，两个版本分数差 3 分，这个差异可能完全是噪声。我做过一个模拟：同一个智能体跑两次，分数差异能达到 2-4 分。所以小样本评测的结论要非常谨慎。

我的经验法则：评测集少于 200 条时，分数差异小于 5 分不要下结论；200-500 条时，差异小于 3 分不要下结论；500 条以上时，差异小于 2 分不要下结论。当然这取决于任务的方差，方差大的任务阈值要更高。

8. 写在最后：一些个人体会

搭评测体系这件事，最难的从来不是技术，而是坚持。我见过太多团队一开始热情满满，搭了一套评测流水线，跑了两个月就荒废了。原因无非是：评测结果和直觉冲突时选择相信直觉、迭代压力大时跳过评测直接上线、评测集长期不更新导致失效。

我的建议是：把评测当成产品的一部分来维护，而不是一次性的工具。给它分配固定的维护人力，定期更新评测集，定期校准裁判模型，定期审查指标树是否还反映业务目标。只有这样，评测体系才能持续产生价值。

另外，不要追求“完美”的评测体系。我见过有人花三个月设计了一套极其复杂的评测框架，结果一天都没跑起来。先用最粗糙的方式跑通闭环——哪怕只有 50 条样本、一个规则验证器、一个裁判模型——然后在使用中逐步完善。跑起来的粗糙评测，比躺在文档里的完美方案有价值一百倍。

最后一个实用技巧：每次评测跑完，把失败案例导出成一个共享文档，让团队成员都能看到智能体到底在哪些地方翻车。这比任何分数都更能激发改进的动力。我团队里有个规矩：每周例会上必须过 5 个失败案例，大家一起分析原因。这个习惯坚持了半年，智能体的真实用户满意度提升了将近 20 个百分点。评测体系的价值，最终要体现在这些真实的改进上。