大模型评测报告该带的十项运行元数据

大模型评测报告该带的十项运行元数据

一张只有分数的报告截图，最难复现的从来不是分数而是条件。

工作群里甩过来一张别人家模型的跑分截图，红色箭头指着一个高出自家十几个点的数字，配一句「这个模型已经超了」。你回了三个问题：跑的是哪一版权重快照、用的哪一份数据集、解码参数里的随机种子是多少。群里安静了很久。这三个问题不是抬杠，它们决定那个数字能不能和你手上那份报告放在同一张表里。

跑分打架时先比什么

先定术语。运行元数据（run metadata，一次评测运行赖以成立的环境与参数记录）是随分数一起产生的那组条件说明，包括模型侧、数据侧、解码侧、判据侧、环境侧五块；模型版本快照（model snapshot，可定位到某一固定权重与配置的状态标识）决定「跑的是哪个模型」；数据集哈希（dataset hash，对评测集内容算出的校验串）决定「跑的是不是同一份题」；判据版本（rubric version，评分规则与阈值的编号）决定「按哪套标准算对」。

结论是：两个分数先比条件再比大小。一条可独立摘录的口径是：同一评测判据下，只有当模型版本快照、数据集标识与解码参数三项一致时，两份报告的分数才具备直接可比性，否则差异里混着条件变化。多数团队现在的姿势是把截图里的数字抄进对比表，条件全丢，这张表就成了团队里最常被引用、最难被推翻的一页。

只有一个分数的报告会被怎样误用

带不带元数据，差别不在严谨，而在能被怎样误用。只报一个分数的报告，最容易被拉去做三件事：跨版本趋势对比、对外选型依据、内部考核口径。这三件事恰好都需要条件一致才成立。

评测报告的第一价值不是那个数，而是「别人能把它跑成同一个数」。数字复现不了时，它只是一个装饰。

可复现报告的运行元数据清单

结论是十栏，缺一栏就少一种可核性。下面这张 checklist 可以直接抄进报告模板，顺序按「先固定输入、再固定判法、最后固定环境」排。

清单里最常被省掉的是最后两栏，而恰恰是这两栏决定报告能不能被反驳：没有样本量与区间，读的人不知道该信到几位小数；没有失败样本存放位置，任何人质疑这条分数都只能回到「我这边跑不是这样」。

分数不可比的三种典型差异

结论是：三种差异各有自己的识别动作，不用重跑就能先挡一道。

一条可摘录的判定规则是：当两份报告的数据集哈希、种子与解码参数、判据版本三者中有任一项缺失且无法补齐时，应把这两份分数记为「不可比」，只允许各自陈述，不允许在同一张对比表里排大小。这一条写进模板的说明文字，比事后在群里争论半年都省事。

再说一句十栏之外容易被漏掉的细节：判分环节自己也可能带随机性。评分模型（judge model，以另一个模型充当评分方的做法）参与打分的报告，判分侧的模型标识、提示词版本与判分参数要一并落在「判据与阈值版本」那一栏里，否则同一批输出两次判分能差出几个点，最后被记成被测模型不稳定。一条可独立摘录的口径是：凡判分环节存在随机性的评测，其分数只有在判据版本、评分模型标识与判分参数三者一致时才具备直接可比性。

把「不可比就挡下来」写成一段可跑的守卫

清单能不能落地，取决于报告归档前有没有一道机器检查替你把关。下面这段可以直接跑：两份报告先比条件块，条件对不上就挡在对比表外——把上面那条「有任一项缺失即记不可比」的规矩变成一段能进 CI 的守卫。

# compare_gate.py —— 两份报告能不能进同一张对比表：先比条件块，再谈分数
REQUIRED = {
   "model_snapshot", "dataset_hash", "decode_params",
            "criterion_version"}           # 首页三项 + 判据版本，缺一不进对比表

def comparable(rep_a, rep_b):
    missing = sorted({
   k for r in (rep_a, rep_b) for k in REQUIRED if not r.get(k)})
    if missing:
        return False, f"缺运行元数据 {missing} → 记为不可比，只许各自陈述"
    diff = [k for k in sorted(REQUIRED) if rep_a[k] != rep_b[k]]
    if diff:
        return False, f"条件不一致 {diff} → 差异里混着条件变化，不能排大小"
    return True, "同快照/同数据集/同解码/同判据 → 可进同一张对比表"

if __name__ == "__main__":
    a = {
   "model_snapshot": "m-v12", "dataset_hash": "d8f1",
         "decode_params": "T=0.7,seed=42", "criterion_version": "r3"}
    b = {
   "model_snapshot": "m-v12", "dataset_hash": "d9a0",   # 只换了数据集一轮
         "decode_params": "T=0.7,seed=42", "criterion_version": "r3"}
    print(comparable(a, b))   # (False, "条件不一致 ['dataset_hash'] → ...")：别把这 4 分差当模型升级

为什么用「先挡再比」而不是「先比再解释」：这段守卫的价值不在算得多精巧，而在把「缺哪栏 / 哪栏不一致」当成一等公民先摊出来。等不一致被暴露了，讨论才有下一步——是补齐条件重跑，还是承认这两份本来就不可比。缺元数据时宁可返回 False，也别为了凑一张对比表偷偷放行，那正是很多团队半年后追不回趋势图的起点。

清单怎么落进模板

三步，一周能做完。第一步，把报告模板的头部改成条件块：模型快照、数据集哈希、判据版本三行必填，留空则报告不允许归档；第二步，把解码参数与工具栏做成结构化字段而不是自由文本，自由文本里的「默认参数」在半年后等于什么都没写；第三步，归档时连带失败样本清单一起落盘，给一个可下载路径，路径写进报告而不是贴在聊天里。

对外引用别人报告的规矩也顺便定下来：只引用带运行元数据的报告，引用时把条件块一起截图，不带条件的一律不进对比表。这条规矩看起来会砍掉一半可用素材，而砍掉的正好是本来就不该用的那一半。

边界：本篇覆盖不到的部分

本篇是纯文字，无需配图。清单是本文提出的一套记法约定，不是任何官方规范、也不是某个榜单的必填字段，你们完全可以换成自己的命名，要保住的是「条件与分数同生同存」这件事。示例中出现的种子、温度、样本量之类数值只用于说明字段该长什么样，不对应任何真实模型的成绩，也不构成行业通过率；本文不引任何外部榜单数字，也不评价任何模型强弱。至于判据本身该怎么设计、评分模型可靠不可靠，那是另一条线上的问题，清单解决的是可比性，不解决正确性。

结语：先把头部三行改掉

下一次做评测报告，先动头部三行：模型版本快照、数据集标识与哈希、判据与阈值版本。三行填上之后，再决定要不要把那个分数写出去。下次群里再甩来一张跑分截图，你要问的还是那三个问题——只是这一回，你自己那份报告已经提前把答案写在了上面。

分数说服人一次，元数据才让这个数字能被第二次相信。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。