大模型评测实战：基准选取、数据污染与可复现流程

1. 评测的底层逻辑先弄清“好”的定义再谈分数去年我参与过一次内部模型选型两个模型在同一个榜单上的分数只差零点几个点A模型在推理任务上全面领先B模型在中文写作上更有味道。业务方只看总榜排名差点选了A结果一上线就被真实用户吐槽“答非所问”。后来我们花了整整三周才弄明白问题出在哪——不是模型不行而是我们最开始就没想清楚“评测到底在评什么”。1.1 评测悖论全能高分不等于场景可用这是做LLM评测最容易踩的第一个坑把“排行榜分数”等同于“实际效果”。你要搞清楚一件事模型评测本质上是在做一个抽样统计——用有限数量的测试样本去估算无限复杂的真实用户请求中模型能表现成什么样。既然是抽样就存在偏差和噪声何况大多数公开榜单一味追求总分最大化模型训练方也会针对性强化薄弱项去刷分。更麻烦的是“能力峰化”现象。一个模型可能需要几百亿参数扛住数学推理但同时会在情感对话这种任务上表现平庸。如果你只拿一个加权总分来选型模型在特定场景下的短板会被其他能力的优势掩盖。这和选人一样——你不可能用一个笼统的“优秀指数”来决定谁来当财务总监而是要看财会能力、抗压能力、沟通表达这些分项够不够。所以我在内部评测体系里第一件事就是建立能力维度拆分知识问答考察模型对百科类事实的准确回答能力常见的有MMLU、C-Eval这类基准逻辑推理覆盖符号推理、数学解题、常识推理GSM8K、MATH、LogiQA都是典型数据集代码生成函数补全、Bug修复、算法实现HumanEval和MBPP用得最多文本生成开放性写作、摘要、改写这类任务很难自动判分通常需要人类打分或强裁判模型指令跟随模型能否严格按用户约束执行比如格式要求、字数限制、否定指令长文本理解从几千字到几十万字的海量上下文中准确检索和综合信息分开测完拉一条能力雷达图出来你再谈选型就有的放矢。如果业务是客服助理那指令跟随和长文本理解权重就应该占大头如果业务是代码补全工具那代码生成和逻辑推理就是生命线。1.2 评测基准不只是“题库”而是模型的度量衡很多人以为基准Benchmark就是一堆题让模型去答答对了就是会。这个理解太小看评测设计了。好的基准本质是一套“标准化度量系统”它规定了三件事测什么能力、用什么方式测、如何判定好坏。比如MMLU设计了57个学科的多选题覆盖人文、社科、理科、工科最终得分是所有学科的平均正确率。这个设计目的是评测模型“广谱知识覆盖度”不是为了模拟真实聊天。GSM8K是小学数学应用题集专门考察多步推理能力解题过程需要一步一步推导直接给答案不算对。HumanEval则是让模型根据函数签名和文档字符串补全函数体判分标准是写出来的代码能不能通过预设的单测。理解了基准的设计逻辑你就明白一个关键结论没有任何一个基准是全能的。MMLU做得好的模型可能在GSM8K上崩掉因为知识记忆和逻辑推理用的根本不是同一套能力机制。所以合格的评测一定是一个集合——知识类、推理类、生成类、代码类各取若干组合成一个测试矩阵。我在实操中会为每个模型跑一遍这个矩阵得到一张“能力体检表”。选型讨论会上不聊总分直接盯着表格聊评测维度代表基准核心考察点判分方式知识广度MMLU、C-Eval跨学科知识覆盖多选题正确率数学推理GSM8K、MATH多步推导、数值计算最终答案正确率代码能力HumanEval、MBPP函数实现、算法逻辑单测通过率通用推理BBH、ARC常识推断、逻辑规则应用答案准确率指令跟随IFEval遵守格式、约束条件规则判定开放生成人工打分 / LLM as Judge流畅度、相关性、内容质量分项评分这一步做扎实了后面所有关于基准和污染的讨论才有意义。因为有了清晰的能力边界和权重设计你才能识别出“某次评测为什么和真实体验相差甚远”的根源到底是基准选错、数据污染还是评测流程不可复现。2. 基准选取的三重陷阱从公开榜单到领域微基准我见过太多团队图省事直接从公开榜单排行榜上扒一个高分模型来用然后被坑。不是说公开榜单没用而是你要看透它们本质上是什么——一组由有限题目、有限判分规则构成的近似评分跟你的业务场景大概率不完全重合。2.1 公开榜单的“同质化”与“能力峰化”现在主流的公开榜单比如Open LLM Leaderboard、MMLU排行榜用的是相对固定的评测集和评测方式。模型之间差异缩小到一两个百分点已经算巨大胜负了而这个差值很可能只是随机噪声或评测代码版本差异引入的。你追着排行榜买模型很容易买到“偏科状元”。我自己的亲身经历曾经跟踪一个排名靠前的开源模型在榜单上全程领先代码能力分很高。但拿我们内部的代码补全场景一测它生成的代码风格混乱、依赖处理错误百出。原因很简单评测集是通用题目覆盖的是算法与函数实现而真实业务里大多是特定框架、特定库的工程代码这一块没有任何公开基准能覆盖。所以我的建议是公开榜单适合用来做初筛和趋势观察真正的选型评测永远要用贴近自己业务的测试集。榜单分数告诉你的是“这个模型大概在什么水平水位”而不是“这个模型合不合适你”。2.2 领域微基准以2D图纸基准选取为例的实用方法自己搭一套业务基准听起来复杂实际上核心就是两步收集真实样本、设计判定标准。以2D图纸这类视觉理解加文档解析的场景为例过程非常典型。先收集100到200份有代表性的工程图纸标注好关键元素尺寸标注、文字说明、图层信息、图框边界、不同视图的对应关系。然后设计对应的评测任务比如图纸版面理解给定一张图纸图片让模型输出标题栏信息、图号、比例尺局部元素定位询问“第二视图左下角的尺寸标注是多少”考察模型在图纸高密度信息下的定位能力跨视图一致性让模型判断主视图和俯视图之间是否存在尺寸矛盾判分标准也不能只看“答得对不对”还要看“关键字段召回率”和“出错位置的严重程度”。图纸解析错一个尺寸可能就是实际生产事故。于是我在分项之外又加了一个“错误分级”严重错误关乎安全尺寸、一般错误非关键标注、轻微偏差精度差异按不同权重折合计分。这种领域微基准比公开基准有用得多因为它测的是你真正关心的能力。而且周期不长——我一般三到五天就能跑完一轮。关键是要坚持两个原则样本必须来自真实业务数据分布判分标准必须让业务方认可并在测试前冻结。2.3 基准覆盖度矩阵检验“测的是不是该测的”我踩过另一个坑觉得已经选了七八个基准覆盖度肯定够了。结果一分析发现知识类占了一半以上真正业务最关心的指令跟随和长文本抽取一个都没测。评测报告做得漂亮但就是不能支撑决策。后来我引入了一个很简单的“覆盖度矩阵”方法。先把业务对模型的核心能力需求列出来比如客服场景语义理解、情感识别、多轮对话、拒答判断代码助手代码补全、Bug定位、重构建议、技术问答文档处理信息抽取、摘要生成、格式整理、逻辑纠错再把候选基准或自制任务按能力标签填进矩阵每项能力至少有20道以上测试题才算通过。这时候你就很容易看出“缺口在哪”补测或者自制任务就有了非常清晰的依据。我见过有的团队把这个矩阵表打出来贴在工位上每条能力后面标注评测集名称和样本量哪个格子是空的就说明这项能力完全没验证过选型讨论时一眼就能怼回去。虽然方法土但真的能逼着整个团队把评测做完整而不是糊一个总分就交差。3. 数据污染榜单分数虚高的最大元凶数据污染是评测领域最让人头疼、也最容易被低估的问题。说直白点测试集的题目如果已经出现在模型的训练数据里模型等于开卷考试分数自然水涨船高。这种虚高会对选型决策产生毁灭性误导。3.1 数据污染的层级结构从显性到隐性的渗透路径数据污染不是单纯的“题目撞车”那么简单它有很深的层次结构。第一层是直接污染也就是测试题完整地出现在训练语料里。这种情况在模型训练时抓取大数据集太常见了GitHub上的题目、论文里的评测集、网页上的题库都可能被爬虫收进去。模型甚至可能把答案背下来连推理过程都省了。第二层是近义改写污染。原始题目没有直接出现但内容基本一致换了人名数字、换了说法模型经过训练后能“认出”这类题目的套路并给出答案。这种情况下评测分数看着合理实际上还是虚高。第三层是领域知识渗透。一些基准涉及特定领域知识比如医学、法律如果模型训练语料里塞入了大量该领域的专业文本——即使不是评测题本身——它也能在这个领域表现得异常出色。这种不是单点污染而是把整套知识库搬进了模型脑子里评测结果失去了区分度。我在实际评测中见过最夸张的情况某个模型在MATH数据集上突然暴涨20个点但同类型的逻辑推理任务表现平平。后来一查训练数据里混入了大量带MATH格式标签的文本。这个教训让我确立了一条铁律任何异常高分必须追查原因不能直接采信。3.2 数据污染的检测方法怎么发现“开卷考试”常规做法是n-gram重叠检测。把测试题切成连续词片去训练语料里比对看有多少百分比高度重合。重合率超过某个阈值基本就可以认定污染了。但这个方法有局限——遇到我刚才说的改写题就不灵了。所以后来我会同时跑一遍“难度曲线比对”拿测试题去问模型同时记录它的输出情况如果某些题目的准确率高得离谱而且对题目的解析能直接暴露“这不是在推理而是在背诵”的痕迹比如直接把某个特定编号或特殊表述原样复述出来那就要高度警惕。还有一种方法是困惑度检测。模型在训练过的文本上困惑度会比较低。我把同一道题随机做若干次变形让模型回答如果模型在原始题和改写题上的表现差异巨大说明它可能记住了原文而不是学会了推理能力很可能存在污染。Min-K%也是最近用得比较多的检测手段找出训练语料里和测试文本重叠度最高的k%区段计算这些区段的平均概率如果明显高于普通文本说明测试文本大概率出现在训练数据里。这个检测不需要额外训练辅助模型成本很低我通常用它在常规评测前先快速扫一遍所有测试集。3.3 数据污染对评测结论的扭曲为什么分数会骗人污染最阴险的地方在于它扭曲的不是单个题目的得分而是你对模型整体能力的判断。假设一个知识问答基准里20%的题目已经被训练数据污染模型这20%的正确率可能是100%但它的真实知识掌握度也许只有70%。这30个点的水分会直接拉高总分让你误以为模型知识储备很强。更糟糕的是如果这个模型刷高的是你业务能力的核心维度那么你带着虚高预期上线真实场景就会现出原形造成线上事故或用户体验骤降。这也是为什么我反复强调评测结果反推业务决策之前必须先做污染排查否则就是在拿一张假体检表给病人开药。另一个很多人没有意识到的扭曲在于“训练方法污染”。有些模型为了冲榜会专门在基准测试集上做强化学习把一条条具体题目的答案调优到完美。这种模型在榜单上名列前茅但你要它做哪怕相似但没见过的题目表现立刻跌回原形。这种“过拟合榜单”的模型比普通数据污染更难防因为它不是训练语料的问题而是评测逻辑被黑客式地利用。应对思路有两个一是平时多关注一些“新鲜出炉”的评测集减少被针对性训练的机会二是把自己业务场景的私有评测集留到最后再跑彻底隔绝模型针对你的数据做过专门优化的可能性。4. 可复现评测流程的完整搭建方案评测结果不可复现是实验室里最常见的内耗源。同一份代码、同一个模型昨天跑出82分今天换台机器跑出79分然后大家开始争论到底哪个分数是对的。扯皮半天谁也说不清。真凶其实很简单随机性没控制住、解码方案不一致、并发调度导致某条线程被延迟、甚至温度参数不同。4.1 环境固定锁定依赖版本和硬件条件可复现的第一步是把“评测环境”做成快照冻结。依赖库不能是“最新版”必须有版本锁。我习惯用锁文件把torch、transformers、datasets这些关键库版本固定下来模型权重文件也要同步记录哈希值以防模型文件被替换了都不知道。更麻烦的是硬件环境的差异。同样的模型在A100和4090上跑如果开了不同的浮点精度设置结果也可能出现微小差异累积起来就变成不可复现的来源。好在现在主流推理框架都支持固定seed和确定性模式比如transformers里面设置model.eval()之外还要保证torch.manual_seed和cudnn.deterministic都设好。在我看来硬件差异不需要追求完全归零不现实但至少要保证评测报告里写明硬件型号、精度设置、batch大小、并发数。后续如果有人复现出不同分数至少能定位是哪一个环节造成的偏差。4.2 锚点测试集先检验评测代码本身是否可靠我自己踩过的最大的坑是评测代码本身有Bug导致所有模型的分数集体偏低。那种“所有模型都很差”的评测结论大概率是在误导人。为了避免这种情况我现在每次搭好评测流程都会先跑一个“锚点测试集的冒烟测试”。锚点测试集选择要很讲究不能太简单全是送分题也不能太难根本没有模型能答好。我通常挑20到30道覆盖各能力维度的代表性题目跑一遍确认评测代码能正常输出结果然后和已知的基线结果比一比。如果偏差在可接受范围再大规模跑剩下的测试集。这一步成本很低但非常值得做。因为它检验的是评测流程本身的正确性——prompt模板没有写错、解析逻辑没有混乱、判分规则没有反转。我曾遇到过解析器把模型的“A.”当成“选项A”而实际模型输出的是“A)”这种低级错误在冒烟测试里一眼就能暴露。4.3 归一化与解码参数温度、Top-p和输出的标准化先明确一个概念LLM生成输出是随机的。哪怕输入完全一样不同的解码参数也会产生不同结果。评测既要考察模型能力也要保证评测结果稳定这就需要在“探索性”和“确定性”之间做个取舍。一般常识类、推理类任务用贪婪解码也就是do_sampleFalse模型每次都会选择概率最高的token结果完全确定。但生成类任务如果也开贪婪解码输出往往会很寡淡没有多样性。这种任务我会用temperature0.7配合top_p0.9做采样但为了保证可复现必须把随机种子固定住。归一化处理也很关键。有些模型的输出会带解释、带标题、带额外说明如果判分脚本只做简单的“包含答案就判对”混淆严重。我的做法是对输出做一套标准化的后处理去掉多余空白、统一数字格式、剥离解释性前缀再把关键答案字段提取出来和参考答案比对。这套后处理逻辑越早写越好而且要写进评测代码库里做成公共模块而不是每个任务单独写一套解析规则。否则同一道题不同任务的解析结果可能自相矛盾评测报告数据完全没法对。4.4 并发调度与随机性控制评测也要讲“环境公平”批量评测通常要开并发多卡并行本来是提速的好手段但也引入了新的噪声来源。简单说如果某个request因为并发调度被延迟到超时返回的就是空结果或者超时标记这类结果会被记为“答错”直接拉低分数。这其实不是模型能力问题而是运维问题。我做过的最有效的调整是把评测中的超时时间放大到正常耗时的三倍以上并且对每次请求的任务分配做固定顺序随机打乱而不是固定顺序。固定顺序容易出现“某个请求总是排在队列尾部导致超时”的系统性偏差。再加一层保险跑完以后检查超时率如果超过1%判定这次评测无效重跑。另一件常被忽略的事是不要让评测脚本在跑的同时做其他任务。机器负载波动会直接拉长推理耗时高负载下长文本生成的表现可能和空闲时有本质差异这不是模型变笨了是算力分配变了。要么专用机器跑评测要么严格限制其他任务并发。4.5 从“跑分数”到“下结论”统计检验、去重与留出集最后一步也是很多人跳过的统计检验。你评测的样本量是有限的分数差异到底是真的能力差异还是抽样波动一个简单粗暴的检验方式是跑置信区间同一测试流程分多次随机子集跑看看分数波动范围。如果两个模型的分差远小于波动范围那你基本不能下谁更强的结论。样本去重也很重要。有些测试集内部题目高度相似比如同一道数学题换个数字就是另一题模型只要学会了一道题的解法同类型题全部能答对。这时候你测出来的正确率被同质样本放大看起来很高实际上模型的能力覆盖只有一道题的范围。所以每次评测前我都要做一次文本相似度聚类把相似度过高的样本只保留一个代表再进入评测。留出集是我压箱底的做法。从业务侧收集一个“锁在保险柜”里的测试集这个测试集由业务方慢工出细活地攒着来源不外流——可以是内部工具的QA案例也可以是真实客服会话的脱敏记录。每次模型上线前我们会在公开基准之外单独跑一次这个留出集因为模型训练方不管是谁都没法针对这个私有测试集做优化结果最接近真实上线表现。写在最后的实际操作体验评测流程搭得越标准越不会出现“一测一个分”的尴尬。我现在的习惯是报告里同时写清楚模型版本、评测集版本、解码参数、硬件环境、污染筛查结果、置信区间外人拿过去能完整复现再谈参考价值。如果非要说一条最有价值的经验那就是评测不是在找最好的模型而是在为你的具体场景选最合适的模型。别人的排行榜标兵不一定是你业务里的实干家而你自己维护的那一小套业务基准和留出集才是选型时说话最响的部分。这套流程多跑几次你会发现自己对模型的直觉判断也比以前准了不少——这大概就是做评测带来的隐藏收益。