专项99.9分、统一62.7分：大模型评测落差解析

一、一组耐人寻味的评测数据

近期公开的一组模型评测数据，再次把“评测分数与真实能力”这个老话题推到了台前：

• 在面向专属框架适配的评测中，某厂商新一代模型拿到了接近满分的 99.9 分；
• 而在统一标准的通用能力评测中，同一个模型的得分只有 62.7 分；
• 在计算机操作类任务上，其得分从上一代的 65.7% 提升到 72.6%；
• 在专业工作自动化任务上，得分从 18.1% 大幅提升至 41.4%，翻了一倍以上；
• 在另一项终端环境任务类基准中得分 57.9%，领先于同期参与对比的其他主流模型。

如果只看单点数字，结论似乎是“全面进步”；但把 99.9 与 62.7 并排放在一起，一个更本质的问题浮现出来：为什么同一个模型，在专属评测里近乎完美，换到统一口径下就明显掉队？这些公开分数，究竟有多少能代表所谓的 AGI 落地能力？

要回答这个问题，需要先理解评测落差背后的技术成因，再建立一套自己动手验证的能力评估方法。

二、评测落差从何而来：四个技术成因

2.1 评测数据污染与记忆效应

大多数公开基准的题目、用例和参考答案是可以在网络上获取的，而这些内容大概率会被爬取进下一代模型的训练语料。当模型“见过题”，它的高分反映的是记忆与复述能力，而不是泛化推理能力。这与学生刷熟了历年真题后模拟考接近满分、但换一套全新命题就掉分的情形同构。

行业里常见的应对手段包括：在评测集中植入唯一标识串以检测语料泄露、通过 n-gram 重叠率排查题目与训练文本的相似性、以及使用从未公开的私有 held-out 集做盲测。凡是没有做防污染设计的基准，其高分都应该打一个折扣来看。

2.2 针对性优化带来的过拟合

“专属框架 99.9 分”往往意味着：该评测所使用的接口约定、任务模板、环境构造方式，与模型在训练后期对齐阶段所优化的分布高度重合。通过面向特定任务分布的强化学习、微调和提示工程，模型可以在该分布内逼近上限——但这本质上是把能力窄化到了一个熟悉的域。

一旦切换到统一标准评测，任务分布更宽、环境更杂、判分更严，泛化短板就会立刻暴露。37 分的落差，恰恰量化了“域内适配”与“域外泛化”之间的距离。对企业用户而言，这反而是有价值的信息：它提醒我们， vendor 的最优分数通常代表“最佳工况”，而不是“平均工况”。

2.3 任务口径与分布差异

同样是“电脑操作能力”，在沙箱化的模拟环境里，界面元素规整、干扰项少、成功判据明确；而在真实桌面与浏览器环境里，弹窗、加载延迟、权限确认、界面改版等噪声因素会成倍增加任务难度。同理，“专业工作自动化”在专属评测中可能被拆成定义清晰的子步骤，而在统一基准中则要求模型自主完成规划、工具选择、错误恢复的完整链条。

因此，72.6% 与 41.4% 这两个数字之间并不存在可比性——它们度量的是不同难度层级、不同噪声水平下的表现。阅读评测报告时，任务构成和环境设定比总分本身更值得细看。

2.4 指标与评分协议不一致

分数背后是协议：是 pass@1 还是多次尝试取最优？允许几步重试？超时设多久？部分完成给不给分？判分是规则脚本、人工评审还是模型评审？这些设定的任何一处差异，都可能造成十个百分点级别的波动。跨模型、跨基准的分数对比，只有在“同一版本、同一环境、同一判分器”的前提下才成立。看到“57.9% 领先同类模型”这类结论时，合理的第一反应是追问对比协议是否对齐，而不是直接接受排名。

三、理性解读公开分数的四个视角

看相对提升，更要看绝对水位。 18.1% 到 41.4% 的翻倍式提升，说明自动化方向的能力确实在快速爬坡，代际间的工程投入是真实的；但绝对值仍不足一半，意味着大多数专业自动化任务尚无法无人值守交付。落地设计应默认“模型辅助 + 人工审核”的人机协同模式，而不是直接追求全自动。

看任务构成，而不只是总分。 去读评测集的用例列表、失败样例与评分脚本。一个模型在哪些子类任务上失分、失分原因是规划错误还是工具调用格式错误，这些信息对判断它与你的业务场景是否匹配，远比一个总分有用。

交叉验证，拒绝单一信源。 优先采信多个独立基准的一致性结论、第三方复现结果和动态更新的私有评测。对“仅在自家专属框架内接近满分”的现象保持警觉——它更可能反映适配深度，而非通用智能水平。

把分数当地图，而不是终点。 任何基准都只是模型能力的低维投影。AGI 落地的真正含金量，体现在你的目标任务上可复现的成功率、稳定性、单位成本与安全合规表现，而不是发布会上的一组峰值数字。

四、落地实践：搭建企业自己的评测体系

4.1 建设业务对齐的私有评测集

从真实工单、日志、代码变更记录中抽样并脱敏，构建覆盖“高频主路径 + 边界与长尾用例”的私有集，并定期增补换代，防止评测集自身被“背题”。私有集的规模不必大，几百条高质量、带明确判据的用例，价值远超数千条来源不明的公开题。

4.2 分层评估：从单步到端到端

• 单元级：单条指令、单次工具/函数调用的正确率与格式合规率；
• 任务级：端到端完成率、完成步数效率、异常恢复与回滚次数；
• 流程级：业务指标——人工修正率、返工率、端到端时延、单位任务成本。

分层的好处是能精确定位短板：是模型不会规划，还是工具接口描述不清，还是判分口径过严。

4.3 固化评测协议，做成自动化流水线

把温度、重试策略、超时、判分器全部固定并纳入版本管理，让每一次模型或提示词变更都能跑出可对比的回归基线。以下是一个极简评测框架的示意代码：

# 极简统一评测框架示意
import json, statistics
SUITE = {
    "computer_use":        load_cases("cases/computer_use.jsonl"),
    "workflow_automation": load_cases("cases/workflow.jsonl"),
    "terminal_tasks":      load_cases("cases/terminal.jsonl"),
}
def run_case(model, case):
    """固定协议执行单条用例：固定温度、重试次数与超时。"""
    traj = model.run(case.instruction, env=case.env,
                     temperature=0, max_retries=1, timeout_s=600)
    return judge.grade(case, traj)  # 统一判分器：0~1 分
def evaluate(model, suite=SUITE):
    report = {}
    for name, cases in suite.items():
        scores = [run_case(model, c) for c in cases]
        report[name] = {
            "n": len(cases),
            "mean": round(statistics.mean(scores), 3),
            "pass_rate": round(sum(s >= 1.0 for s in scores) / len(cases), 3),
        }
    return json.dumps(report, ensure_ascii=False, indent=2)

4.4 线上闭环：评测之外还要看真实流量

线下分数需要与线上指标互相校准：通过灰度发布与 A/B 对比观察真实成功率，用人工抽检校准判分口径，把用户负反馈回流为新的评测用例，并配合监控告警及时发现能力回退。主流云平台（如百度智能云）普遍提供模型服务、评估观测、日志与监控告警等通用能力，团队可以把主要精力集中在评测集建设与业务判分口径上，而不必从零自建推理调度与观测设施。

五、结语：分数是参考，体系才是底气

99.9 与 62.7 的落差并不是“造假”，而是当前评测方法学下的必然现象：专属评测度量的是域内适配上限，统一基准度量的是跨域泛化水位，两者本来就回答着不同的问题。真正决定 AGI 落地含金量的，既不是峰值分数，也不是叙事热度，而是模型在你的业务任务上、在统一且固定的评测协议下、经过真实流量验证的稳定成功率。

对开发者而言，评测工程应当被当作与提示工程、检索增强同等重要的基本功：先有自己的评测集和评测流水线，再看别人的分数，选型与迭代才不会随宣传起舞。分数会过时，体系才是长期资产。