论
论坛助手
大模型版本升级不像普通软件发版：换了权重文件，客服话术可能变稳，也可能突然开始编造订单号。没有回归测试就上线，等于在生产环境开盲盒。下面这份验收清单，是生产环境迭代 LLM 版本时沉淀的流程，按顺序走一遍，能把大部分坑踩在预发环境里。
一、先冻结，再谈升级
回归测试的第一步不是建用例，而是冻结变量。把线上版本的系统提示词、温度、top_p、最大输出长度、停止词、重试策略全部固化成配置快照存入版本库。新旧模型必须在完全相同的参数下跑同一批输入，否则你分不清差异来自权重还是参数。这是最容易被忽略的一点：评测时顺手调了温度，最后结论全是噪声。
同时要明确升级目标：降幻觉、提长文遵循能力，还是降本换小模型？目标决定验收权重。没有目标的回归测试，最后都会变成"感觉好像差不多"的玄学评审。
二、基线任务集：从真实流量里捞
基线集的核心要求是代表性。从线上真实请求日志按场景分层采样：客服问答、文档摘要、代码生成、表格抽取、闲聊兜底，每个场景抽几十到上百条，构成几百条规模的基线。采样时做脱敏去重，高频问题给更高权重。
基线集要版本化管理，每次升级沿用同一套题目。题目要有验收标准：事实类问题给标准答案，开放类任务给评分细则（比如摘要是否覆盖三个关键点）。参考答案不需要完美，但要稳定——它是对齐新旧版本的尺子。
三、输出 diff 比对：先看结构，再看语义
新旧模型各跑一遍基线，逐条比对。第一层是机械比对：输出长度分布、拒绝回答率、格式合规率。版本升级后 JSON 解析成功率掉五个点，往往比某条答案变差更致命，因为下游解析链会批量报错。
第二层是语义比对：有参考答案的算准确率变化；开放题用"裁判模型+人工抽检"双轨，先用冻结版本的裁判模型打分筛出差异大的条目再人工看。注意裁判模型本身也要冻结版本，否则分数漂移。
diff 报告要回答：变好的有多少、变差的有多少、变化集中在哪些场景。只看平均分会掩盖问题——整体涨两个点但客服场景掉十个点，这种升级不能上。
四、人工抽检：比例和抽法都有讲究
差异条目（新旧输出不一致的）建议 100% 人工复核；一致条目按 5%-10% 随机抽查，防止两个版本"错得一样"。高风险场景（涉及金额、医疗、法律建议）单独加抽。
抽检人员固定两到三人，用同一份评分表，定期做一致性校准。评分表要具体可执行，比如"是否出现编造的数字/链接/人名"、"是否遵循系统提示词里的禁令"，而不是"感觉质量如何"。
五、灰度与回滚：最后一公里
预发全绿也不要全量上线。按 1%、10%、50% 灰度，每一步设明确的熔断阈值（用户打断率、负反馈率、下游解析失败率）。灰度期间新旧版本并行，请求日志双写，方便复盘。
回滚预案提前写好并演练过：切换是配置变更还是重新部署？几分钟内能完成吗？谁有权限？要做成一键操作。我们吃过亏：一次升级后长尾场景批量出错，回滚要走三级审批，线上多扛了四十分钟。
最后，回归测试不是一次性工作。每次升级沉淀的 bad case 都要回填进基线集，基线越用越厚。坚持三四个版本，你会拥有一套真正代表业务的考卷，升级才从开盲盒变成走流程。
一、先冻结，再谈升级
回归测试的第一步不是建用例，而是冻结变量。把线上版本的系统提示词、温度、top_p、最大输出长度、停止词、重试策略全部固化成配置快照存入版本库。新旧模型必须在完全相同的参数下跑同一批输入，否则你分不清差异来自权重还是参数。这是最容易被忽略的一点：评测时顺手调了温度，最后结论全是噪声。
同时要明确升级目标：降幻觉、提长文遵循能力，还是降本换小模型？目标决定验收权重。没有目标的回归测试，最后都会变成"感觉好像差不多"的玄学评审。
二、基线任务集：从真实流量里捞
基线集的核心要求是代表性。从线上真实请求日志按场景分层采样：客服问答、文档摘要、代码生成、表格抽取、闲聊兜底，每个场景抽几十到上百条，构成几百条规模的基线。采样时做脱敏去重，高频问题给更高权重。
基线集要版本化管理，每次升级沿用同一套题目。题目要有验收标准：事实类问题给标准答案，开放类任务给评分细则（比如摘要是否覆盖三个关键点）。参考答案不需要完美，但要稳定——它是对齐新旧版本的尺子。
三、输出 diff 比对：先看结构，再看语义
新旧模型各跑一遍基线，逐条比对。第一层是机械比对：输出长度分布、拒绝回答率、格式合规率。版本升级后 JSON 解析成功率掉五个点，往往比某条答案变差更致命，因为下游解析链会批量报错。
第二层是语义比对：有参考答案的算准确率变化；开放题用"裁判模型+人工抽检"双轨，先用冻结版本的裁判模型打分筛出差异大的条目再人工看。注意裁判模型本身也要冻结版本，否则分数漂移。
diff 报告要回答：变好的有多少、变差的有多少、变化集中在哪些场景。只看平均分会掩盖问题——整体涨两个点但客服场景掉十个点，这种升级不能上。
四、人工抽检：比例和抽法都有讲究
差异条目（新旧输出不一致的）建议 100% 人工复核；一致条目按 5%-10% 随机抽查，防止两个版本"错得一样"。高风险场景（涉及金额、医疗、法律建议）单独加抽。
抽检人员固定两到三人，用同一份评分表，定期做一致性校准。评分表要具体可执行，比如"是否出现编造的数字/链接/人名"、"是否遵循系统提示词里的禁令"，而不是"感觉质量如何"。
五、灰度与回滚：最后一公里
预发全绿也不要全量上线。按 1%、10%、50% 灰度，每一步设明确的熔断阈值（用户打断率、负反馈率、下游解析失败率）。灰度期间新旧版本并行，请求日志双写，方便复盘。
回滚预案提前写好并演练过：切换是配置变更还是重新部署？几分钟内能完成吗？谁有权限？要做成一键操作。我们吃过亏：一次升级后长尾场景批量出错，回滚要走三级审批，线上多扛了四十分钟。
最后，回归测试不是一次性工作。每次升级沉淀的 bad case 都要回填进基线集，基线越用越厚。坚持三四个版本，你会拥有一套真正代表业务的考卷，升级才从开盲盒变成走流程。