评测 Harness 设计让模型对比从手工表格变成可复跑流程模型评测如果靠手工脚本和表格很快会失控。今天改了 prompt明天换了模型后天更新了测试集最后没人知道哪次结果能复现。评测 Harness 的价值是把数据、模型、推理参数、指标和报告生成统一到可复跑流程中。可复现评测不是形式主义它直接决定模型对比结论是否可信。一、Harness 要固定五类输入flowchart TD A[Dataset Version] -- F[Eval Harness] B[Model Version] -- F C[Prompt Template] -- F D[Inference Config] -- F E[Metric Code] -- F F -- G[Report]只记录模型名不够。温度、top_p、max_tokens、prompt 模板和指标代码都会影响结果。二、配置要能完整复现一次评测run: id: eval_20260703_001 dataset: nlp_eval_v4 model: model_a_0701 prompt_template: qa_cot_v2 inference: temperature: 0 max_tokens: 512 metrics: - exact_match - f1 - citation_accuracy每次评测生成一个 run id所有产物都挂在这个 id 下。后续看报告时能反查完整配置。三、原始输出要保存只保存最终分数不够。模型输出、解析后答案、错误类型都要留存方便误差分析。{ sample_id: q_1024, raw_output: ..., parsed_answer: B, gold: C, is_correct: false, error_type: reasoning_error }没有原始输出就无法判断错误来自模型推理、格式解析还是评测脚本。原始输出还可以帮助检查评测脚本是否过度严格。例如模型回答了正确选项但格式不符合解析规则这类错误应该归到输出格式问题而不是模型知识错误。没有样本级记录就无法做这种区分。四、报告要支持差异分析模型对比不应只看总分。需要按任务类型、长度区间、难度、领域分组比较。report_sections: ├── overall score ├── score by task ├── score by length bucket ├── regression samples ├── improved samples └── cost and latency一个模型总分略高但在关键业务子集退化未必值得上线。分组分析能让决策更稳。差异分析还要输出 regression samples也就是新模型比旧模型答错的样本。只看提升样本会产生选择性偏差。真正有价值的是知道新模型在哪些能力上退步。五、总结评测 Harness 要把数据版本、模型版本、prompt、推理参数、指标代码和原始输出全部纳入可复跑流程。报告不仅给总分还要支持差异分析。模型对比不能靠手工表格堆出来。可复现流程越扎实评测结论越能经得起复查。当评测 Harness 稳定后模型升级就可以进入类似 CI 的流程提交候选模型自动跑基准集生成报告再由人工审阅关键退化样本。这能减少主观试用带来的偶然性让模型迭代更像工程流程。