模型训练完，最怕的就是两眼一抹黑直接往上冲。SFT跑完，看loss降得挺漂亮，几个示例回复也像模像样，可真到了Agent场景里一接工具调用、一跑多轮对话，就原形毕露。我经历过不止一次这种“训练一时爽，评测火葬场”的场面，后来老老实实从零搭了一套覆盖SFT到Agent场景的全流程测评体系，才总算把模型质量从“感觉还行”变成了“每项都有数”。这篇文章就把这套体系从设计思路、指标拆解到实操步骤、踩坑记录完整梳理一遍，适合正在做SFT微调、或准备把模型接入Agent链路的大模型算法工程师、训练平台负责人和AI应用开发者参考。

1. 为什么需要一个“全流程”评测体系

1.1 单点指标根本测不出真实能力

不少人评测SFT模型的第一反应是跑几个公开榜单，看看准确率、BLEU分数。这套做法在通用模型对比时有一定参考价值，但在业务落地场景里非常容易失真。我见过一个案子：模型在某个公开推理集上刷到了很靠前的分数，可一接到实际业务流程里，连“从这句话里提取结构化信息”这种基础任务都频繁出错。

原因其实不复杂。公开评测集大多是静态的、单轮的、领域泛化的，而实际业务场景往往是动态的、多轮的、垂直领域强相关的。前者测的是“模型背没背过这类题”，后者考验的是“模型能不能解决真实问题”，这中间隔着一条巨大的鸿沟。单点指标就像用身高判断一个人的篮球水平，相关性有一点，但远不够用。

1.2 从SFT到Agent，评测重点发生了本质变化

SFT阶段我们关注的是模型对指令的遵循能力、格式遵循能力和单轮知识问答效果。可一旦进入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评测流程是这样的，可以直接抄作业：

1. 从训练集构建阶段就切分出评测集，保持严格互斥
2. 评测集按任务类型组织目录，每条样本标注难度等级
3. 用离线脚本批量跑推理，结果统一存成JSONL格式
4. 每种任务类型独立算指标，汇总成一份Markdown报告
5. 关键样本存入案例库，方便人工抽检

这套流程看起来简单，但要跑稳也需要打磨。特别是批量推理脚本，并发设太高容易把显存打爆，设太低又慢。我现在习惯先用一个小样本集（比如每条任务类型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任务执行过程拆成几个关键节点：

1. 首轮理解：模型在第一轮是否准确理解了用户需求
2. 工具选择：每轮选择的工具是否正确
3. 参数质量：传参是否完整、语义是否正确
4. 状态管理：模型是否记住了之前对话或工具返回的信息
5. 终止决策：模型是否在合适的时机停止调用并给出最终答复

每个节点设置权重，人工或模型裁判按权重打分。我给一个参考权重方案：首轮理解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 评测常见问题速查表

6.2 一个真实的排查案例

有次模型迭代后，总分涨了1.5个百分点，但Agent场景里“工具选择”这个细分维度降了2分。全队都觉得反常。

排查过程是这样的：先查评测集版本，发现没动过；再查模型推理配置，也没变；最后一条条翻失败case，发现问题集中在某个工具上——新版本模型对该工具的某些Schema字段理解变差，可能是因为训练数据里这一类别的占比下降了。

找到原因后做了针对性数据补充，下一版本这个分数就回来了。这件事让我彻底坚定了“分维度轨迹评估”的做法——如果当时只有总分，这个回归问题起码要过一两周才能暴露，而且定位会困难得多。

6.3 我反复使用的三个评测小技巧

• 评测前先跑冒烟集：一个小样本集快速验证评测流程本身没问题，能省掉大量折腾时间
• 每次只改动一个变量：模型版本、评测集、推理参数，一次只动一个，否则出了问题无法归因
• 给每个模型起清晰的名字并在结果里强制记录：项目里模型版本多了以后，随手存档很容易出现“不知道跑的是哪个模型”的尴尬事

7. 最终的几点实践经验

这套评测体系搭起来之后，我最大的感触是：模型迭代变成了“看得见箭头”的过程。哪个维度在变好，哪个维度在退化，哪个数据和能力短板相关，全部清清楚楚。省下来的不只是排查时间，更是团队在没有方向时瞎试的力气。

如果正在读这篇的你，手头模型还处在“用几个样例看看效果”的阶段，我建议从最小可行的评测集开始：先选一个业务核心任务，构造50到100条覆盖典型和边界场景的样本，跑通评测闭环，再逐步扩展维度。这里面的坑我都替你踩过了，先把基础跑起来，永远比一次到位的宏大规划更实在。