1. 大模型评测到底在评什么1.1 从“跑个分”说起评测的本质是定义能力边界很多人第一次接触大模型评测脑子里浮现的就是“跑个分”——像手机跑安兔兔那样输入一批题目得到一个百分数然后拿这个分数去横向对比。这个直觉不能说错但它只覆盖了评测最表层的一小部分。真正做过评测的人都知道评测的核心不是打分而是定义能力边界。你得先想清楚我要测的是这个模型的哪一层能力是基础的语言理解还是多步推理还是指令遵循还是代码生成还是长上下文的信息保持不同的能力维度对应的评测集、评测方式、评分标准完全不同。我见过太多团队一上来就问“哪个评测集最好”这个问题本身就问错了。评测集没有绝对的好坏只有适不适合你的业务场景。GSM8K 测的是小学数学应用题的多步推理IFEval 测的是指令遵循的精确度MMLU 测的是多学科知识广度HumanEval 测的是代码生成。你拿 GSM8K 的高分去证明一个模型适合做客服对话逻辑上是不成立的。所以评测的第一步永远是明确评测目标而不是急着找数据集。从工程角度看评测要回答三个问题第一模型在目标场景下能不能用第二模型和竞品比处于什么位置第三模型迭代后是变好了还是变差了。这三个问题对应三种评测模式场景化评测、横向对比评测、回归评测。场景化评测最贴近业务但构建成本最高横向对比评测可以直接用公开榜单但和业务的相关性存疑回归评测是内部迭代的刚需需要维护一套稳定的私有评测集。三者缺一不可但优先级要根据团队阶段来定。1.2 评测的三个层次能力层、任务层、系统层我把大模型评测拆成三个层次来理解这样在实操中不容易乱。能力层关注的是模型的基础素质比如语言流畅度、事实准确性、逻辑一致性、指令遵循度、安全性。这一层的评测通常用公开基准集比如 GSM8K、IFEval、MMLU、TruthfulQA、BBH 等。能力层评测的价值在于建立基线让你知道这个模型“大概是什么水平”。但能力层分数高不代表业务效果好这一点后面会反复强调。任务层关注的是模型在具体任务上的表现比如摘要、翻译、分类、信息抽取、代码补全、多轮对话。这一层的评测需要你自己构建评测集因为公开数据集很难覆盖你的业务细节。任务层评测的关键是样本代表性和评分标准可操作。样本代表性决定了评测结果能不能外推到真实流量评分标准可操作决定了不同标注者能不能给出一致的分数。系统层关注的是模型在整个产品链路中的表现比如 RAG 系统的端到端准确率、Agent 的任务完成率、多轮对话的上下文保持能力。这一层的评测最复杂因为模型只是系统的一个组件检索质量、提示词设计、工具调用逻辑都会影响最终结果。系统层评测通常需要构造端到端的测试用例并且要能定位问题出在哪个环节。实操心得很多团队在能力层分数上卷得很厉害但业务效果就是上不去。原因往往不是模型不行而是任务层和系统层的评测缺失导致优化方向跑偏。我的建议是能力层评测用来选型任务层评测用来调优系统层评测用来验收。1.3 为什么公开榜单越来越不够用公开榜单的问题主要有三个数据污染、场景错配、评分粗糙。数据污染是最头疼的。大模型的训练数据规模太大很多公开评测集的题目可能已经以某种形式进入了训练语料。这就导致模型在榜单上的分数虚高实际泛化能力被高估。GSM8K 和 MMLU 都出现过类似争议。判断一个模型是否“背题”可以看它在同分布但不同表述的题目上表现是否骤降或者看它的推理过程是否合理而不是直接跳到答案。场景错配是另一个大问题。公开榜单的题目分布和你的业务流量分布往往差异巨大。比如你的业务是电商客服用户问题集中在退换货政策、物流查询、商品参数对比但 MMLU 考的是物理、化学、法律、医学。模型在 MMLU 上考 80 分不代表它能处理好你的客服对话。所以私有评测集的构建是绕不过去的越早开始越好。评分粗糙也很常见。很多榜单只用准确率一个指标但实际业务中模型的回答可能“部分正确”“格式不对”“语气不合适”。这些细节在单一准确率指标下全被抹平了。更合理的做法是多维度评分比如正确性、完整性、格式合规性、语气适配度每个维度单独打分最后加权汇总。2. 评测集构建从 GSM8K 到私有场景集2.1 公开评测集的正确打开方式公开评测集不是不能用而是要知道怎么用。我的经验是公开评测集主要用在选型阶段和回归监控两个场景。选型阶段你需要快速筛掉明显不行的模型。这时候可以用 GSM8K 测推理、IFEval 测指令遵循、MMLU 测知识广度、HumanEval 测代码能力。但要注意这些分数只能作为参考不能作为决策依据。真正做决策之前一定要用私有评测集复测。回归监控阶段公开评测集可以作为“体检指标”。每次模型迭代或提示词调整后跑一遍公开评测集看看基础能力有没有退化。如果 GSM8K 分数突然掉了 10 个点那大概率是训练或微调出了问题需要立刻排查。使用公开评测集时有几个坑要避开。第一不要只看总分要看分项分数和错误分布。比如 GSM8K 总分 75%但错误集中在“需要多步单位换算”的题目上这个信息比总分更有价值。第二注意评测脚本的版本不同版本的评测脚本在答案抽取、归一化、评分逻辑上可能有差异导致分数不可比。第三不要过度拟合公开榜单如果为了刷榜而针对性优化最终业务效果大概率会失望。2.2 私有评测集构建的完整流程私有评测集是大模型评测的核心资产构建过程可以拆成六步定义维度、收集样本、标注答案、设计评分、试跑校准、版本管理。定义维度是第一步也是最容易被跳过的一步。你需要明确评测集要覆盖哪些能力维度每个维度的权重是多少。比如一个客服场景的评测集维度可能包括意图识别准确率、答案正确性、政策引用准确性、语气友好度、多轮上下文保持。每个维度下面再细分具体场景比如退换货、物流、支付、投诉。收集样本要尽量贴近真实流量分布。可以从线上日志里采样也可以人工构造。采样时要注意覆盖长尾场景不能只挑简单样本。样本量方面我的经验是每个维度至少 100 条总样本量 500 到 2000 条比较合适。太少统计不显著太多标注成本扛不住。标注答案是最耗时的环节。对于有标准答案的任务比如分类、抽取标注相对简单。对于开放式生成任务比如对话、摘要标注难度大很多。我的做法是先定义评分标准再标注。评分标准要具体到可操作比如“答案正确且完整得 2 分答案正确但不完整得 1 分答案错误得 0 分”。标注时至少两人独立标注计算一致性不一致的样本由第三人仲裁。设计评分要区分自动评分和人工评分。自动评分适合有明确答案的任务比如选择题、数值计算、代码执行。人工评分适合开放式任务。自动评分的优势是成本低、可复现劣势是覆盖不了语义细节。人工评分的优势是灵活劣势是成本高、一致性难保证。实际项目中通常是自动评分打底人工评分抽检。试跑校准是用一批已知表现的模型跑评测集看看分数是否符合预期。如果两个能力差异明显的模型得分接近说明评测集区分度不够需要调整样本或评分标准。这一步很关键但经常被忽略。版本管理是长期维护的基础。评测集要像代码一样管理每次修改都要记录变更内容、变更原因、影响范围。否则过几个月回头看根本不知道分数变化是模型变了还是评测集变了。2.3 样本设计的五个关键原则样本设计直接决定评测集的质量。我总结了五个原则都是在踩坑中总结出来的。原则一覆盖真实分布但要有意倾斜长尾。真实流量中简单样本占大多数如果完全按真实分布采样评测集会偏向简单区分度不够。我的做法是对困难样本过采样让评测集里困难样本占比高于真实流量这样更容易暴露模型短板。原则二一个样本只测一个能力点。如果一个样本同时涉及推理、知识、格式遵循模型答错了你都不知道是哪个能力出了问题。所以样本设计要尽量“正交”每个样本聚焦一个能力维度。原则三答案要唯一且可验证。对于有标准答案的任务答案必须唯一不能有歧义。比如“中国的首都是哪里”答案只能是“北京”不能接受“中国首都北京”和“北京”两种表述都算对而不做归一化。归一化规则要提前定义好。原则四包含负样本和边界样本。负样本是指模型应该拒绝回答或表示不知道的样本比如超出知识范围的问题、有害请求。边界样本是指刚好在模型能力边缘的样本比如需要 5 步推理的数学题。这两类样本最能区分模型的实际能力。原则五定期更新防止污染。私有评测集用久了也可能被模型“见过”尤其是如果你用评测集做微调。所以评测集要定期更新替换一部分样本保持新鲜度。更新频率取决于迭代速度一般每季度更新 10% 到 20%。3. 评测执行从跑通脚本到拿到可信结果3.1 评测环境搭建与参数固定评测环境不统一结果就不可比。这是我在多个项目中反复验证的教训。评测环境要固定的东西包括模型版本、推理参数、提示词模板、评测脚本版本、硬件环境。模型版本要精确到 commit hash 或权重文件哈希不能只说“Qwen2.5-7B”因为不同时间下载的权重可能不一样。推理参数要固定 temperature、top_p、max_tokens、repetition_penalty 等。temperature 对生成任务影响很大评测时一般设 0 或接近 0保证结果可复现。提示词模板要版本化不同模板对结果影响可能超过模型差异。硬件环境也会影响结果尤其是涉及浮点运算的任务。不同 GPU 型号、不同 CUDA 版本、不同推理框架可能导致数值精度差异进而影响生成结果。虽然这种差异通常很小但在评测中要尽量消除。# 评测环境固定示例以常见推理框架为例 export MODEL_PATH/path/to/model export MODEL_REVISIONabc123def export TEMPERATURE0 export TOP_P1.0 export MAX_TOKENS2048 export SEED42 export EVAL_SCRIPT_VERSIONv1.2.0注意事项如果评测涉及多次采样比如 passk要固定随机种子并且记录每次采样的结果方便复现和排查。3.2 自动评分与人工评分的配合策略自动评分和人工评分不是二选一而是配合使用。我的策略是自动评分全量跑人工评分抽样验。自动评分适合的场景包括选择题比对选项、数值题比对数值、代码题执行测试用例、格式遵循正则匹配。这些场景下自动评分准确率高、成本低。但自动评分也有盲区比如模型答案语义正确但表述不同自动评分可能判错。所以自动评分脚本要经过充分测试确保归一化逻辑覆盖常见变体。人工评分适合开放式生成任务比如对话、摘要、创意写作。人工评分的关键是评分标准要细细到标注者不需要主观判断。比如“答案正确性”可以分成“完全正确”“部分正确”“错误”“拒答”四档每档有明确定义和示例。标注者培训也很重要培训不到位一致性就上不去。实际项目中我通常用自动评分跑全量然后按 10% 到 20% 的比例抽样做人工评分计算自动评分和人工评分的一致性。如果一致性低于 90%说明自动评分脚本有问题需要调整。3.3 评测结果的可视化与解读评测结果不是一张分数表就完事了。可视化做得好问题定位快一半。我常用的可视化方式包括雷达图多维度对比、热力图错误分布、箱线图分数分布、趋势图迭代变化。雷达图适合对比多个模型在多个维度上的表现一眼就能看出谁强谁弱。热力图适合看错误集中在哪些类别比如按题型、按难度、按场景分类。箱线图适合看分数的离散程度均值相同但方差不同的模型实际体验可能差很多。趋势图适合看迭代效果每次改动后分数是升是降。解读结果时要注意统计显著性。两个模型分数差 1 个百分点可能只是随机波动。判断显著性可以用 bootstrap 重采样计算置信区间或者用配对检验。样本量越小越要注意这个问题。还有一个容易被忽略的点要看错误样本不只看分数。分数告诉你“好不好”错误样本告诉你“为什么不好”。我每次评测后都会随机抽 20 到 30 条错误样本逐条分析错误原因归类总结。这个习惯帮我发现了不少模型和提示词的隐藏问题。4. 常见问题与排查技巧实录4.1 分数异常波动的排查思路评测分数突然波动是最常见也最让人头疼的问题。我整理了一个排查清单按优先级排序。排查项可能原因验证方法模型版本权重更新或加载错误核对权重哈希推理参数temperature 等参数被改动检查配置文件提示词模板模板版本不一致对比模板文件评测脚本脚本版本更新导致评分逻辑变化回滚脚本复测数据污染评测集样本被模型见过替换样本复测硬件环境GPU 或框架版本变化固定环境复测随机种子种子未固定或未记录固定种子复测排查时按“从外到内”的顺序先确认环境再确认参数再确认脚本最后怀疑模型本身。大部分波动都是环境或参数问题真正模型退化的情况反而少。4.2 评测集“失效”的识别与处理评测集用久了会“失效”表现为分数普遍偏高、区分度下降、和业务效果脱节。识别失效的信号有三个分数天花板效应、模型间差异缩小、业务反馈不一致。分数天花板效应是指所有模型都考 90 分以上区分不出来。这时候要么是评测集太简单要么是模型确实都进步了。判断方法是看错误样本如果错误样本都是边角案例说明评测集需要加难度。模型间差异缩小是指原本差距明显的模型现在分数接近。这可能是评测集被污染也可能是模型能力确实趋同。处理方法是用新样本替换旧样本重新校准。业务反馈不一致是指评测分数高但业务效果差或者反过来。这说明评测集和业务场景脱节需要重新审视评测维度和样本分布。处理失效评测集的方法增量更新 难度分层。增量更新是定期加入新样本替换旧样本。难度分层是把评测集分成简单、中等、困难三档分别统计分数这样即使总体分数饱和困难档仍能提供区分度。4.3 多模型对比评测的公平性保障多模型对比评测最容易出现的不公平是提示词适配差异。每个模型对提示词的敏感度不同用同一套提示词可能对某个模型有利对另一个不利。保障公平性的做法是为每个模型单独调优提示词然后固定下来对比。具体操作是先用一套通用提示词跑一遍然后针对每个模型做少量提示词调优比如调整系统提示、few-shot 示例让每个模型都发挥出较好水平再固定提示词做正式对比。这样虽然增加了工作量但结果更可信。另一个公平性问题是推理成本差异。有些模型需要更多 token 才能给出答案有些模型输出更简洁。如果只看准确率不看成本对比就不完整。我的做法是同时记录准确率和平均 token 消耗计算“性价比”指标。还有采样次数的问题。有些模型单次采样不稳定需要多次采样取最优。如果对比时采样次数不一致结果也不公平。公平的做法是统一采样次数或者同时报告 pass1 和 passk。4.4 评测结果到业务决策的转化评测的最终目的是指导业务决策但评测分数和业务效果之间往往有 gap。缩小 gap 的关键是建立评测分数和业务指标的映射关系。我的做法是在业务上线前用评测集分数预测业务指标然后上线后收集真实数据校准预测模型。比如评测集准确率 85% 对应业务准确率 80%那么下次评测 87% 就可以预测业务准确率约 82%。这个映射关系需要持续校准因为业务流量分布会变。另一个关键是设定合理的阈值。不是分数越高越好而是要看边际收益。从 80% 提升到 85% 可能很容易从 85% 提升到 90% 可能成本翻倍。决策时要考虑投入产出比而不是盲目追求高分。最后评测结果要和业务方对齐。技术团队关注的指标和业务团队关注的指标往往不同。技术团队看准确率、召回率业务团队看转化率、客诉率。评测报告要同时呈现技术指标和业务指标用业务语言解释技术结果这样才能推动决策。5. 评测体系的长期维护与迭代5.1 评测集版本管理与数据飞轮评测集是活资产需要版本管理。我建议用 Git 管理评测集每次修改提交 commit记录变更内容、变更原因、影响范围。评测集文件建议用 JSONL 格式每行一个样本包含样本 ID、输入、参考答案、维度标签、难度标签、来源、版本号等字段。数据飞轮是指评测集和模型迭代相互促进的循环。模型上线后收集 bad case人工确认后加入评测集模型迭代时用更新后的评测集验证确保 bad case 被修复。这个循环转起来评测集越来越贴近业务模型也越来越好。飞轮的关键是bad case 收集渠道要畅通。线上日志、用户反馈、人工抽检都是来源。收集到的 bad case 要分类整理定期评审决定哪些加入评测集哪些作为训练数据。5.2 评测自动化与持续集成评测自动化是长期维护的刚需。手动跑评测不仅效率低还容易出错。我的做法是把评测接入 CI/CD 流程每次模型更新或提示词变更后自动触发评测生成报告和基线对比超过阈值就告警。自动化评测的架构通常包括评测任务调度、模型推理服务、评分服务、结果存储、报告生成。调度可以用 Airflow 或类似工具推理服务用统一接口封装不同模型评分服务实现自动评分逻辑结果存数据库报告用模板生成。# 评测任务调度伪代码 def run_evaluation(model_id, eval_set_id, config): eval_set load_eval_set(eval_set_id) results [] for sample in eval_set: output model_inference(model_id, sample.input, config) score auto_score(output, sample.reference, sample.dimension) results.append({ sample_id: sample.id, output: output, score: score, dimension: sample.dimension }) report generate_report(results, baseline) save_report(report) if report.regression_detected: send_alert(report) return report注意事项自动化评测要设置合理的触发频率太频繁浪费资源太稀疏错过问题。我的经验是模型更新必跑提示词变更必跑日常每天跑一次基线。5.3 评测团队的能力建设评测不是一个人能搞定的事需要团队协作。一个完整的评测团队通常包括评测集构建、标注管理、评测执行、结果分析、业务对接。小团队可以一人多岗但职责要清晰。评测人员需要具备的能力包括业务理解、数据敏感、统计基础、工具使用。业务理解是前提不懂业务就设计不出好评测集。数据敏感是指能发现数据中的异常和模式。统计基础是指能正确解读分数和显著性。工具使用是指能写脚本、跑评测、做可视化。团队建设的关键是标准化流程和持续培训。流程标准化保证不同人做评测结果可比持续培训保证团队能力跟得上业务变化。我建议定期做评测复盘分享典型案例和经验教训让团队共同成长。6. 一些踩坑后的个人体会评测这件事做得越久越觉得“功夫在诗外”。工具和脚本只是表象真正决定评测质量的是对业务的理解和对细节的把控。我见过太多团队花大力气搭评测框架但评测集设计得一塌糊涂最后分数好看但业务不买账。我的体会是评测要从业务中来到业务中去。评测集样本要从真实流量里来评测维度要对应业务指标评测结果要能指导业务决策。脱离业务的评测分数再高也是自娱自乐。另一个体会是评测要“小步快跑”。不要想着一次构建完美评测集先构建一个最小可用版本跑起来用起来然后在迭代中完善。评测集是长出来的不是设计出来的。最后评测要敢于暴露问题。有些团队评测分数不好看就改评测集这是自欺欺人。评测的价值在于发现问题而不是证明模型好。分数低不可怕可怕的是不知道低在哪里、为什么低。把问题暴露出来解决掉模型才能真正进步。