我做微调评测这些年，最怕听到的一句话就是“模型好像变好了”。变好是个太含糊的说法。你得说清楚，是原来会的东西没丢，还是新任务上确实涨了分，又或者是评测集恰好撞上了训练数据。这三个问题指向完全不同的东西。能力保持说的是底座模型原本具备的通用本领有没有被微调过程冲掉，任务提升看的是目标领域的指标有没有实质进步，泛化风险识别则要回答模型有没有在评测集上表现漂亮、换个场景就露馅。我通常会把这三件事分开看，每一项单独设计验证手段，避免一个总分把问题糊弄过去。
从我的实践感受来说，能力保持这条线最容易被忽视。很多人微调完只看目标任务分数，涨了就收工。我吃过这个亏。有次做医疗问答微调，目标指标从62分提到78分，团队挺高兴，结果拿通用常识题一测，掉了将近10个点。模型像是被拧得太紧，旧本领忘了不少。那次之后我养成了一个习惯：评测清单里必须包含一组底座模型擅长、但跟微调任务无关的题，专门用来盯能力保持。泛化风险识别更像体检里的肿瘤筛查，平时不做，出问题就是大问题。我会刻意准备一些分布外样本和带扰动的输入，看模型的表现是不是断崖式下跌，跌得狠说明它学到的可能只是表面模式。
评测维度设计：效果、效率、鲁棒性、安全性与部署成本
效果当然是主角。任务准确率、F1、BLEU、人工评分，这些指标该上就上。我自己的习惯是把自动指标和人工抽查混着用，自动指标看大盘趋势，人工看细节质感。有回自动评分挺高，我抽了二十条输出一看，格式全对但内容空洞，评分系统被格式骗了。效率这块我主要盯推理延迟和吞吐量，微调后的模型体积变化、显存占用、单条请求的响应时间，这些数字在实验室里不太显眼，上了生产环境就是真金白银。鲁棒性我理解成抗折腾的能力，输入加个错别字、换个句式、带点噪声，表现不能崩得太离谱。
安全性和部署成本是两条容易被评测报告一笔带过的维度。安全性我会检查模型在敏感话题上的表现有没有因为微调而松动，比如原本会拒绝的诱导性问题，微调后是不是变得有问必答。部署成本说起来很现实，模型大小、量化后的精度损失、推理框架的兼容性，这些直接决定微调成果能不能落地。我见过挺多项目指标漂亮但模型胖了一圈，推理成本翻倍，业务方直接摇头。这几个维度之间有时候会打架，效果上去了效率下来了，或者鲁棒性好了但部署变重了，评测阶段就得把这些矛盾摆到桌面上，让人做取舍时有据可依。
线性评测流程：评测准备、基准选择、实验执行、结果分析与结论形成
我习惯把评测当成一条流水线来走，虽然它远没有听起来那么线性。评测准备阶段要定清楚这次评测回答什么问题，是验证微调有没有效，还是排查过拟合，还是给上线决策提供依据。问题不一样，后面的活儿差别很大。我通常会写一段话放在评测文档最前面：“本次评测要回答的是……”这句话能省掉后面很多扯皮。基准选择得跟着问题走，没有万能基准这回事。我倾向于搭一个基准组合，通用能力占一部分，目标任务占大头，再留一两条对抗性质的数据做压力测试。
实验执行阶段最枯燥也最容易出岔子。我要求自己每次都把运行命令、参数配置、随机种子记下来，哪怕当时觉得“这肯定不会再跑第二遍”。事实证明总会跑第二遍的。结果分析我一般分两步走，先看汇总数字，再钻到个案里看错误类型。汇总数字告诉我有没有问题，个案分析告诉我问题出在哪。有一次准确率只掉了两个点，我觉得问题不大，翻错误案例发现模型把一类特定格式的输出全丢了，这两个点背后是系统性的退化。结论形成阶段我会刻意写一段“本次评测没覆盖什么”，把局限性亮出来，免得读者把结论放大。
评测指标矩阵与可复现规范：指标口径、随机种子、环境记录与版本管理
指标口径这件事我踩过坑。同一个“准确率”，有的人算的是完全匹配，有的人算的是包含匹配，小数点后面差一位，结论可能就反过来了。我现在会在评测文档里把每个指标的计算方式写死，用的是哪个库、什么配置、有没有做归一化处理，写得啰嗦一点没关系，后来的人能照着复现就行。随机种子也是同理，生成任务里温度设成0.7还是1.0，结果稳定性差别不小，我会在报告里注明每次运行的种子值，重要实验跑三到五个种子取均值和方差。
环境记录这块我吃过暗亏。有次评测结果跟同事对不上，查了半天发现是依赖库版本差了一个小版本号，某个评分函数的行为变了。现在我要求自己记下硬件型号、驱动版本、框架版本、甚至CUDA版本。版本管理方面，模型权重、评测数据、评测脚本各管各的版本号，三者绑定成一个评测版本记下来。听着有点繁琐，做习惯了也就那样。我总跟团队说，可复现不是给审稿人看的，是给三个月后的自己留条后路。那时候你多半已经忘了当时怎么跑的，能照着记录原样跑一遍，比什么都强。
挑数据集这件事，我的教训是别贪多，也别迷信“大而全”。刚入行那会儿我恨不得把能下载的公开基准全塞进评测脚本里，跑完几万条样本，出了一张密密麻麻的分数表，结果业务方一句“所以能不能上线”就把我问住了。数字多不等于信息多。基准数据集的选择得从评测目标往回推，这次评测到底想回答能力保持、任务提升还是泛化风险的问题，选的数据集得对着这些答案去。任务匹配度永远排第一，拿一个跟微调任务八竿子打不着的基准来凑数，分数再漂亮也是噪音。
领域覆盖要讲究分层，不能只覆盖任务的核心场景。我做金融文本微调那次，训练数据全是财报问答，评测集也只放了同类问题，模型在测试集上表现很好。换成人行政策解读类的问题，同一个模型就开始胡说八道。领域覆盖得往上下游各扩一圈，核心任务占大头，周边场景也得留位置。难度分层同样不能省，我习惯把评测样本按难度粗略分成三档，简单题看基本功有没有丢，中等题看任务掌握程度，难题看模型的上限在哪里。一份全是简单题的评测集，测出来的分数没有区分度，谁跑都高。
规模成本是现实约束，样本量够用就行，不是越多越好。我现在的经验值是每个评测子集几百条量级，经过难度分层和领域覆盖设计之后，这个规模能给出稳定的信号。上万条的评测集跑一次成本不低，关键是跑完也未必看得过来。有次我贪心上了一个两万条的评测集，跑完出报告只用了一百多条错误案例，剩下的数据基本在睡觉。现在我更倾向于精选加人工抽查的路子，数据集小一些，但每一条都有明确的设计意图。
训练集、验证集与测试集划分策略及数据污染与泄漏排查
划分策略听起来是教科书内容，实际操作里全是坑。按比例随机切分是默认动作，我一般用八比一比一，验证集用来做模型选择，测试集只在最后用一次。这里有个容易松动的纪律：测试集不要反复拿来看结果调参数，看多了它就不叫测试集了，叫第三个验证集。我有段时间忍不住，每次改完超参就顺手跑一遍测试集，后来发现模型在测试集上的表现跟线上真实反馈差了一截，原因是测试集被我的调参动作间接影响了。
时间敏感的任务得用时间切分，不能随机切。文本分类、情感分析这类任务随机切分问题不大，但涉及预测未来趋势或者用户行为演化的任务，随机切分会让训练集里混进未来信息。我见过一个销量预测的微调项目，随机切分后测试集准确率虚高，换成按时间切分，分数掉了十五个点，这才是真实水平。
数据污染和泄漏排查是脏活，但必须做。大模型预训练语料动辄万亿token，公开基准的测试题很可能已经在预训练阶段被模型见过。我现在的做法是对每条测试样本做一遍近似匹配检索，把跟训练语料高度相似的样本标出来，能剔除的剔除，剔不掉的至少在报告里注明。还有一种泄漏是微调训练集和测试集之间的，同一个问题换个问法出现在两边，这种靠去重和语义相似度检测能抓出不少。有次我发现测试集里将近百分之八的样本跟训练集有重叠，清理之后模型的真实分数比原来低了三分，这三分就是泄漏撑起来的。
评测基准组合：通用能力基准、领域任务基准与对抗/扰动评测集
基准组合我一般按三块来搭。通用能力基准负责盯住底座的旧本领，常用的有常识推理、阅读理解、基础数学这几类，选两三个轻量级的就够，目的是能力保持的预警而不是全面体检。领域任务基准是重头戏，占比最大，选的时候跟微调目标对齐，指标口径也得跟业务侧确认过。对抗和扰动评测集是压力测试，我通常会拿一部分领域样本做人工扰动，加错别字、改句式、插入无关信息，或者构造边界案例看模型的反应。
这三块的比例我通常按二比五比三来配，通用能力占两成，领域任务占五成，对抗扰动占三成。比例不是死的，看评测阶段调整。初筛阶段领域任务可以多放，快上线了对抗扰动得加码。我有个习惯是每次评测至少保留一条“钉子”样本，就是那种模型如果真学会了任务就该答对、死记硬背大概率会错的题，用来分辨模型是真掌握了还是碰巧撞上了。
对抗评测集的构造最费心思。我试过用规则自动生成扰动，比如随机替换同义词、加标点噪声，效果一般，生成的样本有时候连我自己都看不懂。后来改成人工加模板结合的方式，人工构造一批高质量的对抗样本，再用模板做批量扩展。还有个取巧但有用的做法是拿模型自己的错误案例反过来做对抗集，把之前评测里模型做错的题整理归类，形成一个专项测试子集，每次迭代都跑一遍，看这些顽固错误有没有被修掉。
对照实验设计：基座模型、微调模型与不同微调策略的公平比较
对照实验是评测里最有说服力的部分，也是最容易做歪的部分。基座模型作为参照系必须纳入，不跑基座模型的评测报告我基本不看，因为微调后的分数单独摆出来没有意义。基座模型跑一遍，微调模型跑一遍，同一套提示模板、同一组解码参数，条件完全对齐。我见过只报微调后分数的报告，问起来就说“基座模型太差了没必要测”，这其实是心虚，基座表现差才能说明微调带来的真实增量。
不同微调策略之间的比较更麻烦，公平性不好把握。全参微调和LoRA微调放在一起比，参数量差着数量级，学习率和训练轮次的最优值也不一样，直接拿各自默认配置跑出来的结果没法比。我现在的做法是给每种策略单独做一轮小规模超参搜索，找到各自比较合理的配置再上正式评测。这么做过一次之后发现，LoRA在低资源场景下确实有优势，但全参微调在数据量充足时上限更高，这个结论不把两边都调到合理状态是得不出来的。
还有一个容易忽略的对照是数据消融。同一套微调配置，训练数据换不同的子集或者不同的质量等级，跑出来的结果能说明数据本身的贡献。我做过一次实验，把训练数据里的低质量样本清掉三成，微调后模型在领域任务上的分数持平，但在对抗集上的表现好了将近五个点。这个发现比单纯比较微调前后分数有价值得多，它直接指向了数据清理的优先级。
评测协议与基线设置：提示模板、解码参数、评分规则与人工/自动评估结合
提示模板是个不起眼但影响很大的变量。同一个模型，提示词里加一句“请逐步思考”和什么都不加，分数能差好几个点。我的做法是把提示模板当超参来管，每种评测任务定一到两套模板，写进评测协议里，所有对比模型统一使用。模板的选择尽量跟实际使用场景贴近，线上产品怎么给提示，评测就怎么给。有次我为了刷分给评测专门设计了一套精心打磨的模板，模型分数确实高了，上线后用户拿不到那么好的提示，真实效果打了折扣。
解码参数的口径也要锁死。温度设0.7还是0，测试的是模型分布还是模型确定性输出，这是两个性质不同的评测。我一般会把温度0和温度0.7的两组结果都跑一遍，温度0看下限稳定性，温度0.7看采样质量。top-p、重复惩罚这些参数同理，全部写进协议文档，每次评测照单执行。评分规则得分自动和人工两条腿走路。自动评分用BLEU、ROUGE或者模型打分器都行，快而且便宜，适合大样本筛查。人工评估抽百分之五到十的样本做盲评，标注员不知道哪条输出来自哪个模型，评分维度拆成相关性、流畅度、事实准确性这几项。
自动和人工结果打架的时候，我一般信人工。有次自动评分器给微调模型打了八十五分，人工抽查发现模型学会了套模板，答案格式完美但内容要么空泛要么偏题，人工给的实际可用率不到六成。那次之后我在评测协议里加了一条硬性要求：任何自动评分超过基线五个点以上的结果，必须经过人工复核才能写进结论。评测协议写成文档还有一个好处，团队里谁来跑评测都能按同一个标准操作，换人的时候交接成本低很多。
3.1 过拟合评估指标：训练验证差距、泛化间隙、学习曲线与早停敏感度
训练损失一路降，验证损失先降后升，这条经典曲线在我第一次做微调时就给我上了一课。当时盯着屏幕上训练损失降到0.02，心里美滋滋，转头跑测试集，分数还不如基座模型。训练验证差距是最直白的过拟合信号，我的习惯是每次训练都画出两条损失曲线叠在一起，肉眼扫一眼大概就能判断模型是“学过头”了还是“没学够”。这个指标简单到有点土，但比任何花哨的评估都先让我发现问题。
泛化间隙是训练验证差距的升级版，不只看损失，还得看任务指标上的落差。我在一个文本分类任务里见过训练集F1冲到0.96、测试集F1只有0.78的模型，间隙接近二十个点，这种模型拿到线上就是灾难。泛化间隙我通常同时看绝对值和相对比例，绝对值大说明过拟合严重，相对比例高说明模型在测试分布上水土不服。有个经验阈值，任务指标上训练测试差超过八到十个点就得警惕了，当然不同任务容忍度不一样，生成类任务的间隙天然比分类任务大一些。
学习曲线能帮我看清趋势，不光看终点。每训一个epoch存一次checkpoint，在每个checkpoint上跑验证集指标，把曲线画出来。好的微调曲线应该是验证指标先快速爬升，然后在一个平台上稳住。如果验证指标在某个epoch之后开始往下出溜，那就是过拟合的起点。早停敏感度是个容易被忽略的指标，我拿验证集上表现最好的那个checkpoint和最后一个epoch的checkpoint做对比，如果两个版本测试集差距超过三四个点，说明模型对早停位置很敏感，这种模型在部署时换个训练轮次结论就可能翻盘，稳定性不够。
验证集本身也会被“看穿”，这是我吃过亏的地方。验证集看多了调参多了，模型实际上是在对验证集过拟合，只是这个过程发生在人的决策层面。我现在会留一个完全不动的小型“锁定验证集”，只在关键决策节点用一次，跟测试集的区别是它不完全封存，但频率极低。有一次我对比了常规验证集和锁定验证集上的模型排名，前三名的顺序居然换了两个，常规验证集上排第一的模型在锁定集上掉到第三，原因就是调参阶段对它太熟悉了。
3.2 过拟合识别方法：交叉验证、正则化消融、扰动鲁棒性与分布外测试
交叉验证在微调场景里做全量K折成本太高，我用的是简化版：把训练数据切出三到五折，每折单独训一个轻量模型，看各折验证指标之间的方差。方差大说明模型对数据划分敏感，泛化能力不稳。有个情感分析项目，五折交叉验证里四折F1在0.85左右，有一折突然掉到0.72，查下去发现那一折里某个类别的样本特别少，模型在那折上等于没学过这个类别。交叉验证不一定非要跑满K折，关键是通过重复划分暴露模型对数据分布的脆弱点。
正则化消融是我判断过拟合的另一个手段。微调时我会开dropout和权重衰减，然后做一组对照实验，分别关掉正则化跑一遍。如果关掉正则化之后验证指标明显变差、训练指标变好，说明正则化确实在压制过拟合，参数设置方向是对的。如果关不关正则化结果差不多，那要么模型没怎么过拟合，要么正则强度还不到位值得再调。有次我发现关掉dropout后验证损失只涨了0.5个点，训练损失倒是降了一大截，说明那个模型本身的过拟合风险不高，后面就放心减少了正则约束，让模型多学点任务细节。
扰动鲁棒性测试更接近实战视角。我拿测试集做人工扰动，加随机错别字、打乱语序、插入无关句子，看模型输出掉多少。过拟合的模型往往在原始测试集上分数很高，稍微加点噪声就崩。有个NER微调模型在干净测试集上实体识别F1有0.91，加了百分之十的随机字符扰动后掉到0.74，基座模型反而只掉了六个点。这个对比很说明问题：微调模型学到的可能是表面模式而不是真正的实体识别能力。我现在会把扰动前后的分数差当成一个独立指标写进报告，差值超过五个点就标红。
分布外测试是过拟合识别的终极考验。从评测集里划出一个和训练数据分布明显不同的子集，比如训练用的是财经新闻，分布外测试就用社交媒体上的财经讨论。领域内分数高、分布外分数塌方的模型，泛化能力存疑。我在一个法律文书生成任务里做过这个实验，同领域测试集BLEU有0.62，切换到口语化的法律咨询场景掉到0.41。这个落差基座模型身上只有0.12，微调把它拉大到了0.21，说明微调过程让模型过度特化到了训练分布的细节上。从那以后分布外测试成了我每次微调评测的固定环节，不做完心里不踏实。
3.3 统计显著性与误差分析：置信区间、显著性检验、错误类型与案例归因
分数是点估计，置信区间才是概率陈述。我早些年出评测报告只写个准确率，后来被数据科学家同事怼过一回：“你这个86.4和85.9有区别吗？” 从那以后我养成了一个习惯，评测指标必须带置信区间。小样本评测集我用bootstrap重采样算区间，几百条样本跑一千次重采样，得到95%置信区间。有次两个微调版本的准确率差了1.2个点，看上去微调版更好，算了置信区间发现两个版本的区间大面积重叠，这个差异没法排除随机波动。报告里我老老实实写“差异不显著”，虽然老板看着不太高兴，但总比拿一个站不住的结论去推动上线强。
显著性检验我用得比较多的是配对检验，同一批测试样本上两个模型的输出逐条对比，用McNemar检验或者配对t检验看差异是否统计显著。这里有个细节值得强调：检验的样本单位得对齐，不能一个模型在A测试集上算分、另一个在B测试集上算分然后硬比。我见过有人拿不同随机种子跑出来的分数做显著性检验，种子引入的方差比模型差异还大，检验出来的p值毫无意义。标准做法是固定测试集、固定解码参数、固定随机种子，只让模型本身变化。
误差分析是评测里最花时间也最出洞察的部分。我把错误类型分成几大类：知识性错误、理解性错误、格式性错误、拒答错误。知识性错误是模型不知道或者记错了事实，理解性错误是读错了题目或者搞混了指令，格式性错误是答案内容对但输出格式不符合要求，拒答错误是该答的时候不答了。分类完之后按比例排优先级，如果知识性错误占大头，那可能得补训练数据或者调整知识注入方式；格式性错误多的话，提示模板和输出约束就得改。
案例归因我一般做双层分析，先看批量统计，再挑典型案例细看。批量统计看错误在难度分层上的分布，难题错误多属于正常，简单题错误多说明基础能力受损。典型案例我会把模型输出、参考答案、输入原文摆在一起看，判断模型是“不会”还是“没看清”还是“想多了”。有个生成任务里模型频繁把否定句处理成肯定含义，翻了几十条错误案例发现训练数据里否定样本比例不到百分之三，模型根本没学到否定模式。这个发现直接推动了下一轮数据增强的方向，比笼统说一句“模型还有提升空间”有用太多了。
3.4 评测结果报告与迭代建议：结论呈现、风险提示、数据与模型优化闭环
评测报告我踩过的坑是写成了流水账，数字堆了一堆，读的人抓不住重点。现在的报告结构固定成三块：一块是核心结论，用三到五条说清楚这次微调在关键指标上到底行不行，每条结论后面挂数据支撑；一块是风险提示，把过拟合信号、分布外表现、扰动敏感度这些负面信息单独列出来，不藏在正文里；最后一块是迭代建议，告诉团队下一步该动数据、动参数还是动评测方案。报告第一页必须能回答“能不能上”这个问题，细节往后放。
结论呈现有个原则：不藏坏消息。训练损失好看但验证指标拉胯的模型，我不会只挑好看的指标写。过拟合风险该标红就标红，分布外塌方该写清楚就写清楚。有一次我坚持在报告里写了一个微调模型在对抗集上比基座还差的事实，虽然这个模型在领域任务上提升明显，但对抗集上的退化后来在线上果然引发了问题——用户输入不规范时模型输出质量波动很大。那次之后团队对我报告里的风险提示部分格外重视，这比多写十页漂亮数字有价值。
迭代闭环是把评测结果翻译成动作。我的做法是每次评测结束开一个短会，把结论和风险过一遍，当场定下三件事：数据侧要不要补样本或者清噪声，模型侧要不要调正则或者换策略，评测侧要不要加新的测试子集。三件事各有一个负责人和一个截止时间，下一轮评测时逐条对账。这个机制让评测不至于变成“跑完就完了”的一次性动作，而是真正嵌进了迭代流程里。
数据优化闭环里有个反直觉的发现值得分享。有次微调模型在验证集上表现平平，我以为是过拟合控制得不够，打算加正则。做误差分析时发现大量错误集中在某几类边缘样本上，训练数据里这些样本本身就标注得模棱两可。后来把这几百条模糊样本清理掉重训，验证指标提升了四个点，对抗集表现也稳了。这个案例让我明白，过拟合有时候不完全是模型复杂度的问题，数据里的噪声和矛盾标注也会逼着模型去记忆矛盾的信号。现在我的评测报告里会专门有一节讲数据质量对过拟合的贡献，提醒团队别只盯着模型侧调参。
