怎样比较 AI 评测成绩，避免混用评测口径
按顺序核对任务版本、指标、工具、预算、不确定性和报告来源的实用方法。
只有先确定测了什么、如何测，两项成绩才构成有用的比较。先核对任务身份，再检查指标、系统配置、资源与不确定性。
首先确认测试相同
从准确的基准名称、版本和子集开始。名称相似，不保证题目、环境或评分相同。SWE-bench 维护不同任务集与榜单设置；没有明确对应关系时，不能把一种设置的成绩插入另一种设置的顺序。同样，基准修复验证器或移除有问题的样例后，也需要重新核对。
写下评测划分和排除项。如果报告排除了环境启动失败、只测支持的语言，或选取较小任务样本，其分母可能与另一份报告不同。标题相同不能消除这种差异。如果这些细节没有公开，应保留两条观察，同时标明比较条件尚不明确。
先读指标，再读数字
确认测量结果、单位和方向。准确率、任务完成率、评审偏好和攻击成功率不是同义词。数值更高，可能表示任务表现更好，也可能表示针对防御的攻击更成功。比例与百分比可能描述同一数量，但只有来源定义了尺度，换算才有依据。
然后检查尝试规则。首次尝试的结果，与多次生成候选后取得成功不同。HumanEval 的 pass-at-k 定义，把采样机会纳入了测量。多次尝试可能符合你的应用需求，但回答的是不同的运行问题。应保留原报告的指标，不要把每个数值都变成没有说明的百分比。
HumanEval and pass-at-k evaluation · HarmBench evaluation pipeline
在明确条件下比较完整系统
记录模型版本及其外围软件。搜索、代码执行、检索文档、界面元数据和外部记忆，都可能提供另一轮运行没有的信息或动作。对电脑操作来说，截图与结构化界面信息是明显不同的观察渠道。对智能体来说，外围控制流程可能决定失败后怎样重试。
除最终结果外，也要比较时间、token 和交互预算。不限资源的运行，与严格限制资源的产品体验不同。如果实际用途有延迟上限或固定成本，应评估相应资源条件下的表现。不要推断更高的完成率没有代价。
OSWorld observation and action settings · Berkeley Function Calling Leaderboard evaluation settings
区分观察到的差距与可靠结论
查看任务数量、重复运行，以及评测者报告的不确定性区间。小幅数值差距不自动有意义，尤其是系统每次尝试会采样不同答案时。如果没有报告不确定性，就明确写“未提供”，不要编造区间或显著性结论。
寻找可能解释差距的评测设计变化。例如，长上下文比较取决于实际输入长度、任务构造与截断规则，而不只是模型宣称的窗口。错误样例可以帮助判断差异是否影响你关心的工作。仅看总分无法发现这种模式。
留下一份可以复核的比较记录
为每条观察保存来源链接、报告日期、准确指标名称和相关评测条件。区分报告发布日期、实验日期与基准发布日期，也要区分评测者的直接测量和模型开发者对他人成绩的转述。这样可以复核结论，不会把多次转述误当成独立验证。
在包含多个来源的目录中，应从来源记录出发；存在明确比较组时，再使用它。不能仅按模型名或基准标题合并记录。零是一个测量值，缺失值不是零。如果现有证据不足以支持排名，逐条标注出处的观察表仍然有用。
最终结论应收窄到：哪个系统，在什么任务和条件下表现更好，还存在哪些不确定性。之后，再用实际应用中的代表性工作做小规模评测。公开成绩可以帮助筛选候选和识别风险，但不能替代对即将作出的选择进行验证。