谁来评估评估者？在信任这些评估工具之前，先对其进行验证。
谁来验证评估套件？评估标准的偏差、仅基于结果的评分方式、私有的故障模式以及隐藏的成本都可能导致大语言模型的评估结果失真。需要对该评估套件本身进行检验。
来源: Nobody Validates the Validator: The Eval Suite Problem in Agent Engineering
到2026年，几乎所有推出AI智能体的团队都会配套使用一套评估系统，其中包含控制面板、通过率统计、持续集成检查点，以及能够根据评分标准对智能体表现进行打分的LLM评估工具。所有这些都体现了严谨性，似乎也划清了生产级系统与仅偶然两次运行成功的演示版本之间的界限。
不过，一旦提出下一个显而易见的问题，情况就变得沉默了：在这套评估系统开发完成半年后，究竟有谁来验证它确实衡量了正确的内容、以正确的方式进行了测量，并且输出的结果真实可靠？几乎没人做到。整个行业花了两年时间构建用于评估智能体的工具，却几乎才开始着手开发用于评估这些评估工具本身的工具。这种差距已经以几种可预见的方式在实际应用中显现出来。
无人明说的假设
在大多数智能体评估系统中，都隐含着一个未明说的前提：通过意味着智能体行为正确，失败则意味着其行为有误。只要接受这一前提，这套系统就会变成人们自动信任的“黑箱”。仪表盘显示为绿色，代码合并成功，团队便可继续前进。
针对智能体执行轨迹的研究开始对这一前提提出质疑。有一项研究分析了58条被结果评分标记为成功的轨迹，发现其中83%的案例存在流程或安全违规问题，而这些违规在通过/失败评分中根本未被发现。智能体虽然给出了正确答案并获得了满分，但其采用的路径实际上存在缺陷。结果与过程之间的差异正是评估系统旨在捕捉的，但也是大多数系统因设计原因而无法察觉的。
有四种故障模式需要被单独命名。每种故障都需要对应的解决方案，而团队通常只注意到那些给他们带来麻烦的故障。
评分模型漂移。任何具有语义意义的内容都倾向于由大型语言模型来评分，因为基于规则的检测无法判断“下周五”是否已被转换为正确的日期。但评分模型本身也是模型，而模型会不断变化。那些长期使用相同评分系统的团队常常会发现整个回归分析仪表板在一夜之间出现异常，他们需要花费一整天的时间进行排查，最终才发现分数变化是因为评分模型升级了，而非智能体性能变差了。固定评分模型版本和评分规则哈希值虽能减轻这一问题，但无法彻底解决它，因为托管的评分模型端点仍在不断变动。
结果谬误。仅依据最终状态进行评分会忽略整个执行过程中的重要环节。某个智能体可能会调用错误的工具，四次重复发送同样的错误参数，但最终仍可能因运气或坚持而得到正确答案，而只读取最终结果的评估系统会将其判定为通过。
内部故障模式。BFCL或tau-bench之类的公开基准测试有助于比较模型性能，但它们无法发现存在于团队内部工具注册表中的故障：可选字段中的空值、日期参数中的时区错误、金额字段中的货币不匹配等问题。这类故障属于该团队的工具范畴，永远不会出现在通用排行榜上。如果覆盖率完全依赖公开基准测试，那么验证工具就会在最关键的地方视而不见，即那些尚未经过其他人测试的系统部分。
成本盲点。这是最少被讨论，却可能最具决定性影响的因素。评估工具可能会在所有考核维度上都认为某个智能体表现准确，却从不考虑它是否能够自行盈利。有一个著名的案例：某个智能体满足了十二项质量指标，但仍被从实际应用中撤下，因为每解决一个问题所需的成本都高于它本应替代的人工处理方式。质量评分确实是准确的，但恰恰因为缺乏衡量“成本”这一关键因素的指标，才导致了它的失败。
评分完美却失败的预订智能体
想象一下，有位预订代理被要求为“下周五”查找航班。它在包含数十种工具的注册表中选出合适的工具，因此工具选择环节获得了完美的1.0分。接着，它直接将日期作为字符串发送，而没有先解析其中的相对表达式。API返回了验证错误，该代理又四次发送了同样的错误字符串，最终才道歉并退出。
这次追踪得出了两个数值：工具选择环节得分为1.0，任务完成环节得分为0。但这两个数值都无法表明究竟是哪三种问题中的哪一种出了错：是参数提取有误，还是代理从未读取到错误响应，又或是重试逻辑在输入未改变的情况下不断循环。对工具调用评估的详细分析表明，仅检查是否调用了正确的工具是在测试意图而非实际执行情况，而失败的根本原因并非意图问题。
这正是问题的缩影。该测试套件输出了两个数值，虽然都不是完全错误，但对于那个至关重要的问题——究竟该修复什么——却毫无用处。
有益的实践
一旦将测试套件视为需要独立质量检测的系统，成熟的体系就会呈现不同面貌。有一些习惯能帮助团队及早发现问题，而避免日后痛苦地才发现：
- 独立的元评估层。在正式部署中，工作会分为结果评估、对每个步骤的评估，以及一个用于相互校验评估结果的层，这样就不会轻信任何单一评估者的得分。
针对现有测试套件的四项改进措施
对于拥有评估工具集且希望对其加以验证而非仅凭信任的团队而言，以下四个步骤就能缩小大部分差距：
- 选取该工具集标记为通过的十到二十条实际运行轨迹，手动查看每条轨迹的完整过程，而不仅仅是最终结果。其中有多少次通过实际上隐藏了流程缺陷，正是衡量该绿色仪表板可信度的真实标准。
- 固定评分模型版本及评分标准文本，并将二者与每个分数一同记录下来，这样评分模型的无声升级就会以明确标注的事件形式呈现，而非变成难以理解的性能退化。
- 从第一天起就开始记录每次成功评估的成本，即便在还无人提出要求之前。
- 利用真实的实际运行故障而非仅合成案例来构建小型回归测试集。公共基准数据可以设定最低标准，而团队自身的故障历史则能预测下一次可能出现的尴尬故障。
这些都无法替代完整的测试套件。它们只是不再将该套件视为过于重要而无法仔细检查的单一组件。
快速解答
对智能体而言，评估套件验证意味着什么？它会对评估系统施加与系统对智能体所用的相同严格标准，检查评分标准、评分规则及评分流程是否仍能准确反映其宣称的评估内容。
为何以大语言模型作为评分者的方式会导致评分偏差？评分者本身也是一个模型。当其提供方更新该模型或更换为更新版本时，即便被评估的智能体没有变化，评分也可能会随之改变。
公共基准测试能否替代自定义测试套件？不能。它们有助于比较模型在常见任务上的表现，但无法发现源于团队自身工具、数据或特殊场景的缺陷。
高通过率就足以让某个智能体持续投入生产吗？ 并非如此。即使某个智能体的准确率和任务执行质量都很高，但如果每次成功处理任务的成本无法与其带来的价值相匹配，它仍可能被淘汰。
该测试套件应多久审查或重新构建一次？ 需要随着生产环境的流量变化而持续进行。由于实际使用场景会偏离最初的测试数据集，因此需要定期补充来自真实故障案例的测试数据，而不仅仅在系统上线时一次。
仪表板背后的理念
评估套件并不能证明某个智能体真的能正常工作。它只是由构建者所定义的“正常工作”的含义，由可能标准会变化的评估者根据测试集进行评分，而该测试集从编写之初就开始逐渐过时。如果人们轻易将这种定义视为绝对正确，那些在仪表板上表现完美的智能体实际上仍可能无法通过真正重要的测试。正如上文所述，只需手动审查十个测试案例，就能很快发现仪表板究竟隐藏了多少问题。
相关阅读
- 利用旅行机器人进行智能体评估：结果与路径、门控机制及pass^k算法 —— 一个用于评估智能体的实际旅行预订案例：结果轴与路径轴、加权得分前的确定性门控、2x2矩阵以及pass@k与pass^k算法的对比。