告别静态评估！CODE2BENCH：动态追踪LLM在真实世界代码中的真本事

论文信息

• 原标题：Dynamic Benchmark Construction for Evaluating Large Language Models on Real-World Codes
• 主要作者：Zhe Zhang, Runlin Liu, Aishan Liu, Xingyu Liu, Xiang Gao, Hailong Sun
• 研究机构：Beihang University（北京航空航天大学）
• 引文格式（APA）：Zhang, Z., Liu, R., Liu, A., Liu, X., Gao, X., & Sun, H. (2025). Dynamic benchmark construction for evaluating large language models on real-world codes. arXiv preprint arXiv:2508.07180v1 [cs.SE]. Retrieved from https://arxiv.org/abs/2508.07180v1

一段话总结

本文提出了一个名为CODE2BENCH的动态基准测试框架，旨在解决现有大型语言模型（LLMs）代码生成评估中存在的数据污染和测试严谨性不足的问题。该框架通过定期摄入GitHub最新代码实现“自动化动态性”、基于范围图分析分类任务依赖（自包含SC和弱自包含WSC）、利用基于属性的测试（PBT）生成高覆盖率测试用例，构建了首个动态基准CODE2BENCH-2505（含1163个来自880个Python项目的任务）。对16个LLM的评估显示，模型在需复杂逻辑的SC任务和跨语言生成中表现较差，而在依赖常见库的WSC任务中表现更优，为LLM代码能力评估提供了更真实、严谨的工具。

思维导图

研究背景

随着GitHub Copilot、Cursor等LLM工具融入软件开发流程，评估它们生成真实世界代码的能力变得至关重要。但现有评估基准存在两大“硬伤”：

1. 数据污染严重：多数基准依赖静态数据集（如HumanEval），这些数据可能早已被LLM的训练数据包含。就像老师用往年考题测试学生，若学生提前做过原题，分数就无法反映真实水平。例如，某LLM在某静态基准上表现优异，可能只是“记住”了答案，而非真正理解逻辑。

2. 测试用例太“敷衍”：很多基准的测试用例是人工设计的，数量少且覆盖不全。这好比考试只考3道简单题，无法发现学生对复杂知识点的掌握漏洞。例如，某函数可能在常规输入下运行正常，但遇到边缘情况（如空列表、极大值）就出错，而简陋的测试用例根本检测不出来。

此外，现有基准要么缺乏动态更新机制（如RepoBench），要么不处理代码依赖（如LiveCodeBench），难以模拟真实开发中“调用外部库”“处理复杂逻辑”等场景。因此，学术界急需一个能动态更新、严谨测试、贴合真实开发的评估工具。

创新点

CODE2BENCH的三大核心创新，直击现有基准的痛点：

1. 自动化动态性：让基准“活”起来
   定期从活跃GitHub仓库抓取最新代码（如2024年8月至2025年5月的提交），确保测试数据不在LLM训练集中。这就像老师每周更新考题，杜绝学生“背答案”，真正考验临场发挥。

2. 依赖分析：给任务“分难度”
   用“范围图”技术分析函数依赖，将任务分为：

   • 自包含（SC）：无外部依赖，仅用语言原生功能（如纯Python逻辑），适合跨语言评估；
   • 弱自包含（WSC）：依赖37个常见库（如numpy、pandas），贴近真实开发场景。
     这种分类让评估更精准，避免“用小学生题考大学生”或反之。

3. PBT测试：让错误“无所遁形”
   传统测试用例是“固定输入→预期输出”，而PBT通过定义“属性规则”（如“函数输出应与 ground truth 等价”），自动生成海量多样的输入（包括边缘情况）。例如，测试一个排序函数时，PBT会生成空列表、重复元素、极大值等输入，确保100%分支覆盖。这好比质检员用各种极端条件测试产品，而非仅看常规使用情况。

研究方法和思路

CODE2BENCH的工作流程分为两大阶段，每一步都针对现有基准的缺陷设计：

阶段1：候选函数筛选（从GitHub到高质量候选）

1. 抓代码：从≥500星的GitHub项目中提取函数，优先选择2024年8月后的提交（避开LLM训练数据）。
2. 预处理：用Tree-sitter解析代码生成抽象语法树（AST），提取函数签名、参数类型等信息。
3. 依赖分析：用范围图技术识别外部依赖，筛选出SC（无依赖）和WSC（仅依赖允许的库）函数，剔除依赖自定义模块的函数。
4. 质量过滤：
   • 用控制流图（CFG）分析排除“不可测试”函数（如无返回值、仅返回常量）；
   • 用圈复杂度筛选中等难度函数（2-10之间）；
   • 用LLM作为“裁判”，剔除过于简单的函数（如简单getter/setter）。

阶段2：基准实例构建（从候选到可直接评估的测试用例）

1. 生成PBT测试用例：基于函数参数类型和逻辑，用Hypothesis等工具生成平均480个测试用例，确保100%分支覆盖。
2. 构建测试运行器：针对不同语言（Python、Java、Go等）生成自动化脚本，加载测试用例并对比LLM生成代码与ground truth的输出。
3. 生成任务指令：包含函数签名和精炼文档字符串（用LLM优化，确保清晰性），作为LLM的输入提示。

主要贡献

CODE2BENCH给LLM代码评估领域带来了三大实质性突破：

1. 首个动态、抗污染的真实世界基准
   解决了静态基准的数据污染问题，通过动态更新确保评估的真实性。对比现有基准，CODE2BENCH在关键维度全面领先：

   基准	动态性	依赖处理	测试严谨性	多语言
   HumanEval	✗	✗	✗	✗
   LiveCodeBench	✓	✗	✓	✓
   CODE2BENCH-2505	✓	✓	✓	✓

2. 揭示LLM代码生成的“软肋”
   对16个LLM的评估发现：

   • 跨语言能力差：Python表现最佳（如Claude-3.7-sonnet达39.9%），Go最差（部分模型仅6.2%）；
   • 复杂逻辑处理弱：SC任务（需自定义逻辑）Pass@1显著低于WSC任务（依赖常见库），例如Gemini-2.5-flash在SC为39.9%，WSC达53.0%。

3. 开源资源助力后续研究
   代码、数据和结果已开源：https://code2bench.github.io/，方便研究者复现和扩展。

关键问题

1. CODE2BENCH如何解决数据污染问题？
   答：通过“自动化动态性”，定期从GitHub抓取最新代码（如2024年8月后的提交），确保测试数据不在LLM训练集中，避免模型“记住”答案。

2. SC和WSC任务的核心区别是什么？
   答：SC任务无外部依赖，仅用语言原生功能（如纯Python逻辑），考验LLM的独立逻辑设计能力；WSC任务依赖37个常见库（如numpy），更贴近真实开发中调用库的场景。

3. PBT测试相比传统测试有何优势？
   答：PBT通过定义“属性规则”自动生成海量多样的输入（包括边缘情况），实现100%分支覆盖，能发现传统固定用例遗漏的细微错误（如函数在极端输入下的异常）。

4. LLM在CODE2BENCH上的表现暴露了哪些问题？
   答：一是跨语言能力弱，在Python外的语言（如Go）表现大幅下降；二是复杂逻辑处理差，SC任务通过率显著低于WSC任务，说明LLM更擅长复用库模式，而非设计原创逻辑。

总结

CODE2BENCH通过动态更新、精细依赖分类和严谨PBT测试，构建了首个能真实反映LLM在真实世界代码生成能力的基准框架。其衍生的CODE2BENCH-2505基准揭示了当前LLM在跨语言生成和复杂逻辑设计上的短板，为改进LLM代码能力提供了明确方向。未来，该框架可扩展到更多语言和领域，进一步推动LLM在软件开发中的实用化。