模型训练完最怕的就是两眼一抹黑直接往上冲。SFT跑完看loss降得挺漂亮几个示例回复也像模像样可真到了Agent场景里一接工具调用、一跑多轮对话就原形毕露。我经历过不止一次这种“训练一时爽评测火葬场”的场面后来老老实实从零搭了一套覆盖SFT到Agent场景的全流程测评体系才总算把模型质量从“感觉还行”变成了“每项都有数”。这篇文章就把这套体系从设计思路、指标拆解到实操步骤、踩坑记录完整梳理一遍适合正在做SFT微调、或准备把模型接入Agent链路的大模型算法工程师、训练平台负责人和AI应用开发者参考。1. 为什么需要一个“全流程”评测体系1.1 单点指标根本测不出真实能力不少人评测SFT模型的第一反应是跑几个公开榜单看看准确率、BLEU分数。这套做法在通用模型对比时有一定参考价值但在业务落地场景里非常容易失真。我见过一个案子模型在某个公开推理集上刷到了很靠前的分数可一接到实际业务流程里连“从这句话里提取结构化信息”这种基础任务都频繁出错。原因其实不复杂。公开评测集大多是静态的、单轮的、领域泛化的而实际业务场景往往是动态的、多轮的、垂直领域强相关的。前者测的是“模型背没背过这类题”后者考验的是“模型能不能解决真实问题”这中间隔着一条巨大的鸿沟。单点指标就像用身高判断一个人的篮球水平相关性有一点但远不够用。1.2 从SFT到Agent评测重点发生了本质变化SFT阶段我们关注的是模型对指令的遵循能力、格式遵循能力和单轮知识问答效果。可一旦进入Agent场景模型不仅要“会回答”还要“会行动”——要在多轮对话中维持目标、从对话历史里提取关键信息、调用外部工具、根据工具返回结果做下一步决策。这就意味着评测维度必须分层。我在实际搭建中把整个体系分成四层每一层对应不同的评测目标和方法层级评测重点典型方法基础能力层语言理解、推理、数学、代码公开评测集 自建对抗集垂直任务层业务场景的分类、抽取、生成人工标注Gold Set 指标自动计算对齐与控制层指令遵循、拒答、格式控制规则校验 模型裁判Agent应用层工具调用、多轮规划、鲁棒性模拟环境 轨迹评估这四层不是并列关系而是递进关系。基础能力层是地基SFT直接改变的是垂直任务层和对齐控制层Agent应用层则是在前几层都过关之后才能谈的。1.3 评测体系必须闭环迭代我见过很多团队把评测当成一个“上线前的检查动作”这从根本上就错了。评测不是一次性的门禁而是训练迭代的一部分。正确的姿态是训练一个checkpoint → 跑全量评测 → 找出失败case → 分析失败原因是数据问题、模型问题还是评测本身问题→ 修正后再训练。这个闭环里评测数据的质量直接决定了迭代的上限。一旦评测集本身有噪音、有泄漏、有过时样本整个闭环都会失真。所以我在体系里专门把评测集的维护当成了和训练数据一样重要的事情来做后面会有专门的章节展开。2. SFT阶段的评测设计与实操要点2.1 评测集构造绝不能拿训练数据当评测集这条听起来像废话但实际操作中翻车的不在少数。尤其是一些业务数据量很少的项目有人图省事直接从训练数据里切了一部分出来当评测集。这里有两个坑一是模型在训练时已经见过这些样本评测分数虚高得离谱二是即使切了10%当评测集也需要确保这10%没有和训练数据做过重合检测。我在实践中要求的评测集构造标准是三条必须和训练数据做过去重重复率要控制在极低水平每条样本必须有正确答案或明确评分标准覆盖范围要包含典型case和边界case而不是只有“好做”的样本一个很容易被忽视的点是边界case。比如做意图分类常规评测集全是非常典型的“查询天气”“设置闹钟”一到那种“明天早上如果下雨就提醒我带伞顺便看看后天有没有雨”这种混合意图样本系统就歇菜了。这种样本才是评测价值的真正体现。2.2 指标选择的坑不同任务要不同指标SFT阶段的任务类型五花八门我见过有人在生成任务上硬套精确匹配指标结果分数惨不忍睹也见过有人在分类任务上只看准确率忽视了混淆矩阵里的严重偏斜。这里分享一套我验证过的指标搭配逻辑分类/抽取类任务主指标用准确率和F1值但必须看分类别细分的F1。单看总体F1会把少数类的糟糕表现掩盖掉。生成类任务参考型指标用ROUGE/BLEU只作为粗筛最终以人工评分或GPT-4/Llama-3裁判评分为准。因为生成任务没有唯一标准答案词面重合度本来就低。指令遵循类任务这是SFT的核心能力强烈建议用“约束检查器”做规则校验。比如要求“必须按JSON格式输出”就直接用解析器判断输出是否合法比让模型裁判打分稳定得多。拒答类任务这类最容易被忽略。安全性评测里要专门准备一组“模型应该拒绝回答”的请求验证模型是否具备正确的边界意识。2.3 评测过程的稳定性控制大模型推理本身有随机性同一个模型同一道题温度调成0.7跑两次都可能给出不同的答案。这直接导致评测结果不可复现。我在实际评测时做了几件非常重要的事情推理时固定temperature为0至少也要调到0.1以下固定随机种子和beam search参数评测环境锁版本模型权重hash、tokenizer版本、transformers版本、CUDA版本全部记录我踩过一个真实的坑某次评测模型版本没锁代码自动拉取了一个小版本升级导致tokenizer行为细微变化结果模型在一个中文分字任务上分数暴跌了3个点。排查了两天才发现根本不是模型退化了而是评测环境变了。注意评测环境的可复现性优先级高于评测速度。宁可跑得慢一点也要保证同样代码、同样权重、任何时候跑出来的分数是一致的。2.4 SFT评测的实操流程我日常的SFT评测流程是这样的可以直接抄作业从训练集构建阶段就切分出评测集保持严格互斥评测集按任务类型组织目录每条样本标注难度等级用离线脚本批量跑推理结果统一存成JSONL格式每种任务类型独立算指标汇总成一份Markdown报告关键样本存入案例库方便人工抽检这套流程看起来简单但要跑稳也需要打磨。特别是批量推理脚本并发设太高容易把显存打爆设太低又慢。我现在习惯先用一个小样本集比如每条任务类型50条做冒烟测试确认无误后再跑全量。3. Agent场景的评测难点与破局3.1 Agent评测为什么和传统NLP评测不一样如果说SFT评测是在“答题”那Agent评测就是在“做事”。传统NLP评测是单轮问答答案对了就给分Agent场景下模型要在一长串多轮交互中做出一系列决策任何一个中间环节出错最终结果都可能不对。我刚开始评测Agent时还用老思路给一个任务看最终结果对不对。后来发现根本不行。有一次模型虽然最终给出了正确答案但过程里调用了五次工具白白浪费了大量时延和token另一次模型中间选错了工具但靠着后面的误打误撞修正了结果。如果只看最终结果这两个问题都会完美地漏掉。所以Agent评测的核心原则是不仅要评结果还要评过程轨迹。这也是Agent评测和SFT评测最本质的区别。3.2 工具调用能力的细粒度评测工具调用是Agent的基础功。我在评测中把工具调用拆成了三个维度分别打分意图识别模型是否准确地判断出需要调用哪个工具参数抽取从对话中提取的实参是否准确、类型是否正确错误恢复工具返回报错后模型能否理解错误并给出正确的重试策略这里一个非常有效的评测手段是“工具Schema变异测试”。就是一个工具的正常调用测完后故意制造输入参数缺失、类型不匹配、缺少必要字段等异常请求观察模型的反应。一个健壮的Agent应该能够在参数不完整时主动追问澄清而不是僵硬地生成一个必然报错的调用。我在实测中发现很多SFT阶段看起来“对话流畅”的模型在工具Schema复杂一点的情况下参差不齐。比如工具定义里同时有必填参数和可选参数时有些模型会把可选参数遗漏得理所当然有些则会把不存在的字段也填进去。这些问题只能靠细粒度的工具评测暴露。3.3 多轮轨迹评估过程比结果重要轨迹评估是Agent评测的核心难点。我现在用的是“关键节点检查 权重打分”的组合方式。具体做法是把一次Agent任务执行过程拆成几个关键节点首轮理解模型在第一轮是否准确理解了用户需求工具选择每轮选择的工具是否正确参数质量传参是否完整、语义是否正确状态管理模型是否记住了之前对话或工具返回的信息终止决策模型是否在合适的时机停止调用并给出最终答复每个节点设置权重人工或模型裁判按权重打分。我给一个参考权重方案首轮理解15%工具选择30%参数质量30%状态管理15%终止决策10%。这套方案的优势是能精确归因分数低了能看出是哪个环节掉链子也就知道该去补什么训练数据。比如某次评测发现分数低的核心瓶颈在参数质量回来针对性补充参数抽取的SFT数据下一版迭代很快就见效了。3.4 评测环境搭建沙箱和模拟工具Agent评测最麻烦的是环境。真实外部工具不可能在评测环境里随意调用一方面是有延迟、有费用另一方面是不可控——外部API的状态会变化今天能返回的数据明天可能就变了。我的解法是自建工具模拟器。把真实工具的Schema抽出来做成一个可配置的Mock服务返回值根据预设场景逻辑生成。这样做有三个明显好处评测完全离线、可复现场景可以覆盖正常情况、边界情况和异常情况工具返回速度极快适合大规模并行评测值得提醒的是Mock服务不要做得太“完美”。真实的工具调用会有延迟、会有偶然的错误、会有返回格式不规范的情况。我在Mock服务里故意注入了一些随机的返回延迟和偶发的报错让评测环境更接近真实生产环境。4. 评测集的设计、维护与防污染4.1 三类数据源搭配使用一个靠谱的评测集我习惯由三类数据组成公开评测集用于对标外部模型。比如通用推理、通用知识类的公开基准好处是行业公认、方便横向对比坏处是和业务场景脱节。业务真实数据从实际用户请求中采样脱敏后构造。这是评测的核心最贴近真实场景。注意一定要保证标注质量我见过业务评测集里标注错误率超过15%的情况所谓评测分数根本没意义。对抗性数据人工构造的边界case、攻击样本和陷阱数据。这类数据占比建议在15%到25%之间是评测体系最体现水准的部分。4.2 评测集的版本管理与防污染策略评测集不是一成不变的但每一次变动都需要非常谨慎。我遇到过最糟心的事一份评测集用了三个月模型迭代了一版分数涨了结果发现是评测集里混进了训练数据——模型“背过答案”分数全面虚高。防污染我用了三个手段训练数据与评测集做双向去重每次新增训练数据都要跑一遍查重评测集做hash版本管理每次变更都留记录、留diff关键评测集定期“轮换”保留核心样本池同时不断注入新样本这里分享一个经验评测集不能只增不减。样本如果长期不变模型很容易产生数据泄漏风险。我现在的做法是“70%稳定核心样本 30%定期刷新样本”的比例。核心样本保证纵向可比性刷新样本保证评测能反映模型对新样本的泛化能力。4.3 评测集的标注质量控制评测集标注质量是整个评测体系的根基根基不稳上层全废。我实践下来的标注质量控制手段每条样本至少双人标注不一致的case进入仲裁流程每批标注完成后抽10%复核标注一致性要达标才接收定期做标注者一致性趋势监控这些措施看起来增加成本但和评测结果失真后浪费的排查时间相比性价比高得多。5. 自动化评测工具链的搭建5.1 最小可用评测流水线评测如果能全自动化效率提升是质的飞跃。我先说一个最小可用版本包含三个模块Runner评测执行器加载模型、加载评测集、批量推理、保存结果Scheduler任务调度器编排评测任务支持回归触发Reporter报告生成器计算指标、生成对比报告、输出case分析评测流水线的伪代码结构 评测集配置 - Runner加载 - 批量推理 - 结果落盘(JSONL) - 指标计算 - 报告生成(Markdown/HTML) - 入库(便于对比历史)在实现上我不建议一开始就追求复杂的分布式架构。先把单机流程跑通跑稳再根据模型规模和评测集规模逐步扩展并行策略实际很多场景单机多卡就足够了。5.2 历史结果管理与回归分析评测最怕“模型越训越差”而不自知。所以历史结果管理非常关键。我做了一份简单的评测历史数据库每次跑完自动记录模型版本权重hash、训练时间评测集版本推理超参数各维度分数当时的环境信息框架版本、驱动版本这份记录的价值在于回归分析。一次模型迭代后如果某些维度分数下降了就能立刻定位是从哪个版本开始下降的再结合该版本的训练改动做归因排查效率翻了不止一倍。5.3 评测报告怎么输出才有用很多人输出的评测报告就是一坨数字表格。不是说数字表格不该有而是只有数字报表远远不够。我在报告里强制要求三部分内容总分和关键维度分快速看整体分case结果明细查问题用典型失败案例top N尤其是分数变化最大的case人工必看典型失败案例是评测报告的精华。没有案例分析的评测报告就像体检报告只有一堆检验数值没有医生解读普通人根本不知道问题在哪、严重程度如何。6. 常见问题与排查技巧实录6.1 评测常见问题速查表问题现象可能原因排查思路相同模型两次评测分数不一致推理随机性未控制检查temperature、seed、beam参数是否固定评测分数虚高但线上效果差评测集泄漏检查评测集与训练集重合度模型某维度分数突然暴跌评测环境变化或样本变更查历史环境记录和评测集diff模型裁判打分和人工严重不一致裁判prompt表述不清晰检查评分标准、提供few-shot示例Agent任务结果正确但过程混乱缺少轨迹评估环节补充关键节点打分工具调用频繁报错参数抽取能力不足针对性补充参数抽取SFT数据6.2 一个真实的排查案例有次模型迭代后总分涨了1.5个百分点但Agent场景里“工具选择”这个细分维度降了2分。全队都觉得反常。排查过程是这样的先查评测集版本发现没动过再查模型推理配置也没变最后一条条翻失败case发现问题集中在某个工具上——新版本模型对该工具的某些Schema字段理解变差可能是因为训练数据里这一类别的占比下降了。找到原因后做了针对性数据补充下一版本这个分数就回来了。这件事让我彻底坚定了“分维度轨迹评估”的做法——如果当时只有总分这个回归问题起码要过一两周才能暴露而且定位会困难得多。6.3 我反复使用的三个评测小技巧评测前先跑冒烟集一个小样本集快速验证评测流程本身没问题能省掉大量折腾时间每次只改动一个变量模型版本、评测集、推理参数一次只动一个否则出了问题无法归因给每个模型起清晰的名字并在结果里强制记录项目里模型版本多了以后随手存档很容易出现“不知道跑的是哪个模型”的尴尬事7. 最终的几点实践经验这套评测体系搭起来之后我最大的感触是模型迭代变成了“看得见箭头”的过程。哪个维度在变好哪个维度在退化哪个数据和能力短板相关全部清清楚楚。省下来的不只是排查时间更是团队在没有方向时瞎试的力气。如果正在读这篇的你手头模型还处在“用几个样例看看效果”的阶段我建议从最小可行的评测集开始先选一个业务核心任务构造50到100条覆盖典型和边界场景的样本跑通评测闭环再逐步扩展维度。这里面的坑我都替你踩过了先把基础跑起来永远比一次到位的宏大规划更实在。