1.概述
软件开发在不断发展，人们对采用最先进的技术提高开发人员的工作效率越来越感兴趣。其中，在集成开发环境（IDE）中使用大规模语言模型备受关注，OpenAI 的 GPT-3.5 和 GPT-4 以及开源的 Code Llama 都具有作为高性能编程助手的潜力。本文对在集成开发环境中利用大规模语言模型作为编程助手的实用性进行了评估，并考察了它们在各种编程场景和语言中的适应性。
该验证评估了五个主要开发场景：文档生成（doc）、错误修复（fix）、自然语言代码生成（generate）、代码测试用例生成（test）以及工作区理解和查询解析（workspace）。评估线束指标的设计考虑到了实际情况，以评估其交互性、准确性和效率。其目的是充分评估模型在实际代码中生成功能的复杂性。
它还提出了新的评估标准，将输出的随机性和大规模语言模型本身造成的逻辑差距考虑在内。这样就能自动了解提示和参数变化对实际代码的影响，从而进行更准确的性能评估。
最后，本文提出的评估框架使用了多种 LLM 模型，包括 GPT-3.5、GPT-4 和 Code Llama，以评估它们在 Visual Studio Code 等集成开发环境中的有效性。它从一个全面的角度阐述了使用大型语言模型编程的能力和局限性，以满足广大开发人员的需求和偏好。
论文地址：https://arxiv.org/pdf/2402.14261.pdf
2.利用大规模语言模型评估软件编程
为了确定现代大规模语言模型在软件工程领域的实用程度，需要使用各种指标来衡量其性能。除了传统的 HumanEval 之外，BLEU 和 Code-BLEU 等基于匹配的指标也被广泛使用。这些指标可作为评估代码生成和代码翻译等任务中大规模语言模型输出质量的标准。此外，还使用大规模语言模型本身对输出进行评估，并提出了侧重于功能正确性的新评估标准。
文档生成：本节将探讨大规模语言模型在自动生成文档方面的有效性。例如，在 VS Code IDE 中，开发人员会要求大规模语言模型为斐波那契函数生成文档。评估的重点是生成文档的位置、格式和覆盖范围的正确性。此外，还要考虑是否在不破坏代码语法的情况下正确插入了文档，以及是否正确描述了函数。
错误修复：使用大型语言模型修复静态分析工具发现的错误也是经过验证的任务。目标是修正后的代码总体上比原始代码的错误更少。在此过程中会使用各种语言的静态分析器，修复成功与否的评估标准是修改后的代码在语法上是否正确，静态分析警告和错误是否得到解决，例如在 VS Code IDE 中修复 "yield "的拼写错误。VS Code IDE。
通过这些任务，我们研究了大规模语言模型对软件开发过程的潜在价值和局限性。特别是，在对静态分析工具发现的错误提出修复建议时，既要有效地解决原有问题，又要避免引入新的错误，这一点非常重要。
从自然语言生成代码（生成）：从自然语言指令生成准确代码片段的能力是一项重要任务，代表了大规模语言建模的创新进步。 VS Code IDE 中生成斐波那契数列的函数示例直观地展示了这一技术的实际工作原理。在 VS Code IDE 中生成斐波那契数列的函数示例直观地展示了这一技术的实际应用。开发人员向大规模语言模型描述任务，生成的代码将以差异视图的形式显示在编辑器中。
要使生成的代码被认为是成功的，必须满足两个主要标准：第一，语法必须正确；第二，必须通过所有相关的测试用例。语法正确性通过特定语言的解析器来验证，而测试通过率则通过运行项目的测试套件来验证。这可以评估大规模语言模型生成的代码的实用性和可靠性。评估程序从一组包含测试用例的资源库开始，选择符合特定标准的方法。对于选中的方法，大规模语言模型会被要求生成其主体，并在主体上注明 “Your Code Here”（您的代码在这里）。生成的方法主体将返回其原始位置，修改后的代码将在测试套件中进行评估。
通过这一过程，我们可以深入了解大规模语言模型如何高效、准确地根据自然语言指令生成代码。
代码测试用例生成（测试）：大规模语言模型的进步使自动生成代码测试用例成为可能。它简化了开发人员创建单元测试的过程，并为质量保证实践提供了新的动力：一位开发人员在 VS Code IDE 中申请斐波那契函数测试用例的例子，就说明了这项技术是如何应用于实际开发环境中的。
生成的测试用例成功与否有两个标准：一个是语法正确，另一个是运行时通过。这一评估基于被测代码是正确的这一假设。生成测试用例的语法正确性和通过率是通过特定语言的解析器来检查的。
评估程序从一组方法开始，让大规模语言模型为每个方法生成测试。具体做法是向大规模语言模型提供方法签名、dockstrings 和主体，由大规模语言模型使用占位符 “Your Code Here”（您的代码在这里）替换原始方法主体。
生成测试后，它们会被添加到方法所在的资源库中，并尝试运行测试；对于 JavaScript 和 TypeScript，测试是使用 Jest 和 Mocha 库生成的，与资源库中现有的测试套件无关。在评估生成的测试时，测试会暂时添加到方法的文件中，并完整地执行，以避免导入错误。如果执行一个明显的测试用例（例如，一个应始终为真的测试）返回假或错误，则认为生成的测试结果不可靠。
通过这一过程，我们正在研究大规模语言模型生成的测试用例如何提高软件开发测试阶段的效率和准确性。
工作区理解和查询解析（工作区）：识别相关代码片段以回答用户问题的能力是测试大规模语言模型理解能力的一项重要任务。这一过程测试了大规模语言模型对用户自然语言查询和大量代码的理解程度。具体来说，我们将以 VS Code IDE 中的斐波那契函数测试需求为例，证明该技术的实用性。
大规模语言模型检索的片段质量通过两种方式进行评估：平均反向排名（MRR）和端到端关键词检测。平均反向排名是根据正确片段在模型提供的片段列表中的位置计算的，代表了模型在每个测试案例中的平均得分。端到端关键词检测则通过检查模型的回复是否包含与查询的正确答案相关的关键词来评估检索片段的相关性。
评估工作从向模型提供用户查询和相关代码库的完整上下文开始，然后让模型检索相关代码片段列表。利用均值反向排序，直接评估模型检索到的代码片段的质量，以衡量模型找到相关代码片段的能力。通过将查询和检索到的代码片段作为上下文提供给模型，并要求其对原始用户查询做出回应，它可以进一步评估所有检索到的代码片段的质量。根据模型的最终回复，可以确定是否找到了完全回答问题所需的信息。
通过这种方法，可以对模型的检索能力进行端到端评估，了解它能在多大程度上有效地找到真正有助于回答当前问题的代码片段。
3.为评估线束收集数据
本文开发了一个副驾驶评估工具包，以便在编程领域提供更好的评估指标。该工具包旨在帮助开发人员从不同角度评估他们创建的代码，并提高代码质量。本节将介绍构建该评估系统的一个重要步骤：数据收集。
数据收集过程包括从数百个公共 GitHub 代码库中收集信息，这些代码库涵盖六种主要编程语言–JavaScript、Typescript、Python、Java、C/C++ 和 C#。我们从这些资源库中提取符合特定标准的代码方法，并以此为基础进行评估。为此，我们开发了一个特殊的构建代理，可以尝试各种构建和测试策略。该代理还允许使用静态分析工具进行评估。
GitHub 资源库的选择标准非常严格，尤其是每种语言都有不同的要求。例如，如果 JavaScript 和 Typescript 资源库的根目录中存在 "package.json "文件并使用 npm 进行管理，就会被选中；对于 Java，使用 Maven 并可使用 JDK 1.8 构建的项目会被选中。对于 Python，只选择可在虚拟环境中成功安装所有依赖项的资源库；对于 C/C++，则从可在 Docker 映像中构建和测试的一组手动选择的资源库中选择。
在选择资源库时，我们排除了那些大小小于 1 MB 或大于 100 MB、构建或运行测试耗时超过 10 分钟以及不包含方法的资源库。这样，我们就能建立高质量的数据集。
通过这一数据收集过程，目的是为各种编程语言和项目建立一个评估工具。这样做的目的是为提高软件开发质量做出贡献，并帮助开发人员更高效、更有效地编写代码。
4. 为评估线束收集测试用例
本文开发了一种方法，用于为每种编程语言精心选择合适的资源库，并从这些资源库中生成有效的测试用例。这一过程是衡量和提高代码质量的重要步骤。本文介绍了所采用的主要方法。
自动生成文档：为具有三行或三行以上方法且未进行缩减或混淆处理的资源库创建测试用例。接受评估的编码助手的任务是为这些方法生成适当的文档字符串。如果生成的文档位置正确、格式正确、内容充实，则视为成功。
错误修复：根据静态分析工具指出的警告和错误生成测试用例，但不包括与导入和配置相关的警告。如果生成的修正语法正确，并减少了静态分析中的警告数量，则评定为成功。不过，重要的是在修复原始问题的过程中不会产生新的问题。
从自然语言生成代码：重点关注现有测试所涵盖的方法，并要求编码助手生成与指定方法签名相匹配的方法体。如果生成的代码语法正确，并通过了所有相关测试，则视为成功。
从代码生成测试：要求编码助手为资源库中确定的方法提供一个工作测试。如果所提供的测试调用了目标方法并正常执行，则评定为成功。
工作区理解和查询解决：收集开发人员提交的有关项目工作区的问题，并通过提供相关代码片段加以解决。所提供代码片段的质量使用平均反向排名 (MRR) 进行评估。
5. 试验
在文档生成和错误修复场景中，使用前面描述的 toevaluation harness 指标和测试用例，对 OpenAI 模型 GPT-3.5 和 GPT-4 以及 CodeLlama 的性能进行了评估。它使用拥有 70 多万活跃用户的 VSCode IDE 的 Large Language Models Powered Chat 扩展作为代码助手。
实验旨在回答以下三个问题
- 问题 1：模型比较：不同的大规模语言模型与编码助手集成后的效果如何？
- 问题 2：改进集成：评估工具可为工程师提供哪些启示，以改进编码助手中大型语言模型的集成？
- 问题 3：数据有效性：评估测试案例在多大程度上反映了用户通过集成开发环境与大规模语言模型交互的真实使用模式？
第一，"问题 1：模型比较：不同的大规模语言模型与编码助手集成后如何相互比较？这就是问题。这里比较了三种模型：GPT-3.5、GPT-4 和 Code Llama。
如下表所示，在文档生成方面，GPT-4 的表现优于其他两个模型。特别是在 Python 中，Code Llama 的成绩与 GPT-4 相当，而在 C/C++ 中，Code Llama 的成绩要差得多。这可能是由于 GPT-3.5 和 GPT-4 从互联网上广泛的开放源代码中学习，因此更容易识别各种代码模式。相比之下，较小的 Code Llama 由于对特定代码片段的经验有限，在某些情况下表现较差。
在错误修复测试中，GPT-4 略胜于 GPT-3.5，Code Llama 紧随其后。不过，在 C# 错误修复中，所有三种模型都表现不佳，GPT-3.5 略胜于其他两种模型；在一些情况下，GPT-4 提出的修复建议被用在了错误的地方，尽管有潜在的解决方案，但错误还是没有得到修复。
我们发现，GPT-3.5 通常会选择更基本、更无效的解决方案，而 GPT-4 则会尝试更高级、更复杂的修复方案。这些差异在解决与类型规范相关的错误时尤为明显，GPT-4 会尝试猜测一个更合适的类型，但这可能与代码的上下文不符。而 GPT-3.5 则通过采用更简单的方法来避免这一问题，但这并不总是最佳做法。
比较结果表明，虽然 GPT-4 的整体表现更好，但 Code Llama 和 GPT-3.5 可能会在某些情况下提供有效的解决方案。了解每种模式的优缺点有助于进一步优化编码助手的集成和使用。
接下来是 "问题 2：改进集成：Co-Pilot 评估工具包能为工程师提供哪些启示，以改进编码助手中大型语言模型的集成？是。同样，重点是文档生成和错误修复过程，并探讨了解决这些问题可以采取的改进措施。
文档生成中的挑战和解决方案：通过对文档生成的评估，确定了四种主要错误类型。它们是代码逻辑更改、语法更改、不完整的文档字符串和不相关的文档字符串。其中，GPT-4 遵循指令的能力较强，倾向于提出更简洁的代码修改建议，这可能导致文档生成任务失败。
为了解决这个问题，在编码助手提示中特别说明不要更改重点代码，从而显著改善了所有语言的评估结果。这一改变使 C++ 性能提高了 5%，Java 性能提高了 11%。还有一些例子显示了 GPT-4 对特定指令的敏感程度。
在评估错误修复时，要仔细分析静态分析器检测到的错误类型。这两种模型都能找到对象命名空间并修复类型问题，但还不能正确解决 "具有’任意’类型 "的错误。
为了解决这个问题，大语言模型 Powered Chat 扩展应该为模型提供额外的上下文，如目标变量类型和命名空间。这样，模型就能正确纠正问题，避免使用不正确的类型或产生新类型的错觉。
通过实验，该项目发现了将大规模语言模型集成到集成开发环境中的挑战，并提出了应对这些挑战的具体改进措施。这些发现和改进可以通过使用一个强大的综合评估系统来实现，该系统预计将有助于提高开发过程的质量。
最后一个问题是 "问题 3：数据有效性：评估测试用例在多大程度上反映了用户通过大型集成开发环境与大规模语言模型交互的真实使用模式？是这样的。
本文利用从真实 git 仓库收集的数据集，研究了用户通过集成开发环境与大语言模型的交互在多大程度上反映了真实世界的使用模式。我们特别关注 VS Code 中大语言模型聊天扩展的文档生成和错误修复功能的使用情况，并通过收集数百名微软开发人员的使用数据，将其与本文提出的测试用例进行比较，从而验证数据集的有效性。通过将数据集与本文提出的测试用例进行比较，对数据集进行验证。
在文档生成方面，使用 OpenAI 的 ada 嵌入模型嵌入了文档代码片段，并将其与微软开发人员的使用数据进行了比较。比较结果表明，就文档生成功能而言，本文提出的数据集与真实开发人员的使用模式相似。
对于错误修复，我们嵌入了包含错误的代码片段，并使用 PCA 降维方法在两个维度上绘制了图表。这一分析证实，本文提出的错误修复功能测试用例与实际使用的测试用例存在相似的空间。
本文的目的不是让测试用例与真实世界的用例完全一致，而是验证测试用例是否在实际用例的范围之内。分析结果表明，无论是文档生成还是错误修复，本文提出的数据集都与实际使用情况相符。希望这将为基于大规模语言模型的开发支持工具的实用性提供重要启示，并为提高开发过程的质量做出贡献。
6.总结
随着开发人员越来越频繁地使用大规模语言模型来完成复杂的工程任务，对大规模语言模型生成的代码进行稳健评估的需求也与日俱增。由于许多公司和产品都希望将大规模语言模型集成到工作流程中，因此仅靠现有的评估指标无法充分保证自动生成代码的质量和准确性。为解决这一问题，本文提出了 Copilot 评估工具包，并介绍了五个关键评估指标：方法生成、测试生成、对接字符串生成、错误修复和工作区理解。它详细介绍了如何收集基于这些指标的测试用例和评估结果，并分享了跨多种编程语言的初步结果。
开发评估工具包的目的是验证大规模语言模型生成的代码质量。虽然用于代码生成的机器学习技术已经取得了长足的进步，但要确保大规模语言模型可靠、有效地集成到代码工作流程中，还需要仔细的监督和工程努力。我们的目标是提供一个全面的评估套件，帮助开发人员将大规模语言模型正确集成到自己的编码流程中。Co-Pilot 评估工具包将使程序员能够更系统地评估各种参数的影响，例如提示的表示方法、提供信息的顺序以及提供给模型的上下文的变化。
此外，协同驾驶评估系统还有助于优化成本。例如，它可以显示有预算意识的大规模语言模型在文档等任务中提供令人满意的性能的潜力。有了这样的洞察力，开发人员就可以明智地分配资源，适当地使用成本效益高的大规模语言模型，同时在更复杂的任务中使用高性能的大规模语言模型，以达到最佳效果。