GPT-4写代码不如ChatGPT，误用率高达62%！加州大学两位华人开源代码可靠性基准RobustAPI _GPT-4

文章插图
新智元报道
编辑：LRS
【新智元导读】代码能否跑起来的不是判断可靠性的标准，用语言模型写代码还需要考虑生产环境下的预期外输入。
大型语言模型（LLM）在理解自然语言和生成程序代码方面展现出了非凡的性能，程序员们也开始在编码过程中使用Copilot工具辅助编程，或是要求LLM生成解决方案。
经过几版迭代后，目前LLM生成的代码已经很少有语法错误了，也更贴合用户输入的文本、符合预期语义，但针对LLM代码生成的可靠性和鲁棒性仍然缺乏彻底的研究。
代码的可执行并不等同于可靠，软件的开发环境、部署环境都存在很大的不确定性。

文章插图
如果直接使用LLM生成的代码，可能会因为AP误用（misuse）导致更严重的问题，例如资源泄漏、程序崩溃；最糟糕的是，使用LLM代码生成服务的用户大多数都是新手开发人员，很难识别出「貌似可运行代码」下的隐藏问题，进一步增加了漏洞代码在现实中的应用风险。
现有的代码评估基准和数据集主要专注于小任务，例如面试中的编程问题，可能不符合开发人员在工作中的实际需求。
最近，来自加州大学的两位华人研究人员发布了一个用于评估生成代码可靠性和鲁棒性的新数据集RobustAPI，包括从StackOverflow中收集得到的1208个编码问题，涉及24个主流JAVA API的评估。
论文链接：https://arxiv.org/pdf/2308.10335.pdf
研究人员总结了这些API的常见误用模式，并在当下常用的LLM上对其进行评估，结果表明，即使是GPT-4，也有高达62%的生成代码包含API误用问题，如果代码被实际部署，可能会导致意想不到的后果。
论文相关的数据和评估器不久后将开源。
方法
数据收集
为了利用软件工程领域现有的研究成果，RobustAPI没有从零构建，而是基于在线问答论坛中频繁出现的Java API误用数据集ExampleCheck

文章插图
研究人员从数据集中选择了23个流行的Java APIs，涵盖了字符串处理、数据结构、移动开发、加密和数据库操作等。
然后再从Stack Overflow中爬取与上述API相关的问题，只选择问题中包含在线答案的，可以保证RobustAPI是可回答的（answerable），能够更有效地评估LLM在「人类容易犯错问题」上的代码能力。
收集数据后将问题转换为JSON格式，包含四个字段：
1. id，为样本分配的唯一标识符
2. api，用来提示大型语言模型问题相关API
3. question，包括问题的标题和描述
4. origin，样本的原始URL
提示生成（prompt generation）
研究人员设计了一个提示模板，并用数据集中的样本进行填充，再从LLMs收集回复内容，并实现一个API使用检查器来评估代码的可靠性。

文章插图
在少样本演示下进行实验时，每个示例都提供回复的格式，然后在最后放入数据集中的问题及相应API提示，模拟新手用户询问时提出的问题。
LLM在对话时可以识别特殊标签的结构，所以研究人员将问题和答案封装起来指示LLM生成问题的答案。
演示样本（Demonstration Samples）
为了深入分析LLMs的代码生成能力，研究人员设计了两个少样本实验：
1. one-shot-irrelevant，使用不相关的API（如Arrays.stream）作为语言模型的提示样例。

文章插图
研究人员假定该示例可以消除生成代码中的语法错误。
2. one-shot-relevant，使用相同的API作为示例，包括一组问题和答案。
JAVA API误用
研究人员在使用API时，需要充分理解API的使用规则，以便实现理想的API效果。
一个典型的例子是文件操作，通过RandomaccessFile打开和写入文件时，需要注意两条使用规则：
1. 读取文件可能会引发异常。
如果在读取预期字节之前达到缓冲区限制，API将抛出IndexOutOfBoundsException异常；当该文件同时被其他进程关闭时，API将抛出ClosedChannelException 。
为了处理这些异常，正确的实现应该将API包含在try-catch块中。
2. 使用后应应该关闭文件通道，否则的话，如果此代码片段位于在多个实例中并发运行的长期程序中，文件资源可能会耗尽，代码需要在所有文件操作后调用close API