预训练模型评测指南：七个维度与可复现选型方法

一、先区分两类问题

榜单分数和模型介绍页可以用于初筛，但不能直接决定上线。评测前，先明确要回答哪一类问题。

第一类是能力验证，即判断模型能否完成某项任务，输出质量是否可用。它用于比较候选模型，结论只适用于测试的任务和数据分布。

第二类是上线准入，即判断模型能否在目标环境中，以可接受的延迟、成本和风险运行，并能长期维护。这一类问题要求更多证据，测试条件应尽量接近生产环境。

两类问题的产出不同。能力验证产出候选模型的排序。上线准入产出通过或不通过的结论，并附带风险清单和回退方案。

二、七个维度与指标口径

评测前，为每个维度定义指标和口径。下表是一个起点，具体阈值由业务方根据场景确定。

维度	要回答的问题	典型指标	口径要求	风险提示
功能	能否覆盖所需任务和输入格式	任务完成率、输出格式合规率、语言与长度支持范围	按任务类型分层统计	只测常见输入，漏掉长文本和特殊格式
准确性	输出是否正确、可靠	准确率、F1、事实一致性、人工评分一致性	固定金标集，记录标注规则	金标样本与训练数据重叠，分数虚高
性能	延迟和吞吐能否满足目标	首 token 延迟、P50/P95/P99 延迟、每秒请求数、每秒输出 token 数	写明批大小、并发数、输入输出长度和硬件型号	用单次请求或空载状态测速
稳定性	长时间运行和异常输入下是否可靠	错误率、超时率、同一输入多次运行的一致性	固定随机种子和温度，同一配置重复运行	只测一次，忽略偶发失败
安全	是否会产生违规内容、泄露信息或被诱导输出有害内容	拒答正确率、越狱成功率、敏感信息泄露次数	使用覆盖业务禁区的红队样本集	通用安全榜单不能代表业务场景
可维护性	团队能否长期运维和升级	版本更新频率、依赖复杂度、工具链成熟度、文档完整度	记录评测时的模型版本号或文件哈希	版本漂移导致结果无法复现
成本	单位请求或单位任务的总成本是多少	每千次请求成本、显存占用、GPU 小时数、人工复核成本	计入推理、存储、带宽和人工，并标注计价单位	只计模型调用费，漏掉工程和运维成本

三、样本设计

样本质量决定评测结论是否可信。建议按以下步骤设计样本。

1. 任务分层。按业务场景拆分样本，例如在线问答、代码补全、离线批量摘要。每层单独统计结果，不直接做总平均。
2. 样本来源。优先使用真实业务日志，并先做脱敏处理，去除姓名、手机号、身份证号等个人信息。
3. 样本量。每层可以先从 200 条开始。正式结论前，应根据期望差异和结果方差估算所需样本量。候选模型之间差距越小，需要的样本越多。
4. 训练与测试隔离。提示词调优用的样本和最终测试集必须分开，避免样本泄漏。
5. 金标一致性。由两名标注员独立标注，计算一致性系数，例如 Cohen’s kappa。若一致性偏低，先修订标注规则，再进入正式评测。
6. 覆盖长尾。保留超长输入、模糊问题、格式异常和历史失败案例，不只挑选理想样本。
7. 环境记录。每次测试都要记录模型版本或哈希、推理框架版本、硬件型号、驱动版本、量化方式、温度、top_p、随机种子、系统提示词、网络环境和访问权限。
8. 重复运行。同一配置至少重复 3 次，报告均值和波动范围，避免把一次偶然结果当作结论。

四、建立基线与阈值

没有基线的评测结果无法解读。基线至少选择以下一种：

• 当前线上在用的模型或方案；
• 同规模的其他候选模型；
• 基于规则或检索的简单方法。

阈值由业务方和技术负责人共同确定，应在测试前写定，测试后不再修改。以下是一个示例，实际数值需要根据业务风险调整：

• 准确性：不低于基线的指定比例，并且在高风险子任务上不出现明显退化；
• 性能：P95 延迟满足产品对响应时间的要求，超时率低于约定值；
• 安全：红队样本中的有害输出数量为零，或达到业务方接受的上限；
• 成本：单位有效结果的成本不高于基线，并预留流量增长后的预算空间。

五、结果解读

评测报告要说明结论的适用范围，避免把数字直接当作普遍结论。

• 绝对分数只在同一测试集内有比较意义。不同测试集的分数不能直接相加或对比。
• 相对基线的提升要同时报告差值和置信区间。若是同一批样本上的成对比较，可以使用自助法（bootstrap）估计区间，或使用 McNemar 检验判断两个模型的差异是否显著。若置信区间包含 0，就不能断定哪一个模型更好。
• 分层结果比总分更重要。整体分数上升可能掩盖某一场景的明显退化，因此每个分层都要单独看。
• 结论有场景边界。在线问答中表现好，不代表离线批量摘要也好。跨场景使用前，应补充对应样本的测试。
• 失败案例要归类。把错误按类型整理，例如事实错误、格式错误、拒答过度、遗漏关键信息，并判断每一类是否可接受。
• 成本要按有效结果计算。一种常用写法是：单位成本 = 总成本 ÷ 达到质量要求的样本数。这样能避免低价模型因质量差而被误判为更划算。

六、合规、安全与风险清单

上线前应逐项确认以下内容，并把结论写入评测报告。

• 许可协议：确认商用范围、衍生模型的限制、是否需要署名或披露。
• 数据隐私：确认平台是否保存输入数据，是否用于再训练，数据存放在哪个地区。
• 安全测试：除通用安全测试外，还要针对业务中的敏感话题做红队测试。
• 内容合规：确认输出是否符合行业规定和企业内部的内容政策。
• 供应商锁定：确认接口是否标准化，更换模型需要改动多少代码，迁移成本有多高。
• 版本维护：确认模型的更新频率和维护状态，评估停止维护的风险。
• 成本波动：确认调用价格是否可能调整，流量增长后成本曲线如何变化。

榜单排名和单次测试都不能作为上线的唯一依据。上线决策至少需要基于一轮完整的分维度测试，并附带风险清单和回退方案。

七、常见错误

以下错误在评测中很常见，应在方案设计阶段主动排查。

• 样本泄漏：测试样本出现在提示词示例或微调数据中，分数被系统性抬高。
• 只看平均分：平均分掩盖了长尾失败和高风险场景的问题。
• 忽略失败案例：只展示成功样本，无法发现模型的边界。
• 忽略版本漂移：模型或依赖库更新后，结果已经变化，但报告仍沿用旧数据。
• 成本口径不一致：有的方案计入了人工复核，有的没有计入，导致对比失真。
• 用榜单代替业务测试：通用榜单与真实业务数据的分布可能差异很大。

八、落地流程

1. 定义准入标准和各维度阈值，并形成书面文档。
2. 通过榜单、模型介绍和许可协议做初筛，选出三到五个候选模型。
3. 构建分层样本，记录金标标注规则，并确定基线方案。
4. 按七个维度执行测试，保存原始日志和环境信息。
5. 解读结果，形成结论、风险清单和回退方案。
6. 上线后持续监控。每次模型版本变化或依赖升级，都要重新运行回归测试。

按照这一流程，团队能够得到可复现的评测结果，也能清楚地知道结论在哪些条件下成立。