FEA-Bench: A Benchmark for Evaluating Repository-Level Code Generation for Feature Implementation¶
会议: ACL 2025
arXiv: 2503.06680
代码: https://github.com/microsoft/FEA-Bench
领域: 文本生成
关键词: 代码生成, 仓库级开发, 新特性实现, 基准测试, 增量开发
一句话总结¶
提出 FEA-Bench——首个评估 LLM 在仓库级代码库中实现新特性（Feature Implementation）能力的基准，包含来自 83 个 GitHub 仓库的 1401 个任务实例，每个实例配有单元测试。最强模型 DeepSeek-R1 仅解决约 10% 的任务，揭示了仓库级增量开发对当前 LLM 的巨大挑战。
研究背景与动机¶
- 领域现状：代码生成评估已从单文件（HumanEval、MBPP）发展到仓库级（SWE-bench），但 SWE-bench 聚焦于 bug 修复。在实际软件开发中，新特性实现（添加新函数、新类、甚至新文件）是更核心的开发活动。
- 现有痛点：(a) 缺乏专门评估新特性实现的基准——SWE-bench 的 pull request 主要是 bug fix，不涉及添加新组件；(b) 新特性实现同时要求代码生成（新组件）和代码编辑（修改现有代码的关联部分），比 bug fix 更复杂；(c) 代码补全（Code Completion）只关注局部生成，不评估全局影响。
- 核心矛盾：新特性实现是软件发展的驱动力，但现有评估都忽略了它——评估的是"修复已有问题"而非"创造新功能"。
- 本文要解决什么？ 定义仓库级增量代码开发任务并构建首个基准。
- 切入角度：从 GitHub pull request 中筛选出专注于新特性开发（引入新函数/新类/新文件）的实例，配对单元测试进行执行验证。
- 核心idea一句话：评估 LLM 同时"创建新代码"和"修改已有代码"的能力——比 bug fix 更难。
方法详解¶
整体框架¶
(1) 从 83 个 GitHub 仓库收集 pull request；(2) 用规则过滤（是否引入新函数/类）和意图过滤（是否是新特性开发而非 bug fix）筛选任务实例；(3) 配对每个实例的单元测试文件；(4) 最终构建 1401 个任务实例的 FEA-Bench。
关键设计¶
- 任务定义（Repository-Level Incremental Code Development）:
- 做什么：给定仓库代码库 + 特性描述（PR 描述），LLM 需要同时创建新代码组件和修改已有代码
- 与 SWE-bench 的区别：SWE-bench 修复 issue（代码修改为主），FEA-Bench 实现新特性（代码创建+修改）
-
设计动机：新特性实现要求更全面的代码理解——不仅要知道"在哪改"还要"添加什么"
-
数据构建流水线:
- 做什么：从 GitHub PR 中自动筛选新特性实现实例
- 核心思路：(a) AST 解析检测 PR 是否引入了新的函数/类定义；(b) 意图分类器过滤掉 bug fix、重构、文档更新等非特性 PR；(c) 检查配对的单元测试是否存在且可执行
-
设计动机：不能简单用所有 PR——需要精确筛选"新特性"类型
-
评估指标:
- 做什么：基于执行的自动评估
- 核心思路：运行配对的单元测试，统计通过率
- 指标分为：完全解决率（所有测试通过）和部分解决率
损失函数 / 训练策略¶
- 纯评估基准——无训练组件
- 评估多个 SOTA LLM：DeepSeek-R1/V3、GPT-4/4o/o1、Claude-3.5-Sonnet 等
实验关键数据¶
主实验（完全解决率 %）¶
| 模型 | 参数 | FEA-Bench（完整） | FEA-Bench（精选） |
|---|---|---|---|
| DeepSeek-R1 | 671B | ~10% | ~14.5% |
| DeepSeek-V3 | 671B | ~8% | ~14.5% |
| GPT-4o | - | ~6% | ~5% |
| Claude-3.5-Sonnet | - | ~7% | - |
| GPT-4 | - | ~5% | ~6% |
| o1-mini | - | ~2% | ~2-3% |
FEA-Bench vs SWE-Bench 统计差异¶
| 特征 | SWE-Bench | FEA-Bench |
|---|---|---|
| 主要任务类型 | Bug fix | 新特性实现 |
| 新函数引入 | 少 | 多（核心） |
| 代码变更长度 | 较短 | 较长 |
| 所需能力 | 代码编辑 | 代码创建+编辑 |
| 最强模型解决率 | ~50%+ | ~10% |
关键发现¶
- 最强 LLM 仅解决 ~10% 的新特性任务——远低于 SWE-bench 上 >50% 的 bug fix 解决率
- 新特性实现需要更长的代码生成——任务难度和所需创造性显著高于 bug fix
- DeepSeek-R1 因其强大的推理能力领先——但仍然大幅落后于人类开发者
- 模型在"理解仓库结构"和"定位需要修改的现有文件"上是主要瓶颈
- 小模型（如 DeepSeek-R1-Distill-32B）性能显著下降——仓库级任务对模型能力要求高
亮点与洞察¶
- "创造比修复更难"的发现符合直觉但被量化了——SWE-bench 上 50%+ 到 FEA-Bench 上 ~10% 的落差说明 LLM 的代码"创造力"远逊于"修补力"。
- 同时要求代码创建和代码编辑是 FEA-Bench 的独特挑战——真实开发中这两者总是并存的。
- 83 个仓库的多样性确保了基准的代表性——涵盖了不同领域、不同规模的 Python 项目。
- 基于执行的评估（单元测试）比基于匹配的评估更可靠。
- 该基准可用于持续追踪 LLM 代码生成能力的进步——特别是"创造性开发"维度。
局限性 / 可改进方向¶
- 仅覆盖 Python 仓库——Java、TypeScript 等其他语言的新特性实现未涉及
- 1401 个实例虽比 SWE-bench 大但仍可扩展
- PR 描述的质量不均——有些描述很详细，有些很简略，影响了任务公平性
- 仅评估"是否通过测试"——不评估代码质量（可读性、可维护性等）
- 过滤流水线可能遗漏某些新特性 PR 或错误包含非特性 PR
相关工作与启发¶
- vs SWE-bench: SWE-bench = bug fix 评估，FEA-Bench = 新特性评估——互补定位
- vs HumanEval/MBPP: 单文件编程题，无仓库上下文——FEA-Bench 的仓库级更接近真实开发
- vs TestCase-Eval: TestCase-Eval 评估测试生成，FEA-Bench 评估代码生成——不同角度
- LLM 开发助手（Cursor、Devin）在新特性实现上的能力可用 FEA-Bench 评估
评分¶
- 新颖性: ⭐⭐⭐⭐⭐ 首个仓库级新特性实现评估基准，填补 SWE-bench 的重要空白
- 实验充分度: ⭐⭐⭐⭐ 83仓库+1401实例+多个SOTA模型+与SWE-bench对比
- 写作质量: ⭐⭐⭐⭐ 定义清晰，与SWE-bench的区别阐述到位
- 价值: ⭐⭐⭐⭐⭐ 对代码LLM评估和软件工程AI有重大贡献