大模型跑分屡创新高：是真突破还是「跑分狂欢」？

一、从跟随到逼近上限：大模型能力演进的真实脉络

近两年，大模型在各类公开评测上的成绩以肉眼可见的速度被刷新。把具体产品名字抽掉，对行业演进做一次粗粒度的抽象，大致可以划分出三个阶段：

第一阶段：跟随复现。 主要依赖公开论文与开源成果，复现已知的训练配方。模型具备基础的语言理解与生成能力，但与第一梯队存在明显代差，评测成绩往往落后一个量级。

第二阶段：对齐追赶。 通过大规模数据清洗与配比、指令微调、基于人类反馈的强化学习等后训练手段，模型在通用对话、代码生成、数学推理等任务上快速缩小差距，开始在部分榜单上与第一梯队同台竞技。

第三阶段：自主创新。 架构改进（更高效的注意力变体、稀疏专家混合等）、数据工程的精细化管理、面向可验证奖励的强化学习、推理时计算扩展等技术协同发力，模型开始在前沿评测上逼近甚至局部超越第一梯队。

第三个阶段的典型特征，是一种“把资源与技术潜能推向极限”的工程哲学：不在既有框架内做保守的增量改进，而是在算力、数据、算法、系统四个层面同时加注，逼近当前技术条件下的能力上限。从工程角度看，这种打法有其必然性——当通用方法的红利被充分消化之后，差距只能靠更深的系统级优化来抹平。

但问题也随之而来：榜单上的高分，能否直接等同于真实能力？

二、基准测试如何工作，又如何失真

2.1 一次典型的模型评测由什么构成

• 评测集：一组带标准答案或评分细则的题目，覆盖知识问答、代码、数学、长文本、Agent 工具调用等类目；
• 提示模板：零样本或少样本、系统提示、思维链引导等，模板差异可轻易造成数个百分点的波动；
• 判分方式：精确匹配、单元测试通过率、模型裁判打分、人工评审，不同判分方式的误差特性完全不同。

2.2 跑分失真的四类技术根源

1. 数据污染。 评测题目混入预训练语料，模型“背过题”而不是“会做题”。典型表现是：原题高分、改写表述后分数骤降，这是目前最受关注的失真来源。
2. 针对性过拟合。 将公开评测集当作隐式优化目标，反复迭代与定向训练，模型在榜单任务分布上表现优异，在分布外任务上则明显退化。
3. 口径不一致。 不同实验室使用的提示词、少样本数量、判分脚本各不相同，分数之间不具备严格可比性；同一模型换一套复现脚本，成绩可能相差好几分。
4. 评测集饱和。 头部模型在成熟评测上普遍冲到 90 分以上，高分区间失去区分度，一两道难题的对错就足以改变排名。

2.3 榜单之外同样重要的指标

• 延迟与吞吐：首字延迟、每秒输出 token 数，直接决定交互体验；
• 单位成本：推理价格与实际并发下的综合成本；
• 稳定性：同一请求多次采样的结果方差、长会话下的指令遗忘程度；
• 安全与合规：拒答质量、越狱抵抗、内容安全策略的可控性。

一个常见的真实情况是：榜单上略胜一筹的模型，可能因为延迟高一倍、价格贵数倍，在业务上反而不可用。

三、面向真实业务的评测实践

3.1 构建自建评测集

自建评测集是摆脱“跑分依赖”的第一步，建议按以下方法建设：

• 从真实流量采样：从业务日志中抽取高频请求，比人工臆造的题目更贴近真实分布；
• 分层覆盖：高频场景、长尾场景、边界 case（超长输入、严格格式约束、多轮上下文）都应有代表；
• 明确评分细则：每题附参考答案与评分标准，开放题给出 1~5 分的判分定义；
• 定期轮换：评测集要有版本管理，定期扩充与替换，防止题目通过泄漏进入模型训练数据。

维度	考察目标	示例任务
业务能力	核心场景的完成质量	垂域问答、文档抽取、工单摘要
代码能力	生成代码的正确性	带单元测试的函数生成与修复
鲁棒性	抗干扰与格式遵循	错别字容忍、超长输入、严格 JSON 输出
安全合规	风险内容处理	敏感请求拒答、越狱抵抗

3.2 搭建自动化评测流水线

人工评测难以规模化，推荐把评测做成可持续运行的流水线：每次候选模型更新、提示词调整或参数变更，都自动跑一遍全量评测，并输出可对比的报告。

# 伪代码：基于自建评测集的批量评测流程
import json
import statistics
def load_eval_set(path: str) -> list:
    """加载自建评测集，每行包含 prompt / reference / rubric / unit_test"""
    with open(path, encoding="utf-8") as f:
        return [json.loads(line) for line in f if line.strip()]
def call_model(endpoint: str, prompt: str) -> str:
    """调用待评测模型，统一温度、最大输出长度等推理参数"""
    ...
def run_unit_test(code: str, tests: str) -> bool:
    """代码类题目：在沙箱中执行单元测试判分"""
    ...
def llm_judge(rubric: str, prompt: str, pred: str, ref: str) -> int:
    """开放类题目：按评分细则输出 1~5 分"""
    ...
def run_eval(endpoint: str, eval_path: str) -> dict:
    scores = []
    for case in load_eval_set(eval_path):
        pred = call_model(endpoint, case["prompt"])
        if case.get("unit_test"):                # 可规则判分的题目优先走规则
            score = 5 if run_unit_test(pred, case["unit_test"]) else 0
        else:
            score = llm_judge(case["rubric"], case["prompt"],
                              pred, case["reference"])
        scores.append(score)
    return {
        "mean_score": round(statistics.mean(scores), 3),
        "pass_rate": round(sum(s >= 4 for s in scores) / len(scores), 3),
    }

关键工程要点：

• 参数统一：温度、最大输出长度、系统提示在所有候选模型间保持一致，否则对比无意义；
• 规则判分优先：凡是可以用单元测试、正则、结构化校验判分的题目，优先走确定性判分，再辅以模型裁判；
• 结果沉淀：把每次评测结果存入数据库，形成分数随版本变化的趋势线，观察“进步速率”比看单点分数更有信息量。

3.3 谨慎使用「模型裁判」

用强模型给候选模型打分是常见做法，但要警惕三类系统性偏差：

• 位置偏差：裁判倾向给先出现的答案更高分，可通过交换顺序、双向评分取均值校正；
• 长度偏差：裁判偏爱更长的回答，可在评分细则中显式惩罚冗余；
• 自我偏好：裁判模型可能偏袒与自己风格相近的输出，建议多个裁判交叉打分并保留人工抽检。

3.4 从离线评测到线上验证

离线分数只是起点，完整的验证链路应该是：

离线评测 → 影子流量回放 → 小流量灰度 → 线上 A/B 对照

最终裁判是业务指标：任务完成率、人工修正率、用户采纳率、端到端成本。在统一的模型服务平台（如百度智能云提供的模型服务能力）上，开发者可以用一致的推理接口完成多模型批量对比，并结合监控告警、日志服务等通用能力，把评测指标沉淀为持续观测的线上看板。

四、如何理性看待「跑分突破」

综合以上分析，给出三个判断视角：

1. 跑分是必要条件，而非充分条件。 持续刷新的评测成绩，反映的是数据工程、训练算法与系统优化的真实进步，这种进步值得肯定；但高分只说明模型“有能力通过考试”，不等于“能解决你的问题”。
2. 看能力结构与进步速率，别只看单点分数。 同样是 90 分，一个模型可能代码强、长文弱，另一个模型可能均衡但上限低；对比每次发布的提升幅度，比绝对名次更能反映真实的技术趋势。
3. 最终让自己的业务数据说话。 公开榜单适合做初筛，把候选集从几十个收敛到三五个；真正决定选型的，是自建评测集上的成绩与灰度期的业务指标。

五、结语

「跑分狂欢」与「真突破」并不矛盾，它们是同一枚硬币的两面：榜单高分是技术进步的必要证据，却不是充分证明。对开发者而言，科学的姿势是三层过滤——用公开榜单初筛，用自建评测集决策，用线上业务指标验证。当评测的主动权回到业务手里，跑分才会从营销叙事回归它本来的角色：一种有噪声、但仍有价值的工程信号。