如何科学评价新一代通用智能模型的能力

每当新一代大模型发布，“它是不是目前最聪明的模型”“通用人工智能是否已经实现”都会成为讨论焦点。然而，从工程视角看，这类问题不能依赖发布方口径、少数排行榜或几个令人惊艳的演示来回答。

模型能力是一个多维概念。知识问答得分高，不代表它能稳定修改大型代码库；能够操作桌面应用，也不代表它具备可靠的长期规划能力；在安全测试中发现更多缺陷，更不能直接等同于可以安全部署。要严谨评价一款新模型，必须拆解“智能”的具体含义，并同时考察能力、效率、可靠性和风险。

一、“最智能”首先需要明确评价对象

所谓模型智能，至少可以拆分为以下几个维度：

1. 知识与理解能力
   包括事实检索、文本理解、概念归纳、跨领域知识迁移等。该维度主要回答模型“知道多少”以及“能否理解问题”。

2. 逻辑与推理能力
   包括数学推导、因果分析、多约束决策和复杂问题分解。它反映模型能否在信息不完整或约束较多的情况下形成合理结论。

3. 任务执行能力
   指模型能否调用外部能力、操作应用界面、读写文件，并把一个目标转化为连续动作。它解决的是模型“能不能把事情真正做完”。

4. 智能编程能力
   不仅包括生成代码，还包括理解现有工程、定位缺陷、修改多个文件、执行测试、分析失败原因和迭代修复。

5. 可靠性与可控性
   包括输出一致性、事实准确率、指令遵循程度、权限边界和异常恢复能力。企业应用中，这一维度往往比峰值能力更重要。

6. 效率与成本
   包括响应时延、任务完成时间、计算资源消耗、调用次数，以及人工复核和失败重试带来的隐性成本。

因此，“综合得分最高”和“最适合生产环境”并不是同一个命题。某个模型可能在通用推理中略逊一筹，却因为工具调用稳定、编程任务完成率高、操作步骤更短，而成为更优秀的工程执行模型。

二、为什么综合排行榜不能直接代表真实智能

综合能力指数通常会把多个测试集的结果加权汇总。其基本形式可以表示为：

[
Score=\sum_{i=1}^{n}w_i \times s_i
]

其中，(s_i) 是模型在第 (i) 类任务中的归一化得分，(w_i) 是该任务的权重。

这个公式看似客观，但存在三个关键问题。

1. 权重选择带有明显主观性

如果数学推理权重较高，擅长复杂推导的模型会占优势；如果桌面操作、代码维护和工具调用权重较高，行动型模型则可能领先。综合分数实际上隐含了评价者对“智能”的定义。

企业不能直接照搬公开榜单的权重，而应根据自身业务重新设定。例如，研发团队可以提高代码修改和自动化测试的权重，客服场景则更重视知识准确性、语言一致性和合规性。

2. 静态题目与动态任务差异巨大

传统评测通常给出一个固定问题，要求模型输出答案。真实工作任务却往往包含以下过程：

• 读取多个文件或页面；
• 识别目标与约束；
• 制订执行计划；
• 调用工具完成操作；
• 检查中间结果；
• 遇到异常后重新规划；
• 最终交付可验证结果。

静态测试衡量的是“答对一道题”，动态任务衡量的则是“完成一项工作”。两者相关，但不能互相替代。

3. 公开测试可能存在数据污染

如果测试题或相似样本曾出现在训练数据中，模型可能依靠记忆获得较高成绩。更可靠的方法是使用内部构造、持续更新并且严格隔离的测试任务，同时记录完整执行轨迹，而不是只看最终答案。

三、智能编程应评价完整闭环，而非代码片段

判断模型是否具备较强的开发能力，不能只测试“根据描述生成一个函数”。真实软件工程通常涉及大型上下文、多文件依赖、历史约束和复杂测试环境。

一套完整的智能编程评测至少应包含以下环节：

1. 代码库理解

模型需要识别项目结构、模块依赖、核心入口和测试范围。若模型只根据局部文件直接修改，很容易引入跨模块回归问题。

2. 缺陷定位

高质量模型应先根据报错日志、调用关系和输入条件建立假设，再通过检索代码或运行测试验证，而不是盲目修改。

3. 多文件协同修改

真实需求经常同时影响业务逻辑、数据结构、配置文件和测试用例。评测时应考察模型能否维护接口一致性，避免只修复表面现象。

4. 测试与迭代

生成代码并不等于任务结束。模型应主动执行测试、读取失败信息、修正实现，并在完成后总结修改范围和潜在风险。

可以使用如下指标评价编程任务：

[
ProgrammingQuality =
CompletionRate \times TestPassRate \times RegressionSafety
]

其中：

• CompletionRate 表示任务是否完整完成；
• TestPassRate 表示新增和原有测试的通过比例；
• RegressionSafety 表示修改是否引入新的缺陷。

此外，还应统计平均尝试次数、无效修改比例、人工接管率和总耗时。一个需要反复重试十次的模型，即使最终成功，也未必比一次完成的模型更有生产价值。

四、计算机操作能力为何成为关键分水岭

计算机操作能力是判断模型能否从“对话系统”走向“任务执行系统”的重要指标。它要求模型理解视觉界面，并连续执行点击、输入、滚动、选择、上传和确认等动作。

这种能力比纯文本问答困难得多，原因主要有以下几点。

1. 界面状态持续变化

按钮位置、窗口大小、弹窗和加载状态都可能变化。模型不能简单记住固定坐标，而需要结合界面语义识别当前状态。

2. 长任务容易积累误差

一个任务可能包含几十个操作步骤。即使每一步的成功率达到较高水平，连续执行后的整体成功率仍会明显下降。

如果单步成功率为 (p)，任务包含 (n) 个相对独立的步骤，那么理想化的整体成功率约为：

[
P_{task}=p^n
]

这说明提高单步稳定性、减少冗余动作和增加状态校验都非常重要。

3. 错误恢复比首次成功更重要

真正可用的操作模型不能在遇到弹窗或页面变化后立即失败，而应具备以下能力：

• 判断当前界面是否符合预期；
• 识别上一步是否执行成功；
• 在必要时回退；
• 重新规划后续动作；
• 在高风险操作前请求确认。

因此，桌面操作评测不应只记录最终成功率，还要统计完成时间、动作数量、回退次数、误操作率和人工接管率。

五、评估执行型模型必须加入安全边界

模型越能操作真实系统，安全问题就越不能被视为附加项。具备文件读写、网络访问、代码执行和界面操作能力的模型，本质上获得了更大的行动范围。

生产环境至少应建立以下控制机制：

1. 最小权限

模型只能访问完成当前任务所必需的数据和功能。例如，读取报表不应默认获得删除文件的权限，生成代码也不应自动拥有生产发布权限。

2. 高风险动作确认

涉及数据删除、权限变更、资金操作、外部发送和生产环境修改时，应强制要求人工确认，不能由模型自主完成。

3. 全链路审计

系统需要记录模型看到的输入、制订的计划、调用的能力、操作结果和异常信息。没有完整日志，就难以复盘失败原因，也无法满足安全审计要求。

4. 隔离执行环境

代码运行、文件处理和网页访问应在隔离环境中进行，并限制网络、存储、进程和执行时长，避免错误操作影响核心系统。

5. 对抗性测试

安全评测不仅要测试模型能否完成正常任务，还应测试它面对诱导指令、恶意文档、越权请求和冲突指令时是否会突破边界。

需要强调的是，模型在受控漏洞识别任务中表现优秀，只能说明其具备较强的安全分析能力，不能直接证明它“更智能”或“更适合开放部署”。能力越强，越需要严格的权限设计和审计机制。

六、成本不能只看单次调用价格

一些模型为了获得更高质量，会执行更长时间的推理，或使用更多步骤完成任务。此时，仅比较输入输出量的单价容易得出错误结论。

更合理的指标是单位成功任务成本：

[
Cost_{success}=
\frac{ModelCost+ComputeCost+RetryCost+HumanCost}
{SuccessfulTasks}
]

其中包括：

• 模型调用费用；
• 外部执行环境的计算成本；
• 失败重试产生的额外消耗；
• 人工检查、修复和接管成本。

假设模型甲单次调用成本较低，但任务成功率只有60%，经常需要人工修复；模型乙单次调用略高，却能以更少步骤稳定完成任务。按单位成功任务计算，模型乙可能反而更便宜。

企业还应同时关注时延。对于实时客服、交互式编程等场景，数十秒的额外等待可能显著影响用户体验；对于离线分析和批量处理，则可以用更长时间换取更高准确率。

七、企业应如何建立自己的评测体系

公开测试适合了解模型的大致能力边界，但最终选型必须回到实际业务。建议按以下流程建设内部评测集。

第一步：收集真实任务

从历史工单、研发需求、运营流程和数据分析任务中提取具有代表性的案例。任务应覆盖简单、一般和困难三个等级，并包含常见异常情况。

第二步：定义成功标准

每个任务都应有明确、可自动或半自动验证的结果。例如：

• 代码是否通过测试；
• 文件是否生成且字段完整；
• 数据是否写入正确位置；
• 操作是否触发越权行为；
• 输出是否包含无法证实的信息。

第三步：统一运行条件

不同模型必须使用相同输入、权限、执行环境、时间限制和最大尝试次数。否则，比较结果没有意义。

第四步：记录过程指标

除了最终成功与否，还应记录：

• 首次成功率；
• 平均完成时长；
• 平均动作数；
• 重试次数；
• 人工接管率；
• 风险事件数；
• 单位成功任务成本。

第五步：多次重复测试

模型输出存在随机性，单次测试可能偶然成功或失败。关键任务应重复执行，并给出均值、波动范围和最差表现。

一个简化的评测逻辑可以表示为：

for 每个候选模型:
    for 每个业务任务:
        重复执行若干次
        记录是否完成
        记录运行时间与资源消耗
        记录工具调用和异常恢复过程
        检查安全规则是否被违反
    计算成功率、稳定性、成本和风险分
    按业务权重生成综合结果

推荐采用“门槛加权重”的方式，而不是只计算一个总分。例如，先要求安全违规率低于规定阈值、关键任务成功率达到上线标准，再比较成本和速度。这样可以避免模型凭借某些高分项掩盖不可接受的风险。

八、达到高分是否意味着通用人工智能已经到来

这个问题取决于如何定义通用人工智能。

如果定义是“在大量认知任务上达到较高水平，并能借助工具完成多步骤工作”，那么先进模型确实正在接近这一工程化标准。尤其是当模型可以理解需求、规划步骤、操作软件、编写代码并根据结果自我修正时，它已经不再只是文本生成系统。

但如果定义要求模型具备稳定的世界模型、长期自主目标、跨环境持续学习、可验证的因果理解，甚至自主意识，那么现有评测远不足以证明这些能力已经实现。

高分仍然可能掩盖以下局限：

• 面对轻微改写的问题时表现波动；
• 对罕见情境缺乏可靠判断；
• 长任务中逐步偏离原始目标；
• 无法稳定区分事实与合理猜测；
• 在工具返回异常结果时继续执行错误计划；
• 缺少持久、统一且可验证的内部认知状态。

因此，“在许多任务上超过普通人类表现”和“拥有类人的通用理解”是两个不同层次的结论。前者可以通过大量任务评测获得证据，后者则涉及更复杂的认知与哲学问题，不能仅靠排行榜宣布成立。

九、结论：真正重要的是能否稳定创造业务价值

评价新一代模型时，不应把注意力全部集中在“谁的综合分更高”。更有价值的问题是：

• 它能否完成真实而复杂的任务？
• 它的成功是否可重复？
• 失败后能否识别并恢复？
• 它需要多少时间、资源和人工监督？
• 它是否遵守权限和安全边界？
• 它在业务关键场景中的最差表现如何？

未来模型之间的差异，可能不再主要体现为知识问答分数，而会更多体现在智能编程、计算机操作、长期规划、工具协同和异常恢复上。换言之，竞争焦点正在从“谁更会回答”转向“谁更能可靠地完成工作”。

因此，一款模型即使没有拿到最高的综合智力分，也可能凭借更强的执行能力、更低的单位成功成本和更稳定的安全边界，成为更适合企业部署的选择。至于它是否应被称为通用人工智能，则必须先明确标准，再用透明、可复现、覆盖真实任务的证据进行判断，而不能由一次发布、几个演示或单一榜单决定。