大模型评测刷榜之后：如何理性看待AGI宣言

每当新一代大模型发布，技术社区总会被一类叙事刷屏：某项公认困难的基准测试，上一代模型得分不足一成，新一代直接跃升到六成以上；换用厂商自适配的评测框架后，分数更是逼近满分；高难度数学评测跑到98%，安全攻防类评测干脆拿到100%。于是，“AGI时代来了”的论断再一次被推上热搜。

作为工程师，比起情绪化的惊叹或嘲讽，更有价值的问题是：这些数字究竟在测量什么？哪些结论可以直接采信，哪些需要打折扣？“基准被打满”与“AGI到来”之间，到底还隔着多少环节？本文尝试从评测方法论的角度，把这件事拆开讲清楚。

一、同一模型、两套分数：评测框架是被低估的变量

很多讨论默认“分数=能力”，但严格来说，模型对外呈现的能力 = 模型本身 × 评测框架。评测框架（俗称 harness）决定了：模型在每一步能看到什么观测、历史信息如何组织、是否保留中间推理、重试与工具调用如何编排、终止条件与计分规则是什么。

举个示意性的例子（数字仅为说明用）：同一模型，在标准框架下每一步只拿到当前观测、不保留历史，得分 62.7%；在自适配框架下保留完整轨迹与推理上下文，得分 99.9%；而上一代模型在标准框架下只有 7.8%。用伪代码表达这两种差异：

# 示意：同一模型在两种评测框架下的行为差异
def run_blind(model, env):
    """标准框架：单步观测，无历史记忆"""
    obs, done = env.reset()
    while not done:
        action = model.decide(obs)            # 只看当前帧
        obs, reward, done = env.step(action)
    return reward
def run_with_memory(model, env):
    """自适配框架：保留完整轨迹与推理上下文"""
    obs, done = env.reset()
    trajectory = []
    while not done:
        thought = model.reason(trajectory + [obs])   # 带记忆推理
        action = parse_action(thought)
        obs, reward, done = env.step(action)
        trajectory.append((obs, thought, action))
    return reward

对于交互式任务，这两种设置几乎是两场不同难度的考试：前者要求模型“一眼看出答案”，后者允许模型“边试边学”，分数差异巨大并不奇怪。这给我们的第一个启示是：任何评测结论都必须绑定明确的评测条件才有意义。企业在做模型选型时，尤其要警惕把不同框架下的分数直接横向比较。

二、基准饱和：分数逼近100%之后发生了什么

当一家模型厂商公开宣称某项基准“已经进入饱和状态”，这句话包含两层信息：其一，新模型确实在这项基准上大幅超越了前代；其二，这项基准作为“标尺”的历史使命基本结束了。

基准测试的核心价值在于区分度。假设某项评测上，上一代模型得 78.5%、新一代得 100%，人们能得出“新模型更强”的结论；但下一代模型即便真实能力再提升一倍，也只能得到 100 分——此时分数与能力脱钩，基准失去区分度。

饱和通常由三种因素叠加造成：

1. 任务覆盖面有限：基准题库的规模与多样性有限，能力天花板就是 100%；
2. 数据污染风险：公开基准的题目可能混入训练语料，“背题”与“解题”难以区分；
3. 真实能力提升：模型确实变强了。

三者往往同时存在，比例难以精确切分。这正是评测社区会不断推出更难版本、引入动态题库与私有测试集、用人类专家成绩做锚点校准的原因。从古德哈特定律的视角看：“当一项度量成为目标，它就不再是好的度量。”基准被打满，与其说是“考试结束”，不如说是“出题人该干活了”。

三、三类典型评测分别测什么

结合近年主流评测的演进，可以把刷屏的三类分数还原为三种能力指向：

1. 抽象推理与持续学习类。这类评测通常把模型放进一个陌生的交互式环境（规则未知、反馈稀疏），考察它能否在解决问题的过程中归纳规则、持续学习。它测的不是知识记忆，而是面对新任务的泛化能力与样本效率，因此常被视为与“通用智能”关系最密切的一类信号。也正因如此，它的分数跃迁才格外引人注目——但同样要区分“有记忆的框架”与“无记忆的框架”（见第一节）。

2. 高难度前沿数学类。这类评测由领域专家参与出题、按难度分级，要求模型完成多步严格推理与长链路规划。在最难档位拿到 98%、接近跑满，说明模型的深度推理能力确实上了一个台阶；但要注意，“解出数学题”与“在真实科研中提出正确猜想”之间仍有距离，后者还涉及问题定义、实验设计与结果可验证性。

3. 安全攻防与漏洞利用类。这类评测考察模型发现并利用系统漏洞的能力，天然是双刃剑：一方面，它反映了模型在代码理解与逻辑分析上的极限能力，可服务于红队测试与防御加固；另一方面，满分成绩也提醒我们，模型的攻击面能力正在快速逼近专家水平，企业必须同步建设安全策略——权限最小化、输出审计、沙箱隔离、常态化红队演练，而不能只把它当“更聪明的助手”。

四、从“答对题目”到“可靠干活”：AGI宣称的距离

“AGI”并没有公认定义。能力派认为它应通过人类可完成的所有认知测试；经济派认为它应能以显著成本优势完成大部分有经济价值的工作；行为派则强调在开放环境中长期自主运行的可靠性。基准分数主要支撑第一派的论据，而企业与用户真正关心的是后两派的标准。

根本原因在于：基准是窄域采样，真实工作是长尾分布。一道题的输入是干净的，真实业务的输入是脏的——需求模糊、数据缺失、上下游系统不稳定、异常路径远多于正常路径。一次跑对和稳定跑对之间，隔着方差控制、失败模式分析、可观测性与可回滚性等大量工程问题。

给出一份理性检查清单，用于判断“AGI 宣言”的成色：

• 分数是在什么评测框架、什么提示词、几次重复下取得的？方差多大？
• 基准是否公开？是否存在数据污染的可能？
• 换到与你业务相近的任务上，成绩还剩多少？
• 模型失败时如何表现：静默出错，还是可检测、可恢复？
• 单位成本与延迟是否支撑它在生产环境大规模使用？

五、开发者与企业如何构建自己的评测体系

对外部刷榜，合理的姿态是“当参考系，不当决策依据”。真正决定选型的，是自有评测。建议按以下方式落地：

1. 分层构建评测集：

• L1 能力级：单点能力，如格式化抽取、函数调用、短文本推理，用精确匹配或单元测试断言；
• L2 任务级：完整工作流，如多步文档处理、跨系统信息聚合，用步骤完成率与人工抽检衡量；
• L3 业务级：端到端场景，绑定真实业务指标（解决率、返工率、时延 SLA）。

一个最小可用的评测样例结构：

{
  "task_id": "case-0001",
  "layer": "L2",
  "capability": "多步表格推理",
  "input": "（脱敏后的真实业务样例）",
  "expected": "（期望输出或断言脚本）",
  "scoring": "exact_match + 关键字段校验",
  "notes": "覆盖边界条件与历史失败案例"
}

1. 固定评测条件并纳入版本管理。提示词模板、解码参数、评测框架版本都应锁定，否则模型升级带来的分数变化无法归因。

2. 看分布，不只看均分。均分相同的两个模型，失败模式可能完全不同；重点分析失败案例的聚类，判断问题出在模型能力还是工程链路。

3. 善用云上现成能力。以百度智能云为代表的大模型服务平台，一般会提供数据集管理、自动化评测、灰度发布与监控告警等通用能力，可以直接复用，避免从零自建评测流水线；关键是在接入前，先用自己的评测集跑一轮基线。

4. 安全评测先行。把越权操作、提示注入、数据泄露等安全用例纳入常规回归，而不是等出事后再补。

结语

评测分数的跃升，是真实且值得尊重的技术进步信号；但“打满三项基准”与“AGI 时代到来”之间，仍隔着评测框架的差异、任务覆盖的窄宽、可靠性与经济性的验证等多重距离。对工程师来说，比追问“AGI 到底来没来”更有生产力的问题是：它在我的场景里，能不能稳定地、可验证地、安全地把活干好。把评测这件事做扎实，答案自然会浮现。