1. 大模型评测到底在评什么先把一个误区摆在桌面上很多人一提“大模型评测”脑子里浮现的就是跑个分、看个排行榜、截个图发朋友圈。这套思路在小模型时代勉强能用放到今天的大模型上基本等于拿体温计量海拔——工具和对象根本不匹配。大模型评测的本质是用一套可复现、可比较、可解释的方法去回答“这个模型在特定任务上到底行不行”这个问题。注意三个关键词可复现、可比较、可解释。少了任何一个评测结果就是自娱自乐。我见过太多团队踩的坑拿几道题手工测一测觉得“还行”就敢往生产环境推。结果上线三天用户反馈一塌糊涂。问题出在哪手工测的那几道题恰好是模型擅长的真实场景里的长尾输入压根没覆盖到。所以评测要解决的核心问题有三个层次能力层模型会不会做这件事比如数学推理、指令遵循、代码生成。稳定性层换个问法、换个顺序、加个干扰它还能不能做对边界层它在什么情况下会崩崩的时候是胡编、拒答还是答非所问这三个层次对应三种不同的评测设计思路后面会逐一拆开讲。先记住一句话评测不是给模型打分是给你的使用场景做风险画像。1.1 评测和训练的关系不是终点是导航很多人把评测当成训练完之后的“验收环节”这是典型的流水线思维。实际上在成熟的大模型研发流程里评测是贯穿始终的导航仪。预训练阶段你需要用评测来判断数据配比是否合理——比如中文数据加多了英文能力掉没掉代码数据掺进去通用对话能力有没有被带偏这时候用的通常是轻量级代理指标比如小规模验证集上的困惑度、特定任务的准确率不可能每次都跑全量基准。微调阶段评测的作用更关键。你做SFT监督微调怎么知道这一版数据比上一版好靠loss曲线loss降了但模型变啰嗦了、变谄媚了这种情况太常见了。必须用任务级评测来卡指令遵循率、格式正确率、事实准确率这些指标才能反映真实质量。到了对齐阶段RLHF/DPO评测更是核心。奖励模型打的分高不代表人类真的满意。这时候需要人工评测自动评测双轨并行自动评测负责快速迭代人工评测负责校准方向。提示如果你还在用“训练完跑一次MMLU”的方式做评测建议立刻改成“每个关键节点都跑一组针对性评测”。评测频率上去了返工成本才能下来。1.2 自动评测、人工评测、模型评测三套体系别混用大模型评测的方法论粗略分三大类各有各的适用场景混着用会出大问题。自动评测就是用程序化指标去打分。典型代表是GSM8K小学数学应用题这种有标准答案的数据集直接比对最终答案对不对。优点是快、便宜、可复现缺点是只能测“有明确对错”的任务开放式生成基本无能为力。人工评测就是找人来看、来打分。优点是能捕捉微妙的质量差异比如语气是否自然、逻辑是否连贯缺点是贵、慢、主观性强。人工评测的关键在于评分标准的设计和标注者的一致性校准这两点做不好人工评测比自动评测还不靠谱。模型评测也叫LLM-as-a-Judge就是用一个大模型去评另一个模型的输出。这是近两年最火的方向因为它试图在自动化的效率和人工判断的质量之间找平衡。但坑也最多——评判模型本身的偏见、位置偏好、长度偏好都会污染结果。我个人的经验是能用自动评测卡硬指标的绝不劳烦人工必须人工判断的先用模型评测做初筛人工只复核边界案例。这样能把人工成本压到原来的三分之一左右。2. 主流评测基准怎么选、怎么用选评测基准这件事跟选跑鞋差不多——不是越贵越好也不是别人说好就好得看你的“脚型”和“路况”。下面把几个最常被提到的基准拆开讲重点说清楚它们各自测什么、不测什么、什么场景下该用。2.1 GSM8K数学推理的入门标尺GSM8K全称Grade School Math 8K是8000多道小学数学应用题。别看是“小学”难度它测的是多步推理能力——模型得读懂题、列对式子、算对结果中间任何一步错了最终答案就错。它的评测方式很直接给模型题目让它输出解题过程和最终答案然后提取答案比对。准确率就是答对的比例。但GSM8K有几个明显的局限用的时候必须心里有数答案格式敏感模型可能算对了但格式不对提取失败就算错。所以评测脚本里的答案提取逻辑要足够鲁棒。数据污染风险GSM8K太出名了很多训练数据里可能混入了原题。如果你的模型在GSM8K上分数异常高先查污染别急着高兴。难度天花板低GSM8K做得好不代表复杂数学推理就行。它更像是“及格线测试”不是“拔高测试”。实操建议GSM8K适合作为基础推理能力的快速筛查配合few-shot示例通常4-shot或8-shot跑一遍看个大概水平。但别把它当成数学能力的唯一证据。2.2 IFEval指令遵循的照妖镜IFEvalInstruction-Following Evaluation测的是另一件事模型能不能严格按照指令的约束来输出。比如“用不超过50个字回答”“回答中必须包含‘苹果’这个词”“用JSON格式输出”这些约束模型能不能守住。这个基准的价值在于它直接对应生产环境里最常见的痛点——用户给了明确要求模型却自由发挥。IFEval的题目设计就是各种“刁钻”的格式约束看模型是乖乖遵守还是自作主张。IFEval的评分是基于规则的自动检查比如数数字数、查关键词、验证格式。这意味着它非常客观但同时也意味着它只能测“可程序化验证”的约束。对于“语气要委婉”这种软约束它无能为力。我实测下来的感受是IFEval分数高的模型在结构化输出场景比如API调用、表单填写里明显更省心。如果你的应用需要模型稳定输出特定格式IFEval值得重点看。2.3 其他常用基准的定位速查除了GSM8K和IFEval还有一堆基准经常被提及。下面这张表把常见基准的定位、适用场景和注意事项列清楚方便你按需选用。基准名称主要测什么适用场景注意事项MMLU多学科知识广度通用能力摸底污染严重分数虚高常见HumanEval代码生成正确性编程辅助场景只测函数级不测工程能力BBH复杂推理高阶推理能力难度高小模型基本全军覆没C-Eval中文知识中文场景中文基准里相对靠谱的选择MT-Bench多轮对话质量对话系统依赖模型评判有偏见AlpacaEval指令遵循有用性通用助手长度偏好明显需去偏选基准的原则就一条你的应用场景里用户最常让模型做什么就优先测什么。做客服的重点测多轮对话和意图理解做代码助手的重点测HumanEval和实际工程任务做内容生成的重点测指令遵循和事实准确性。3. 从零搭建一套评测流水线前面讲的都是“评什么”这一节讲“怎么评”。我会按实际搭建顺序从数据准备到结果分析把每个环节的关键决策点讲清楚。这套流程我在多个项目里跑过中小团队直接抄作业问题不大。3.1 评测集构建自己造题才是正道公开基准可以用但不能只用公开基准。原因很简单你的业务场景公开基准覆盖不到。用户问的行业黑话、内部流程、特定格式要求这些都得自己造评测集。自建评测集的核心原则是分层抽样高频场景覆盖80%日常请求的典型任务每个任务至少50条。边界场景容易出错的、输入格式奇怪的、多意图混合的每个至少20条。对抗场景故意诱导模型犯错的、包含干扰信息的每个至少10条。造题的时候标准答案的制定比题目本身更重要。对于有确定答案的任务直接标注正确答案对于开放式任务要制定评分细则比如“事实错误扣3分格式错误扣1分语气不当扣0.5分”让不同标注者能打出接近的分数。注意自建评测集最忌讳“拍脑袋造题”。最好从真实用户日志里采样脱敏后作为题目来源。这样测出来的结果才跟线上表现有相关性。3.2 评测执行温度、提示词、次数都有讲究评测执行阶段有几个参数直接决定结果的可比性必须固定死。温度temperature评测时通常设成0或接近0让模型输出尽量确定。如果设成0.7、0.8同一个问题每次答案都不一样评测结果就没法比较了。但要注意有些模型在温度0时反而表现异常需要实测确认。提示词模板同一个模型换个提示词模板分数可能差十几个点。所以评测时必须固定模板并且把模板版本号记录下来。我习惯在评测报告里附上完整的提示词方便复现。评测次数对于温度非0的评测或者本身有随机性的任务单次结果不可靠。通常跑3到5次取平均同时记录方差。方差大的任务说明模型在这个场景下不稳定本身就是重要信号。答案提取逻辑这是最容易被忽视的环节。模型输出一大段话你怎么从中提取出最终答案正则匹配、关键词定位、还是再调一个模型来提取提取逻辑的鲁棒性直接影响评测分数的可信度。建议对提取失败的案例单独统计如果失败率超过5%说明提取逻辑需要优化。3.3 结果分析分数之外要看什么拿到一堆分数之后别急着排名。分数只是表象下面这些分析维度才是真正有价值的错误类型分布是知识错误、推理错误、格式错误还是拒答不同错误类型对应不同的改进方向。难度分层表现简单题、中等题、难题的准确率分别是多少如果简单题全对、难题全错说明模型能力有明确天花板。输入长度敏感性短输入和长输入的表现差异大不大这直接关系到实际应用中的上下文管理策略。一致性分析同一道题换种问法模型还能不能答对一致性差的模型生产环境里就是定时炸弹。我通常会做一张错误案例归因表把每个错误案例归类到具体原因然后按频次排序。排在前三的原因就是下一轮优化的重点。4. 评测中最容易踩的坑这一节全是血泪教训。有些坑我踩过有些是看别人踩的共同点是——踩之前都觉得“这能有什么问题”踩之后才发现代价不小。4.1 数据污染分数虚高的头号元凶数据污染指的是评测集的题目或高度相似的变体出现在模型训练数据里。这种情况下模型不是“会做”而是“见过”分数自然虚高。检测污染有几个实用方法n-gram重叠检测把评测题和训练数据做n-gram比对重叠度高的标记出来。改写测试把评测题换个说法、换组数字看模型分数掉不掉。掉得厉害说明之前是背的。时间戳检查如果评测集发布时间晚于模型训练数据截止时间污染风险低反之则要警惕。提示公开基准的污染几乎是必然的只是程度问题。所以公开基准的分数只能横向比同条件下比不同模型不能纵向比跟历史分数比进步。纵向比较必须用自建评测集。4.2 评判模型的偏见LLM-as-a-Judge的暗坑用模型当裁判效率是高但裁判本身有偏见。最常见的三种位置偏见把两个答案A和B给裁判模型它倾向于选第一个或第二个跟内容质量无关。解决办法是交换位置测两次只有两次都选同一个才算数。长度偏见裁判模型倾向于给长答案打高分哪怕长答案里废话更多。解决办法是在评分标准里明确“简洁性”权重或者对长度做归一化。自我偏好裁判模型倾向于给自己或同家族模型的输出打高分。解决办法是用不同家族的模型当裁判或者用多个裁判取平均。我实测下来用GPT-4当裁判评GPT-4的输出分数普遍偏高5%到10%。换成Claude或Gemini当裁判分数会回归理性一些。4.3 评测与业务脱节分数高不等于好用这是最隐蔽也最致命的坑。模型在评测集上分数漂亮上线后用户却不买账。原因通常是评测集和真实场景之间有鸿沟。弥合鸿沟的办法只有一个让评测集持续进化。具体做法包括定期从线上日志采样新案例补充进评测集。对线上bad case做归因把典型问题转化成评测题。评测指标里加入业务指标比如“用户追问率”“任务完成率”而不只是准确率。评测集不是造一次就用一辈子的它应该像产品一样持续迭代。我见过做得好的团队评测集每两周更新一次始终保持跟线上场景同步。5. 不同阶段的评测策略怎么定评测策略不是一成不变的模型研发的不同阶段评测的重点、频率、方法都不一样。这一节按阶段拆开讲。5.1 预训练阶段轻量代理指标为主预训练阶段动辄跑几周甚至几个月不可能频繁跑全量评测。这时候用的是轻量代理指标验证集困惑度最基础的指标反映模型对语言的建模能力。但困惑度低不代表下游任务好只能作为参考。小规模任务抽样从各个目标任务里抽几十条快速跑一遍看趋势。能力探针设计一些极简的探测题比如“11等于几”“把这句话翻译成英文”看基础能力有没有退化。这个阶段的核心是监控趋势而不是精确测量。只要趋势是向上的没有明显的能力塌陷就可以继续。5.2 微调阶段任务级评测卡质量微调阶段是评测的主战场。每一版数据、每一组超参都需要用任务级评测来验证效果。这个阶段的评测设计要点评测集要覆盖微调目标你做的是医疗问答微调评测集就得是医疗问答不能拿通用基准糊弄。要有基线对比微调前的模型、上一版微调的模型都要跑同样的评测才能看出增量。关注副作用微调经常导致“偏科”——目标任务涨了通用能力掉了。所以评测里要包含通用能力的回归测试。我习惯在微调阶段维护一张评测看板横轴是版本纵轴是指标每个版本一行数据。这样一眼就能看出哪版好、哪版退步、退步在哪个指标上。5.3 上线前端到端场景评测模型要上线了这时候的评测必须端到端模拟真实用户的使用路径。端到端评测的关键点用真实请求分布评测集的题目分布要跟线上请求分布一致不能全是简单题或全是难题。包含多轮交互很多问题不是单轮能解决的要测多轮对话中的表现。模拟异常输入空输入、超长输入、乱码、恶意诱导这些都要测。设定通过标准提前定好“达到什么分数可以上线”避免上线前临时拍脑袋。注意上线前评测发现的问题如果修复成本高可以考虑用提示词工程或后处理来兜底而不是硬等模型迭代。生产环境里工程手段往往比模型手段更快见效。5.4 上线后持续监控与回归评测模型上线不是终点。线上表现会随着用户行为变化、数据分布漂移而波动所以需要持续监控。监控指标分两类业务指标任务完成率、用户满意度、追问率、投诉率。这些是最终裁判。模型指标输出长度分布、拒答率、格式错误率、延迟。这些是早期预警信号。同时定期回归评测不能停。每周或每两周跑一次固定评测集看分数有没有异常波动。如果某个指标突然掉了赶紧查原因——可能是线上流量变了也可能是模型服务出了问题。6. 评测工具链怎么搭工欲善其事必先利其器。评测这件事纯手工做迟早会崩必须有一套工具链支撑。这一节讲工具选型和搭建思路。6.1 开源评测框架速览市面上有不少开源评测框架各有侧重。下面列几个我用过或深入研究过的框架名称特点适用场景上手难度lm-evaluation-harness基准覆盖全社区活跃学术评测、基准跑分中OpenCompass中文支持好配置灵活中文场景、多模型对比中promptfoo轻量适合提示词评测提示词迭代、A/B测试低Ragas专注RAG评测检索增强生成场景中DeepEval单元测试风格工程化评测、CI集成低选框架的原则先看你的核心场景是什么再看框架能不能覆盖。如果主要做RAGRagas比lm-evaluation-harness更对口如果主要做提示词优化promptfoo比OpenCompass更轻便。6.2 自建评测流水线的核心模块开源框架再好也很难完全贴合你的业务。所以成熟团队通常会在开源框架基础上自建一层核心模块包括评测集管理题目的增删改查、版本管理、分层标签。评测执行引擎并发调用模型API、重试机制、限流控制。答案提取与评分针对不同任务类型的提取器和评分器。结果存储与可视化评测结果的持久化、对比看板、趋势图。CI集成代码提交或模型更新时自动触发评测不通过则阻断发布。这套东西搭起来工作量不小但一旦搭好后续每次评测的成本会大幅下降。我的建议是先搭最小可用版本能跑通“读评测集→调模型→提取答案→算分→存结果”这条链路就行后面再逐步加功能。6.3 评测成本控制别让评测比训练还贵评测是要花钱的尤其是调用商业模型API做评测的时候。控制成本有几个实用技巧分层评测先用小规模评测集快速筛只有通过的模型才跑全量评测。缓存机制同一个模型、同一个提示词、同一个参数的调用结果缓存起来避免重复调用。采样评测对于大规模评测集随机采样一部分跑用统计方法估计整体表现。模型裁判降级初筛用便宜模型当裁判只有边界案例才用贵模型复核。我算过一笔账一个中等规模的评测任务如果不做任何优化API成本可能上千元做了分层和缓存之后能压到一两百元。评测频率高了之后这个差距非常可观。7. 几个实操中的经验之谈最后这部分是我个人在评测实践中攒下来的一些零散经验不成体系但每一条都是真金白银换来的。评测集的题目要“活”。什么叫活就是题目本身要能反映真实场景的复杂性。比如测客服场景别只测“退货怎么操作”要测“我上周买的衣服洗了一次缩水了能退吗”“订单号我忘了但手机号是xxx能查吗”。真实用户不会按标准格式提问评测集也不该全是标准格式。分数要带置信区间。只报一个准确率数字信息量太低。样本量小的时候准确率的波动范围可能很大。报分数的时候带上置信区间比如“准确率82%±3%”读者才知道这个分数的可信度。评测报告要写“人话”。我见过太多评测报告满篇指标和缩写看完不知道模型到底行不行。好的评测报告应该让非技术背景的人也能看懂模型擅长什么、不擅长什么、在什么场景下可能出问题、建议怎么用。别迷信单一分数。一个模型在GSM8K上90分另一个85分不代表前者数学能力一定强。可能是提示词模板的差异、答案提取的差异、甚至随机种子的差异。多维度、多方法交叉验证才能得出靠谱结论。评测的最终目的是决策。评测本身不产生价值基于评测做出的决策才产生价值。所以每次评测之前先想清楚这次评测要回答什么问题如果结果是A我会怎么做如果结果是B我又会怎么做想不清楚这个评测就是浪费资源。保持对评测结果的怀疑。分数异常高的时候先怀疑污染分数异常低的时候先怀疑评测脚本有bug。我自己的经验是评测结果跟预期严重不符时八成是评测本身有问题而不是模型真的那么强或那么弱。先查评测流程再下结论。评测是团队共识的载体。技术团队说模型好产品团队说模型不行这种扯皮太常见了。一套公开、透明、可复现的评测体系能让讨论回到事实层面。所以评测集和评测脚本最好对全团队开放谁有疑问都可以自己跑一遍验证。这比开十次会对齐都管用。