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

1. 评测这件事远比跑个脚本复杂如果你在训练一个大语言模型不管是7B还是70B训练loss曲线好看不代表模型真的好用。我见过太多团队在训练完成后随便跑几个benchmark看到MMLU涨了两个点就开香槟庆祝结果上线之后被用户骂得狗血淋头。问题出在哪评测这件事本身就是一个系统工程从基准选择到数据污染排查再到整个评测流程的可复现性每一个环节都可能让你的结论完全失真。这篇内容适合正在做LLM训练、微调或者模型选型的同学。不管你是刚入门想搞清楚怎么科学地评测一个模型还是已经踩过一些坑想建立一套靠谱的评测体系下面的内容应该都能给你一些直接能用的思路。我会从基准选择的底层逻辑讲起然后重点聊数据污染这个几乎所有人都遇到过但很多人不知道怎么处理的问题最后给出一套我自己在实际项目中反复验证过的可复现评测流程。先说一个反直觉的结论大部分团队报告的评测分数是不可信的。不是因为大家故意造假而是因为评测流程中的坑太多了——prompt模板不一致、few-shot示例不同、解码参数没对齐、测试集被污染、甚至tokenizer版本差异都会导致结果偏差。这些问题叠加起来让你的评测结果和真实能力之间的相关性大打折扣。2. 基准选择不是排行榜越高越好2.1 先搞清楚你要测什么能力选基准之前你得先回答一个问题这个模型要用来干什么如果你的模型主要做中文法律文书生成那MMLU和HellaSwag的高分对你来说参考价值有限。基准选择的第一原则是任务对齐——测试任务要尽可能接近实际应用场景。我一般把评测需求分成几个维度知识能力模型记住了多少事实性知识。代表基准有MMLU、C-Eval、CMMLU。这类基准适合评估模型的“知识储备”但要注意知识是有时效性的训练数据截止日期之后的知识模型大概率不知道。推理能力模型能不能做多步逻辑推导。代表基准有GSM8K、MATH、BBH、ARC-Challenge。这类基准对prompt格式非常敏感同一个模型不同的prompt模板可能差十几个点。代码能力代表基准有HumanEval、MBPP、LiveCodeBench。这里特别推荐LiveCodeBench因为它用的是竞赛平台上的新题天然抗污染。指令遵循代表基准有IFEval、MT-Bench、AlpacaEval。这类评测更接近真实使用场景但主观性也更强。安全性代表基准有TruthfulQA、ToxiGen。如果你的模型要面向C端用户这个维度不能跳过。2.2 基准的“保质期”问题这里有一个很多人忽略的事实静态基准是有保质期的。一个基准发布两三年后随着模型在训练数据中越来越多地“见过”这些题目它的区分度会急剧下降。MMLU在2023年还能很好地区分模型能力到了2024年底头部模型的分数已经挤在85-90分这个狭窄区间里区分度大不如前。我的做法是维护一个“基准组合”而不是依赖单一基准。具体来说基准类型推荐组合更新频率备注知识类MMLU-Pro C-Eval半年评估一次MMLU-Pro选项更多区分度更好推理类GSM8K MATH BBH季度评估关注新发布的推理基准代码类HumanEval LiveCodeBench月度评估LiveCodeBench持续更新题目对话类MT-Bench 自建评测集持续迭代自建集最贴近业务长文本LongBench RULER季度评估长文本能力越来越重要2.3 自建评测集最被低估的工作公开基准只能告诉你模型在“通用能力”上的表现但你的业务场景大概率有特殊性。我强烈建议每个团队都花时间建自己的评测集。具体怎么做第一步从真实业务日志中采样。比如你做客服机器人就从历史对话中随机抽取500-1000条覆盖各种意图和边界情况。第二步人工标注标准答案。这一步很费时间但值得。第三步设计评分标准。对于生成类任务可以用GPT-4做裁判但一定要人工校验裁判的一致性。自建评测集的好处是你清楚地知道每道题的来源不存在数据污染问题评测结果直接反映业务效果说服力强可以持续迭代随着业务变化更新题目。注意自建评测集一定要留一个“保留集”只在最终评估时使用平时调参不要碰它。否则你就是在过拟合自己的评测集。3. 数据污染那个所有人都在假装不存在的问题3.1 数据污染到底有多普遍数据污染指的是评测数据以某种形式出现在了训练数据中。这个问题比大多数人想象的严重得多。2024年的一篇综述文章系统梳理了这个问题发现主流基准几乎都存在不同程度的污染。有些是直接污染——训练数据里原封不动地包含了测试题目有些是间接污染——训练数据里包含了测试题目的变体或者答案。我亲身经历过一个案例某个模型在GSM8K上报告了92%的准确率听起来很厉害对吧但我们用同一套评测流程在GSM8K的一个“清洗版”上测试准确率直接掉到78%。差了14个点这就是污染的影响。3.2 怎么检测数据污染检测污染有几种常用方法我按从简单到复杂的顺序介绍方法一N-gram重叠检测。把测试集的每道题拆成N-gram通常N13然后在训练数据里搜索是否有匹配。这个方法简单快速但只能检测直接复制的情况对改写和翻译无效。方法二困惑度分析。计算模型在测试集上的困惑度如果显著低于在类似分布的非测试数据上的困惑度说明模型可能见过这些数据。这个方法需要有一个“干净”的对照集。方法三扰动测试。对测试题目做微小扰动比如改数字、换名字、调整选项顺序如果模型准确率大幅下降说明它可能是在“背答案”而不是真正理解。这个方法最直观我一般都会做。方法四时间戳分析。如果基准是某个时间点发布的而你的训练数据截止日期晚于这个时间点那污染风险就很高。反过来如果训练数据截止日期早于基准发布时间污染风险就很低。这也是为什么LiveCodeBench这类持续更新的基准更有价值。3.3 污染了怎么办发现污染之后处理方式取决于污染程度和你的目标轻度污染在报告中注明污染情况同时报告清洗版和原始版的分数。让读者自己判断。中度污染使用去污染后的测试集重新评测。很多基准现在都提供了去污染版本比如GSM8K的清洗版。重度污染这个基准对你的模型已经失去参考价值了换一个基准。实操心得在训练数据准备阶段就做好去污染比训练完再检测要省事得多。具体做法是在数据清洗pipeline里加一步把常见基准的测试集做成一个黑名单训练数据中与黑名单重叠度过高的样本直接剔除。这一步会增加一些数据处理时间但能省掉后面很多麻烦。4. 可复现评测流程的搭建4.1 为什么可复现性这么难你可能觉得评测不就是跑个脚本吗有什么难的问题在于LLM评测涉及太多变量了模型端权重版本、tokenizer版本、推理框架版本、量化方式评测端prompt模板、few-shot示例、解码参数temperature、top_p、max_tokens、停止条件环境端随机种子、硬件差异、并行策略任何一个变量不同结果就可能不一样。我见过同一个模型在不同框架下跑出来的MMLU分数差了3个点原因仅仅是tokenizer对某些特殊字符的处理方式不同。4.2 我的评测流程模板经过多个项目的迭代我总结了一套可复现的评测流程核心原则是配置即代码结果可追溯。具体分四步第一步环境固化。用Docker把整个评测环境打包包括Python版本、CUDA版本、推理框架版本、评测脚本版本。每次评测都从同一个镜像启动。模型权重用哈希值标识确保每次加载的是同一个版本。第二步配置外置。所有评测参数写在一个YAML配置文件里包括prompt模板、few-shot数量、解码参数、随机种子。配置文件纳入版本管理每次评测记录对应的commit hash。# eval_config.yaml model: path: /models/llama-3-8b hash: a1b2c3d4... tokenizer: /models/llama-3-8b/tokenizer dtype: bfloat16 eval: benchmarks: - mmlu: prompt_template: Question: {question}\nA. {a}\nB. {b}\nC. {c}\nD. {d}\nAnswer: num_fewshot: 5 seed: 42 - gsm8k: prompt_template: Q: {question}\nA: Lets think step by step. num_fewshot: 8 seed: 42 decoding: temperature: 0.0 top_p: 1.0 max_tokens: 512第三步多次运行取统计。对于生成类任务单次运行的结果随机性很大。我一般至少跑3次报告均值和标准差。如果标准差超过2个点说明评测本身不稳定需要检查prompt或者解码参数。第四步结果归档。每次评测的原始输出、配置文件、环境信息全部归档。这样当有人质疑你的结果时你可以完整复现整个流程。4.3 评测框架选型目前主流的评测框架有lm-evaluation-harness、OpenCompass、HELM等。我的建议是lm-evaluation-harness最通用支持基准最多社区活跃。缺点是配置稍复杂对中文基准支持一般。OpenCompass中文基准支持好有榜单可以直接对比。适合国内团队。自建框架如果业务场景特殊自建框架灵活性最高但维护成本也高。我一般用lm-evaluation-harness做通用能力评测用自建脚本做业务场景评测。两者结果交叉验证。5. 那些只有踩过才知道的坑5.1 Prompt模板的“蝴蝶效应”同一个模型同一个基准仅仅因为prompt模板不同分数可能差10个点以上。我做过一个实验在GSM8K上用“Q: ... A: Lets think step by step.”模板模型准确率是76%换成“Question: ... Answer:”模板准确率掉到61%。15个点的差距仅仅是因为少了一句“Lets think step by step”。所以报告评测结果时一定要附上完整的prompt模板。否则这个结果没有参考价值。5.2 Few-shot示例的选择偏差Few-shot示例不是随便选几个就行的。不同的示例组合会导致不同的结果。我建议示例要覆盖不同类型的题目示例的难度要适中太简单或太难都会影响模型表现固定一组示例不要每次随机选否则结果不可比如果可能报告多组示例下的结果范围5.3 解码参数的隐藏影响Temperature0并不意味着完全确定性的输出。由于浮点数运算的顺序差异同一个输入在不同硬件上可能得到略微不同的logits进而导致不同的输出。对于短答案任务如选择题这个影响通常可以忽略但对于长文本生成影响可能很大。我的做法是对于需要精确复现的场景用greedy decodingtemperature0并且固定随机种子和硬件环境。对于探索性评测用temperature0.7左右跑多次取平均。5.4 评测集本身的标注质量问题这个问题很少被讨论但确实存在。有些公开基准的标注质量参差不齐甚至存在错误答案。如果你发现模型在某个基准上的表现异常低先别急着怀疑模型检查一下测试集本身有没有问题。我遇到过一个情况某个中文基准里有大约3%的题目存在标注错误导致所有模型在这些题上都“答错”。修正这些标注后模型的分数普遍提高了2-3个点。6. 从评测结果到决策评测的最终目的是辅助决策。但一堆数字本身不构成决策依据你需要把评测结果转化成可行动的洞察。我的做法是建一个“评测-决策”映射表评测发现可能原因建议行动知识类基准分数低训练数据知识覆盖不足补充领域知识数据继续预训练推理类基准分数低训练数据缺乏推理链加入CoT格式的训练数据代码基准分数低代码数据质量或数量不足增加高质量代码数据调整数据配比指令遵循分数低SFT数据质量或多样性不足优化SFT数据增加指令多样性安全基准分数低安全对齐不充分增加安全对齐数据调整RLHF策略这个映射表不是绝对的但能帮你快速定位问题方向。具体到每个项目还需要结合训练日志、数据分布等信息综合判断。最后分享一个我踩过的坑曾经有一个项目模型在MMLU上表现很好但上线后用户反馈“答非所问”。排查后发现MMLU的高分主要来自模型在选择题格式下的表现而实际使用中是开放式问答模型根本没有理解问题的意图。这个教训让我意识到评测基准和实际使用场景的gap是评测中最需要警惕的问题。后来我在评测流程中强制加入了一个“开放式问答”环节用真实业务问题做测试才避免了类似问题再次发生。评测这件事说到底就是一句话用正确的方法在正确的数据上测正确的能力。三个“正确”缺一不可。希望上面的经验能帮你少走一些弯路。