benchmark论文阅读
实习期间阅读的一些有关benchmark的文章
1、DAComp: Benchmarking Data Agents across the Full Data Intelligence Lifecycle
【benchmark】
本文提出 DAComp，用于评测数据代理在企业级全生命周期数据智能中的能力，覆盖 DE（数据工程） 与 DA（数据分析） 两部分。它试图解决的核心问题是：现有 benchmark 多停留在单条 SQL、单脚本或封闭式分析，高估了模型在真实企业数据工作流中的能力。这不是全新问题，但本文首次较系统地用 “设计—实现—演化—分析” 的一体化框架来评测。
论文验证的假设是：当前最强 LLM 在真实数据工程编排和开放式数据分析上都存在显著短板。方法上，关键不是提出新模型，而是提出新 benchmark：DE 任务用执行式评测，DA/架构任务用 hierarchical rubric + LLM judge。实验基于 210 个任务，结果显示：DE 严格成功率普遍很低，DA 总分也不高，说明瓶颈不只是代码生成，而是全局依赖管理、任务规划、结果解释与洞察综合。
最重要贡献：提出更真实的数据代理评测标准，并清楚揭示 “工程能力 ≠ 分析能力”。
最值得学习的是其 benchmark 设计思想：任务设置贴近真实工作、评测指标分层、还能诊断失败来源。未来可继续做真正端到端评测，并专门改进 orchestration 能力。
2、DA-Code: Agent Data Science Code Generation Benchmark for Large Language Models
【benchmark】
本文提出DA-Code，面向“Agent式数据科学代码生成”的基准，解决现有评测过于偏向静态代码补全、难以反映真实数据分析流程的问题。
问题本身并非全新，但将数据科学任务系统化为“多文件环境探索—规划—编码—调试—提交结果”的可执行benchmark，具有明显新意。
核心工作包括：定义agent data science task；构建500个真实任务，覆盖数据清洗、EDA、机器学习；搭建可执行沙箱环境与统一动作空间（Bash/Python/SQL/Terminate）；设计面向表格、图表、文本和ML指标的自动评测体系；提出基线DA-Agent。实验表明，GPT-4仅30.5%，说明当前LLM离“自主数据科学家”仍有差距；提供参考计划可显著提升性能，说明规划能力是关键瓶颈。
值得学习之处在于：以“能力定义—任务构建—环境设计—评测闭环”方式做benchmark；强调真实性、可执行性与评测鲁棒性；通过错误分析定位 hallucination、调试失败与上下文误解等关键问题。
3、MLE-BENCH: EVALUATING MACHINE LEARNING AGENTS ON MACHINE LEARNING ENGINEERING
【benchmark】
为评测AI是否真能做端到端ML工程，作者提出MLE-bench：把75个Kaggle竞赛离线化，统一成本地评分，并用人类leaderboard奖牌作参照。
问题不算全新，但过去缺少大规模、贴近真实工作流的ML engineering benchmark，工作量很大。
核心工作是：任务筛选、重建数据与grader、设计奖牌指标、比较不同模型/agent scaffold，并检查污染与抄袭。结果表明最强组合已能在部分任务拿牌，但离稳定自动化还远。
值得学的是：benchmark设计很完整，指标选择贴近现实，对污染/公平性有专门验证，实验维度也比较扎实。
4、PaperBench: Evaluating AI’s Ability to Replicate AI Research
【评价为夯，感觉目前最有意思的一个工作】【benchmark】
[Summary]
这篇文章提出 PaperBench：一个用来评估 AI agent 能否从零复现顶会 ML 论文的 benchmark，核心是把“复现论文”拆成可细粒度打分的 rubric，并用隔离执行 + LLM judge 做可扩展评测。
[Question & Solution]
文章要解决的是：现在大家说 agent 会做科研、会复现论文，但缺少一个真正像样、可量化、能防作弊的评测。传统任务要么太简单，要么给现成代码库，不足以测“从读论文、写代码、跑实验到拿结果”这一整条链路。作者的解法是做一个高难 benchmark：选 20 篇 ICML 2024 论文，让 agent 只能看论文和补充说明，禁止看原作者代码；提交的代码还要放到全新环境里重新执行。最关键的是评分设计：作者和原论文作者一起写树状 rubric，把任务拆成 Code Development / Execution / Result Match 三层，既能查代码有没有真写出来，也能看有没有真跑起来、结果是否对上，再用 LLM judge 自动批改，解决了“人工评太贵太慢”的问题。
[Contrasts]
它和已有 baseline 的根本区别，不是“换了个更难数据集”，而是评测对象变了。像 MLE-bench、MLAgentBench 这类更像 Kaggle/工程任务，很多是封闭评分函数；CORE-Bench 是给代码库做复现，不要求从零写；RE-Bench 更偏开放工程任务，但没有 PaperBench 这种“论文作者共建 rubric + 隔离复现 + 分层评分”的组合。PaperBench 的本质不是测“会不会调 API”或“能不能写点实验代码”，而是测 agent 有没有长链条科研执行力。这也是为什么它的分数普遍很低，但信息含量很高。
[Takeaways]
第一，评分设计本身就是研究贡献：PaperBench 最值得学的不只是 benchmark，而是它把复杂科研任务拆成可审计、可部分得分、可防投机的 rubric，这种设计以后完全可以迁移到代码 agent、科研 agent、甚至复杂办公 agent 的评测里。第二，当前模型的问题不只是能力不够，而是长时程执行太差：很多模型不是不会写，而是很快“早退”、停在前几步，说明 bottleneck 很可能在 agent scaffold、任务分解和持续纠错，而不只在 base model。第三，强制迭代式 scaffold 能显著改结果：o1 在 IterativeAgent 下提升很大，说明 agent 评测对框架极其敏感；换句话说，今天测出来的“模型能力”，有相当一部分其实是“模型 × scaffold”的联合产物，而不是纯模型上限。
[[Limitations & Directions]]
局限性也很明显：只有 20 篇论文，rubric 制作极其贵，LLM judge 仍不如专家稳定，而且未来还会面临训练数据污染——模型可能直接背过原论文代码。作者给出的方向主要有三条：一是自动化 rubric 生成，减少对专家和原作者的依赖；二是更强的 judge，提高复杂任务自动评分的可靠性；三是研究agent 的策略性行为和投机空间，包括怎么识别“看起来像复现、其实在钻评分空子”的提交。对后续研究来说，最有价值的切入点不是再做一个更难 benchmark，而是去解决“怎么更低成本、更可信地评估长链条 agent”。
5、GDPVAL: EVALUATING AI MODEL PERFORMANCE ON REAL-WORLD ECONOMICALLY VALUABLE TASKS
[Summary]
这篇论文提出了 GDPval：一个用真实行业专家任务来评估大模型在“有经济价值的真实工作”上能力的 benchmark，并比较了前沿模型与人类专家在质量、速度和成本上的差距。
[Question & Solution]
痛点是：现在讨论 AI 对经济和就业的影响，大多看采用率、使用数据、GDP 变化这类滞后指标，但这些指标往往要等很多年才看得清，无法及时反映模型真实能力。作者的解法是反过来，直接测模型能不能做“真实工作”。他们从美国 GDP 占比最高的 9 个行业里，挑出 44 个高薪、数字化职业，让平均 14 年经验的行业专家按真实工作流程构造任务，形成 1320 个任务；再用职业专家做盲测 pairwise 比较，把模型输出和人类专家输出直接对打。难点不在模型，而在任务构造是否真实、覆盖是否系统、评分是否可信。最终它把“AI 是否能干活”这件事，从抽象讨论变成了一个可测、可比较、可追踪的评估问题。
[Contrasts]
它和传统 baseline 的根本区别，是评估对象从“学术能力”变成了“真实经济任务能力”。对比对象一类是 GPQA、MMLU、Humanity’s Last Exam、AgentBench 这类考试式 benchmark，它们主要测推理或 agent 能力，但任务像考试题，不像工作；另一类是 SWE-bench / SWE-Lancer 这类垂直 benchmark，只测某个职业域，覆盖面窄。GDPval 的思路是从经济结构 top-down 地选行业和职业，再用真实 deliverable、人类专家盲评、多模态文件和长时任务来做评估，所以它不是“模型会不会答题”，而是“模型能不能交付一个专业人士会真的用的结果”。
[Takeaways]
第一，真实任务评估会暴露出和标准 benchmark 完全不同的模型短板：不是不会推理，而是不会按要求交付，比如格式崩坏、文件损坏、没跟指令走完。第二，简单 scaffold 和 prompt engineering 的收益可能非常大，文中 GPT-5 只靠更严格的检查提示和 best-of-N，就明显提升表现，说明很多“能力上限”其实被 agent 执行流程卡住了。第三，不同模型有很明显的职业化分工：Claude 更强在美观和排版，GPT-5 更强在准确性和 instruction following，这提示后续研究不要只追单一总分，而应关注“任务—模型能力结构匹配”。
[[Limitations & Directions]]
这篇论文最大的不足是：覆盖面虽然比现有 benchmark 广，但本质上还是一个小规模、单轮、强上下文、偏数字化知识工作的数据集，离真实工作流还有距离；很多任务是 one-shot，不涉及反复沟通、隐性上下文、组织流程和长期责任。评分也很贵，自动 grader 只有接近但不等于人类专家，且可能偏向自家模型。未来可做的方向很明确：把任务做得更交互、更长周期、更贴近组织协作；扩展到非数字化和高 tacit knowledge 场景；研究更稳的自动 grader；以及更重要的一点——把 benchmark 分数和真实世界 adoption / productivity 数据真正对上，验证“能力评估能否预测经济影响”这个核心命题。
6、AgentIF-OneDay: A Task-level Instruction-Following Benchmark for General AI Agents in Daily Scenarios
【benchmark】
[Summary]
这篇文章提出了一个新的通用 Agent 评测基准 AgentIF-OneDay，专门衡量 AI 智能体在真实日常场景中完成任务的能力。它把任务分成 开放工作流执行、隐式指令推断（这个是难点）、迭代式修改 三类，强调 Agent 不只是对话回答，而是要读懂 PDF/Excel/PPT/SVG 等附件，并交付实际文件结果。覆盖范围为学习，工作和生活（感觉实在是范围有些泛泛了，数据支持不太够）。作者还设计了一个 文件中心的数据合成流程 来扩展任务，并用 带搜索和多模态能力的 LLM judge 做自动评测。
[Question & Solution]
现有 Agent 评测的根本问题是：要么只测单点能力，比如代码、数学、网页操作；要么只测显式指令执行，默认用户会把要求说得特别清楚。但真实世界不是这样，用户往往是丢给你 PDF、Excel、PPT 模板，让你自己理解隐含规则，再按流程把活干完。本文的核心机制就是提出 AgentIF-OneDay，把通用 Agent 的日常能力拆成三类：开放工作流执行、隐式指令推断、迭代式修改；同时采用文件中心的任务设计和实例级 rubric + 多模态 LLM judge + 搜索校验的评测方式，真正去测“能不能交付结果”。这篇文章最难也最值钱的地方，不是模型结构创新，而是评测范式重构：它把 Agent 的考核从“会不会答题”升级成“能不能在真实多模态工作流里稳定干活”，这是对通用 Agent 评测维度的一次质变。
[Contrasts]
这篇论文的本质区别在于：传统方法是用 IFEval、FOFO、ComplextBench 这类 benchmark 去测模型对显式指令和格式约束的遵循能力，或者用 GAIA、VisualWebArena、tau-Bench 这类 benchmark 去测特定环境里的工具使用和任务完成；而本文方法是把评测对象从“模型/工具能力”切到“真实日常 Agent 产品能力”，重点考察它在多附件、长工作流、隐式规则、文件交付、多轮返工这些现实场景里的端到端表现。也就是说，传统 baseline 更像在测“会不会做题”，而 AgentIF-OneDay 测的是“能不能像一个靠谱实习生一样把事做完”。
[Takeaways]
这篇文章最有启发性的点有三个。第一，隐式指令推断才是当前 Agent 的真死穴：不是不会搜、不会写，而是看了模板、表格、旧文件之后，依然很难稳定提炼出“潜规则”并迁移到新任务里。第二，Agent 基础能力正在快速商品化：实验里 API 驱动的 Agent 产品已经能和原生 agent RL 路线打得很接近，这意味着未来竞争重点很可能不在底层框架，而在产品体验、工具链集成和用户反馈闭环。第三，复杂 Agent benchmark 的 judge 不能再是裸 LLM：要让评审模型带搜索、带视觉、带渲染能力，否则打分本身就不可信。换句话说，未来不光 Agent 要会用工具，评测系统本身也必须是工具增强的 Agent。
[Limitations & Directions]
这篇论文的局限性也很明确。首先，它虽然比现有 benchmark 更接地气，但规模仍然不大，104 个任务还不足以完全覆盖真实世界的长尾需求；其次，它测的是 OneDay 级别任务，仍然偏短周期，无法真正反映 Agent 在一周甚至更长周期中的状态保持和持续协作能力；再者，自动化评测虽然一致性已经不错，但离完全替代人类评审还有差距。作者明确指出的下一步方向是构建 OneWeek 级别的通用 Agent benchmark，去测更长时间跨度下的任务连续性和泛化能力。可继续深入的研究点包括：如何系统提升隐式规则抽取与迁移能力，如何设计更稳健的长程记忆与状态管理机制，以及如何构建更强的工具增强型 judge来支撑复杂、多模态、动态环境下的自动评测。
7、RubricBench: Aligning Model-Generated Rubrics with Human Standards
【benchmark】这篇文章的立意是很新奇的，可以进行学习，传统的是评判某个东西是不是准确的，但是这里是评判我评判的标准到底是不是对的？这一点十分值得学习。
[Summary]
这篇论文提出了 RubricBench：一个专门评测“模型能不能生成对的评分标准并据此做好评判”的 benchmark，而不是只测模型会不会在两个答案里选一个。
[Question & Solution]
核心痛点是，现有的 Reward Model、LLM-as-a-Judge、甚至带 CoT 的 judge，经常不是“不会评”，而是先把评判标准想错了：它们容易被长度、格式、语气这些表面特征带偏，也抓不住人类真正重视的隐含要求。作者的核心解法是把这个问题拆开测：构建 1147 个高难度 A/B 对比样本，每个样本都带有人类编写的、只基于 instruction 的 atomic rubrics，然后分别测试三种设置——直接判、模型自生成 rubric 后再判、给人工 rubric 再判。这样就能把“rubric 生成错”与“rubric 执行错”分开，最终证明当前评估瓶颈主要卡在 rubric formation，而不是单纯的 judge 推理能力不够。
[Contrasts]
这篇方法和传统 baseline 的本质区别在于：传统 Scalar RM、Generative RM、Vanilla LLM Judge 主要是在做“直接比较答案”，最多加一段解释或 CoT；而这篇工作强调，真正关键的是“先定义什么才算好答案”。它对比的对象包括 ArmoRM、InternLM2-Reward、Tulu-3、Nemotron-GenRM、RM-R1、GPT-4o-mini judge、DeepSeek judge，以及 OpenRubric、TICK、CheckEval、RocketEval 这类 rubric-aware 方法。论文的核心发现不是“rubric-aware 一定赢”，而是：光有 rubric pipeline 还不够，模型自己写的 rubric 质量才是决定上限的关键变量；一旦把人类 rubric 注入，同样的 backbone 会明显变强，说明 baseline 的根本问题不是“不会打分”，而是“不会定标准”。
[Takeaways]
这篇论文最值得记的有三点。第一，评估系统的瓶颈已经从 judge inference 转到了 judge specification：模型能执行规则，不代表它能自己提出对的规则。第二，更多 test-time compute 不能自动补齐错误 rubric，多采样、多轮 refinement 对自生成 rubric 基本救不了场，说明问题不是“想得不够多”，而是“想偏了”。第三，高质量评估的关键不是更长的 checklist，而是更贴近人类意图的 checklist：模型很容易写出“高刚性、低必要性”的伪规则，看起来专业，实际上抓错重点；后续做 judge、RM、agent evaluator 时，最好把“标准生成”和“标准执行”拆开设计，而不是默认一步到位。
[Limitations & Directions]
局限性主要有四个：一是数据来自已有 benchmark 的再筛选，虽然难度提高了，但分布仍受原始数据源限制；二是人工 rubric 很贵，规模和覆盖面都有限，不容易无限扩展；三是即便给了正确的人类 rubric，模型也不能做到 100% 正确，说明 execution gap 依然存在；四是 rubric matching 和质量分析本身也依赖额外判别器，不是完全无噪声。未来最值得做的方向也很清楚：一是研究如何让模型学会生成更接近人类价值排序的 rubric，而不只是生成更长 checklist；二是研究硬约束/软约束、规则权重、拒答语义这类更结构化的 rubric 表达；三是把 rubric generation、verification、decision 分成多模块优化；四是往更真实的 agent 任务、多轮交互、安全边界和行业场景里扩展，做真正能落地的 evaluator benchmark。