[论文阅读] 人工智能 + 软件工程 | 首个仓库级多任务调试数据集！RepoDebug揭秘LLM真实调试水平

首个仓库级多任务调试数据集！RepoDebug揭秘LLM真实调试水平

论文信息

一段话总结

为解决现有代码调试数据集“只聚焦函数级、忽视仓库级场景”“任务/语言/错误类型单一”的问题，论文提出RepoDebug——首个支持“错误识别、错误定位、自动修复”3大任务、覆盖Java/C/Python等8种语言、包含22类错误亚型的仓库级数据集，数据源自63个GitHub仓库并通过AST注入错误+人工校验保障质量；基于该数据集对10个LLM（3闭源+7开源）测试发现，Claude 3.5 Sonnect表现最优但仍存短板，模型在高级语言（Java/JavaScript）上表现更好、语法错误最易处理、多错误最难解决，且代码长度增加会显著降低性能。

思维导图

研究背景

咱们用个通俗的类比：如果把代码调试比作“修东西”，现有LLM的调试能力更像“修单个零件”——比如给一个独立的“加法计算函数”找错改对；但真实开发中，程序员面对的是“修一整辆车”——比如一个包含多个文件的电商后端仓库（User.java处理用户、Order.java处理订单、Pay.java处理支付），要跨文件找错（比如Pay.java调用Order.java函数时传错参数）、处理多个关联错误（比如既少分号又逻辑算反）。

但目前的调试数据集，偏偏跟不上这种“修整车”的需求，主要问题有两个：

1. 场景太窄：多数数据集（如DebugEval）只让模型“修零件”（函数级代码），完全不涉及“修整车”（仓库级项目）；少数仓库级数据集（如SWE-Bench）又只支持Python一种语言，且只能做“修复”这一个任务，没法让模型先判断“有没有错”、再定位“错在哪”——比如小明开发Java电商项目时，遇到“跨文件参数传错+少分号”的问题，现有数据集根本覆盖不到。

2. 错误类型混乱：很多数据集不分类错误，把“少分号”（语法错误）和“循环次数算错”（逻辑错误）混在一起，既没法知道LLM擅长修哪种错，也没法针对性优化——比如想提升LLM处理逻辑错误的能力，却找不到专门的训练数据。

简单说，现有数据集就像“只教修自行车零件，却让去修汽车整车”，完全 mismatch 真实开发需求，这就是论文要解决的核心问题。

创新点

RepoDebug的亮点可以概括为“三个首次+一个精准”，每一个都戳中现有数据集的痛点：

1. 首次覆盖仓库级“全流程调试任务”：第一次让模型完整走“错误识别→错误定位→自动修复”全流程，而不是只做“修复”——就像让修理工先判断“车哪坏了”、再指“具体坏的零件位置”、最后“修好”，完全贴合真实开发中的调试逻辑。

2. 首次支持8种语言的仓库级调试：涵盖从高级语言（Java/JavaScript/Python）到低级语言（C/Rust）、甚至冷门语言（Ruby/C#），解决了之前数据集“语言单一”的问题——比如能同时测试LLM修Java电商项目和C驱动程序的能力，而不是只局限于Python。

3. 首次将错误体系化为22类亚型：把错误分成4大类22小类——语法错误（9类，如少分号、括号不匹配）、引用错误（5类，如调用不存在的函数）、逻辑错误（5类，如条件写反）、多错误（3类，如语法+引用错误并存），能精准定位LLM的“短板”——比如发现Claude 3.5能搞定80%的语法错，却搞不定3%的多错误。

4. 精准的AST-based错误注入：不像传统数据集“靠人工编错误代码”（容易不规范），而是用Tree-Sitter工具解析真实仓库的正确代码生成“代码骨架”（AST），再按真实错误类型“精准做手术”式注入错误——比如要注入“函数名写错”，就直接在AST的“函数调用节点”修改名称，最后还通过自动过滤（确保代码能编译）+人工检查（合格率98.85%）保障质量，比人工编错更贴近真实场景。

研究方法和思路、实验方法

（一）RepoDebug数据集构建方法（4步走，清晰易懂）

步骤1：筛选“合格的仓库”（数据源）

• 从GitHub筛选仓库，满足3个条件：2022年后创建（保证代码新）、≥100星（保证质量）、MIT协议（可合法使用）；
• 最终选了63个仓库，按7:3比例分成46个训练仓库（34457个实例）和17个测试仓库（5438个实例），覆盖电商、工具类等多种场景。

步骤2：AST注入错误（核心创新步骤）

• 用Tree-Sitter解析仓库中的正确代码，生成抽象语法树（AST）——可以理解为“代码的骨架”，能看清函数、变量、条件判断的结构；
• 根据22类错误亚型，在AST上“精准改节点”：比如要注入“引用错误”，就找到AST中“函数调用节点”，把正确函数名改成错误的（如getUser()→getUsers()）；要注入“多错误”，就同时改2-4个不同节点（如改函数名+删分号）；
• 规则：单错误只改1行，多错误可跨文件但需相关（比如改A文件的函数名，同时改B文件调用该函数的参数）。

步骤3：质量校验（确保数据靠谱）

• 自动过滤：比如C语言代码注错后，要能通过编译（避免注错后代码完全没法用）；Python代码注错后，要能运行到错误位置（不直接报语法错）；
• 人工检查：从8种语言中各抽20个实例，检查“错误类型是否匹配”“代码是否可运行”“信息是否完整”，合格率超98.85%，确保数据质量。

步骤4：整理数据格式

• 每个数据实例包含“原始正确代码+注错后代码+错误类型+错误行位置”，方便模型直接用于3大任务：判断错误（输入注错代码，输出是否有错+错误类型）、定位错误（输出错误行）、修复错误（输出正确代码）。

（二）实验方法（3步评估LLM能力）

步骤1：选择评估模型

• 共10个LLM，分两类：
  • 闭源模型（3个）：Claude 3.5 Sonnect（最新代码强模型）、GPT-4o（多模态强模型）、GPT-4o-mini（轻量版）；
  • 开源模型（7个）：Qwen2.5 Coder（7B/14B）、StarCoder2（7B/15B）、DeepSeek-Coder-V2、Code Llama-7B等，用Ollama框架做4位量化（节省算力）。

步骤2：确定评估指标

• 错误识别（BI）：用“准确率”判断模型预测的错误类型是否和实际一致；
• 错误定位（BL）：分“单错误定位（OBL）”（预测错误行与实际有1行重叠就算对）和“全错误定位（ABL）”（预测错误行包含所有实际错误行才算对），均用准确率；
• 自动修复（APR）：用“Pass@1”（修复后代码通过所有测试用例的比例）、“编辑相似度（ES）”（修复代码与正确代码的相似程度）、“完全匹配（EM）”（修复代码与正确代码完全一致的比例）。

步骤3：搭建实验环境

• 硬件：Intel Xeon CPU + NVIDIA A100/4090 GPU（跑开源模型）；
• 软件：Ubuntu系统，闭源模型调用官方API，开源模型用Ollama框架，确保上下文长度足够（如DeepSeek-Coder支持16万tokens，避免截断长代码）。

主要成果和贡献

（一）核心实验成果（表格+大白话解读）

（二）核心贡献（给领域带来的实际价值）

1. 填补仓库级调试评估空白：之前没有数据集能同时支持“多任务+多语言+多错误”的仓库级场景，RepoDebug第一次做到了，给后续研究提供了“标准训练场”；
2. 揭示LLM调试短板：明确告诉行业“LLM在仓库级场景还不行”——尤其是多错误、长代码、低级语言这三个痛点，为后续模型优化指明方向（比如提升长上下文注意力、增加低级语言训练数据）；
3. 提供可复用的基准实验：公开了10个LLM的测试结果，后续新模型不用重复搭环境测基础数据，直接对比就能知道自己的水平；
4. 数据集质量可靠：AST注错+人工校验确保错误真实、代码可运行，且覆盖8种语言22类错误，满足不同研究需求（比如有人想优化Rust调试，直接用RepoDebug的Rust数据就行）。

（三）开源资源

• 数据集地址：https://github.com/RepoDebug-Team/RepoDebug（假设开源，具体以论文附录为准）；
• 实验代码：论文补充材料提供完整实验配置和代码，可通过论文链接下载。

关键问题

1. 问：RepoDebug和之前的仓库级数据集（如SWE-Bench）比，优势在哪？
   答：核心优势是“全”——SWE-Bench只支持Python+仅能做修复任务+错误无分类，而RepoDebug支持8种语言+3大任务（识别+定位+修复）+22类错误亚型，能更全面测试LLM的真实调试能力，比如能测LLM修Java多错误项目，SWE-Bench做不到。

2. 问：即使是表现最好的Claude 3.5，在仓库级调试中还有哪些明显短板？
   答：有三个大短板：①多错误处理差（识别准确率仅3.66%）；②长代码能力降（＞500 tokens准确率就下滑）；③低级语言（C/Rust）不擅长，这说明LLM目前还没法完全替代程序员处理复杂仓库项目。

3. 问：RepoDebug的错误是人工注入的，会不会和真实项目的错误不一样？
   答：不会！因为注入错误的“原材料”是真实GitHub仓库的正确代码（保证场景真实），注入的错误类型也是程序员常犯的（如函数名写错、少分号），最后还人工校验确保错误符合实际，比单纯人工编错更贴近真实开发。

4. 问：这个研究对普通开发者有什么用？
   答：能帮开发者“理性用LLM调试工具”——比如用ChatGPT修Java单文件语法错时效率高，但修C语言多文件多错误项目时，别指望它一次搞定，一定要自己核对错误位置和修复结果，避免踩坑。

总结

这篇论文的核心工作是“造了一个好数据集（RepoDebug）+用它测清了LLM的调试水平”：针对现有数据集“只修零件、不修车”的问题，RepoDebug首次构建了覆盖“多任务+多语言+多错误”的仓库级数据集，通过严格的构建流程保障质量；基于该数据集的实验清晰揭示了LLM的调试现状——闭源模型优于开源，但所有模型都存在多错误、长代码、低级语言处理能力不足的短板。

论文的价值不仅是填补了技术空白，更给行业提供了“LLM调试能力的基准线”：对研究者，明确了后续优化方向；对开发者，提供了理性使用LLM调试工具的参考。当然，论文也提到局限——仓库级任务需要长上下文，对模型架构和算力要求高，未来还需更高效的模型来突破这一限制。