✨ 要点🔬 技术摘要
以下是用通俗语言和日常类比对论文"RepoZero"的解释。
核心思想:AI 能否仅凭蓝图建造房屋?
想象你有一个非常聪明的机器人助手(AI),它擅长修理漏水的水龙头或粉刷一面墙。但现在,你向它提出了一个更棘手的问题:“你能仅凭一份指令列表,在不查看原始蓝图或成品房屋的情况下,从零开始建造整栋房子吗?”
这篇论文 RepoZero 提出的正是这个问题,只不过它关注的不是房屋,而是软件代码仓库 (构成软件程序的文件集合)。
问题所在:“假装直到成功”的陷阱
此前,研究人员通过让 AI 修复小漏洞或编写单个文件来测试这些机器人。但在从零开始构建整个程序时,很难判断 AI 究竟是真正理解 了构建方法,还是仅仅死记硬背 了训练数据中的答案(就像学生死记硬背课本答案而非学习数学原理)。
大多数现有测试依赖人类或其他 AI 阅读代码并说“看起来不错!”。这就像老师批改数学试卷时,只看最终答案而不检查解题过程。这种测试很容易作弊,且不可靠。
解决方案:"RepoZero"挑战
作者创建了一个名为 RepoZero 的全新、超严苛测试。以下是其运作方式,采用烹饪类比 :
原始菜肴(源文件): 想象一位名厨拥有一份复杂蛋糕的秘方。我们确切知道它的味道和表现。
挑战: 我们给 AI 机器人一份食材清单,以及关于蛋糕应该 具备功能的描述(例如:“加热时必须膨胀”,“尝起来必须甜”)。
转折(跨语言): 机器人不允许使用原始食谱。更糟糕的是,它必须在完全不同的厨房 中使用不同的工具来制作蛋糕。
如果原始蛋糕是在 Python 厨房制作的,机器人必须在 JavaScript 厨房中构建它。
如果原始版本是 C++ ,机器人必须在 Rust 中构建它。
为什么? 这阻止了机器人直接复制食谱。它迫使机器人真正理解逻辑并从头重建。
品尝测试(验证): 机器人制作自己的蛋糕。然后我们将两个蛋糕并排品尝。如果机器人的蛋糕表现与原始蛋糕完全一致 (膨胀程度相同、味道相同、质地相同),则通过测试。如果有细微差别,则失败。
"ACE"框架:机器人的自我修正循环
论文还介绍了一种让机器人在工作过程中学习的新方法,称为 ACE (代理代码 - 测试演进)。
这就像大型比赛前的练习环节 :
机器人不再只是尝试一次建造房屋并寄希望于最好结果,而是先构建一小部分,然后立即测试 它。
如果测试失败(例如,“门打不开”),机器人会看到错误,修复门,然后再次测试。
它重复这个循环:构建 -> 测试 -> 修复 -> 构建 。
论文发现,使用这种“练习循环”的机器人在构建最终产品方面,比那些试图一次性完成构建的机器人表现要好得多。
他们发现了什么?
结果令人惊讶且略显清醒:
即使是最“聪明”的机器人也感到吃力: 当今最先进的 AI 模型(如 Claude、DeepSeek 和 Kimi)成功从零构建完整软件“房屋”的概率仅为 30% 到 55% 。
差距巨大: 虽然这些 AI 在编写单行代码方面表现出色,但它们距离能够自主从零构建复杂、可运行的软件系统还有很长的路要走。
自我检查是关键: 使用"ACE"循环(测试并修复自己的工作)的机器人表现显著更好。这表明,要让 AI 成为真正的软件工程师,它需要提高检查自身工作 的能力,而不仅仅是猜测。
总结
RepoZero 是为 AI 机器人设立的一个全新且严格的训练场。它迫使机器人在不同语言中重建复杂软件,以证明它们并非通过死记硬背答案来作弊。测试表明,虽然 AI 在处理小任务方面日益精进,但在能够独立构建整个软件项目之前,仍有很长的路要走。论文指出,实现这一目标的关键在于教会 AI 在构建过程中测试并修复自身的错误 。
技术摘要:RepoZero
问题陈述
尽管大语言模型(LLMs)在代码生成方面已展现出显著进展,但其从零构建完整软件仓库的能力仍知之甚少。现有的仓库级编码基准测试存在关键局限性:
评估偏差 :许多基准测试依赖人工介入或“LLM 作为裁判”的框架,引入了主观性和不可靠性。
数据泄露 :在海量 GitHub 语料库上预训练的模型往往只是记住了现有仓库,而非展示真正的推理能力。使用“干净”或罕见的仓库来缓解这一问题,本质上限制了数据集的规模,且容易受到快速污染。
验证缺口 :当前针对“从零开始”生成的基准测试往往缺乏可验证的、基于执行的真实基准,特别是对于新生成的项目,其预存在的单元测试非常稀缺。
方法论:RepoZero 基准测试
为应对这些挑战,作者引入了 RepoZero ,这是首个专为从零开始的仓库级生成设计、支持完全自动化且基于执行验证的基准测试。
核心概念:仓库复现
RepoZero 将生成任务重构为仓库复现 。代理(Agent)并非仅根据自然语言描述生成代码,而是获得以下输入:
API 规范 :源仓库 API 的功能规范。
白盒测试用例 :提示词中提供的四个示例测试用例(输入和真实输出)。
约束条件 :严格规则以防止“捷径”解决方案,例如跨语言嵌入或直接 API 委托。
代理必须用不同的编程语言 重新实现整个仓库(例如,从 Python 到 JavaScript,或从 C/C++ 到 Rust)。生成的仓库通过执行隐藏测试套件并与原始源仓库进行逐字节输出比较来进行评估。
基准测试构建
数据集 :精心筛选了两个子集:RepoZero-Py2JS (400 个样本,Python 到 JavaScript)和 RepoZero-C2Rust (200 个样本,C/C++ 到 Rust)。
源选择 :仓库根据确定性、开源完整性和架构复杂性(需要多文件实现)进行人工筛选。
测试生成 :LLM 生成调用源 API 的测试文件和用例。这些测试经过严格过滤,以确保它们是确定性的(移除依赖时间或内存地址的输出)且可执行。
评估协议 :
黑盒测试 :代理仅可见四个白盒用例;其余测试套件被隐藏以防止过拟合。
环境隔离 :评估在具有受限文件系统权限的隔离 Docker 容器中运行。
跨语言约束 :禁止代理使用外部包或桥接命令(例如,通过 Shell 包装器调用 Python),强制进行真正的跨语言合成。
代理代码 - 测试演化(ACE)框架
本文提出了 ACE ,一种用于测试时扩展的框架。与静态评估不同,ACE 采用迭代循环:
编码代理生成目标仓库。
测试代理生成新的测试用例并执行源仓库以获取真实输出。
如果目标仓库失败,错误消息会反馈给编码代理以进行优化。 该过程持续进行,直到仓库通过所有测试用例,利用源仓库作为确定性预言机。
主要贡献
RepoZero 基准测试 :首个可扩展、可验证的从零开始仓库生成基准测试,弥合了单文件编码与完整软件工程之间的差距。它独特地将跨语言约束与基于执行的验证相结合。
ACE 框架 :一种新颖的代理工作流,集成了迭代测试生成和错误驱动的优化,实现了复杂仓库合成的有效测试时扩展。
综合评估 :对多个代理脚手架(OpenHands-bash 和 Mini-SWE-Agent)上的最先进 LLM(包括 Kimi、GLM、DeepSeek、Ernie、Minimax 和 Claude)进行了广泛的基准测试。
实验结果
作者在不同难度等级(简单、中等、困难)下评估了众多模型。主要发现包括:
有限的成功率 :即使是最强的代理,其通过率也仅适中。表现最佳的模型 Claude-4.6-Sonnet ,在使用 OpenHands-bash 脚手架时,在 Py2JS 任务上的通过率约为 51.5% ,在 C2Rust 任务上为 44.6% 。
代理性能 :Mini-SWE-Agent 通常优于 OpenHands-bash ,这归因于更复杂的上下文工程。
测试时扩展的影响 :ACE 框架显著提升了性能。对于 OpenHands-bash 上的 DeepSeek V3.1,通过率从仅编码的 26.1% 提升至经过两次“编码 - 测试 - 优化”迭代后的 42.9% 。
失败模式 :分析显示,虽然运行时错误很少见,但代理经常因以下原因失败:
上下文漂移 :在长推理轨迹中丢失对需求的跟踪。
可运行性 vs. 正确性 :约 40% 的可执行代码未能匹配源仓库的确定性输出,突显了“可运行代码”与“语义正确代码”之间的差距。
意义与主张
本文将 RepoZero 定位为端到端代码生成的具有挑战性、可扩展且可靠的测试平台。作者声称:
当前的 LLM 代理,即使有高级脚手架的支持,其能力与现实世界软件开发需求之间仍存在巨大差距 ,通过率很少超过 55%。
通过测试生成进行自我验证 是推进编码代理的关键方向。利用可执行环境进行测试驱动开发的能力被确定为成功的基本决定因素。
该基准测试通过跨语言合成和严格的执行约束成功缓解了数据泄露问题,提供了比以往的"LLM 作为裁判”方法更严格的评估。
该研究得出结论:虽然迭代的“代码 - 测试”循环前景广阔,但未来的进步需要更稳健地集成自主的高质量测试套件合成,并改善代理的长上下文保留能力。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题,再试一次?
无垃圾邮件,随时退订。