bench papers

•
AI4SE

Automatically Benchmarking LLM Code Agents through Agent-driven Annotation and Evaluation

paper link

  • Agent as a judger：一种评估范式，其中一个智能体或LLM被用作“评委”来对另一个智能体的输出进行评分、分析和评估
  • Scaffold：一个软件项目的核心框架，包括模块设计和接口设计，用于辅助标注
  • Arrange-Act-Assert：准备测试数据和环境 -> 执行被测行为 -> 验证结果是否符合预期

现状问题

  • 高标注成本和专业知识要求高，需要大量时间投入
  • 僵化的评估指标，主要依赖于单元测试

贡献

提出了一个以产品需求文档为中心的基准测试集，并设计了一个智能体驱动的数据生成管线

pipeline:

image

  • 从学术论文，github上找一些”seed tasks”
  • LLM分析，创建初始的prd和aaa-method
  • code agent根据上一步创建的prd和aaa-method生成一个代码的基本框架（scaffold），评估方案和一些测试要用的东西
  • 评估人根据生成的scaffold&something4test来建议
  • code agent根据建议修改内容
  • 最后移除scaffold，保留下来一份纯净的prd和评估方案

评估实验

引入EvalAgent作”Agent as a judger”
image

DevBench: A Comprehensive Benchmark for Software Development

paper link

  • Software Development Lifecycle, SDLC：指软件从概念提出到最终退役的整个过程，包括需求分析、设计、实现、测试、部署和维护等阶段。DevBench重点评估设计、环境搭建、实现、验收测试和单元测试等阶段。
  • Oracle Test：一种测试方法，通过比较模型生成的预期输出与参考代码的实际输出来评估测试用例的正确性

problems

  • 现有基准测试的局限性：当前代码生成基准（如HumanEval、APPS）主要关注单文件代码生成或简化任务，无法全面反映真实软件开发中的复杂挑战（如多文件协作、依赖管理）。
  • 缺乏全生命周期评估：现有工作（如SWE-bench）仅聚焦于代码修复等狭窄环节，缺少对软件设计、环境搭建等关键阶段的系统化评估。
  • 模型在复杂场景中的能力不足：即使先进模型（如GPT-4-Turbo）在DevBench的仓库级代码生成任务中通过率低于10%，尤其在处理多语言、复杂项目结构时表现不佳。

contributions

  • 提出首个全生命周期评估基准：DevBench覆盖软件开发的5个核心阶段（设计、环境搭建、实现、验收测试、单元测试），填补了综合性评估的空白。
  • 构建高质量多语言数据集：包含22个精选仓库，涵盖Python、C/C++、Java、JavaScript4种语言，涉及机器学习、Web服务、算法等多个领域，平均每个仓库包含2-7个代码文件、276-617行代码。
  • 设计细粒度评估指标：针对不同任务定制评估方案（如LLM辅助评估设计任务、Oracle测试验证测试代码），确保评估的严谨性。
  • 实证揭示模型瓶颈：发现模型在理解仓库结构、管理编译过程、掌握面向对象编程等高级概念上存在显著困难，为未来研究提供方向。

workflow

DevBench基于瀑布模型设计，将软件开发分解为模块化任务，支持端到端或分阶段评估。核心流程如下：

  • 步骤1：软件设计
    输入PRD，模型需生成UML类图/序列图（使用Mermaid语法）和架构设计（文件树结构）。评估重点为设计的 cohesion（内聚性）、decoupling（解耦）和与PRD的忠实度。
  • 步骤2：环境搭建
    根据PRD和设计文档，生成依赖文件（如Python的Conda配置、Java的Gradle文件）。评估基于依赖安装成功率和示例代码执行通过率。
  • 步骤3：代码实现
    模型按架构设计依次生成各代码文件，遵循依赖关系的有向无环图顺序。评估通过预定义的验收测试和单元测试的通过率。
  • 步骤4：测试生成
    • 验收测试：模型基于PRD生成验收测试代码，通过Oracle测试验证其准确性。
    • 单元测试：模型为代码单元生成测试，评估指标包括Oracle测试通过率和代码覆盖率。

experiments val

  • 评估基准：在DevBench自有的22个仓库数据集上进行测试，覆盖4种编程语言和多个领域（NLP、CV、数据库等）。
  • 核心指标：
    • 实现任务：验收测试通过率（Pass@Accept. Test）和单元测试通过率（Pass@Unit Test）。
    • 测试任务：Oracle测试准确率和代码覆盖率。
    • 环境任务：示例代码执行成功率。
  • 主要结果：
    • GPT-4-Turbo表现最佳，但实现任务通过率仍低于10%（验收测试7.1%，单元测试8.0%），其他任务最高通过率不超过40%。
    • 开源模型（如CodeLlama-34B）在复杂任务中接近零通过率，凸显能力差距。
    • 执行反馈（Execution-Feedback）提示策略能显著提升效果（如GPT-4在实现任务中通过率从3.0%提升至8.9%）。
  • 消融实验：
    • 验证了外部信息（如执行反馈）对模型性能的关键作用：无反馈的审查（Normal-Review）几乎无改善。
    • 在测试任务中，提供源代码作为输入可使验收测试性能提升约10-15%（如GPT-4从7.7%升至14.9%）。