开源模型更新快，若评测脚本每次改提示或温度，比分就不可比。评测脚手架的目标：同一提交在同一约束下可复跑，结果带配置指纹。

最小组件

  1. 数据快照（版本号或哈希，不默默改题）
  2. 模型与权重路径/修订号
  3. 解码参数（temperature、max tokens 等）
  4. 提示模板文件（纳入版本管理）
  5. 运行日志与逐题输出
  6. 汇总表（分项 + 配置指纹）

搭建步骤

  1. 选定任务集并冻结快照
  2. 写 run_config.yaml：模型、参数、模板路径
  3. 跑推理，保存 raw outputs
  4. 独立评分脚本（与推理分离）
  5. 输出 metrics.json + config_fingerprint

实践注意

  • 少样本题的示例必须固定，勿每次随机抽例
  • 裁判模型若用于打分，要单独记录裁判版本，或优先规则可判题
  • 与团队协议对齐时，可参考开源模型基准协议

技巧与坑

  • 「我本地感觉更好」不能代替脚手架
  • GPU 差异可能导致数值漂，记录硬件与软件栈
  • 不要公布可能泄漏私有题的逐题全文到公网

小结

脚手架是评测的诚实机器：冻结输入、记录配置、分离评分。有了它，开源权重迭代才有可比叙事。

与排行榜宣传的边界

脚手架产出的是可比内部比分，不等于外网排行榜名次。对外沟通时写明任务集、约束与是否开放权重，避免把内部复现实验写成权威榜单。

持续集成

把评测挂到权重发布流水线：新修订必跑冻结集，失败则阻断发布。比分跌了要能指向配置指纹与逐题日志。

最小可运行目录（示意）

configs/、prompts/、data/snapshots/、runs/<timestamp>/、score.py。每次运行复制配置到 runs/，保证事后能复盘。不要把权重文件提交进 Git；只记录获取方式与哈希。团队成员换机器时，先复跑同一指纹是否得到同档结论。

若任务含生成质量主观面，固定评分细则与示例分，或使用多个评分人抽检一致性。不要把一次演示对话当作基准。对解码随机性：评测时尽量温度取 0 或固定种子，并在报告写明。发现比分异常先查是否换了提示模板或数据快照，再查模型本身。

相关阅读