agentic-ctx/skills/benchmark-crime-auditor.md

Benchmark Crime Auditor

用于审计计算机系统论文、技术报告、实验设计或具体性能 claim。核心参考 Gernot Heiser 的 “Systems Benchmarking Crimes”：https://gernot-heiser.org/benchmarking-crimes.html

立场：误导性 benchmark 不是写作瑕疵，而是会破坏科研结论。没有证据时判定 NEEDS EVIDENCE，不要替作者假设实验是公平的。

Inputs

必填：

• 待审 artifact：论文 evaluation、实验设计、图表集合、日志摘要、或具体性能 claim。
• 审查目的之一：
  • experiment-design-review
  • pre-submission
  • pre-release
  • claim-spot-check

可选：

• 目标 venue / 读者。
• 原始实验脚本、日志、CSV、配置、机器规格。
• context depth: Low | Medium | High，默认 Medium。

Output

必须输出：

• 1-3 条 headline claims。
• benchmark surface：workload、baseline、metric、platform、statistics、data range。
• 逐条 crime 审计表。
• 按严重度排序的修复清单。
• 总体建议：Ship | Revise (Major) | Block。

判定：

• PASS：artifact 中有足够证据支撑。
• FAIL：artifact 明确违反。
• NEEDS EVIDENCE：可能没问题，但 artifact 看不到证据。
• N/A：不适用，必须写理由。

严重度：

• Blocking：影响 headline claim 的 FAIL；或 baseline/公平性/选择性 benchmark 伤害主结论。
• Major：影响支撑性 claim 的 FAIL；或 headline claim 的 NEEDS EVIDENCE。
• Minor：信息缺失但不改变主要结论；或支撑性 claim 的 NEEDS EVIDENCE。

Audit Table Template

| Crime | Verdict | Severity | Evidence | Fix |
|---|---|---|---|---|
| 1.1 Not evaluating degradation | FAIL | Blocking | Fig. 6 only shows winning workloads | Add adversarial workload where mechanism predicts overhead |

Crimes

1. Selective Benchmarking

1.1 Not Evaluating Potential Performance Degradation

气味：

• 只展示新方法赢的场景。
• 没有展示机制上可能会输的反向场景。
• 只证明 progressive criterion，不证明 conservative criterion。

应有证据：

• 新方法提升目标场景性能。
• 新方法不显著伤害其他重要场景；若伤害，说明 tradeoff 是否可接受。

修复：

• 补一个按机制预测会输的 workload。
• 明确收益和退化的适用边界。

1.2 Benchmark Subsetting Without Strong Justification

气味：

• “representative subset”, “typical results”, “we report selected benchmarks”。
• 用 benchmark suite 子集却报告 suite-level 平均。
• 排除 benchmark 的原因是“跑不动”，但没有解释这如何限制结论。

应有证据：

• 被排除项清单。
• 每个排除项的技术理由。
• 不从子集推出全 suite claim。

修复：

• 跑全套；或逐项报告，不给整体平均。
• 明确 claim 只覆盖已运行子集。

1.3 Selective Data Set Hiding Deficiencies

气味：

• x 轴刚到系统快崩前停止。
• 负载范围不覆盖真实运行区间。
• 只画低并发、低争用、低内存压力、低尾延迟区间。

应有证据：

• 参数范围覆盖真实 workload。
• 覆盖 scaling knee 两侧。

修复：

• 延伸数据范围，报告崩点或收益消失区间。

2. Improper Handling of Benchmark Results

2.1 Pretending Microbenchmarks Represent Overall Performance

气味：

• 用 IPC、syscall、memcpy、cache hit rate 等 micro metric 证明系统端到端更快。

应有证据：

• macro benchmark 或真实 workload。
• micro result 只作为机制证据，而不是主结论。

修复：

• 补端到端 workload。
• 将 micro result 降级为 breakdown/mechanism。

2.2 Throughput Degradation Is Not Equal to Overhead

气味：

• throughput 下降 x%，就写 overhead 是 x%。
• 吞吐不变，就说 overhead 为 0。
• 把额外 core、加速器、远端节点、batch window 当成免费资源。

原则：

• throughput 是外部观察量。
• overhead 是单位有用工作的资源消耗。
• 只有资源同等饱和时，吞吐变化才可能近似资源 overhead。

应有证据：

• CPU load、cycles/op、processing time per request、memory bandwidth、IOPS、queue depth、tail latency、energy/op 等资源账。
• 对所有被使用的资源计费。

修复：

• 用 per unit useful work 重算 overhead。
• 报告吞吐时同时报告完整资源利用率。

2.3 Downplaying Overheads

子罪：

• 2.3a 混淆百分比和百分点。6% -> 13% 不是增加 7% overhead，而是 overhead 超过翻倍。
• 2.3b 分母选错。baseline 必须在分母中。60s -> 80s 是 +33% degradation，不是 25%。
• 2.3c 创意算法。0.39us -> 2.28us 接近 6x，不应写成 82.89% slowdown。

应有证据：

• 写清公式。
• 分母使用 baseline。
• 同时给绝对数和相对数。

修复：

• 从原始数重算所有百分比。
• 删除二阶相对数或 ratio of ratios。

2.4 No Indication of Significance

气味：

• 只有平均值。
• 没有标准差、置信区间、error bar、trial 数。
• 拟合线没有回归质量。

应有证据：

• 多次重复。
• 标准差或置信区间。
• 边界 claim 使用统计检验。
• 确定性结果也应说明方差足够小。

修复：

• 重跑多 trial。
• 报告 variance 和 trial protocol。

2.5 Arithmetic Mean Across Normalized Scores

气味：

• 对 normalized speedup/slowdown 用算术平均。

应有证据：

• normalized benchmark score 使用几何平均。
• 或逐项报告，不聚合。

修复：

• 改用 geometric mean。
• 报告每个 sub-benchmark。

3. Using the Wrong Benchmarks

3.1 Benchmarking a Simplified Simulated System

气味：

• 模拟器假设刚好对方法有利。
• 在模型中验证模型自己。

应有证据：

• 说明简化假设不影响被测指标。
• 最好有真机验证或外部 sanity check。

修复：

• 上真实系统验证关键结果。
• 明确模拟结论的迁移边界。

3.2 Inappropriate or Misleading Benchmarks

气味：

• 用单核 workload 证明多核 scalability。
• 用 CPU-intensive benchmark 测网络栈/NIC overhead。
• 使用没有线性或因果意义的指标。

应有证据：

• workload 的压力向量与 claim 对齐。
• metric 与系统问题有因果关系或合理解释。

修复：

• 换成能压到目标瓶颈的 benchmark。
• 删除科学意义不明的指标。

3.3 Calibration Set Equals Evaluation Set

气味：

• 模型标定和模型评估使用同一批 workload/data。

应有证据：

• calibration set 与 validation/evaluation set 完全不相交。

修复：

• 留 hold-out workload。
• 重新报告预测准确性。

4. Improper Comparison of Benchmark Results

4.1 No Proper Baseline

气味：

• 只比较两个虚拟化系统，不给 native baseline。
• 只给新系统不同变体。
• 没有 SOTA、理论上限、硬件上限或 unperturbed baseline。

应有证据：

• baseline 是读者判断好坏所需的真实参照。

修复：

• 补 native/SOTA/optimal/hardware-limit baseline。
• 若无法补，缩小 claim。

4.2 Only Evaluate Against Yourself

气味：

• 只和自己旧版本比较。
• 只和自己的 ablation 比较，却声称总体优越。

应有证据：

• 与 accepted standard 或当前外部最佳方法比较。

修复：

• 补外部 baseline。
• 把 claim 改成 internal improvement。

4.3 Unfair Benchmarking of Competitors

气味：

• competitor 配置不详。
• competitor 跑在 debug/default/suboptimal 配置。
• 结果与公开数据不一致却没有解释。

应有证据：

• competitor 版本、commit、配置、参数、编译 flag。
• 尽可能使用作者推荐配置；必要时联系原作者确认。

修复：

• 用公平配置重跑。
• 公开配置和脚本。

4.4 Inflating Gains by Not Comparing Against SOTA

气味：

• 新论文仍锚定旧 baseline，忽略已有工作已经在该 baseline 上改进。
• 声称 22% improvement，但当前 SOTA 已经有 20%。

应有证据：

• 与当前 SOTA 的 delta。

修复：

• 重新锚定到 SOTA。
• 把 headline claim 改成真实增量。

5. Missing Information

5.1 Missing Platform Specification

应给：

• CPU 型号、microarchitecture、core 数、频率。
• 内存容量、配置、cache 层级。
• NIC、switch、disk、accelerator 规格。
• OS、kernel、hypervisor、compiler、runtime、library 版本。
• 编译 flag、关键系统参数。

5.2 Missing Sub-Benchmark Results

气味：

• 只给 suite-level 几何平均。
• 不展示每个 benchmark，掩盖 regression。

修复：

• 表格或 appendix 给每项结果。
• 标出退化项。

5.3 Relative Numbers Only

气味：

• 只给 speedup、ratio、normalized value，没有绝对值。
• 比较两个 overhead ratio。

修复：

• 相对数旁边给绝对数。
• 删除 ratio of overheads 这类二阶相对。

Best Practice Checklist

用于 experiment-design-review。

• 系统开始计时前处于 quiescent 状态。
• benchmark rig 纳入 regression test。
• 文档记录命令、参数、版本、机器、时间。
• 写入数据后读回校验；读取数据时验证正确性。
• 每次 run 使用不同数据，避免 stale cache 或旧 block。
• 同一数据点既连续测，也隔开测，检查缓存和干扰。
• 测量顺序正向和反向都跑。
• 不只用规则 stride 或 2 的幂；加入随机点和病理点，如 2^n-1, 2^n, 2^n+1。
• 比较不同配置时使用完全相同的数据点。
• 多次运行，检查标准差；异常方差要解释。
• outlier 剔除必须有预先规则或统计程序。
• 计时前有 warmup。
• 用足够迭代次数降低时钟粒度影响。
• 消除 loop overhead。
• 必要时检查机器码，确认计时 loop 与预期一致。