没有任何 AI 味儿的总结我直接聊点实战的东西。做模型训练的人来说最怕的不是训练不出来而是大家都说“效果不错”问“哪儿不错”的时候只能甩出两条 loss 曲线。我做了几年的模型评测一个特别深的体会是评测体系这件事决定了训练闭环能不能真正转起来。尤其是当你从单纯做 SFT慢慢开始碰 Agent 这种多轮、多工具、多约束的场景评测如果不跟着升级训练就是在盲目地改参数。这篇内容主要围绕大模型训练全流程测评体系来展开核心就一句话从 SFT 到 Agent 场景评测的目标、维度、数据构建和验收标准是一条连续的、必须提前设计好的演进线。本文会拆解从模型训练到评测指标设计、测试集规划、场景迁移、常见踩坑记录适合正在搭建评测体系、面临模型验收问题或者准备让模型从对话走向 Agent 场景的团队参考。1. 大模型测评体系的概念界定与设计思路1.1 评测不是最后一环而是训练闭环的转向轴很多团队习惯把评测放在模型训练完之后出一次指标写一份报告任务就算结束了。这个做法最大的问题是评测结果已经改变不了任何训练决策。模型是个黑盒如果你等训练跑完再评测评测就变成了“验尸”而不是“导航”。我理解的训练全流程测评体系至少在训练的全生命周期里要做三次关键评测在 SFT 数据准备阶段做数据质量抽测用少量样本验证喂给模型的数据是否错乱、重复、格式不统一在 SFT 训练过程中做 checkpoint 评测选出一个数值漂移最小、综合能力最好的中间结果在训练结束进入 Agent 场景前做能力边界的压力测试明确当前模型在复杂任务拆解、工具调用、上下文记忆方面的短板在哪。这三次评测不是同一个模板换几个题而是目标和尺度完全不同的三类体系化操作。数据阶段看的是“干净不干净”训练阶段看的是“变化稳不稳”场景阶段看的是一个复合能力——复杂度、工具利用率、状态恢复能力全部都是不一样的。评测体系的这个“转向轴”作用在于给训练提供回馈。那个中间 checkpoint 到底选哪一步继续跑强化或者哪一版数据导致模型指令遵循崩了全靠评测结果反推。没有这个转向机制训练过程就是消耗大量算力在黑盒里撞运气。1.2 设计评测体系的三层原则设计这套体系的时候我一般按三个层次拆先想清楚再往下落第一层评测目的。不同阶段下你想要回答什么问题是“SFT 质量合格吗”还是“Agent 场景能不能上线”。这个问题决定了评测指标必须收敛到什么程度也决定了人工评测资源投入的密度。比如数据质量抽测可以去人工但千级规模的 checkpoint 对比必须用自动化指标初筛。第二层评测维度。任务是单轮还是多轮是否依赖外部工具返回结果是开放式生成还是确定性比对这三个问题直接决定测试数据和评估指标后续细讲。第三层评测运行逻辑。也就是谁来评、怎么采样、怎么避免噪声。人工评会累模型评会偏规则评太死板这三种方法在整套体系里要各司其职。比如开放式的自然对话靠人工打分工具选择正确性用规则拦截长文本相关性可以用大模型辅助评估。按这三层想清楚再动手你会发现评测不是一个“测试用例一个脚本”这么简单。很多团队评测体系搭不起来不是没有算力而是在目的和维度上没想清楚最后产出的是一堆看着像样却不能用于决策的指标。2. 从 SFT 开始的测评基础监督微调模型的测评重点2.1 SFT 评测首先关注的三件基本功SFT 阶段紧接预训练之后是在特定分布的数据上微调让模型学习到符合下游任务预期的输出风格和领域知识。这个阶段评测的核心其实是验证三件基本功而不是一味追高分。第一件是指令遵循能力。给模型下发不同复杂度、不同措辞的指令观察它是否真正理解了指令的意图与约束。这一项我建议采用封闭式题目给一个明确的目标输入和约束条件评估模型输出是否能满足硬性约束。比如指定“用一句话回答且必须包含三个要点”这是可直接判定对错的。关键的一点是SFT 模型的指令遵循直接决定后续 Agent 场景能不能可靠执行步骤分解。第二件是输出的确定性。同一道题、同一个 prompt在温度为 0 的条件下SFT 后的模型是否输出稳定。如果不稳定那大概率是数据里有冲突样本或者微调策略引入的随机噪声偏大。在后面的 Agent 场景里输出确定性差会直接导致任务链路中工具反复调用出错所以这个基本功必须在 SFT 阶段守住。第三件是格式合规。模型是否能在生成的内容中包含指定字段、JSON 结构、Markdown 标题或固定模板。特别是在数据生成任务中格式就是协议协议不对后续任何解析都会崩。当然不能只看格式外壳内容是否仍然保持逻辑和事实准确同样重要这两者需要分开评测避免模型为了套格式而牺牲可读性。完整地测好这三件基本功再谈领域知识和风格模拟之类的锦上添花否则后面搭 Agent 一定返工。2.2 SFT 数据质量与评测集构建之间的隐藏关系SFT 效果好坏的八成因素在训练数据。评测的重要性就在于反向验证数据质量。我在项目中常用一种“数据换评测”的循环随机抽 500~1000 条训练数据喂给模型做小批量微调再拿固定评测集跑一轮若某些能力分数暴跌基本是数据分布出了问题从数据侧定位而不是反复调超参数。评测集在 SFT 阶段要刻意分成四个部分通用能力集参考通用通用能力基准覆盖逻辑、理解、抽取、改写等基础能力主要看微调是否让模型产生严重的灾难性遗忘领域能力集针对业务场景自建 100~300 条领域问答用来验证领域知识的覆盖程度约束遵循集包含复杂约束的指令 50~100 条比如禁止提及某些词、限定字数、固定输出格式用来考察模型对约束的敏感度对抗样本集包含相似但语义相反的问题、重复追问、恶意诱导用来确认模型的稳定性和安全边界。在四个维度上做多维矩阵评分最终合成一个综合指数。这个综合指数不理想的时候可以通过下钻看是约束遵循出了问题还是领域知识空白。真正落地的 SFT 评测体系必须能让评测数据反向索引到训练数据否则训练阶段的修正无从下手。2.3 自动化评估与人工评估的分工节奏SFT 阶段数据量大评测频次高不可能全量人工评审。我常用的做法是自动指标初筛 争议样本人工评审。自动阶段依赖 ROUGE/BLEU 这类文本相似度指标会偏表面所以我更推荐用一个大模型作为裁判先对“相关性”“完整性”“逻辑一致性”等维度打分再做归一化处理。人为的阶段只挑出低分段和高分段中意见不一的样本这样能大幅降低人工评审压力把时间花在最能反映问题的样本上。不过模型裁判也有偏置它偏向文笔好但不一定正确的内容。所以要用规则兜底凡是涉及数字、实体、时间的输出必须挂一个基于知识库的自动比对在覆盖面有限、但判断绝对可靠的那部分完成闭环。SFT 的评测频率上我的建议是每 500 步左右跑一次轻量版评测集挑低分和高分样本人工看这一步能及时感知训练是否偏移。很多项目只在最后做一次测评训练中期的潜在崩溃是在最后才暴露出来的那时候算力已经花掉太多基本只能重训。3. 测评向 Agent 场景延展的关键转变3.1 Agent 场景评测与 SFT 评测的本质差异到了 Agent 场景核心变化在于模型的输出不再仅仅是一段文字而是一连串动作。SFT 阶段关心“答得好不好”Agent 阶段更关心“事办没办成”。这个“办成”的过程涉及多轮交互、工具选择、工具返回结果处理、异常恢复等多个环节任何一个环节出错最终任务都可能归零。SFT 评测常见的做法是让模型直接生成最终答案评测对象是结果文本。但 Agent 场景中模型要先解析用户意图、拆解为步骤、决定调用哪个工具、根据工具返回的信息修正下一步计划推理过程被显式暴露在链路里更要关注中间输出的合法性。比如让模型订机票。SFT 评测可能关注“生成的回答是否流畅”Agent 评测则要看“模型是否正确地调用了查航班工具、是否解析了返回的 JSON、在航班售罄时是否切换到备选日期”。这已经无法用文本相似度来度量而是需要一套围绕任务状态和工具轨迹的评测方法。所以在体系设计上Agent 评测必须引入“过程信号”和“结果信号”的双重标准“过程信号”指每一步动作的是否正确“结果信号”看最终目标是否达成。单一终局打分对 Agent 来说帮助甚微因为你知道结果不对却不知道坏在拆解、工具调用还是解析结果上。3.2 Agent 场景的核心评测维度设计针对 Agent 场景我在实践中最常落地的评测维度有五个任务完成率。用一个明确的目标检查器来判断整个多轮对话是否最终完成了用户初始目标这是首要维度任务没完成过程再好看都是负分。工具调用的正确性。这一步看模型是否在恰当的时机选择了恰当的工具且参数格式完全符合工具定义。多数情况下我会用规则校验 JSON Schema甚至直接根据返回结果构建最小状态机来判断状态传递是否正确。多轮一致性。模型在长时间多轮交互中是否能记住关键信息不出现用户已经给出明确约束却又违反的情况。这个维度可以通过在测试数据中人为加入“跨轮次约束”来压测比如第一轮说要靠窗座位第五轮再订票看模型是否依然遵守。错误恢复能力。当工具调用失败或返回异常时模型是死循环重试还是能换一条路径这一项直接决定 Agent 的可用性。测评时我会注入工具返回错误、空结果、超时数据观察模型的策略切换。资源效率。完成一个任务用了多少轮、调用了几次工具、信息是否重复请求。这个问题在实际部署中关乎成本和延迟一方面模型可能反复调用同一个工具而无法收敛另一方面对话轮数过长也会影响真实用户体验所以要在评测中做量化和上下界限值。把这五个维度串起来如果只是做单项评分团队仍然不知道自己该在哪个环节去调模型、调 prompt、调工具说明。最高效的方式是按“任务完成度、工具轨迹正确度、恢复策略有效度”三类汇总缺失哪块补哪块。4. 从 SFT 到 Agent 场景的全流程测评体系搭建4.1 统一测评底座测试集、模拟环境和评测报告串联很多人一提到 Agent 评测就头疼因为模型和应用强耦合难以单独评估。但反过来想只有先建一个“统一的、可运行的测试环境”才能把模型本身的能力和应用侧的表现分开来评测从而判断问题到底出在模型还是系统。整个测评底座由三个部分组成。测试集是最核心的部分其次是与真实场景接近的 mock 工具环境最后是任务状态记录器和评分模块。测试集要包含多条完整任务流附带明确的期望步骤和最终目标mock 工具环境则要求每个工具的输入输出可预期、可注入异常便于反复测试任务状态记录器负责在评测过程中把每一步动作和状态变化落盘评分时才可以做步骤级定位。我更推荐的评分方式是“过程分终局分”的组合。过程分每执行一步就累积终局分由最终状态决定两边结合避免“很早出错后面靠运气拉回”的情况或者“最终结果对但过程混乱不可信”的情况。上线之后的评测更加关键。模型在真实世界里会碰到测试集覆盖不到的长尾情况、工具更新、接口延迟等问题所以线上评测要有一个轻量级的采样通道把真实对话脱敏后回放进评测环境定时批量评分。这样才能保证小体量测试集的盲区不会完全失控。4.2 测试集迭代策略与体系自身的演进测试集必须是活的。从 SFT 转过来初期只有几百条用例但随着模型上线新的失败案例出现测试集要及时补进去保持对变化的敏感性。具体操作上每周从线上数据中随机采样 200 条进行人工标注和误报分析把有代表性、覆盖新场景或新难度的用例沉淀进回归测试集。回归测试集是守住体系本身的手段。每次模型或工具配置更新都要拿全量回归集跑一遍确认旧能力没退化。这个流程很多人忽略直到 SFT 的新数据把 Agent 链路整体搞崩才发现。越早建立回归习惯后期问题越少。评测体系自身的指标也有“健康度”评估。比如通过率上升但用户投诉也在上升说明测试集和真实场景背离了。评测不能只看单一的数值曲线这个数据本身要能回答“为什么模型变差了往哪个方向调”的问题。若评测全部通过而线下体验一个问题百出那就先怀疑测试集的设计和场景分布再去怀疑评分。4.3 从训练到评测的闭环机制设计为了让评测真正服务于训练不能只发布一份报告更重要的是建立机制评测结果出来后能自动或半自动地形成训练或者数据侧的调整建议。我的闭环分三步走。第一步问题定位。评测后从失败用例中聚类出失败模式比如“工具调用参数错误”和“工具结果解析错误”是两类不同问题聚类靠分析日志关键词和动作序列实现。第二步根因分析。失败模式对应数据侧还是模型侧如果工具调用参数经常把日期格式传错去查 SFT 数据中的工具调用样本有没有覆盖日期格式的变体大概率是训练数据缺覆盖。第三步形成回填任务。对缺失的样例组织标注补充、工具说明改写、prompt 模板修订变更后再次进入评测。这个闭环跑起来后模型的进步就变得可解释、可追踪。在团队配合上评测报告一定得包含“建议下一步动作”而不能只是直观的数字。评测该和训练、数据、应用侧同属一个节奏至少每周对齐一次保证发现的问题及时有人接。5. 常见问题与排查技巧实录5.1 Agent 评测中“过程正确但结果失败”的归因迷雾这是最典型的现象模型每一步看起来都选了正确工具最终却没能完成任务评分卡在任务完成率低但工具调用正确率又很高。初看是矛盾数据实际上问题往往出在“前置信息不完整”。比如一个查询任务模型必须先向用户确认某个参数但它没有确认直接带着默认值调了工具。工具调用是成功的过程也是合规的然而任务目标已经偏离用户预期。归因时要专门检查“参数来源”和“信息完整性”这两个隐藏过程项不要只看动作名称正确与否。5.2 工具返回错误时的死循环逃逸策略缺失很多 Agent 模型在工具返回错误后会反复用同一参数重试比如网络超时重试三次就直接失败或者干脆一直循环不下去。评测中我会注入“连续错误返回”和“部分错误返回”两类失败看模型能否更换策略或向用户反馈异常。一种是死循环重试说明模型缺少对错误的判断和策略切换机制另一种是直接放弃任务说明模型的容错设计过于简单。实战中可以用工具说明文档加入错误码解释与处理建议显著改善这类问题。同时在评测维度里专门加上“失败恢复后任务完成率”这个指标比单纯完成率更能体现模型的真实 Agent 能力。5.3 模型裁判的自洽性问题如何减少评分偏置用大模型当裁判时最常见的问题是评分漂移。同一份输出换一个评测 prompt、换一个模型版本分数可能完全不同。为了降低这种噪声我在评分设计上加了三个保险第一评价维度要拆细。不要只给一个“综合分”要让裁判分别对相关性、完整性、格式合规、逻辑一致性打分维度越细裁判的注意力越聚焦偏差越小。第二使用多裁判模型投票。三个不同的裁判模型分别打分取中位数或多数票比单模型稳定很多。代价就是成本变高所以只用于最终验收不在训练中途的每个 checkpoint 上跑。第三锚定样本对照。每次评测集里混入 20 条已有人工打分的“锚点样本”如果裁判模型给锚点样本的人工分差超过阈值则认为本轮评分不可信需要重置或人工介入。另外不要迷信单一自动化指标。真正上线前至少人工抽检 15%重点看那些自动化评分认为“完美”的样本因为模型裁判往往会放过一些事实错误这些错误规则匹配和人工视角其实很容易察觉。5.4 测试集过拟合模型背答案而不是练能力做 Agent 评测超过三个月就会出现一个特别隐蔽的问题测试集被模型“记住”了。模型其实并不是学会了任务本身而是背下了测试集路径。典型特征是单条任务在回归中通过率高但换一个包装或场景描述就大幅下跌。为了防止这种隐性过拟合尽量定期对测试集做“场景扰动”改变用户表述、改变参数取值、改变数据顺序但不改变目标难度。同时要留一份“金标测试集”封存不外泄只有模型发布前才解开。金标测试集的制作要有人工参与标注完整的期望行动轨迹和任务约束平时不用它调参专治各类墙内开花墙外香的假高分。6. 最后再分享一个我实践中的真实体会如果你现在刚开始搭测评体系我强烈建议先不要一上来就追求方法论完整或者自动化程度高先找 20 条最关键的场景任务人工把每一步跑通跑完你会对整个 Agent 链路长什么样、模型的脆弱点在哪里有一个非常清晰的感知。我在实际项目中最大的收获其实是评测从 SFT 到 Agent 的过程迫使我把“模型能力”和“应用编排能力”两者彻底分开。过去我总以为模型表现不好就是模型的问题后来发现很多所谓的 Agent 失败是评测时把编排系统和模型耦合太紧导致的——单独测模型的步骤没问题一接上外部环境和工具链就到处都是杂质。评测体系真正成熟的时候是你能清晰地看到能力的边界知道哪些任务是靠模型本身、哪些必须靠提示词和工程手段兜底。最后一个小建议整个评测体系的维护成本要算入项目日常开销。测试集更新、标注迭代、裁判模型调优都不是一次性投入得有人长期轮值盯盘。比模型训练本身还“费人”但只要这个体系活着未来任何一次模型升级、场景拓展你都能在更短的时间内判断出该不该上、能不能上这比单纯堆算力练模型有价值得多。