一名研究者想为新模型挑一套评测，往往要在论文、代码仓库、数据集页面、模型卡和排行榜之间来回跳转。更麻烦的是，同名 benchmark 可能来自不同目录，页面上的一个数字也未必交代版本、提示词、工具、尝试次数和评审器。9 月 10 日提交的 Benchmark Radar 技术报告试图把这条链路接起来，却先得到一个并不光鲜的结果：冻结版收录的 1283 条来源记录中，493 条没有数值分数，占 38.4%。
这不是“近四成 benchmark 没有评测结果”。Benchmark Radar 保留的是各来源自己的记录，同一评测可以出现多次；“无分数”只说明该条来源记录没有归档数值。项目真正揭示的，是评测检索最基础的工作仍未完成：名字、工件、采用记录和分数历史还分散在不同系统里。
四套目录提供四种证据，不是一个统一排行榜
Benchmark Radar v0.11.0 把四类输入压进同一数据契约：LLM Stats 提供 687 条记录，主要承载 benchmark 名称、描述和分数；OpenCompass Hub 提供 461 条，重点是论文、仓库、发布日期和数据集链接；Artificial Analysis 提供 25 条商业评测记录；37 份模型发布文档——包括模型卡、技术报告、系统卡和发布说明——则被整理为 110 条“模型报告”记录。
这些记录与另一条“日常发现”管线分开。后者每天扫描 13 个直接连接器和 24 个机构的一方信息源，在截至 9 月 7 日的 46 个快照中留下 11068 次观察和 6546 个工件。一次观察可以是论文、仓库或版本更新；它不会自动增加 1283 条目录记录的总数。换句话说，系统同时回答“今天出现了什么”和“这个 benchmark 过去有哪些证据”，但两个问题使用不同计数单位。
这种分层是它相对单一排行榜的主要增量。搜索先按字段匹配找候选，再把来源身份、工件链接、模型报告和分数设置交给研究者检查。它没有宣称一个分数能跨来源直接比较，也没有把名称相同的条目默认为同一个 benchmark。
493 条无分数，主要是目录职责留下的空位
AGI Daily 下载了 v0.11.0 的冻结数据包，并按 benchmark-index.json 与每条 detail shard 重新计数：1283 条记录中，790 条至少有一个数值分数，493 条没有；所有记录合计 12916 个数值观察，与论文和 release 说明一致。493 条无分数记录里，有 464 条仍链接到论文、仓库或数据集，占 94.1%。
来源拆分解释了这个缺口。OpenCompass Hub 的 461 条记录在冻结包里全部无分数，却常常提供身份和工件；LLM Stats 只有 8 条无分数，Artificial Analysis 为 0，模型报告为 24。把 493 解读为“没有评测结果”，会把 OpenCompass 没有在这次快照中承担分数层的事实，误写成 461 个 benchmark 没有被运行过。
去重也没有一键答案。项目先保留来源记录，再用人工复核的 identity link 连接等价条目。我们从 detail shard 的 siblings 关系去重，得到 31 组已复核的跨来源身份关系；抽查其中 20 组，包括 MMLU、GPQA、HumanEval、LiveCodeBench 和 MathVista，均能追到论文、仓库或数据集。它证明系统确实能把部分同名记录接起来，也同时显示 1283 不是“1283 个独立 benchmark”。
有分数仍不等于可以比较
分数层的缺口比“有没有数字”更深。790 条有分数记录中，只有 82 条同时满足三个条件：明确声明百分比单位、知道分数方向、数值落在 0 到 100。其余 708 条使用其他量尺或量尺未核实。即使都写成百分数，测试版本、提示词、工具、推理预算、尝试次数和评审器不同，也不能直接排出高下。
“采用”同样不是质量分。模型报告层把一份文档对某个 benchmark 的引用计作采用证据；同一份报告列出十种提示设置，也仍是一份文档。以 GPQA Diamond 为例，Artificial Analysis 记录用一张目录页承载 586 个模型分数，而模型报告记录连接 27 份文档、19 个模型和 21 个数值观察。文档数、模型数和分数行分别回答“谁提过”“测了多少模型”和“留下多少次测量”，不能互相替代。
这也是为什么外部研究需要继续读原始评测。ICML 2026 的一项系统研究在 60 个语言模型 benchmark 中发现，接近一半出现饱和，且 benchmark 越老，饱和越常见。Benchmark Radar 可以帮助定位分数历史和工件，却不能仅凭关注度、采用次数或离满分的距离判断一个评测是否有效。
冻结数据可复算，检索效果还没有被独立证明
v0.11.0 将软件固定在提交 8f46bbf，发布了包含 1332 个审计输入文件的数据包和 SHA-256 清单。AGI Daily 下载的数据包哈希为 346a039375129154ceddb2c13c187c80b9af94532244da4e0254cd87a1f766e9，与发布清单相符；在本地重算的四项核心统计也全部对上。相比实时网页，这个冻结面更适合引用，因为网站数字会继续增长，而论文只描述截至 9 月 7 日的状态。
边界也写在论文里。四个输入目录和 37 个发现源不覆盖全部 AI 评测；同义改写和更名会让词法检索漏掉候选；论文没有给出检索准确率、任务适配度或节省时间的对照实验。日常发现里五个来源标签贡献了 88.0% 的观察，GitHub Search 在截止日还触及 300 条上限。搜索结果因此只能是待核查候选，不是完整先例清单。
对模型发布者、benchmark 作者和编辑来说，Benchmark Radar 最实用的变化不是多了一张榜单，而是把最低证据要求变得具体：引用来源记录和 benchmark 版本，附论文、代码或数据工件，保留分数设置及日期依据，再说明同名记录是否已经人工核为同一对象。下一步真正决定它能否成为评测基础设施的，也不是目录数字继续上涨，而是更多身份链接被复核、更多缺失量尺被补齐，以及检索召回率第一次接受独立测试。
