大模型无法替代码农！普林斯顿芝大惊人发现：GPT-4解决GitHub编程问题成功率为0( 三 ) _大模型

文章插图
如果补丁应用成功，并且通过所有这些测试，就可以认为LLM建议的方案成功地解决了问题。
基准的度量指标，是已解析任务实例的百分比。
构建SWE-bench的独特数据集
传统的NLP基准，通常只涉及短的输入和输出序列，并考虑一些专门为基准创建的“人为”问题。
相比之下，为了构建SWE-bench ，研究者为数据集注入了独特的属性。
比如，采用的是真实的软件工程任务。

文章插图
由于SWE-bench中的每个任务实例都包含一个庞大而复杂的代码库和相关问题的描述，解决SWE-bench，就需要经验丰富的软件工程师拥有的复杂技能和知识，但在传统的代码生成基准中，这些通常不被评估。
而且，收集过程可以轻松地应用于GitHub上的任何Python存储库，几乎不需要人工干预。
因此，研究者就可以通过不断提供新的任务实例来扩展SWE-bench，并就训练日期后创建的问题对语言模型进行评估，这就确保了训练语料库中，并没有包含解决方案。
此外，研究者还保证了基准中不同的长输入、稳健评估、跨上下文代码编辑、解决方案的广泛范围等。
微调SWE-Llama
接下来，就是到了评估开放模型与专有模型在SWE-bench框架的效果了。
可是研究者发现，现成的CodeLlama微调模型，无法遵循详细的指令生成整个资源库范围内的代码编辑，通常会输出占位符响应或不相关的代码。
为了评估这些模型的能力，研究人员对70 亿参数的CodeLlama-Python模型和130亿参数的CodeLlama-Python模型进行了监督微调（SFT）。
由此产生的模型是专门的仓库编辑器，可在消费级硬件上运行，并解决GitHub问题。

文章插图
大模型都败北
接下来，研究者对GPT-3.5、GPT-4、Cluade 2以及微调的模型进行了评估。
结果发现，所有模型都失败了——除了发现最简单的问题外，它们都无法解决所有问题。
比如，Claude 2和GPT-4分别只能解决4.8%和1.7%的任务。
在使用BM25检索器后，Claude 2的性能进一步下降到1.96% 。
【大模型无法替代码农！普林斯顿芝大惊人发现：GPT-4解决GitHub编程问题成功率为0】不同资源库的难度不同。
如果按资源库对性能进行细分，就会发现所有模型在不同资源库中都表现出相似的趋势。
尽管如此，每个模型所解决的问题并不一定广泛重叠。比如，在Oracle设置中， Claude 2和SWE-Llama 13b的性能相当，每个模型分别解决了110个和91个实例。
难度与上下文长度相关。
模型可以在长代码序列上进行预训练，但通常要求一次生成单个函数，并提供有限的上下文来确定问题的框架。
如图所示，可以看到随着上下文总长度的增加，Claude 2 的性能大幅下降，这种情况在其他模型中也可以观察到。
即使增加BM25的最大上下文大小，会提高相对于甲骨文文件的召回率，但性能仍然会下降，因为模型根本无法在茫茫词库中定位有问题的代码。

文章插图
难度与问题解决日期无关。
在表7中，展示了在「oracle」检索设置下，针对2023年之前或之后创建的 PR，按日期划分的模型结果。
对于大多数模型来说，除GPT-4外，在这一日期之前或之后的性能差别不大。

文章插图
另外，研究还发现微调模型对上下文分布变化很敏感，生成补丁比生成整个文件更容易。而且大模型倾向于生成更短、更简单的编辑。
LLM无法替代程序员，但可以加快工作流
有网友对「通才模型」的未来有所憧憬和希望。
没错，这也是我的经验之谈。通才模型还不够好，没有足够宽的上下文长度，除了相对较短的代码片段外，无法自行编码。
但我认为这只是时间问题。我可以预见，在不久的将来，接受过特定训练的通才LLM将成为非常专业的模型。