评测 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 的流程：提交候选模型，自动跑基准集，生成报告，再由人工审阅关键退化样本。

这能减少主观试用带来的偶然性，让模型迭代更像工程流程。