超越基准：AI 评估体系的五大支柱

August 25, 202611 分钟阅读Artificial intelligence

随着 AI 智能体从演示阶段进入生产环境，各团队发现：仅靠基准测试分数几乎无法转化为业务价值。常见情况是：新的前沿模型发布后，在基准测试排行榜上名列前茅，投入生产环境后，业务指标和代码迭代效率却毫无起色。我们提出五大原则，用于在标准模型基准测试之外评估智能体。

全新软件时代需要全新的正确性概念

迈入软件 3.0 时代后，我们对软件“正确性”的定义必须随之改变。

软件 1.0（代码即软件）：开启数字时代。正确性的判定简单直接，因为代码明确定义了每一处细节。

软件 2.0（模型即软件）：先进计算机视觉和聊天机器人。正确性转变为由数据和模型设计确定的统计指标。

软件 3.0（提示词即软件）： 改变了人类与机器的交互方式。但是，我们仍然缺乏对正确性的明确定义。对正确性的定义正是释放其真正价值的关键。

软件 3.0 存在两个主要痛点：

验证瓶颈： 我们构建出的机器生成解决方案的速度快于我们评估这些解决方案的速度⁷。如今，该领域的进展取决于我们构建验证器的能力。

递归信任问题：使用大语言模型（LLM）评估 LLM 会产生递归信任问题⁶。LLM 生成的评估器会继承它所评估 LLM 的所有问题。

尽管 AI 的第一阶段由研究人员主导取胜，但上述痛点表明，下一阶段属于那些能够为现实任务定义何为“好”的人⁹。

AI 评估体系的五大支柱

智能体评估体系可以分为五个不同的领域。

1. 您实际衡量的是什么？

您认为自己在衡量模型，但实际上衡量的是技术栈，其中包含三层波动来源⁵。

数据评估依托的对象	任务、基准真值、数据污染
模型所评估的对象	您认为要衡量的对象
评估框架评估执行方式	提示词格式、工具调用、预算上限、采样温度、引导策略

数据和评估框架配置的差异可能超过模型之间的差异。

评估框架主导效应：在许多现代基准测试中，评估框架造成的排名波动甚至超过更换底层模型带来的影响²。Brand 指出，命令行界面（CLI）评估框架会彻底颠覆标准化的最先进（SOTA）结果：同一模型，评估框架不同，分数截然不同²。

即使评估框架保持不变，数据本身也可能导致结果失真。基准真值是一种主张，而不是事实。它可能出错、存在数据污染或者已经过时。基于错误的基准真值，只能得出看似精准实则错误的结论。评估框架与数据的影响相叠加，催生了第三个问题：引导。模型的评估分数是其能力的下限，绝非上限。

2. 除了输出之外，还应该评估什么？

评估检查的对象。 Lee 指出了五个层面：大多数团队只涉及第一个⁴。

	层面	问题	证据
1	输出	任务成功了吗？	最终工件、测试结果、数据库（DB）状态
2	追踪记录	如何得到该结果？	工具调用顺序、推理步骤、被忽略的错误
3	记忆	存储的状态有益还是有害？	记忆读取/写入、回合之间的行为偏差
4	环境	状态变更是否正确？	文件系统偏差、数据库变更、发起的 API 调用
5	机制	内部发生了什么？	注意力模式、内部表示

正确的输出可能会掩盖存在缺陷的推理过程。设想一个编程智能体，任务是修复失败的测试用例。它查询文档 API，收到 404 错误，但没有重试或上报错误，而是基于训练数据生成了看似合理的补丁。测试虽然通过了，但这只是因为修复掩盖了表象，并未解决根本问题。输出评估判定为“通过”。但追踪记录显示，智能体根本没有读取相关文档，而是凭空编造了修复方案。如果没有多层面评估覆盖，就会存在巨大评估盲区⁴。

这个问题不仅限于智能体的输出，还延伸到它所涉及的系统。智能体会更改其所处的环境。如果评估只捕获最终状态，而不记录每一步的状态变更，就无法将失败归因于特定操作。变更记录是证据，最终状态只是结论⁴。

3. 可重现的评估需要哪些基础架构？

由您掌控的评估基础架构⁴。

控制平面	数据平面
决定执行哪些任务	运行智能体
选择用例、变体、模型	记录发生的一切
解读结果	捕获追踪记录、状态变更
确定是否上线	管理试验隔离
管理实验元数据	处理检查点

智能体不需要数据集，它们需要的是环境⁴。智能体需要独立的文件系统和数据库快照。实验绝不能共享可变状态。数据平面是工程层面更棘手的难题，因为它必须提供可重现、相互隔离、可观测的环境。

只有每次试验都从干净状态开始，提供这些环境才有意义。如果没有试验隔离，您衡量的就是基础架构干扰所造成的结果，而不是智能体的能力¹。Anthropic 发现，Claude 会利用之前试验中的 Git 历史记录¹。运行之间的共享状态会引发关联性失败，污染结果。每次测试运行都需要完全干净的环境。|

4. 您应该针对哪些指标进行优化？

根据您的目标，可以用四个不同指标定义成功标准。 ^1、3、7

维度	问题	公式	适用场景
能力	是否有可能完成任务？	真/假	一次成功即可体现价值的工具
稳定性	是否总能完成任务？	(pass_rate)^k	可靠性至关重要的智能体
效率	能否在资源预算内完成任务？	质量/成本	生产环境部署决策
可验证性	验证任务是否完成的难度如何？	（人工验证成本）	确定强化学习训练的可行性

验证者法则：训练 AI 完成某项任务的难易程度与该任务的可验证性成正比。现实中的任务之所以进展缓慢，是因为不存在能够验证“是否有用”的简易验证器。该领域的进步不在于模型能力，而在于我们构建验证器的能力⁷。

软件领域也存在这一规律。由于单元测试极易验证，新的离散功能会迅速生成，而那些需要根本性架构更改的总体目标却没有得到解决。最终结果是：更多 PR 被提交，维护人员被审查工作压得不堪重负，真正的目标却未能达成。另一方面，设计更优良的软件会形成飞轮效应。设计一致、遵循原则的代码库可以让新的离散功能在架构上尽可能合理。相比于充斥着权宜之计和临时补丁的代码库，这类代码库可以从智能体身上获得高得多的价值。

可验证性决定改进是否具备可行性；成本决定改进是否具备实用性。如果不考虑成本，准确性就毫无意义³。许多“SOTA”结果明显偏向于能力，忽略成本。对成本和准确性进行联合优化可以大幅降低成本，同时将对准确性的影响降至最低。3

5. 如何持续进行改进？

改进是一种迭代反馈循环，通常称为评估驱动开发（EDD）周期⁸。

1. 错误分析（观察）：查看追踪记录日志，了解简单的通过或失败结果。

2. 提出假设（诊断）：为失败模式找出明确、可验证的原因。

3. 实验（测试）：每次更改一个变量。

4. 衡量（验证）：衡量结果。

5. 标准演进（适应）：发现新问题后，更新评分规则，然后回到第 1 步⁶。

标准偏差： 您无法在评分之前编写评分准则⁶。标准取决于观察到的输出，您需要根据标准来评分，但评分过程反过来又有助于定义标准。这不是错误，而是评估开放式系统的固有特性。评估体系必须适应评分准则的迭代演进，不能预设评分准则固定不变。

这个循环只有在团队坚持持续执行的情况下才有效。将科学方法应用于 AI 产品是真正的差异化优势，持续坚持采样、标注、实验和监控比任何评估工具都更重要。在实践中，这套方法是分阶段发展成熟的：首先为发现的错误编写评估器，待失败模式趋于稳定后，再推进到评估驱动开发。

弥合基准测试与生产环境之间的差距

现在，我们可以从五大支柱的视角，重新审视软件 3.0 的两大痛点。递归信任问题可通过第二支柱和第三支柱缓解：确保不单独依赖单个评估器或共享状态。第四支柱和第五支柱用于攻克验证瓶颈，将验证器构建视作核心工程难题，而非事后补救措施。基准测试表现与实际业务价值之间的差距并非模型本身的问题，而是评估层面的问题。要想弥合这一差距，需要将评估视为一门一流的工程学科。那些能够内化这一理念的企业，将交付更可靠、更具成本效益的智能体系统；其余企业则更可能构建出令人印象深刻的演示，但一到生产环境就会失败。

大规模构建生产就绪型智能体系统

将 AI 智能体从原型推向生产环境需要强大的数据平面隔离、多层面评估，以及可靠的集群级治理。了解红帽 OpenShift AI 如何提供企业级基础架构，支持在混合云中测试、评估和扩展值得信赖的 LLM 应用。要在管道中原生实施 EDD，请了解 EvalHub 如何跨红帽 OpenShift 集群编排多框架 LLM 评估作业。