爱游戏中国官方网站大模型无法替代码农！普林斯顿芝大惊人发现：GPT-4解决GitHub编程问题成功率为0ChatGPT之类的AI编码工具来势汹汹，Stack Overflow又裁员了！不过，普林斯顿和芝大竟发现，面对真实世界GitHub问题，GPT-4的解决率竟是0%。

　　作为全世界每个开发者最爱的代码辅助网站，Stack Overflow在此前的形势还一片大好，在去年掀起了一场招聘狂潮，整个公司的员工人数都翻了一番，达到了540人。

　　AI聊天机器人提供的帮助，比5年前的论坛帖子更加具体。通过LLM，开发者可以及时更正确切的代码、优化建议，以及每行代码正在执行操作的说明。

　　虽说LLM提供的答案也并不是100%可靠，但代码具有独特的能力，只需在IDE集成开发环境中进行测试，即可立即验证代码了，这一切都使写代码成为了ChatGPT的理想用例。

　　CEO对于裁员的解释是，宏观经济压力下，Stack Overflow在努力走上盈利之路，不断推出产品创新。

　　ChatGPT给Stack Overflow造成冲击这件事，最大讽刺之处在于，大语言模型的强大能力，很大程度上就是来自像Stack Overflow这样的抓取网站。

　　大语言模型吸空了这些数据，却不回馈任何东西，如果所有数据源都赶出了这一业务，那时会发生什么？

　　一是开发自己的AI编码工具OverflowAI，二是直接和OpenAI这样的科技公司寻求合作，因为这些公司会使用Stack Overflow的数据构建AI模型。

　　据悉，OpenAI正在为ChatGPT开发网络爬虫控制，这样Stack Overflow这样的网站的数据就不会被爬取。

　　CEO表示，Stack Overflow已经表明了立场：谁想用我们的数据来训练LLM，谁就来付费。

　　CEO认为，像Stack Overflow这样的网站对于大语言模型的发展至关重要，为了进步，它们需要在新知识上进行训练。

　　在最新论文中，研究人员提出了一种全新框架SWE-bench，以评估大模型在解决2294个GitHub真实问题中的能力。

　　再具体点，GPT-4可以解决随机GitHub问题的通过率竟是0%，而最佳模型Claude 2，也只能解决其中的1.96%。

　　更值得一提的是，在使用BM-25检索每个问题的相关代码文件时，Claude 2编写的补丁中只有23%是有效的（可以用于repo），只有~1%真正解决了问题。

　　终于有人为代码模型制作了一个真正的eval数据集，HumEval只是LLM的leetcode面式。我们都知道，这对人类工程师来说是个错误的衡量标准。不到4%听起来是对的，因为大模型离完全自主还很远。

　　在这项研究中，作者发现，当前许多评测大模型编码能力的基准已经趋于饱和，无法评测出大模型真正的实力。

　　修复一个bug可能需要浏览庞大的资源库，理解不同文件中函数之间的关系，又或者在错综复杂的代码中发现一个小错误。

　　SWE-bench通过连接GitHub问题和解决相关测试的合并请求解决方案，从真实Python代码库中获取任务实例。

　　首先从GitHub上12个流行的开源Python代码库中收集拉取请求（PR），总生了约90,000个PR。

　　研究人员将重点放在流行的仓库上，因为这些仓库往往维护得更好，有明确的贡献者指南，并且有更好的测试覆盖率。每个PR都有一个相关的代码库，即PR合并前的仓库状态。

　　创建候选任务的方法是，选择符合以下条件的合并PR：（1）解决了GitHub问题；（2）修改了仓库的测试文件，这表明用户很可能贡献了测试来检查问题是否已解决。

　　研究者会过滤掉没有至少一项测试的任务实例爱游戏(ayx)中国官方网站，这些测试的状态从失败变为通过（以下简称「失败到通过测试」）。此外，还会过滤掉导致安装或运行错误的实例。

　　通过这些阶段的筛选，原始的90,000个PR被筛选为2,294个任务实例，这些任务实例构成了SWE-bench。

　　如下图3所示，显示了这些任务实例在不同资源库中的最终分类，表是SWE-bench任务实例的主要特征。

　　研究者强调，这些代码库都很大，包含数千个文件，而且参考拉取请求通常会同时对多个文件进行修改。

　　其中包括，利用用户提交的问题和解决方案的线个资源库的独特代码问题为特色的多样化输入、基于执行的强大评估框架，以及利用新实例不断更新基准的能力，且只需极少的人工干预。

　　研究者会使用unix的补丁程序，将生成的补丁应用于代码库，然后执行与任务实例相关的单元和系统测试。

　　由于SWE-bench中的每个任务实例都包含一个庞大而复杂的代码库和相关问题的描述，解决SWE-bench，就需要经验丰富的软件工程师拥有复杂的技能和知识，但在传统的代码生成基准中，这些通常不被评估。

　　因此，研究者就可以通过不断提供新的任务实例来扩展SWE-bench，并就训练日期后创建的问题对语言模型进行评估，这就确保了训练语料库中，并没有包含解决方案。

　　可是研究者发现，现成的CodeLlama微调模型，无法遵循详细的指令生成整个资源库范围内的代码编辑，通常会输出占位符响应或不相关的代码。

　　尽管如此，每个模型所解决的问题并不一定广泛重叠。比如，在oracle设置中，Claude 2和SWE-Llama 13b的性能相当，每个模型分别解决了110个和91个实例。

　　模型可以在长代码序列上进行预训练，但通常要求一次生成单个函数，并提供有限的上下文来确定问题的框架。

　　如图所示，可以看到随着上下文总长度的增加，Claude 2 的性能大幅下降，这种情况在其他模型中也可以观察到。

　　即使增加BM25的最大上下文大小，会提高相对于甲骨文文件的召回率，但性能仍然会下降，因为模型根本无法在茫茫词库中定位有问题的代码。

　　在表7中，展示了在「oracle」检索设置下，针对2023年之前或之后创建的 PR，按日期划分的模型结果。

　　另外，研究还发现微调模型对上下文分布变化很敏感，生成补丁比生成整个文件更容易。而且大模型倾向于生成更短、更简单的编辑。

　　没错，这也是我的经验之谈。通才模型还不够好，没有足够宽的上下文长度，除了相对较短的代码片段外，无法自行编码。

　　但我认为这只是时间问题。我可以预见，在不久的将来，接受过特定训练的通才LLM将成为非常专业的模型。

　　虽然大模型无法替代程序员，但可以加速他们的工作流。过去需要10人的团队，现在可能只需要4个人。这样就能腾出资源，用于公司筹备的其他目标。