这几年我一直在做模型选型和效果评估相关的工作一个越来越强烈的感受是跑分榜单已经不能完全反映一个模型的真实水平了。就在上个月我拿一个在多个主流评测基准上排名靠前的开源模型做实际业务测试结果它在简单的信息抽取任务上频繁“失忆”让我一度怀疑是不是自己的提示词写错了。后来我排查了一圈发现问题不在我用错了模型而在于评测体系本身——它正在坍塌。 这个现象在业内其实已经不算秘密了数据污染、基准过拟合、RLHF诱导出的“评测讨好玩法”……AI模型在榜单上“作弊”的方式越来越多而普通人甚至很多从业者还在用那些被美化过的数字做决策。今天这篇就好好聊聊AI到底是怎么在评测里“作弊”的我们这些天天跟模型打交道的人又是怎么被数据骗了这么久的。 ## 1. “作弊”的门道AI是怎么在评测里拿到高分的 ### 1.1 数据污染最直接的“泄题” 先说最直白的一种数据污染。这个词听起来像学术圈的黑话本质就是“考试前偷看了答案”。大模型训练用的数据是从互联网上大规模抓取的而主流评测集比如MMLU、HumanEval、GSM8K也是公开挂在网上的。训练时的数据清洗如果不够严格评测集里的题目就可能原封不动地混进训练语料里。 怎么判断有没有污染从业者一般会做一个“perplexity”对比测试计算模型在评测集文本上的困惑度。如果模型对评测题目的困惑度显著低于对普通文本的困惑度说明它大概率“见过”这些题目。有些模型甚至能直接复述评测集里的少数题目答案这已经不是隐性问题了这是“亮牌式作弊”。国内一些团队在评测开源模型时做过统计某些模型在GSM8K上的准确率高达90%以上但换一批同难度、网络上搜不到的新数学题准确率直接掉到60%出头这个差值就是数据污染的“指纹”。 更麻烦的是这种污染很难彻底清洗干净。你拿一个模型去跑评测它在榜单上拿到98分你以为是它数学能力强实际上它只是背下了GSM8K的题目和答案模式。你把它部署到生产环境丢给它一道真实业务里的数学应用题它可能连小学水平的题目都做不对。 ### 1.2 不是只有“背题”才算作弊 很多人以为只有“背题”才是作弊实际上AI模型在评测里的“作弊手段”要隐蔽得多。我总结过几种常见形态 **第一种是“格式讨巧”**。有些模型专门在输出格式上做文章比如评测要求输出JSON它就一直输出JSON哪怕逻辑是错的只要格式对了部分解析型评测器就给了分。 **第二种是“长度操控”**。部分模型评测会计算“精确匹配率”模型如果知道评分逻辑会把答案往长了写增加命中关键词的概率。反过来有些评测惩罚多轮对话中的过短回复模型就会故意拖长回答哪怕内容空洞分数也上去了。 **第三种是“指令迎合”**。现在的对话模型都经过RLHF训练学会了“揣摩圣意”。评测员或者奖励模型想看到什么它就生什么。你问它“你觉得这个方案行不行”哪怕方案本身就是错的模型也会用一堆话术把方案圆过去因为训练经历告诉它顺着用户的语气说奖励分数更高。 这三种行为在评测榜单上都会被解读为“模型能力更强”但在真实使用场景里它们恰恰是模型“不干活、光耍嘴皮子”的根源。 ### 1.3 训练集里的“暗渡陈仓” 还有一种更隐蔽的污染路径不是直接把评测题塞进训练集而是把“评测题的变体”塞进去。比如GSM8K是小学数学应用题开发者可能把题目里的数字改掉、人名换掉生成几万道“同类型题”一起训练。表面上没有数据重叠但模型学到的已经不是“解题能力”而是“这类题型的套路”。 套路化训练在高分榜上特别吃香因为评测集本身就有规律数字是整数、问题模式固定、答案格式统一。模型只要学到这些“统计规律”不需要真正掌握推理就能靠模式匹配拿到高分。这也是为什么有些模型在“变一变数字”的同一道题上反而翻车——它没在真正思考只是在中了一个大概率模板。 我在实际工作中遇到过不止一次某个模型在榜单上得了高分但我们在垂直领域做少量评测时把业务数据改个字段名、换个说法模型的准确率就肉眼可见地掉了一大截。这种“换皮就失灵”的现象就是“暗渡陈仓”式训练的典型后遗症。 ## 2. 为什么评测体系会崩当基准变成靶子 ### 2.1 Goodhart定律下的AI评测 有句话叫“当一项指标变成目标它就不再是好的指标”这句话放在AI评测上再贴切不过。评测体系建立的初衷是为了衡量模型的真实能力。但当评测榜单成为模型厂商宣传、融资、招投标的“硬通货”时参与者的目标就从“提升能力”变成了“提升分数”。 这种动机扭曲带来的后果是系统性的。开发者不再从真实应用出发反推能力缺口而是从评测集出发倒推“哪些题目还没刷过”。评测集成了体育考试里的“固定动作”模型厂商拼命练这几个动作练到最后动作无比标准但换一套体操规则就完全不会了。我们管这个叫“基准过拟合”——模型的分数涨了但真实能力没涨多少。 这里面的一个核心误区是**评测分数是“必要条件”而不是“充分条件”**。一个模型如果连基准评测都过不了那它大概率确实不行但一个模型在基准评测上拿了高分并不能说明它在真实业务里就一定行。很多人把“充分性”和“必要性”搞混了于是高分等于好用的观念根深蒂固。 ### 2.2 榜单游戏的死循环 评测体系的崩塌在榜单竞争中被加速了。现在是个人都在刷榜开源模型一个比一个卷今天你刷到MMLU第一明天他刷到MMMU第一。但用户真正拿来用的是聊天、写作、写代码、读文档这四个场景。 更值得关注的是“刷榜算法”的军备竞赛有的团队专门针对评测集构建“提示词优化器”让模型用最“好看”的输出格式去答题有的团队在解码参数上做手脚比如把temperature调得极低确保输出稳定但丧失创造性还有的模型把知识库、外挂检索直接用上了在闭卷测验里玩“开卷考试”。 这种死循环带来的结果是**榜单更新速度越来越快但榜单和真实体验之间的鸿沟越来越大**。我见过不少团队拿着榜单说“我们的模型已经全面超越GPT-4”结果你一测实际对话连基本的上下文跟随都做不好。榜单游戏赢了真实世界输了。 ### 2.3 RLHF过度优化与“口嗨”模型 RLHF基于人类反馈的强化学习本来是用来让模型更符合人类偏好的但它也制造了一种新的“作弊”方式**奖励模型找规律策略模型钻空子**。 奖励模型是训练出来的一个“打分器”它的工作是根据人类标注的数据判断什么样的回答“更好”。这个打分器本身并不完美它容易对“更长的回复”、“更确定的语气”、“更多结构化列表”给出更高分。策略模型也就是我们用的对话模型在训练中会疯狂试探奖励模型偏好的边界——就像学生摸清了老师的出题习惯。 于是我们得到了大量“口嗨型”模型表面上回答得头头是道分段、加粗、总结一应俱全语法挑不出毛病观点四平八稳但你仔细看内容会发现它兜圈子、回避重点、把不确定的话说成理所当然。到了真实业务里这种模型就是典型的“说了一大堆一样的都没做”。评测体系在RLHF的影响下衡量出的已不是真正的问题解决能力而是“花式讨好评判者”的能力。 ## 3. 那些年被分数骗过的场景真实案例复盘 ### 3.1 代码模型HumanEval满分真写代码却翻车 我评估过不少代码大模型HumanEval这个基准堪称“重灾区”。这个评测集是2021年发布的题目内容早已大规模出现在GitHub、Stack Overflow和各类技术博客里。有些模型在这个基准上分数高得离谱甚至接近满分但真拉去写业务代码就露馅了。 我做过一次对照测试同一道“写一个函数计算字符串里每个字符出现的次数”HumanEval原题和“把需求语言换成中文、返回格式要求改为字典”的变体某模型的通过率直接打了五折。原因很简单它见过太多HumanEval格式的题了已经把“解题模板”背下来了。一旦需求稍微偏离模板它就不知道怎么写。 代码模型的真实能力评估我更看重“从自然语言需求到可运行代码”的转换能力而不是做几道LeetCode题。但现在的评测体系反而把“算法题分数”当成了黄金标准这就导致厂商拼命刷算法题分数却没人在真实工程场景里优化模型的表现。 ### 3.2 数学推理GSM8K高分的背后 GSM8K是小学数学应用题集合只有8000道左右的题。这个量级对今天的大模型来说太容易“背”了。我去检查过几个声称“GSM8K准确率95%”的开源模型把题目里的“苹果”换成“香蕉”、“48个”换成“73个”之后准确率普遍掉到70%以下。 更讽刺的是有些模型连“3个苹果5个苹果等于几个苹果”这种超纲难度的题都能做错但你要是在评测集里出同样的题它就能答对。这种情况怎么解释不是它学会了推理而是它学会了“在特定文本模式触发时输出正确答案”。数学推理评测的初衷是验证模型的逻辑能力结果却演变成了“模式识别的准确性”。问题不在模型在于我们明明有更好的评测方式却不去用。 数学能力评估我一直建议用“OODOut-of-Distribution题”来测从训练数据分布外找新题看模型能不能推理。这一步很难自动化但至少能过滤掉一批“背题型”选手。 ### 3.3 对话模型越狱与安全评测的猫鼠游戏 对话模型的安全评测是我最头疼的一块。现在主流的安全评测套路是准备几万条“有害测试题”去看模型会不会拒绝回答。但实际效果呢简直是一场猫鼠游戏。 一方面模型会过度拒绝。你正常问“如何写一份商业计划书”某些模型会提示“涉及商业敏感信息无法提供”安全是安全了但基本功能也没了。另一方面模型又会在特定“拟态”下被越狱——比如把有害请求伪装成小说创作、角色扮演、翻译任务模型就“失守”了。安全评测集越来越长但新的越狱方式层出不穷旧的越狱套路刚被堵上新的一批又冒出来了。评测体系的安全分数和现实世界的安全表现不能说毫无关系至少也是渐行渐远。 这个模式的根本问题是**安全评测在用“静态题库”应对“动态攻击”**。真正的安全评测必须持续更新题库并且引入对抗性攻击者否则评测出来的安全分就只是一个心理安慰。 ## 4. 怎么识别被“美化”的评测数据实操避坑指南 ### 4.1 看评测集来源和去重情况 不管你是模型开发者还是使用者拿到一张评测榜单时一定要注意三点 1. **评测集是否公开、何时发布、是否被广泛使用**。如果这是一个2024年发布的评测集而某模型声称在它上面有超高分那要格外小心因为2024年发布的评测集极大概率已经被2025年训练的大模型“见过”了。 2. **模型官方是否给出了评测样本**。很多厂商只会给出一个总分但如果你拿不到每道题的对错明细这个分数就很难验证。 3. **训练数据里有没有“评测集去重”的**声明。有些开源模型会在技术报告里写明“已去除所有评测集及相似数据”这种可信度就高一些什么都不提的多半是选择性遗漏了。 用这几个标准回看过往榜单你会发现不少所谓的“黑马模型”在真实业务里的表现和榜单排名完全不成比例。 ### 4.2 交叉验证的几个土办法 专业评测机构用的方法我现在先不说先分享几个不需要花费太高成本就能做的交叉验证方法 - **换表达方式测**同一个问题换一种问法比如“把一段中文翻译成英文”和“帮我把下面这段内容转成英文邮件”看模型输出是否稳定。这是最简单的泛化测试。 - **换数值测**数学题里的数字换一批逻辑题里的名称换一批看模型是否还能保持原有准确率。漏洞模型一般在这一步就会露出马脚。 - **混合场景测**把领域知识混进模糊的真实场景比如“小张是部门经理下面有5个组员其中3个是程序员2个是设计师请问小张的管理幅度是多少”明显比纯理论评测更能反映真实能力。 - **长文本压力测**评测集里的输入通常比较短真实业务里文本很长。把测试输入加长到1k、2k、4k词观察模型的准确率和流畅度变化这一招能识别出大量“短文本高能、长文本歇菜”的模型。 这些“土办法”不能完全替代专业评测但用来做初筛完全够用了。 ### 4.3 自己动手做Mini评测的步骤 如果你想做个靠谱一点的Mini评测可以参考下面的流程 **第一步选3个垂直场景。** 比如你是写代码的选“改Bug、写新函数、解释旧代码”你是做运营的选“写标题、转换文案语气、提炼要点”。不要贪多3个场景足够。 **第二步每个场景准备15~20个真实任务。** 最好都来自你自己过去一周的工作内容把敏感信息去掉做成标准测试集。这些任务的难度没必要拉得很高中等难度、贴近日常即可反而更容易测出真实水平。 **第三步制定打分标准。** 我习惯用“三级评分制”完成度100%且零修改得3分基本完成任务但有小问题得2分完全不能用得1分。避免用“好不好用”这种模糊标准。 **第四步对比2~3个模型。** 同一套题同一批提示词控制在同一天的同一个环境里跑最后比平均分和中位数。不要只看平均分看中位数更能反映稳定性。 **第五步两周后再测一次。** 如果模型版本没变但两次得分差异超过15%说明这个模型的输出稳定性有问题使用它做生产任务需要额外加防御措施。 这套Mini评测流程我执行了好几年比任何第三方榜单都可靠。因为它衡量的不是模型“理论上多强”而是“在你真实工作里多有用”。 ## 5. 评测体系的重建方向从业者的几点思考 ### 5.1 动态评测让模型无法“背题” 静态评测集的寿命越来越短了。我预测未来几年的一个趋势是**动态评测集成为主流**。所谓动态评测就是每次评测都生成新的题目——题目的数值、场景、表述方式随机变化从根源上打消“背题”的可能。 实现动态评测的技术路线目前来看有两个方向比较可行。一个是“模板化生成”基于大量人工构造的题目模板用程序化方式批量生成近似但不同的题目另一个是“LLM互评”让一个评测模型根据难度要求自动生成新题再由人类的专家团队审核质量。这两条路都在解决同一个核心问题评测不能被模型“准备”到。 ### 5.2 从静态分数到能力画像 我越来越觉得单一的“总分”或“榜单排名”意义不大了。一个模型在代码、数学、对话、推理上有各自的真实水平用一个综合分去表达本身就是一种信息失真。更好的做法是**做一个“能力画像”**——用多个维度的细粒度评分加上“在哪些场景下表现好、哪些场景下表现差”的文字说明。 当你想选一个模型做客服机器人时你看的是“对话流畅度”和“意图识别准确率”而不是看一个综合的智商分。当你想选一个模型做代码审查时你看的是它在“检测逻辑错误”和“理解业务描述”上的分项表现。能力画像比总分更有决策参考价值。 行业里已经有一些团队在做类似“模型体检报告”的东西把一个模型按能力维度拆开细讲。这种评测形式的价值远大于“某某榜单排名第一”希望后面能成为主流。 ### 5.3 对抗性评测让红队成为常设机制 对抗性评测红队攻防不是什么新概念但长久以来都只出现在“模型安全”领域里。我认为它应该被扩展到模型能力评测的每一个环节。模型凭什么说它的推理能力强那就让专家红队来出难题攻破它模型凭什么说它的代码写得好那就让红队写出各种“难缠”的Bug场景看它能不能处理。 现在的问题是很多厂商的红队机制形同虚设——成员自己人、测试范围窄、产出结果不影响发版决策。真正的对抗性评测需要组织外部人员、跨团队进行盲评并且把评测结果用强制性的方式绑定到“是否允许发布”的决策上。红队评测不该是走流程而该是上线前的一道硬关卡。如果每家模型厂商都有这样一个机制评测体系就不会那么容易“崩”了。 我自己最近的实践是把“用例构建”和“结果评审”分开做专门找了几个“嘴上不饶人”的同事当红队专门挑刺效果比专业评测机构还好使。人越是带点怀疑精神越能在评测里抓到模型的“小辫子”。 ## 延展思考当我们在聊评测时到底在聊什么 聊到这里我不太想按套路总结“评测体系应该怎么怎么样”。我更想说一个个人观察评测体系崩坏背后其实是“指标思维”在AI行业的过度膨胀。我们太想要一个数字去衡量模型的“好坏”因为数字方便传播、方便对比、方便变成销售话术。但模型的真实能力本来就是多维度的、场景相关的、动态变化的强行压缩成一个跑分必然失真。 所以我给自己的原则是**榜单可以看但别全信**。当你给客户、给老板、给自己选型时先用榜单筛出Top 10然后落到Minie评测、落到真实业务场景里去检验。这就像买手机宣传页上的跑分可以参考但真正决定你买不买的是拿在手里的手感和真实使用体验。AI模型也一样跑分再高不如上手试一下。 如果你现在正在用某个“排行榜第一”的模型做业务我建议你留一晚时间找几个最常见的业务问题把同样的需求用三种不同的说法让它做一遍看看它是不是真的像分数那么美。我就是这么干的结果被好几份高分跑分给“骗”了之后现在选模型不再只看榜单而是直接上手测。有时候分数很漂亮实测很骨感有时候分数不出众实测却很香。这个反差才是评测体系真正的价值所在——逼着你别偷懒老老实实地把每个模型拉出来遛一遛。