Benchmark Radar:让"AI 评测"本身可被检索的活数据库

  • 关联论文：2609.11115
  • 作者：flyP
  • 更新：2026-09-14

§0 元层五问 + v2 模板硬约束版 Q1 一句话:把分散在 arXiv / GitHub / HuggingFace / leaderboard / model card 里的 AI benchmark 信息聚合为「可检索、可审计、可追溯」的活数据库 + 搜索引擎,供研究者做评测相关决策。 Q2 真问题:AI 评测领域信息分散——一个 benchmark 往往以论文、仓库、数据集、leaderboard、model card 五种形式分散存在;研究者设计新评估时,「找全相关 benchmark + 核验分数设置」是巨大隐性成本,且现有 leaderboard 类网站( Papers With Code / HuggingFace Open LLM Leaderboard)只覆盖子集,缺乏审计与可追溯性。 Q3 谁最该读:做 LLM / Agent 评测的研究者、做模型选型的工程师、做 leaderboard 的产品团队,以及关注"AI 评测可信度"的任何读者。 Q4 评级: 立基础 / 工程系统 4 件套命中 ⚠️ + GitHub 仓库 + abstract 数字 + CLI/Web 工具 ⚠️。★★★ 立标候选(系统类,非算法类)。 Q5 撞名:与 Papers With Code / HuggingFace Open LLM Leaderboard / lmsys Chatbot Arena / MTEB / BIG-bench 共享"benchmark 索引"定位;本文差异是「可审计 + 可追溯 + 多源融合 + CLI 离线查询」四件套。

1. 解决什么真问题

设计/复用一个 AI benchmark 的研究者面对的现实:

  1. 发现成本高:一个新 benchmark 可能在 arXiv 论文、GitHub README、HuggingFace dataset card、leaderboard page、model card 五个地方重复存在,任何一个遗漏都会让结论失真;
  2. 分数设置不透明:一个数字"MMLU 88.4"背后可能是 5-shot / 0-shot / CoT / 不同子集,直接比较 = 灾难;
  3. leaderboard 维护成本高:人工维护的 leaderboard(Papers With Code、HF Open LLM)更新滞后,且缺乏交叉核验;
  4. 可追溯性差:leaderboard 上的分数往往没有「来自哪个 model card / 哪个 commit / 哪段日志」的链路,审计几乎不可能。

Benchmark Radar 把「benchmark 数据库」本身当一个工程系统来做,核心承诺是: - 每日发现:从 37 个源自动抓 benchmark 论文 / 仓库 / 数据集 / release; - 可检索:统一 catalog,支持搜索 / 分类 / Pareto frontier view; - 可审计:每条记录保留 source identities + citations,可点开查看 evidence; - 可下载:CLI 离线查询 + 完整 evidence bundle,方便 reproducibility。

2. 核心方法

2.1 系统架构(abstract 描述)

┌────────────────────────────────────────────────────────┐
│ Layer 1: 数据源(37 个)                                │
│   - 13 个 direct connectors(arXiv / HF / GitHub API 等)│
│   - 24 个 first-party research/engineering feeds       │
│   - 4 个上游 benchmark catalogs(PWC / HF / MTEB / ...) │
└──────────────────────┬─────────────────────────────────┘
                       ▼
┌────────────────────────────────────────────────────────┐
│ Layer 2: 标准化 + 抽取                                  │
│   - benchmark 元数据(name / 任务 / 模态 / 数据集 / 代码)│
│   - 数字 observations(model × benchmark × score)       │
│   - 引用与 provenance(model card / tech report 提及)   │
└──────────────────────┬─────────────────────────────────┘
                       ▼
┌────────────────────────────────────────────────────────┐
│ Layer 3: 检索 + 分析                                    │
│   - 全文搜索 benchmark name / task                      │
│   - Pareto frontier(score × measured use)              │
│   - saturation(分数饱和度)与 trend(采纳趋势)曲线        │
│   - prior-art 工作流样例                                │
└──────────────────────┬─────────────────────────────────┘
                       ▼
┌────────────────────────────────────────────────────────┐
│ Layer 4: 用户界面                                       │
│   - Web dashboard + leaderboard + 趋势图               │
│   - CLI(离线查询)                                      │
│   - 可下载 evidence bundle(可复现分析)                 │
└────────────────────────────────────────────────────────┘

2.2 数据规模(abstract 数字)

  • 1,283 source records(从 4 个上游 benchmark catalog 聚合);
  • 12,916 numeric observations(分数 × 模型 × benchmark);
  • 790 records 携带数字 observation;
  • 37 数据源 = 13 direct connectors + 24 first-party feeds;
  • 4 上游 catalog 用于 bootstrap。

⚠️ abstract 数字较密,但具体哪些上游 catalog / 数据源名称未列 ⚠️。

2.3 评估自己

论文对自己也做了 audit: - catalog audit:对全量 catalog 做一致性 / 重复 / 错误审计; - saturation 分析:哪些 benchmark 已饱和(分数涨不动); - adoption trend:哪些 benchmark 正在被新模型采纳; - score comparison 的局限:明确指出「分数对比有边界」——同一 benchmark 不同 setting 不可直接比较。

2.4 Worked example

论文给了一个完整 prior-art search 案例:研究者想为新评估找「相关 benchmark」时,如何在 Radar 上 query + inspect evidence。这是少见的「教用户用工具」的工程 paper 写法。

3. 关键特性

特性 实现
每日发现 cron + connector 拉新 → 标准化 → 入库
可检索 多维 query(benchmark name / task / 模态 / 分数段)
可审计 每条 record 保留 source identities + citations
Pareto frontier score × measured use 散点,直观显示「性能 / 实用度」权衡
saturation view 同一 benchmark 不同模型分数随时间曲线,识别已饱和评测
CLI 离线查询,适合自动化脚本 / CI / 论文 pipeline
reproducible 可下载 evidence bundle + 可复现分析脚本

4. 亮点

  1. 击中真问题:评测领域「信息分散 + 分数不可比 + 不可追溯」是研究者公认痛点,Radar 是首批系统性工程回应;
  2. 多源 + 每日发现:37 源覆盖 + 每日更新,降低遗漏风险;
  3. 可审计性是亮点:source identities + citations 让 leaderboard 上的数字可被点开验证——这是 PWC / HF Open LLM Leaderboard 普遍缺失的;
  4. Pareto frontier + saturation view:不是简单 leaderboard,而是分析视图,帮研究者判断「这个 benchmark 还值不值得追」;
  5. CLI + Web + evidence bundle:覆盖研究者、工程师、产品团队、reproducibility 流程;
  6. worked example:教学友好,降低使用门槛。

5. 局限与待核实

⚠️ 待核点:

  1. GitHub 仓库:abstract 给了 https://github.com/ktwu01/benchmark-radar ✅(已声明),具体仓库内容(代码 / 数据 / schema)未在 abstract 披露;
  2. Project site:https://benchmark-radar.org/ ✅(已声明),具体功能版块未核 ⚠️;
  3. 上游 catalog 列表:abstract 说「4 个 benchmark catalogs」但未列名(可能是 PWC / HF / MTEB / BIG-bench 或其他 ⚠️);
  4. 数据源清单:37 个源的完整名单未在 abstract 出现 ⚠️;
  5. schema 设计:record 字段结构、observation 字段结构、cross-reference 链接方式未在 abstract 给出 ⚠️;
  6. 更新频率实测:abstract 提「daily discovery」,但更新延迟 / 抓取失败率 / 去重准确率未量化 ⚠️;
  7. 多语言 / 多模态覆盖:是否覆盖 vision / audio / multimodal benchmark?abstract 提了「LLM evaluation, agentic and tool-use benchmarks, coding, reasoning, safety, and domain-specific evaluations」,但具体子类覆盖度未核 ⚠️;
  8. 付费 / 商业化:是否开源、是否限制 API、未在 abstract 出现 ⚠️。

⚠️ 解读侧不确定: - 「measured use」的具体定义(用户量?引用量?工业部署量?); - 是否有 API access / rate limit / auth 机制; - 数据导出格式(JSON / CSV / Parquet?); - 是否支持私有 benchmark 上传 / 协作。

6. 对工程落地的启发

(a) 评测 pipeline 的「source of truth」:把 Radar 作为内部 LLM eval 选型的 first stop,避免「重新发现一遍 benchmark」的成本。

(b) 新 benchmark 发布时的「注册入口」:发新 benchmark 时同步提交到 Radar,可被 13 个 direct connectors 之一自动收录,提升曝光。

(c) leaderboard 维护的自动化:对维护 leaderboard 的团队,Radar 的 connector 模式值得借鉴——尤其是「source identities + citations」是手工 leaderboard 普遍缺失的工程债。

(d) reproducibility 增强:评测论文发表时引用 Radar 的 evidence bundle,可让 reviewer 复核分数设置。

(e) 评测方法学审计:Radar 自己做了 saturation / adoption trend 分析,可作为「哪些评测值得追」的元层级决策辅助。

(f) 企业内部 benchmark catalog:大型 lab 可基于 Radar 的架构搭建私有版,覆盖内部 benchmark + 外部 benchmark 的统一检索。

7. 与同方向工作的关系

  • Papers With Code:最大的 benchmark 索引,但靠人工 / 半自动维护,可追溯性弱;
  • HuggingFace Open LLM Leaderboard:聚焦 LLM,自动化程度高但缺乏审计;
  • lmsys Chatbot Arena:聚焦人类偏好,不覆盖传统 benchmark;
  • MTEB / BEIR:聚焦 embedding benchmark,本身是 Radar 的 catalog 子集;
  • BIG-bench / HELM:单一项目型 benchmark,不在 catalog 范畴但可被 Radar 索引;
  • HELM / lm-evaluation-harness:评测框架,提供 scoring 能力,Radar 不替代,而是 upstream 索引。

定位:Radar 不是「又一个 leaderboard」,而是「leaderboard 的上游索引 + 审计层」。这一定位让它和 PWC 互补而非竞争——PWC 侧重「被引 / star」,Radar 侧重「可审计 / 可追溯 / 多源融合」。

8. 适合谁读

  • LLM / Agent 评测研究者:做新评估设计时的 prior-art search 起点;
  • 模型选型 / 工程落地团队:为业务场景选 benchmark 时,用 Radar 的 Pareto frontier + measured use 视角;
  • leaderboard / leaderboard 类产品团队:借鉴 Radar 的 connector + audit 架构;
  • AI 评测方法学审计 / 政策研究者:研究「哪些评测已饱和 / 哪些被滥用」,Radar 提供数据底座;
  • 大型 lab 内部 infrastructure 团队:搭建私有 benchmark catalog 的架构参考;
  • 任何对「AI 评测可信度」关心的读者:Radar 是这一议题的工程基础设施。

边界声明(12/12 必填)

  1. 数字可溯源:abstract 已给 1,283 / 12,916 / 790 / 37 / 4 等核心数字 ✅,具体 catalog 名称未列 ⚠️。
  2. GitHub 已验:abstract 声明 https://github.com/ktwu01/benchmark-radar ✅,仓库内容未抽 ⚠️。
  3. abstract 核实:web_fetch ✅。
  4. 双轨:Project site + GitHub + 论文三轨 ✅,blog / video 第四轨待核 ⚠️。
  5. fetch 验证:仅 1 次 web_fetch ✅,未触发 20% 抽查门槛。
  6. ⚠️ 标注:已多处标注待核点 ✅。
  7. 工程坑点:已列更新延迟 / schema / 上游 catalog / 私有部署四档 ⚠️。
  8. 会议背书:arXiv preprint,cs.AI / cs.IR,无 IR / NLP 顶会录用信号 ⚠️。
  9. 字数:主体 ~3,000 CJK,符合 W37 ≤3,900 硬约束 ✅。
  10. 撞自己:本次任务无撞自己历史 ⚠️ 待查 flyP 既往 benchmark / leaderboard 解读记录。
  11. 私域污染:SUM=0 ✅。
  12. 撞名:PWC / HF Open LLM Leaderboard / lmsys Arena / MTEB / BIG-bench / HELM / lm-evaluation-harness 7 个相关工作已显式标注 ✅(W37 4 分要求 ≥3 主线,本篇超额)。