大模型评测这事儿，看着是跑几个榜单、算几个分数，实际上水很深。外行看热闹，觉得跑个MMLU、刷个榜单就是评测了；内行都知道，评测体系的设计直接决定你手上的模型到底能不能用、值不值得上线。我从做大模型应用落地和模型选型评估的角度，把这一整套方法论掰开揉碎讲清楚，看完你可以直接上手搭一套自己的评测方案。
1. 评测到底在测什么：先想清楚三类能力维度
很多人一上来就急着选数据集、跑分数，这是典型的本末倒置。评测的第一步不是找题，而是想明白你要回答什么问题。同样是“这个模型行不行”，问的人和用的人不同，答案完全不一样。研发团队关心的是模型智商有没有提升，产品团队关心的是某个具体场景能不能用，而运维或成本负责人关心的是同等效果下能不能换个小一点的模型省钱。
1.1 基础能力层：模型“知道什么”
这一层回答的是知识储备和基础推理问题。典型评测点是语言理解、常识问答、数学计算、代码生成、逻辑推理等。对应到数据集就是MMLU、C-Eval、GSM8K、HumanEval这类通用基准。这个维度的特点是“标准化程度高、横向可比性强”，但它只能告诉你模型“大体上”什么水平，没法告诉你它在你那个垂直场景里是不是真的好用。
基础评测的实战意义在于筛选基线。我一般拿它做第一道闸门，先筛掉明显不及格的模型，省得后面花大量精力做垂直场景适配。
1.2 场景适配层：模型“会不会用”
这一层最容易被忽略，却是应用方最该关心的。同一个模型，写周报、做客服、抽取合同条款、做数据库问答，表现可能天差地别。原因在于大模型的能力释放高度依赖提示词、上下文结构、输出格式约束，甚至依赖指令微调阶段有没有见过类似的数据分布。
场景化评测的思路是：从你真实的业务里取一批有代表性的任务，做成评测集。比如你做法律文书助手，就从合同文本里抽条款，设计“找出争议焦点”“生成风险提示”“对比新旧条款差异”这三类任务，每类准备几十条到几百条样本。关键是题目必须来自真实场景，不能自己凭空编，编出来的题测不出真实水平。
1.3 安全与对齐层：模型“能不能信”
包括越狱攻击、有害内容生成、幻觉率、偏见歧视等。大模型在开放域对话时，如果没有安全对齐，它可能会一本正经地给出危险建议，或者被几个精心构造的恶意提示词绕过限制。这类评测不只要看拒答率，还要看拒答的姿势——是用“我不能回答这个问题”的通用话术，还是用“我们可以讨论如何在合法范围内帮到你”的建设性引导，两者体验差别很大。
幻觉评测是安全层里最难做的，因为需要知道标准答案才能判断模型输出是否偏离。实际操作中，我会把输出拆成若干个事实性断言，再逐个比对上下文或知识库。指令遵循能力也是关键维度——让模型输出JSON却带了一堆解释，就好比让实习生整理表格结果他在表格里写批注，得专门训练和评测。
1.4 稳定性与鲁棒性：模型“什么时候会崩”
这个维度包括同题多次回答的波动、对提示词扰动的抵抗力、长上下文的记忆能力等。实际碰到的案例非常典型：同一个数学题，换个数字模型会做，换种问法就出错；同一份长文档，问题放在开头能答对，放在第8000字之后就答不对了。这背后涉及的其实是模型在不同位置注意力分配的能力。
我之前做过一个测试，用同样的30道题跑同一个模型十次，其中有5道题模型给出的答案每次都不一样，有的甚至对错反复横跳。这个结果直接影响了它能否上线做自动评分——一个标准方差这么大的模型，你不敢让它做自动化决策。
2. 评测集怎么构建：数据配比和题目设计
评测集是整个评测体系的核心资产。榜单可以被刷爆，但你手里沉淀的评测集才是别人拿不走的。
2.1 三源数据配比策略
高质量评测集至少由三块组成。
第一块是通用公开数据，占30%左右，用MMLU、C-Eval、GSM8K这些成熟数据集，保证横向对比时有参照物。网上有现成的下载包和HuggingFace数据集可以直接拉取，关键是固定版本号，别今天跑V1明天跑V2，分数差距会说不清。跑公开题还有个价值：如果公开题得分远高于自建场景题，说明你的场景数据覆盖有短板，模型极有可能是“题库型选手”——见过类似题能答对，换实际场景就露馅。
第二块是业务真实数据，占50%以上。做法是从生产环境日志里抽真实用户问题，人工清洗和标注答案。一个数据点至少要包含输入上下文、标准答案或评分标准、难度等级、考察能力项。业务数据是整个评测集的护城河，也是最能反映模型真实场景能力的部分。
第三块是对抗性数据，占20%左右。包括易错题、边界题、恶意输入、误导性问题。比如你做一个金融客服问答，就需要专门准备一些“诱导模型给出投资建议”的对抗样本，用于检验安全红线。这部分数据需要持续从线上badcase里积累，属于长期建设。
2.2 出题标准与答案设计
好的评测题不是简单把业务问题丢给模型，而是经过精心设计。
题目必须自包含。模型没有你脑子里那些上下文，问题本身就要能把背景交代清楚。把“这个条款有效吗”改成“根据以下合同第4条关于违约责任的约定，如果乙方逾期交货且未提前书面通知，甲方能否单方解除合同？请根据合同条款回答并说明理由”，效果截然不同。
答案设计上，客观题用标准答案做精确匹配或关键词匹配，主观题更依赖打分。主观题打分有两条路线：一条是规则+关键词的硬评分，适合格式规整、要点明确的场景；另一条是模型打分，用GPT-4或更强的模型当裁判，好处是速度快、尺度稳定，坏处是裁判模型本身也有偏好，下面细说。
2.3 数据污染与防泄漏
这是当前评测中极其棘手的问题。跑分高可能不是真本事，而是模型训练时见过这些题。所以要做两件事：一是评测题定期清洗，尤其是从公开数据集来的题目，每隔一段时间就拿当前最强模型跑一遍，凡是它满分答对的题，直接丢进“疑似污染池”，人工再审一遍。二是自建数据的隔离，场景数据只从真实业务里抽，不上传公开平台、不打到公开数据集、不写进任何论文，像保护种子资源一样保护核心评测数据。
还有个细节：如果团队里有人同时负责数据和训练，要明确权限隔离，保证做数据的人知道题目分布但训练方拿不到，做训练的人一旦看到了题目分布，评测就失去了意义。
3. 评测执行的关键细节：配比、抽检与工具选型
3.1 评测跑分前先确定“匹配策略”
同样的评测集，评测结果差异极大，主要原因就是匹配方式不同。指标上分类准确率、ROUGE、BERTScore、LLM-as-Judge不同策略都会影响分数。比如做选择判断题，用模型直接输出“A/B/C/D”和用模型自由生成一段话再从中提取结论，对模型的要求完全不同，分数自然不同。
跑分前必须确定三件套：模型输出格式约束、提示词模板、匹配与打分方式。以选择题为例，做法是要求模型务必以“答案是：字母”格式输出，然后精准提取字母和标准答案比对。每个题设定最大解码长度，避免个别题“想太多”把答案写飞了。
3.2 半自动人工抽检机制
自动跑分会出幻觉，特别是模型打分作为裁判的时候。我建立了一套抽检机制：每次跑完评测，按比例抽取结果人工核对，客观题抽5%、主观题抽20%，至少100条起步。如果抽检发现自动评分和人工判断不一致率超过5%，就回炉调整评分策略。
对于模型打分偏好问题，有个实用技巧：打出来的分普遍偏高是默认倾向，普遍偏低是过于苛刻，前后矛盾则是提示词写得不够细。我一般会在提示词里写明“分数区间说明”和“扣分细则”，再加上“先分析后打分”的要求，让裁判模型先充分思考再输出分数。
3.3 评测集版本管理
评测集和代码一样需要版本管理。每次更新记录清楚：加了什么题、删了什么题、改动理由是什么。线上固定在一个版本上作为季度打分依据，新版本先在沙箱里跑通再切换。否则评测集在悄悄变，模型分数也在变，你根本分不清模型是真的变强了，还是题目变简单了。
4. 主流评测体系与工具盘点
4.1 通用基准榜单怎么看
MMLU是知识广度，C-Eval偏中文知识和推理，GSM8K是小学数学应用题，HumanEval是做函数补全，MATH是竞赛级数学题，BBH是更难的综合推理。看榜单时绝对不能只看总分，要分开看细项。一个模型总分挺高，但代码项拉胯，你让它写SQL就大概率不行。
还有个容易踩的坑：不同机构公布榜单时的采样和提示词模板很可能不同，同一模型在不同榜单排名差异巨大。所以同一榜单内部比排名有意义，跨榜单比分数就得小心。我一般只认自己跑的分数，外部榜单仅作为初筛参考。
如果你要做相对公平的横向对比，必须固定一套配置：同样的温度（生成参数里的随机性）、同样的提示词模板、同样的解码长度、同样的评测子集、同样的硬件环境。最好一个脚本顺序跑完，别今天跑两个、明天跑两个，环境稍有差异结果就不可比。
4.2 开源评测工具选型
实际操作中可以组合使用多个开源框架。OpenCompass（司南）对中文支持好，适合做国内模型的对比和场景评测，配置灵活但上手成本偏高。lm-evaluation-harness是老牌框架，英文生态强、代码清晰，集成新模型比较方便，对中文支持相对弱一些。还有专门面向智能体和多模态的评测框架，比如构建Agent评测环境验证工具调用和多步决策能力。
我的习惯是OpenCompass为主干做场景化评测，lm-eval做公开英文基准的快速交叉验证。两个工具对同一数据集的打分会略不一样，这是prompt模板差异导致的，别纠结谁对谁错，固定一个为主就行。
4.3 LLM-as-Judge的实战参数
LLM-as-Judge是目前处理主观题最高效的方式，但必须做“裁判一致性校验”。做法是准备一批已知答案的题目，跑三次裁判打分，算一下方差。方差大说明裁判本身不稳定，或者题目边界不清晰，先把题目打磨好再大规模跑。线下跑小批量主观题评测，优先选旗舰闭源模型当裁判，线上追求性价比，开源强模型往往也够用。
最容易被忽略的坑是裁判模型的上下文长度限制。被评测模型输出很长时，裁判决议会忽略尾部内容，导致漏判关键信息，必须截断或提前在提示词里要求“先定位关键段落再评分”。
还有一个技巧：评测记录全部保存成带时间戳的日志文件，方便复盘。每次评测都记录评测集版本、模型版本、提示词版本、配置参数、运行时间这五要素，复盘时才能精准定位问题是谁引入的。
5. 常见错误和避坑经验
❌ 评测集过小：20道题跑出来的分数没有统计意义，波动大到你没法判断模型是否真的有变化。起步至少200道题，核心场景建议500道以上，跑分才有参考价值。
❌ 用单一指标做决策：只盯着Accuracy或ROUGE，把真实业务里更关心的“回答有没有踩到红线”给忽略了。评测指标应该和业务目标强对齐，计算类任务看准确率，摘要类任务就要看关键信息召回率。
❌ 直接拿测试集做提示词调优：这等于开卷考试。用评测集调提示词，分数是漂亮了，但一到真实场景就原形毕露。正确做法是单独划分dev集做调优，评测集只在最后跑一次。
❌ 主观题只有标准答案没有评分标准：如果没有“写出关键词X得一半分，完整逻辑链得满分”这种细颗粒规则，评分一致性很差。而评分不一致的评测结果没法指导优化，因为你不知道模型到底差在哪。
❌ 只看分数不看输错样本：分数只能告诉你模型大概什么样，样本分析才能告诉你模型错在哪儿。所以每次跑完必须留出时间看badcase，并按错误类型归类——是理解错了、推理错了，还是输出格式没遵守，这些才是下一步优化模型和提示词的方向。
评测体系是个需要持续迭代的东西，没有一套完美方案能一劳永逸。关键是从业务真实需求出发，把评测集、评分体系、观测流程这个闭环建起来。我个人的体会是：花在评测上的时间永远值得，因为评测清楚了你才知道每一步优化到底是在前进还是在瞎忙。先把框架搭起来，哪怕糙一点，跑起来再迭代，远比比一个完美的方案却迟迟不动手强得多。
