大模型评测范式之变：从知识答题到任务执行

一、一个反直觉的“发布季现象”

每当新一代旗舰大模型集中亮相，技术社区总会重复相似的剧情：各家实验室接连放出新版本，跑分榜随之更新，然后是一片“分数怎么没涨”的质疑。有第三方评测机构给出的对比颇具代表性：某新一代旗舰模型与其上一代在综合智力类基准上的得分几乎完全一致，甚至不比同期其他竞品更高；但换到自动化任务、终端环境科学实验、代码安全审计等执行型基准上，任务完成率出现了成倍提升，部分高难度抽象推理任务甚至接近满分。

同一批模型，两套基准，两条完全不同的曲线。这个反差比分数本身更值得琢磨：它说明大模型的能力重心正在迁移，也说明我们习惯了多年的那套评测尺子正在钝化。

二、传统基准为什么“钝化”了

传统智力类基准通常测三件事：知识记忆、单轮推理、静态作答。这类基准在设计之初确实有效，但走到今天暴露出三个结构性问题：

1. 考核目标偏静态。 题目给出完整上下文，要求一次性输出答案，不涉及环境交互、工具使用与多轮纠偏。它衡量的是“知道什么”，而不是“能做成什么”。
2. 数据饱和与污染。 高质量题目长期公开，训练语料难免覆盖到相似内容，榜单分数的水分越来越难挤干，提升的边际收益递减。
3. 区分度衰减。 头部模型普遍进入高分区间，一两分的波动不具备统计意义，却容易被营销叙事放大成“代际差距”。

换句话说，综合智力分持平，并不等于模型没有进步，只说明这把尺子已经量不出新增的那部分能力。

三、执行型基准到底在测什么

执行型基准的题面通常只有一句目标，例如“在这个代码仓库里修复缺陷并让测试全部通过”“完成一份数据分析报告”“在终端环境里完成一组实验操作”。要拿到分数，模型必须独立走完一整条链路：

• 任务拆解：把模糊目标分解成有序、可执行的子步骤；
• 工具调用：操作命令行、编辑文件、执行测试、检索资料；
• 反馈闭环：读取执行结果，判断成败，出错后定位原因并重试；
• 长程稳定性：几十步操作之后仍然不偏离原始目标；
• 结果导向评分：以“任务是否真正完成”计分，而非“回答是否像人写的”。

需要特别说明的是安全类任务：此类评测应在完全隔离的沙箱中进行，题目设计应服务于漏洞分析、代码加固、防御性审计等正当工程场景，评测结果反映的是模型在安全工作中的辅助能力，而不应被理解为对攻击性行为的鼓励。

四、从“知道”到“做到”：能力结构的三点变化

为什么执行型基准上会出现“换了一个物种”式的跃迁？从公开的技术趋势看，至少有三点原因：

1. 测试时算力的可控分配。 新一代模型普遍支持推理深度的分级调节：在复杂任务上允许模型“多想一会儿”，用更长的思考过程换取规划质量；在简单请求上则保持低时延。静态智力题对深推理的收益有限，而多步执行任务对此极为敏感。
2. 状态与上下文的长期维护。 长任务的真实瓶颈往往不是单步智商，而是执行几十步之后是否还记得最初目标、能否持续维护计划清单与中间产物。
3. 自我校验成为默认习惯。 高完成率的模型会主动跑测试、复查输出、验证前提条件，“先验证再交差”显著降低了表面完成、实际失败的比例。

五、开发者如何搭建自己的评测体系

公开榜单只能作为初筛，真正的选型依据必须来自贴近业务的任务集。一个可落地的最小框架如下：

EVAL_TASKS = [
    {
        "id": "fix-broken-pipeline",
        "sandbox": "container",            # 隔离环境，防止副作用
        "goal": "修复数据处理脚本并让单元测试全部通过",
        "tools": ["shell", "file_edit", "run_tests"],
        "max_steps": 30,
        "timeout_sec": 600,
        "weights": {"result": 0.6, "efficiency": 0.2, "stability": 0.2},
    },
    # ... 更多从真实工单中抽取的任务
]
def run_eval(model_client, tasks):
    report = []
    for t in tasks:
        traj = agent.run(model_client, t)      # 在沙箱内执行完整轨迹
        score = (
            t["weights"]["result"]     * traj.result_passed +
            t["weights"]["efficiency"] * traj.efficiency_score +
            t["weights"]["stability"]  * traj.stability_score
        )
        report.append({"task": t["id"], "score": score, "steps": traj.steps})
    return aggregate(report)   # 汇总任务完成率、平均步数、失败原因分布

配套三条工程原则：

• 多任务、多轮次：每个任务至少重复若干次，取完成率分布而非单次最好成绩；Agent能力的方差本身就是重要的稳定性指标。
• 过程与结果双维度打分：结果正确性权重最高，同时记录步数效率、工具调用错误率、超时率，用于成本与稳定性归因。
• 轨迹留存：将每条执行轨迹写入日志服务并支持回放，失败案例是迭代提示词与工具设计的最好素材。

六、企业选型：把“能不能做完”写进评估标准

对企业而言，模型选型应当按场景分层：

• 问答与检索类应用：知识类基准仍有参考价值，重点考察事实准确性与引用可靠性；
• 流程自动化、研发提效、数据分析类应用：必须以执行型评测为准，关注任务完成率、平均耗时与单位任务成本。

工程底座上，可以依托百度智能云等云平台的容器服务搭建隔离评测沙箱，用对象存储保存任务定义与执行轨迹，用日志服务做失败归因，用监控告警盯住评测任务的时延与失败率——这些通用云能力的组合，足以支撑一套可长期运行的回归评测流水线。每当候选模型版本更新，重跑同一任务集，即可量化“这次升级对我的业务到底有没有用”。

同时要警惕成本结构的变化：执行型任务的推理消耗远高于单轮问答，一个三十步的Agent任务可能抵得上上百次问答的开销。评测时应把“每成功任务的平均成本”作为一等指标，才能避免“完成率上去了、账单也上去了”的尴尬。

七、结语

榜单分数的停滞，不是能力的停滞，而是评测维度的切换。行业正在从“答对了吗”走向“做完了吗”，开发者和企业的评估重心也应随之迁移：以真实任务集为尺，以任务完成率为纲，以稳定性和成本为界。谁能尽早建立这套面向执行的评测体系，谁就能在下一轮模型迭代中，更快地把能力红利兑换成业务价值。