我刚开始接触模型评测的时候，心里其实挺没底的。训练好的模型摆在那里，指标跑出来一堆数字，可这些数字到底能说明什么，我一开始是真说不清楚。后来踩的坑多了才慢慢明白，评测这件事远不是跑个脚本看个分数那么简单。它更像是一套完整的判断体系，帮我们回答一个最朴素的问题：这个模型，到底行不行？
如果你也在准备做模型评测，或者正在被各种评测报告搞得头晕，那这一章就是写给你的。我会把自己这些年做评测的经验、犯过的错、绕过的弯路都摊开来讲，尽量帮你在一开始就把方向找准，少做一些无用功。
1.1 模型评测的定义、价值与常见误区
我自己对模型评测的理解是：用一套可重复、可对比的方法，去测量模型在特定任务上的表现，并且对结果给出合理的解释。它不是简单地报一个准确率，也不是随便找几个例子试一下就下结论。评测的核心在于“有据可查”——你的结论背后得有一套站得住脚的流程和数据支撑。
说到价值，我觉得最直接的一点是帮团队做决策。选哪个模型做底座、要不要上线新版本、某个优化到底有没有效果，这些问题的答案都得从评测里来。没有评测，选型就是拍脑袋，上线就是赌博。我见过太多团队在模型选型时凭感觉，结果上线后效果一塌糊涂，回头补救的成本高得吓人。评测的另一个价值是暴露问题，它能告诉你模型在哪些场景下会翻车，这比单纯看总分有用得多。
常见误区我踩过不少，挑几个最典型的说说。第一个是“只看总分不看细节”，一个模型综合分高，不代表它在你关心的场景里表现好。第二个是“评测集和训练集不分”，数据泄漏会让分数虚高，上线后原形毕露。第三个是“指标堆砌”，觉得指标越多越专业，其实很多指标之间高度相关，堆多了反而干扰判断。还有个特别隐蔽的误区是“一次评测定终身”，模型在变、数据在变、业务也在变，评测得跟着迭代。
1.2 评测对象与任务类型：分类、生成、检索增强、多模态等
评测对象这事，得先搞清楚你评的是什么。最常见的分类任务，比如情感分析、意图识别、文本分类，评测起来相对直接，看准确率、F1这些指标基本够用。我刚开始做评测时就是从分类任务入手的，流程简单、结果好解释，很适合练手。
生成任务就复杂多了，文本摘要、对话生成、翻译这些都算。生成任务的难点在于“好”的标准不唯一，同一个输入可以有很多种合理的输出。这时候光靠自动指标就不够了，得结合人工评测或者用大模型来当裁判。我印象很深的一次是做摘要评测，自动指标分数很高，但人工一看发现摘要漏掉了关键信息，这种问题自动指标根本抓不住。
检索增强生成（RAG）是这两年特别火的方向，评测它得把检索和生成拆开看。检索部分看召回率、准确率，生成部分看忠实度、相关性。我见过不少团队只评生成不评检索，结果模型答得挺流畅，但引用的内容全是编的，这就是评测维度缺失导致的盲区。
多模态评测是另一块硬骨头，图像、文本、音频混在一起，评测设计要考虑模态之间的对齐和融合。这块我还在持续学习，经验不算多，但有一点体会很深：多模态评测的数据集构建成本远高于纯文本，标注规范也得更细致，不然评测结果的可信度会打折扣。
1.3 模型评测教程的学习路径：目标→指标→基准→工具→实验→报告
我把评测的学习路径总结成一条链：目标→指标→基准→工具→实验→报告。这条链的顺序很重要，跳步容易出问题。先明确目标，你评模型是为了选型、为了回归测试、还是为了上线验收？目标不同，后面每一步的侧重点都不一样。
目标定了之后选指标，指标得跟任务匹配。分类任务用准确率、F1，生成任务看BLEU、ROUGE再加上人工评分，大模型能力评测就得覆盖知识、推理、代码这些维度。指标选完找基准，公开基准能快速上手，但要注意数据污染和领域适配的问题。工具这块我后面会专门讲，OpenCompass、lm-evaluation-harness这些都是常用选择，先把一个任务跑通比什么都重要。
实验设计和执行是整条链里最耗精力的环节。数据集怎么划分、提示模板怎么定、采样参数怎么设，这些细节都会影响结果。我建议新手从最简单的配置开始跑，跑通了再逐步加复杂度。最后是报告，报告不是把数字罗列一遍，得说清楚结论、证据、局限和改进建议。我写过不少评测报告，最深的体会是：好的报告能让不看过程的人也能快速抓住重点。
1.4 评测方案设计前的关键问题：评测什么、和谁比、如何判定成功
动手设计评测方案之前，有三个问题必须先回答清楚，不然方案大概率会跑偏。第一个问题是“评测什么”，这听着像废话，但很多人真没想明白。你是要评模型的通用能力，还是评它在某个垂直场景下的表现？是要评它的准确性，还是要评它的安全性和鲁棒性？范围划不清楚，评测就会变成大杂烩。
第二个问题是“和谁比”。评测得有参照系，是跟基线模型比、跟竞品比、还是跟上一版比？我见过一些评测报告，分数列了一堆，但没交代对比对象，读者根本不知道这个分数算好还是算差。对比对象的选择也有讲究，拿一个参数量差十倍的模型来比，结论的说服力会打折扣。基线设置要合理，最好选同量级、同场景下的模型做参照。
第三个问题是“如何判定成功”。这个得在评测开始前就定好，不能等结果出来了再回头找标准。判定成功可以是绝对阈值，比如准确率超过90%；也可以是相对提升，比如比基线高5个百分点；还可以是多指标综合判断，比如准确率不降的前提下推理速度提升20%。判定标准定得越具体，评测结论就越不容易被主观因素干扰。我自己的习惯是把判定标准写在方案文档的第一页，实验过程中反复对照，避免跑着跑着就偏了。
这三个问题回答完，评测方案的骨架就有了。后面章节里的指标选择、基准构建、工具使用、实验执行，都是往这个骨架上填肉。骨架搭正了，后面的工作才有意义。
我刚开始做评测那会儿，最头疼的就是指标这一块。满屏的英文缩写，准确率、精确率、召回率、F1、BLEU、ROUGE、困惑度……每个都好像认识，真到用的时候又拿不准该选哪个。后来项目做多了，我慢慢摸出一个门道：指标这东西不是越多越好，也不是越高级越好，关键得跟你要评的任务对上。这一章我就把自己在指标选择与计算上攒下的经验掰开揉碎讲一讲，尽量让你少走我当年走过的弯路。
2.1 常见自动指标：准确率、精确率、召回率、F1、BLEU/ROUGE、困惑度
准确率是我最早接触的指标，也算是最直观的一个。预测对的样本数除以总样本数，就这么简单。它的好处是解释成本极低，跟业务方沟通的时候说“一百个里对了九十个”，谁都能听懂。可这个指标有个大坑，类别不平衡的时候它会骗人。我做过一个故障检测的项目，正常样本占百分之九十八，模型全预测成“正常”也能拿到九十八的准确率，可实际上它一个故障都没抓出来。那次之后我养成了一个习惯：拿到分类任务先看类别分布，分布偏得厉害就直接上精确率和召回率。
精确率和召回率是一对孪生兄弟，得放在一起看。精确率回答的是“模型说是正例的里面有多少真的是正例”，召回率回答的是“真正的正例里面模型抓到了多少”。这两个指标天生打架，你把判定阈值调高，精确率上去了召回率就下来，反过来也一样。F1是它俩的调和平均，用来给一个综合分。我自己的经验是，具体用哪个得看业务代价。垃圾邮件过滤宁可错杀不可放过，召回率优先；法律文书检索错一个代价很大，精确率优先。F1适合那种两边都得兼顾、又说不清哪边更重要的场景。
生成任务常用的BLEU和ROUGE，我一开始用得很嗨，后来发现它们有明显的天花板。BLEU看的是n-gram重叠，ROUGE看的是召回层面的重叠，本质都是在比对参考答案的字面相似度。问题在于生成任务的“好”很多时候不体现在字面上。我评过一个摘要模型，BLEU分数挺高，人工一看发现它把原文的句子原封不动搬过来了，信息密度低得可怜。这类指标适合做快速筛查和版本间对比，真要做质量判断还得搭配人工或者更强的评判方式。
困惑度这个词听着吓人，其实就是模型对一段文本的“惊讶程度”。困惑度越低，说明模型越觉得这段文本顺理成章。它在语言模型预训练阶段特别好用，能反映模型对语言分布的拟合程度。拿它来评下游任务就得小心了，困惑度低不代表任务表现好，这两件事之间没有必然的因果关系。我一般把它当辅助指标看，主要用来监控训练过程有没有跑偏。
2.2 大模型能力指标：知识、推理、代码、鲁棒性、安全性、公平性与效率
大模型的能力评测跟传统任务评测完全不是一个路数。传统分类任务一个准确率能打天下，大模型不行，它的能力维度太散，得拆开来一项一项看。知识这块我一般用问答准确率来衡量，给模型一批事实性问题，看它答对的比例。这里有个细节得注意，得区分“不知道”和“答错了”，模型胡编一个答案跟老实说不知道，性质完全不一样。
推理能力的评测要复杂一些。单步推理用准确率还凑合，多步推理就得看整个推理链对不对。我试过用最终答案准确率来评数学应用题，结果发现有些模型答案是蒙对的，中间步骤错得离谱。后来我改成步骤级评分，虽然标注成本上去了，但能看出模型到底会不会推。代码能力现在主流用pass@k，就是让模型生成k个方案，看有几个能通过单元测试。这个指标挺实在的，跑得过就是跑得过，跑不过就是跑不过，没什么模糊地带。
鲁棒性、安全性、公平性这三块经常被忽略，我在实际项目里吃过亏。鲁棒性看的是输入有扰动时模型表现掉多少，比如加个错别字、换个句式，性能断崖式下跌就说明模型不够稳。安全性得有专门的对抗样本集，测模型会不会输出有害内容、会不会被提示注入带偏。公平性要看模型在不同群体上的表现差异，这个在涉及人的场景里特别重要。效率指标容易被当成工程问题甩给后端，我觉得评测阶段就该把它纳进来，延迟、吞吐、显存占用这些数据直接影响模型能不能落地。
2.3 人工评测与LLM-as-a-Judge：评分表设计、一致性检验与偏差控制
自动指标覆盖不到的地方，就得靠人来补。人工评测听着简单，做起来全是坑。我最早做人工评测的时候，就给了标注同学一句话：“给这个回答打个分，一到五分。”结果收上来的分数根本没法用，有人打分严有人打分松，同一个人上午和下午的标准都不一样。后来我才明白，评分表得设计得足够细。把“相关性”“准确性”“完整性”“流畅度”拆成独立维度，每个维度写清楚一分是什么样、五分是什么样，最好配上正反例。
一致性检验是人工评测的生命线。我一般会让至少两个人评同一批样本，然后算一下评分者间的一致性，Cohen's kappa或者Krippendorff's alpha都行。一致性太低说明评分标准有歧义，得回头改评分表。这个环节不能省，我见过团队跳过一致性检验直接拿平均分用，最后结论被质疑到没法收场。
LLM-as-a-Judge这两年被用得越来越多，说白了就是拿一个大模型当裁判去评另一个模型的输出。它便宜、快、可扩展，适合大批量初筛。用的时候有几个偏差得防着。位置偏差是指裁判倾向于偏好排在前面的答案，解法是把两个答案的顺序对调再评一次。长度偏差是指裁判喜欢长的回答，哪怕长的都是废话。自我偏好是指裁判模型偏爱跟自己风格相似的输出，选裁判的时候得避开跟被测模型同源的。我现在的做法是LLM裁判加人工抽检，LLM跑全量，人工抽查百分之五到十做校准，两边对不上就回头查裁判的提示词。
2.4 指标选择原则与任务匹配：避免单一指标误导与指标堆砌
指标选择这件事，我的第一条原则是：先想清楚这个指标会被谁看、用来做什么决定。给算法同学看的指标可以细一点，方便定位问题。给业务方看的指标得粗一点，直接对应业务价值。给管理层看的指标最好就一两个，多了反而没人看。我见过一份评测报告列了二十多个指标，翻到第三页读者就迷路了。
单一指标误导的情况太常见了。准确率会被类别不平衡骗，BLEU会被复制粘贴骗，pass@k会被简单题刷分骗。我的应对办法是每个核心维度至少配一个互补指标，准确率配召回率，BLEU配人工评分，pass@k配难度分层统计。互补的意思是这两个指标从不同角度刻画同一件事，一个涨一个跌的时候能提醒你去看看到底发生了什么。
指标堆砌是另一个极端。有些团队觉得指标越多显得越专业，把能算的全算一遍，报告厚得像本书。这种做法的坏处是指标之间高度相关，信息冗余严重，读者抓不住重点。我现在的习惯是控制在五到八个核心指标，每个指标在报告里都得能回答“为什么选它”。选不出来的就砍掉，别心疼。
2.5 指标计算示例与常见统计口径说明
光讲概念容易飘，我拿个具体例子把计算过程走一遍。假设一个二分类任务，一百个样本，模型预测结果是这样的：真正例四十个，假正例十个，真负例三十五个，假负例十五个。准确率就是（40+35）/100，等于百分之七十五。精确率是40/（40+10），等于百分之八十。召回率是40/（40+15），约等于百分之七十二点七。F1是精确率和召回率的调和平均，算下来大概百分之七十六。这几个数摆在一起看，能发现模型偏保守，精确率高召回率低，漏判比误判多。
统计口径这块有几个坑我得提醒一下。多分类任务算指标的时候，微平均和宏平均结果能差不少。微平均是把所有类别的预测合在一起算，样本多的类别权重大。宏平均是先算每个类别的指标再取平均，每个类别权重一样。类别不平衡的时候这两个口径的结论可能完全相反，报告里必须写清楚用的哪个。BLEU有好几个变体，BLEU-1到BLEU-4，还分带平滑和不带平滑的，不同工具算出来的数经常对不上，跨报告对比的时候得确认口径一致。
还有一个经常被忽略的点是指标的波动范围。单次评测跑出来的数只是个点估计，样本量小的时候波动能吓死人。我现在的做法是至少跑三次不同随机种子，报均值加标准差，条件允许的话再算个置信区间。两个模型分数差两个点，如果置信区间大面积重叠，这个差距很可能不显著，别急着下结论说谁赢谁输。样本量估算也有讲究，想检测出五个点的差异和想检测出一个点的差异，需要的样本量差着数量级，这个在实验设计阶段就得算好，别等跑完了才发现样本不够。
指标讲完了，接下来得聊聊基准。我刚入行的时候以为指标和基准是一回事，后来被项目狠狠教育了一顿才明白：指标是尺子上的刻度，基准是那把尺子本身。选错了基准，刻度再精细也白搭。这一章我就把自己踩过的基准坑、攒下的自建评测集经验，还有数据污染这些糟心事儿一件件捋清楚。
3.1 主流大模型评测基准概览：MMLU、C-Eval、GSM8K、HumanEval、HELM等
MMLU是我接触的第一个大模型基准，五十七个学科、一万多道选择题，覆盖面确实广。我一开始拿着它给团队里的模型跑分，看到分数挺高兴，后来仔细看学科拆分才发现，模型在数学和物理上的表现跟人文社科差了老大一截，总分数把问题全盖住了。用MMLU我更建议看子集分布，别只盯着那个总分。C-Eval是中文版的类似物，学科设置偏国内教育体系，做中文模型评测绕不开它。它跟MMLU有一个共同的问题——选择题格式对模型来说太友好了，答对不代表真的会，猜对的概率也不低，四个选项纯瞎蒙也有四分之一的期望。
GSM8K我印象特别深，小学数学应用题，看着简单，实际非常考验多步推理能力。我拿它测过好几个模型，有的模型答案对了但中间步骤对不上，后来我把评分逻辑改成看推理链才抓出这批“蒙对党”。HumanEval是代码评测的经典基准，一百多道题，配了单元测试，跑得过就是跑得过。它的题目难度偏基础，测大模型的代码能力有点不够看，现在社区里出现了不少扩展版本，题目更多、场景更复杂。HELM的思路跟前面几个不太一样，它不追求单一分数，而是从多个场景、多个维度做综合评测，更像一套评测方法论而不是一个数据集。我挺喜欢HELM这种设计哲学，做评测的时候会借鉴它的维度拆分思路。
这几个基准各有各的定位，我在项目里一般不会只用一个。知识面看MMLU和C-Eval，数学推理看GSM8K和它的变体，代码看HumanEval系列，整体框架参考HELM。把它们组合起来看，才能拼出一个相对完整的模型画像。
3.2 基准选择与组合策略：能力维度覆盖、难度分布与领域适配
选基准这件事，我的经验是先画一张能力雷达图，把你要评的模型能力拆成几个维度，然后给每个维度找一个对应的基准。知识一条线、推理一条线、代码一条线、长文本一条线、多轮对话一条线，每条线上配一到两个基准就够了。我见过有的团队拿七八个知识类基准堆在一起，跑出来的报告全是知识维度，其他能力全是空白，这种组合策略就是有问题的。
难度分布容易被忽略。一个基准如果全是简单题，模型分数虚高，区分度也差。我现在的做法是先做一次题目难度分层，简单、中等、困难各占一定比例，分开看模型的表现。有些模型在简单题上几乎满分，到了困难题断崖式下跌，这种情况在总分上完全看不出来。领域适配也得考虑，通用基准跑得好不代表在你的业务领域也能打。我做过一个医疗问答项目，模型在通用评测上分数很漂亮，一上医疗专有数据集就露馅了，术语理解、诊疗逻辑全都不对路。
我的组合策略一般是“三七开”：七成通用基准保底，三成领域基准做针对性检测。通用基准用来做横向对比，看看模型在行业里大概什么位置；领域基准用来做落地判断，看它到底能不能扛你具体的业务。比例可以按项目调，纯研究性质的项目通用基准多放一点，奔着上线去的项目领域基准权重得提上来。
3.3 自建评测集教程：样本设计、标注规范、质量控制与防泄漏
公开基准跑多了就会发现，它们跟你的业务总有隔阂。自建评测集这件事早晚得做，我自己的经验是从小样本起步，别一上来就想着搞个上万条的大工程。样本设计阶段我最看重的是覆盖度，业务里出现过的问题类型、用户问法、边界情况，尽量都收进去。我一般会先列一张问题类型清单，给每种类型分配样本配额，配额按业务实际占比来定，高频问题多放，长尾问题也不能漏。
标注规范写得多细都不为过。我现在的做法是给每类样本配一个标注手册，写清楚什么样算正确、什么样算部分正确、什么样算错误，每种判定都配正反例。复合型任务还得拆维度标注，比如一个问答样本要分别标答案准确性、信息完整性、表达清晰度。标注同学培训完得做一轮试标，试标一致率达标了才正式开工。质量控制上我会安排交叉标注，至少两成样本双人独立标注，算一致性系数，低于阈值就复盘规范。
防泄漏是自建评测集的生命线。我吃过一次亏，评测集里有些样本跟训练数据高度相似，模型跑出超高分数，上线后表现却一塌糊涂。现在的做法是评测集构建完之后跑一遍去重，跟训练数据做相似度匹配，超过阈值就剔除。样本来源也得控制，尽量用新采集的、模型训练时没见过的数据，别图省事从已有语料里直接抽。
3.4 基准使用注意事项：数据污染、提示敏感性、版本差异与可复现性
数据污染这事现在越来越严重。大模型的训练数据动辄几万亿token，公开基准的题目很可能在预训练阶段就被模型见过了。我判断一个基准有没有被污染，会看模型分数是不是高得离谱，或者用同义改写后的题目再测一遍，分数掉太多就说明有记忆成分。社区的应对办法是定期更新基准，或者保留一部分不公开的测试集，我倾向于自己建个私有holdout集，百来条也行，关键是不外泄。
提示敏感性是个隐蔽的坑。同一个模型、同一批题目，换个提示模板分数能差好几个点。我测过一个模型，在零样本提示下勉强及格，换成少样本示例后分数蹭蹭上涨，说明它的能力在不同提示形式下稳定性很差。用基准的时候得把提示模板固定下来，报告里写清楚，别今天这个模板明天那个模板，分数没法横向对比。版本差异同样得小心，同一个基准不同年份的版本题目可能变了，评测工具算分口径也可能变了，跨报告对比前先确认版本号对齐。
可复现性是老生常谈。随机种子、采样参数、评测脚本版本、依赖库版本，这些信息我都要求记录进评测日志。光记还不够，得能一键复跑。我现在的习惯是把整个评测环境打包成容器，几个月后想复查结果，把镜像拉起来就能跑，不用重新配环境。这件事前期费点功夫，后期省下的排查时间能翻好几倍。
3.5 从公开基准到业务场景评测集的迁移方法
公开基准到业务评测集之间有一条不小的鸿沟，直接搬过来用基本行不通。我的迁移方法第一步是任务映射，把公开基准里的任务类型跟你的业务任务对一遍，找到形态最接近的那类，看它的样本构造方式和评分逻辑能不能借鉴。比如你的业务是多轮客服对话，那HumanEval那种单轮的形式就不太适用，可能得从对话类基准里找参考。
第二步是样本改造。挑一批形态相近的公开样本，把内容替换成你的业务场景。这一步不是简单换词，得保留原样本的考察意图，只换外壳。我做过一个金融合规问答的评测集，就是从通用问答基准里挑了几十条，把问题情境改成金融场景，答案按监管要求重新标注。改完之后跑一遍小模型验证难度是否合理，太难太易都得调。
第三步是彻底自采。改造样本只能解决起步阶段的问题，长期还得靠业务真实数据。我从线上日志里定期采样、脱敏、标注，慢慢积累出自己的评测集。这套东西建起来之后回报很大，模型选型、版本回归、线上监控全能用上。配套的维护机制也得跟上，评测集不是建完就完事，业务变了、模型变了、用户问法变了，样本得跟着迭代，我一般一个季度做一次全量review，把过时的样本替换掉，补充新的边界案例。
基准聊完，工具得跟上。我刚开始做评测那会儿，全靠手写脚本调API、存结果、算指标，一个模型跑下来得折腾大半天，换个模型还得把脚本改一遍。后来被逼着上工具，才发现这玩意儿能省下来的时间远超想象。不过工具也不是拿来就能用，选错了、配歪了，照样踩坑。这一章我按自己用过的几套工具，从安装到跑通到自动化，一步步讲。
4.1 常用评测工具与框架：OpenCompass、lm-evaluation-harness、HELM等
我第一次系统用评测框架选的是lm-evaluation-harness，主要是它跟HuggingFace生态贴得近，模型加载、数据加载都很顺。它把任务定义拆成配置文件和代码两层，想加新任务照着现有模板改一改就行。缺点是文档偏简，有些参数得翻源码才知道什么意思，我当初调批量推理那块被卡了两天。
OpenCompass是国内团队做的，中文基准支持得比较全，C-Eval、CMMLU这些开箱即用。它的配置文件写法比harness友好一些，数据集、模型、评测器分得清楚。我用它跑过一轮多模型的横向对比，一次配置批量出分，结果表格直接生成，省了不少手工活。HELM那套我之前提过思路好，实际用起来偏重，部署一套完整的HELM环境要拉不少依赖，适合做体系化评测的团队，个人开发者上手成本偏高。
我现在手上的组合是OpenCompass跑中文任务和常规对比，lm-evaluation-harness补一些社区新基准，HELM的维度拆分思路拿来设计自建评测。三套东西各管一摊，不用强求一套通吃，工具本来就是干活的，顺手最重要。
4.2 工具安装配置与首个评测任务跑通
装工具这一步我吃过不少亏，先说环境。Python版本一定要对齐，OpenCompass和harness对新版本的支持有时间差，我现在固定用3.10，踩坑概率小很多。依赖装完先跑官方给的冒烟测试，别急着上自己的模型，拿它自带的小数据集跑一遍，确认框架本身是通的。这一步花十几分钟，能省掉后面排查是框架问题还是模型问题的麻烦。
配置模型接入的时候，API模型和本地模型是两条路。本地模型看框架支持哪些推理后端，vLLM接进去速度快但显存要求高，小机器上我用transformers直接加载，慢就慢点。API模型重点是key管理和并发控制，别一上来开太高并发，被限流了还以为是代码bug。我第一个成功跑通的任务是C-Eval的一个子集，一百来条，跑完对一下官方示例的输出格式，确认无误再放大到全量。
跑通第一个任务之后，我习惯把配置存成模板，模型路径、数据集、评测参数分开放。下次换模型只改模型那一段，其他原样复用。这个习惯看起来不起眼，项目多了之后能省下大量复制粘贴的时间，也降低了配错参数的概率。
4.3 批量评测、分布式执行、缓存管理与结果汇总
批量评测是绕不开的场景，我一般十几二十个模型一起跑。裸跑肯定不行，得靠框架自带的批量能力，OpenCompass的多模型配置能一次提交全部任务，排队执行。本地机器扛不住的时候上分布式，多卡或者多机，评测框架大多支持把数据集切分到不同进程，结果最后合并。切分的时候注意样本级别的均衡，别一个进程全是简单题另一个全是难题，否则合并出来的分数有偏差。
缓存这块我要多啰嗦几句。推理结果缓存和指标计算结果缓存是两层，推理缓存能让你在只改评分逻辑的时候不用重新跑模型，省下的算力非常可观。我把缓存目录按模型版本加数据集版本命名，换版本自动隔离，避免脏缓存污染结果。有些框架默认缓存开在临时目录，跑完就清，得手动指到持久化路径上。
结果汇总我踩过一个坑，不同任务跑出来的json文件名规律不一样，直接脚本遍历容易漏。后来我统一让框架把结果输出到按任务命名的子目录里，汇总脚本按目录结构扫，日志里也记清楚每个任务的状态。跑完一批之后先看有没有失败任务，失败的重跑，全部成功再进汇总环节。汇总表我一般保留原始json，表格只是视图，原始数据留着方便后面复查。
4.4 自定义评测脚本与工具框架集成
框架覆盖不到的任务，自定义脚本就派上用场了。我写自定义脚本的原则是尽量贴着框架的接口走，别另起炉灶。比如harness里加自定义任务，照着它的task定义写一个类，数据处理、提示构造、指标计算三个方法填进去，框架的批量、缓存、日志能力全部继承过来。自己从头写个脚本虽然自由，但批量调度、结果汇总这些轮子得重新造，划不来。
跟框架集成还有一层是模型适配。有些私有模型或者特殊部署方式框架不直接支持，我会写一个轻量适配层，把模型调用封装成框架约定的接口形式，其余流程不动。适配层里我会加超时重试和错误记录，模型服务偶尔抖一下不至于让整个评测任务挂掉。调试适配层的时候先拿三条样本跑，确认输入输出格式对了再上量。
自定义脚本的另一个场景是业务专用指标。通用框架里的指标库里没有你要的口径，比如某个领域特有的评分规则，这种情况我写个独立的评分脚本，输入是框架跑出来的原始推理结果，输出是结构化分数。这样推理和评分解耦，评分别的模型也能复用同一个脚本，评分逻辑改了也不影响已经跑完的推理结果。
4.5 工具选型对比：覆盖范围、易用性、扩展性与社区维护
工具选型我一般看四个点：覆盖范围、易用性、扩展性、社区维护。覆盖范围看它内置了多少基准和指标，开箱能用的东西多不多。易用性看文档、配置写法、报错信息是否友好，这一点上OpenCompass对我更顺手，harness的报错有时候太隐晦。扩展性看加自定义任务和自定义模型的成本，写代码量小、接口清晰的就占优。
社区维护的重要性容易被低估。我选框架之前会翻一下最近的commit记录和issue响应速度，几个月没动静的项目慎用，基准更新快，工具跟不上就废了。HELM维护节奏偏慢但架构稳，适合把评测当长期基建的团队。小团队我会推荐先从lm-evaluation-harness或OpenCompass起步，社区活跃、资料多，遇到问题能搜到答案。
我的实际建议是别在选型上纠结太久。工具之间概念是通的，任务定义、模型适配、指标计算这套逻辑哪家都差不多，先拿一个跑通全流程，后面换工具迁移成本没想象的那么高。我见过团队为了选型讨论了两周，一行评测没跑，这才是最大的浪费。选个社区活跃的先用起来，跑出第一批结果，再根据实际痛点决定要不要换或者补。
工具这一章讲完，下一章进实验设计。工具是把手，实验设计是脑子，两个得配合着来。我踩过的那些工具坑，说到底都是实验方案没想清楚就急着上工具导致的，先想明白要评什么、怎么比、判定标准是什么，再去挑工具配环境，顺序别反。
上一章聊工具的时候我提过一句，工具是把手，实验设计是脑子。这话不是随便说的。我自己就干过那种事——环境搭好了、脚本跑通了，兴冲冲地拿模型上去跑一轮，结果出来一看，分数挺高，但仔细一想根本不知道这个分数能说明什么问题。没人告诉我这个模型到底行不行，因为一开始就没想清楚要回答什么问题。这一章我按实验从设计到执行的顺序来讲，重点放在怎么让结果站得住脚、以后还能再跑出来。
5.1 明确评测问题与假设：选型、回归、对比与上线前验收
做评测实验之前，我会先逼自己写一句话：这次评测要回答什么问题。听起来很虚，实际非常管用。常见的问题大概分四类。选型的问题是“这几个候选模型哪个更适合我的场景”，回归的问题是“新版本比旧版本有没有退步”，对比的问题是“我的模型和某个参考模型差在哪”，上线前验收的问题是“这个模型够不够格进生产环境”。四类问题对应的实验设计完全不一样。
我踩过最典型的坑是拿着选型的问题做了个对比的实验。当时要在一堆开源模型里挑一个做客服问答，我图省事直接跑了一轮公开基准的分数排名，选了第一名。上线之后发现那个模型在长对话里容易丢上下文，而我的业务场景恰恰是多轮对话为主。公开基准里没有这一项，我一开始的问题就没问对。选型的问题必须围绕业务场景来拆，基准分数只能当参考，不能当结论。
回归和对比这两类问题对实验的严谨性要求更高。回归实验里，我会把旧版本的结果当成基线，任何新版本的分数波动都要能解释来源。对比实验我会要求同一套数据、同一套提示模板、同一套评分逻辑，连采样参数都不许变。上线前验收最容易糊弄，很多人跑几道题觉得差不多就放行了。我现在的做法是验收必须有一个事先写好的阈值和一份明确的检查清单，跑完对着清单一条条打勾，没过就是没过，不给自己找理由。
假设也要提前写下来。比如我预期新模型在多步推理题上的准确率会比旧模型高五个点，这个预期写进实验方案里。跑完发现只高了两个点，那就要去分析为什么，是模型本身的问题还是提示模板不匹配。没有假设的实验，跑完看到什么结果都能自我解释一通，那种评测做了等于没做。
5.2 实验设计：数据集划分、提示模板、采样参数与基线设置
数据集这块，公开基准直接用没问题，但我会额外划一小份留出集。留出集不参与任何调参和提示优化，只在最后验证的时候跑一次。我见过有人拿测试集反复调提示模板，调到分数满意为止，这个分数就没有意义了。自建评测集的话，划分要在标注阶段就定好，训练、验证、测试三份物理隔离，文件命名和目录结构上都分开，避免手滑混用。
提示模板的设计比很多人想的要讲究。同一个模型，换个提示写法，准确率能差出十几个点。我的做法是主实验用一套标准模板，另外准备一到两套变体模板做敏感性检查。标准模板的写法参考该基准的官方示例或者论文里的设置，别自己发挥。变体模板用来回答“这个模型的分数对提示有多敏感”这个问题。提示里涉及few-shot样例的，样例从训练集里抽，固定下来，不要每次跑随机抽，否则结果没法复现。
采样参数是另一个容易出岔子的地方。温度、top_p、最大生成长度这些参数，评测分类任务的时候我一般把温度设成0或者接近0，让模型输出尽量确定。生成类任务要采样的时候，参数必须写进实验配置里，跟结果一起存档。最大生成长度尤其要注意，设短了答案被截断，评分脚本拿到半截答案判错，模型的真实水平被低估。我一般按任务的最长参考答案长度再留百分之三十的余量。
基线设置经常被忽略。跑新模型之前，先确认基线模型在同配置下的结果。基线结果要么来自你自己复现，要么来自官方发布的数字，两者最好不要混用。混用的时候要注明来源，因为官方数字可能用了不同的提示模板或者评分口径。我现在的习惯是每个实验都带一个固定的基线模型一起跑，哪怕这次评测跟它没关系，带着跑一遍能验证整个流水线是通的，相当于一个内部对照。
5.3 执行与质量控制：日志、版本管理、随机种子与复现实验
执行阶段我最看重的是日志。日志要记的东西比大多数人想的多：模型名称和版本号、数据集名称和版本号、提示模板的哈希值、采样参数、随机种子、运行的起止时间、每条样本的原始输入输出。这些东西当时觉得啰嗦，事后排查问题的时候每一条都可能救命。我吃过一次亏，跑完一批结果发现有个模型的分数异常低，查了两天才发现是数据集加载的时候某个字段解析错了，日志里没记原始输入，只能重跑。
版本管理不只是代码的版本管理，配置和数据也要管。我的做法是实验目录下放三个东西：一份实验配置的yaml文件、一份代码的git commit哈希、一份数据集和模型的版本说明。这三样凑齐了，别人拿到你的实验目录就能复现。配置文件的命名我带上日期和简短描述，比如20240512_客服模型对比_v2，别用final、new这种词，过两周自己都分不清哪个是哪个。
随机种子这件事说起来简单做起来烦。Python的random、numpy的random、深度学习框架的随机初始化、采样过程的随机性，每一处都要设。我一般在实验配置里放一个全局种子，代码启动的时候统一设置，同时记录到日志里。有一点要承认，即使种子全设了，不同硬件或者不同框架版本下结果也可能有微小差异。所以复现实验的时候，我关注的不是小数点后第三位是否一致，而是主要结论是否稳定。
复现实验我建议在实验方案里就写进去。主实验跑完之后，隔一天用同样的配置再跑一遍，对比两次结果的差异。差异在合理范围内，说明流水线是稳的。差异很大，那就得查原因，是缓存的问题、服务稳定性的问题还是代码里有隐藏的随机性。这个步骤花的时间不多，但对结果可信度的提升非常明显。
5.4 常见失败模式与排查：格式不匹配、截断、评分脚本错误
格式不匹配是我遇到频率最高的失败模式。模型的输出格式跟评分脚本期望的格式对不上，评分脚本一刀切判错，模型分数直接崩。典型场景是要求模型输出选项字母，模型输出的是完整句子，或者带了个前缀“答案是A”，评分脚本做精确匹配就挂了。排查的时候我会先抽十条样本人眼看输出，确认模型确实在按预期格式回答，再去看评分脚本的正则或者解析逻辑是不是覆盖得够全。
截断的问题前面提过，这里再展开说。截断分两种，一种是模型生成被最大长度限制截断，另一种是输入提示太长被截断。前者看输出末尾是不是突然断掉，后者看日志里记录的输入长度。生成类任务被截断的样本要单独标出来，算分的时候要么排除要么在报告里注明。我现在的做法是在评分脚本里加一个截断检测，输出长度等于最大长度的样本打上标记，汇总的时候单独统计比例。
评分脚本错误往往最隐蔽，因为分数看起来很正常。我自己写错过一次，多分类任务里把类别标签的映射关系写反了，两个类别的分数对调，总分看起来没大问题，但分类细项全错。发现这个问题靠的是混淆矩阵，光看准确率根本看不出来。从那以后我养成了一个习惯，评分脚本写完先拿几条人工标注的样本跑一遍，逐条对答案，确认无误再上全量。
还有一个失败模式是环境不一致导致的。本地跑得好好的，换到服务器上分数就不对了。常见原因是依赖库版本差异、模型加载方式不同、默认参数不一样。排查这种问题我会先跑一个最小验证集，在两边各跑一遍，对比每条样本的输出，定位到第一条不一致的样本，然后顺着这条样本查环境差异。这个方法比盲猜快得多。
5.5 评测成本控制：样本量估算、缓存复用与并行调度
评测是真烧钱，API调用按token计费，本地推理按GPU小时算。控制成本得从样本量开始。公开基准动辄上万条，全量跑一轮成本不低。我的做法是先跑一个分层抽样的子集，比如按难度和领域分层抽五百到一千条，看结果稳不稳定。子集上的结论和全量结论如果排名一致，后续对比实验就用子集跑，只在最终报告的时候跑全量。样本量的估算可以用置信区间的思路，粗略地说，想区分两个模型百分之二的差距，子集规模至少得覆盖到能把这个差距的置信区间分开。
缓存复用在我的实验流程里是标配。推理结果缓存按模型版本加数据集版本加提示模板哈希值来命名，三者任何一个变了缓存就失效，自动重新推理。这样我在调评分脚本或者做错误分析的时候，不用重新调模型，直接从缓存里读结果。缓存目录我放在持久化存储上，定期清理太老的版本，别让缓存把磁盘撑爆。
并行调度要控制好粒度。API模型按并发数控制，别一上来就开满，分批加压观察错误率。本地模型按GPU显存和batch size来，batch size设太大容易OOM，设太小又浪费算力。我的经验是先小批量试跑，把batch size调到显存占用的百分之八十左右，留点余量。多卡并行的时候注意数据集切分的均衡，按样本数量均匀切，不要按文件切，有的文件大有的文件小，按文件切会导致负载不均。
最后说一个省钱的小技巧，实验方案里写明中止条件。比如子集上某个模型的分数比基线低了十个点以上，那就不用跑全量了，直接排查原因。没有中止条件的话，一批实验跑下来可能一大半都是无效的，钱花了结论没有。条件提前写进方案里，执行的时候按规则停，不心疼也不纠结。
实验设计这一章就聊到这。回过头看，这里面的东西没有哪一条是特别高深的，难的是一以贯之地执行。我自己的体会是，实验设计的价值不在于让你跑得更快，而在于让你跑完之后敢拿结果说事。下一章我们聊结果分析和报告，那一步是把实验数据变成结论的最后一公里，同样马虎不得。
上一章结尾我说结果分析是把实验数据变成结论的最后一公里。这话我现在还是这么认为。跑完实验拿到一堆数字，很多人第一反应是排个名、看谁高谁低，发个表格就完事了。我干过这种事，后来被一个问题问住了：两个模型差1.2分，这个差距是真的还是噪声？我当时答不上来。这一章就从这个尴尬说起，把结果怎么读、报告怎么写、评测怎么持续做下去讲清楚。
6.1 结果统计与显著性分析：置信区间、方差与配对比较
只看平均分是评测里最常见也最危险的习惯。我现在拿到结果，第一件事不是看均值，而是看这批样本上分数的分布。同一个模型在同一批题上，不同样本的得分波动可能很大。有的题它稳稳做对，有的题它时对时错。均值把这一切都抹平了，看起来干净，实际藏了很多信息。我会把每条样本的得分列出来，算一个标准差，再看最小值和最大值，心里对模型的“发挥稳定性”有个数。
置信区间这个东西听着学术，实际用起来特别朴素。样本量有限的时候，均值本身就有不确定性。我的做法是用bootstrap重采样，把这批样本反复抽一千次，每次算一个均值，得到一千个均值之后取百分之二点五和百分之九十七点五分位数，就是置信区间。如果两个模型的置信区间大面积重叠，我不会急着说谁更好。上次有个场景，模型A比模型B高了0.8分，我一开始想报A胜出，算了置信区间发现重叠得厉害，后来扩大样本量重跑，差距缩到了0.2分。幸好没早下结论。
配对比较是我最近两年才认真用起来的。两个模型跑的是同一批样本，那就不是两组独立数据，而是成对的。用配对的方法做检验，比直接比均值敏感得多。分类任务上我会看两个模型在每条样本上是不是一个对一个错，把这类不一致的样本单独拎出来做McNemar检验。生成任务上配对比较麻烦一点，我会按样本算分差，看分差的分布是不是显著偏离零。说起来这些统计方法都不复杂，关键在于养成习惯，每次对比之前先问自己一句：这个差距我有没有把握说是真实的。
小样本上的差异尤其要克制。五百条样本上差三个点，放到五千条样本上可能就变成一个点甚至反过来。我现在的规则是，样本量低于一千的对比实验，结论里一律加“初步观察”四个字，不当成定论往外报。这个自我约束救过我几次，避免了把噪声当信号推给业务方。
6.2 错误分析与切片分析：按任务、难度、领域定位模型短板
总分只能告诉你模型行不行，错误分析才能告诉你它哪里不行。我每次跑完实验都会抽一批错误样本人工看，数量大概五十到一百条，随机抽加上按置信度低优先抽。看的时候我会给每条错误打一个类型标签，比如理解错题意、知识缺失、推理跳步、格式没对齐、被干扰信息带偏。标签体系不用很细，能覆盖主要问题就行。打完标签统计一下，模型的主要短板基本就浮出来了。
切片分析是把总分拆开看的另一个手段。按任务类型切片，看分类、问答、摘要各自的表现。按难度切片，简单题和中难题的准确率差距能反映模型的鲁棒性。按领域切片，医疗、法律、金融这些垂直领域经常是模型的重灾区。按输入长度切片也很有用，我遇到过总分不错的模型，长文本一进去分数断崖式下跌，这种问题在总分里根本看不出来。切片维度不用一次铺太多，我会先按业务最关心的两三个维度切，发现问题再往下钻。
混淆矩阵是分类任务上的必备工具。准确率这东西会骗人，类别不平衡的时候更明显。有次一个三分类任务，模型准确率百分之八十五，看着挺体面，画了混淆矩阵才发现它把其中一个少数类几乎全判成了另一个类，另外两个类的高准确率把这个灾难盖住了。从那以后我评分类任务必看混淆矩阵，再看每个类别的精确率和召回率，最后才看总体准确率。
找到短板之后我会做一件事：把典型的错误样本摘出来，附在报告里。光说“模型在长文本上表现较差”太虚，附上两三个具体例子，读者一下就能明白差在哪、差到什么程度。这些例子也是后续改进的抓手，提示工程、检索增强还是换模型，很多时候看几个错误样本就能判断方向。
6.3 评测报告撰写：结论、证据、局限与改进建议
写报告之前我会先想清楚读者是谁。给技术团队看的报告可以放细节、放实验配置、放错误案例；给业务方或者管理层看的，结论必须在最前面，一页纸能把事说清楚。我一般会准备两个版本，一个完整版一个摘要版。摘要版就一页，三句话：评了什么、结论是什么、建议怎么做。完整版作为附件，谁需要细节谁去翻。
报告的骨架我固定成四块：结论、证据、局限、建议。结论先行，每一条结论都必须有对应的证据支撑，证据要能追溯到具体的实验和具体的数字。局限这部分很多人不爱写，觉得是自曝其短。我的看法正相反，主动写清楚局限，读者才会信任你的结论。数据覆盖不到的场景、样本量的限制、评测环境和真实环境的差异，这些写明白了，结论的适用边界就清楚了。
改进建议要具体到可执行。我见过太多报告结尾写“建议进一步优化模型效果”，这种话等于没说。好的建议是“长文本场景下建议引入分段检索再拼接”“多轮对话的上下文丢失问题建议优先用滑动窗口方案验证”。每条建议后面我会标一个优先级和预估成本，方便决策方排期。
报告里的数字呈现也有讲究。我不喜欢一上来甩大表格，十几个模型几十个指标，读者眼睛都花了。我的习惯是先给一张主表，只放核心指标和最终排名，其他指标放到附录。图比表更直观，模型对比用条形图，切片分析用分组柱状图，趋势变化用折线图。图表下面一定要有一句结论性的说明，别让读者自己去解读。
6.4 持续评测与上线后监控回归：评测集迭代与模型版本追踪
一次评测只能反映一个时间点。模型在迭代，数据在漂移，业务场景也在变，评测集如果一直不更新，很快就失去参考价值。我现在的做法是评测集按版本管理，每个季度做一次小版本更新，补充新场景的样本、修正标注有问题的样本、剔除已经过时的样本。更新的时候会保留一个固定的“锚定集”，这部分样本永不改动，用来保证跨版本的分数可比。
数据泄漏是评测集迭代里要盯紧的事。新补充的样本不能和训练数据有重叠，尤其是自建评测集和业务方共用数据源的时候。我一般会用n-gram重叠或者向量相似度做一轮筛除，相似度高的样本人工复核。另外提示模板也要防泄漏，有些团队把评测集的答案 inadvertently 写进了few-shot样例里，这种低级错误一旦发生，分数再高也是假的。
上线后的监控回归是另一条线。离线评测分数好看，线上指标不一定跟着涨。我会在上线后头两周重点盯几个线上指标，比如用户追问率、人工兜底率、答案被点踩的比例，把这些指标和离线评测的结论做对照。如果线上表现明显偏离离线预期，说明评测环境和真实环境之间有gap，得回头查评测集的设计是不是漏了关键场景。
模型版本追踪我建议做成一张表，每次模型更新都往里填一行：版本号、更新时间、离线评测分数、线上关键指标、是否回滚。这张表看着简单，时间长了就是团队的资产。哪次更新出了问题、哪个指标从什么时候开始下滑，翻表一目了然。我们团队现在做模型灰度，第一件事就是翻这张表看上一个版本的表现基线。
6.5 进阶方向：多模态、Agent、RAG评测与评测体系治理
多模态评测是我目前觉得最难的一块。文本评测好歹有标准答案可比对，图像、音频、视频的输出怎么判对错，很多时候连人都要争论半天。我现在用的办法是分层评：先评感知层，图文匹配、物体识别这类有明确答案的任务用自动指标；再评理解层和生成层，这部分靠人工评分和LLM-as-a-Judge结合。多模态的LLM-as-a-Judge本身可靠性还在验证中，用它评图像描述质量，我见过明显的偏差，长描述更容易拿高分，不管内容对不对。
Agent评测和传统模型评测的思路差别很大。传统评测看最终输出对不对，Agent要看整个过程：工具调用选得对不对、参数填得对不对、多步任务里有没有走弯路。我现在评Agent会用轨迹评分加结果评分两套。轨迹评分看步骤合理性，结果评分看任务完成度。有个坑要提醒，Agent的任务完成有时候靠运气，错误路径也能歪打正着，所以光看完成率会高估能力，必须结合轨迹看。
RAG评测要拆成检索和生成两段来评。检索段看召回率、精确率、排序质量，生成段看忠实度、相关性、答案完整性。我踩过一个坑，端到端评RAG效果不好，一直以为是生成模型的问题，拆开一查是检索召回率太低，模型根本没拿到该有的上下文。拆开评之后，问题定位快了很多。忠实度这块我现在会用基于NLI的方法自动评加上人工抽检，纯靠人工成本太高，纯靠自动又怕漏判。
评测体系治理听起来很虚，做起来其实很具体。谁来定评测标准、新评测集怎么评审、评测结果怎么归档、不同团队的评测口径怎么对齐，这些都是治理问题。我们团队现在的做法是设一个评测评审会，每月一次，新评测集和新指标要过会才能进正式评测流程。标准统一了，跨团队的评测结果才能互相比较。这件事没有终点，模型在变，评测体系也得跟着长。
写到这里这一章就差不多了。回头看这五节，从统计到切片、从报告到持续监控、再到几个进阶方向，核心其实是一条：评测不是跑完就结束的动作，而是一个持续循环的系统。结果要经得起追问，报告要让人看得懂、信得过，评测集和评测体系要跟着模型一起进化。这套东西搭起来之后，你会发现评测真正发挥价值的地方，不是给模型打个分，而是帮团队在每一个决策节点上少走弯路。
