先看分数背后的测试
一个模型排名第一，另一个提高了九分，团队想知道该选谁。回答前，先打开测试说明。分数不仅取决于模型，也取决于题目、提示词、工具、时间和评分规则。条件变了，结果也可能变。
PaperBench让这一点更容易看清。它要求AI智能体复现20篇论文的结果，把工作拆成8,316项可评分任务，还测试了负责评分的AI评审。[1] 分数说明系统在这组研究与工程任务上的表现，不代表研究者需要做的所有工作。
报告分数时，带上必要条件：哪个模型版本、做什么任务、用哪些工具和限制、怎样评分？读者才能判断它是否回答了自己的问题，以及另一个分数是否来自可比条件。
把分数当作选型理由前，先读测试条件。
先决定需要系统做什么
假设你需要AI起草客服回复。事实问答测试可以检查它是否知道某些事实，却不能说明它会不会遵守退款规则、询问缺失信息，或识别何时应交给人处理。测试应围绕需要完成的工作来选。
评估研究把想了解的能力或行为称为构念，把用来评估的数字称为指标。不用术语也能分清：“客户能看懂回复”是目标，“评审者选了这条回复”是一项观察。把观察当成目标达成的证据前，还需要查什么？
HELM同时评估准确性、稳健性、公平性、效率等方面，让取舍可见。[2] 系统可能答对更多题，却更贵，或对某个人群表现较差。选择对用途重要的指标，同时保留各自不同的含义。
检查测试包含哪些任务和用户
标为“编程”的测试可能主要要求写短函数，你的团队却需要修改大型现有项目。标为“推理”的测试可能使用简短英语问题，你的服务却要处理日语长对话。不能只看标签，要读实际任务。
检查重复模板、含糊题目、错误标准答案，以及只用少数例子代表的重要情况。模型之间的小差距，可能难以与抽样任务带来的波动区分。Bowman和Dahl主张改进标注、确保足够的统计检验能力，并关注难度和偏差，而不只是增加难题。[3]
为预定工作列一张覆盖清单：测试包含哪些任务、语言、用户、工具和任务长度？哪些很少或完全没有？主动排除的也写清楚。如果重要用途没有覆盖，就先安排单独核查，再把结果推广过去。
检查测试是否仍有参考价值
公开试题可能进入训练数据，高分便可能部分来自见过题目，而不是处理新任务的能力，这通常称为基准污染。即使没有原题，反复练习相似问题，也可能让熟悉的测试不再能说明陌生工作中的表现。
检查题目、公开发布、模型和评估的日期。条件允许时，比较旧题与新题或保留题。发现照抄措辞会引起疑虑，但没找到也不能证明模型没见过。无法确定先前接触是否影响结果时，要如实说明。
LiveBench定期从近期来源加入新题，并按客观答案评分，以降低这类风险。[4] 更新也会改变比较条件：新题得分不能自动与上个月相比。记录测试版本，必要时使用共同题目。决定新模型、工作流程变化或接触试题的迹象，何时需要重新评估。
旧分数可能已不再回答当前工作的问题。
像检查答案一样检查评分
评分规则也可能漏掉重要内容。文字精确匹配会拒绝表述不同的正确答案；代码测试只覆盖写进测试的行为。专家能评估更复杂的工作，但需要明确标准。AI评审能快速看更多答案，却可能同时受呈现方式和内容影响。
比较具体模型前，先写标准。请相关专家抽查通过和失败的案例，并检查分歧。并排比较时调换答案顺序，或稍微改变评分指令的措辞。如果这些变化颠倒排名，就应呈现不确定性，而不是宣布稳定的赢家。
Chatbot Arena通过成对比较收集人类偏好，并检查其可靠性。[5] 它提供了人们在那种环境下偏爱哪些答案的证据，但不能单独证明胜出的系统更安全、更符合事实，或更适合专业任务。要看谁在评分，以及被要求评什么。
看失败集中在哪里
总体平均可能掩盖集中在某项任务或人群的失败。计算方式也重要：每类权重相同，与每道题权重相同，得到的概括不同。多次尝试中任一次通过就算成功，也不同于首次成功率。
下图是两组各20个案例的假设示例。成功率都是80%，但其中一组的大部分失败集中在一个群体。因此，报告还应列出重要人群和任务的结果，以及不确定性和运行间波动。比较模型时，看同一任务的答案和错误的严重程度。
总体成绩相同，失败的集中程度却不同
假设案例 · 每幅图20例，其中4例失败 · 总体成功率80%
失败分散在各组
失败集中于一组
阅读失败记录，判断需要修复的是知识缺口、遗漏指令、工具错误还是评分含糊。通过的案例也要查。METR的一项研究发现，有些代码提交通过了自动测试，维护者却仍需修改才能使用。[8] 测试可以正确检查一部分工作，同时漏掉其他要求。
相同的总分，可以掩盖很不一样的失败。
把有希望的系统放到实际工作中试
基准可以帮助列出候选，下一步是看成功能否延续到自己的工作流程。实际任务可能涉及私有工具、不完整请求、中断、变化的信息，以及自动检查未覆盖的质量标准。
PaperBench的复现任务包括理解、实现和执行实验。[1] METR则把智能体的成功概率与人类专家完成任务所需时间联系起来。[6] 这里的时间是人的任务时长，不是AI运行多久。两种方法都比短问答揭示更多，但仍限于所研究的任务和条件。
依赖系统前，用真实工具和领域评审测试代表性任务。先从不影响用户、输出可审核的情况开始，测完成时间、修正工作、重要错误和结果是否可用。METR对2025年初AI与资深开源开发者的研究中，参与者以为自己更快，测得的完成时间却增加了。[7] 结果针对该环境；值得借鉴的是直接测量关心的成果，不要从分数或感觉推断。
用这些问题把分数转化为范围明确的决定。尚未回答的问题，指出仍需补充的证据。
说明结果支持什么，何时再查
结尾给出别人可以评估的决定。例如：“这些结果支持有人监督的常规英语回复试点；退款例外和其他语言尚未测试。”这个假设结论比“模型最好”有用，因为写出了用途、限制和下一步。
保存理解和重复评估所需的细节：模型版本、提示词、工具和权限、任务集、时间或费用限制、评分规则、评审者或评分模型版本，以及重复尝试怎样计数。也保存汇总分数的计算。重要设置改变后，相应标记新结果。
安排人审核新证据，并明确何时重测。模型更新、用户群变化、工具修改或测试范围外的失败，都可能触发。结果可能支持试点、修改一段流程、继续测试，或维持当前系统。说清证据支持其中哪项选择。