大型语言模型(LLM)正在日益塑造软件开发的未来，为代码生成、调试和解决错误提供了新的可能性。这些人工智能驱动工具的最新进展促使人们更仔细地研究它们的实际应用和对开发人员工作流程的潜在影响。

本文探讨了LLM在软件开发中的有效性，特别关注解决错误。根据软件开发人员在Raygun公司的人工智能解决错误工作中获得的行业观察和见解，将分析LLM当前的能力及其对未来开发实践的影响，并讨论将权衡这些技术融入人们的日常工作所带来的具有前景的进步和挑战。

一、用于软件开发的OpenAI模型

OpenAI公司已经成功发布了更新、更快、更智能的模型。虽然基准测试网站证实了这些结果，但越来越多的非官方证据表明，人们感觉这些模型更加笨拙。大多数现有的基准测试完全侧重于关注这些模型的逻辑推理方面，例如完成SAT问题，而不是关注定性响应，特别是在软件工程领域。而这里的目标是使用错误解析作为基准，定量和定性地评估这些模型，因为解决错误在开发人员的工作流程中很常见。

这个综合评估将涵盖几种模型，其中包括GPT-3.5 Turbo、GPT-4、GPT-4 Turbo、GPT- 40和GPT-40 mini。本文将使用现实生活中的堆栈跟踪和发送的相关信息来评估这些模型如何解决错误，还将彻底检查响应速度、答案质量和开发人员偏好等因素。这种分析将导致从这些模型中提取最佳响应的建议，例如提供更多场景(例如源图和源代码)对其有效性的影响。

二、实验方法

如上所述，将评估以下模型： GPT-3.5 Turbo、GPT-4、GPT-4 Turbo、GPT- 40和GPT-40 mini。使用的特定变体是截至2024年7月30日由OpenAI API提供的默认模型。

为了进行评估，从各种编程语言中选择了七个现实世界中的错误，包括Python、TypeScript和.NET，每种语言都结合了不同的框架。通过在账户和个人项目中抽样现有的错误来选择这些具有代表性的样本。没有选择瞬态或未指向直接原因的错误。

然后使用来自Raygun公司的AI Error Resolution的模板系统提示，其中包含了发送崩溃报告中的信息。通过OpenAI的API直接在所有模型上进行了测试。这个过程产生了35个LLM错误响应对。然后这些配对被随机分配给工程师，他们根据准确性、清晰度和实用性对它们进行1到5的评分。此次评估的工程师有11人，其中包括软件工程师和数据工程师，他们的经验水平各不相同，既有只有几年经验的工程师，也有多达几十年经验的工程师。

除了偏好评级，还将对模型的性能进行解析分析。这项分析将集中在两个关键方面，即响应时间和响应长度，然后将使用这两个方面来推导这些模型有效性的多种衡量标准。

三、开发者偏好：定性结果

总体看法

根据工程师的评分制作了下面的图表。由此，有一些明显的结果既支持也反驳了非官方证据。虽然这项分析侧重于解决错误，但将这些发现与引言中讨论的其他动机因素进行比较是必要的。例如，模型在解决错误方面的有效性可能与它们在代码生成或调试等任务中的性能不同，这可能会影响总体看法。这个更广阔的视角帮助人们理解大型语言模型对开发人员工作流程的不同方面的不同影响。

意外发现

人们认为GPT-4是最好的LLM模型，但Raygun公司的软件工程师认为它是最差的。可以使用来自软件工程师的反馈和一些分析数据为这个结果提供可能的理由，将在下一节中展示这些数据。这些假设来自于关注这项研究的工程师进行的讨论。GPT-4 Turbo及以后的模型在建议更改时包括代码片段，工程师们表示，这使他们更好地理解解决方案。GPT-4没有生成片段，并且其解决方案比GPT-3.5 Turbo更长，这表明工程师不喜欢不包含补充资源的更长响应。

错误模式

工程师们还观察到，JSON验证错误在所有模型变体中的排名一直很低，因为仅靠堆栈跟踪并不能很好地解决这个错误;这使工程师在向LLM寻求帮助时，能够及时了解提示工程以及哪些信息是有帮助的。

场景影响

(1).NET错误

.NET错误包括所有这些测试用例，除了除零错误和无效的停止ID，如上面的表中所述。结果是只有LLM和工程师知道的场景是堆栈跟踪、标签、面包屑和自定义数据。Raygun公司的工程师看到这些错误的报告评分更高，可能是因为他们主要使用.NET。然而，在测试不同语言的情况下，仍然观察到良好的结果。

(2)其他语言

根据工程师的评论，这样做的原因是在采用Python和TypeScript的情况下，堆栈跟踪与周围的代码场景一起出现。在Python中，周围的代码场景是作为堆栈跟踪的一部分提供的，在TypeScript错误中，它来自包含源代码的源映射。有了这些额外的信息，LLM可以生成直接解决错误的代码片段，这也有助于对GPT-4变体的后续系列进行评级。

性能洞察

(1)GPT-4 Turbo的后续版本性能下降

从GPT-4 Turbo及后续版本的评分来看，看到评分有所下降，尤其是评估到GPT-4o时，尽管这些结果仍然优于GPT-4，而且大多数都优于GPT-3.5 Turbo。如果将JSON序列化错误作为异常值删除，可以观察到GPT-4 Turbo之后版本的性能有所下降。这一结果清楚地表明，GPT-4系列的性能在GPT-4 Turbo达到峰值后有所下降。

(2)场景对非描述性堆栈跟踪的重要性

JSON序列化错误导致的性能不佳可能是由于需要有关潜在问题的支持信息。仅仅查看堆栈跟踪就很难确定错误，因为存在多个故障点。同样，这也涉及到包含更多场景(例如源代码和变量值)的主题，以提示问题可能在哪里。这里的增强可能是源代码上的RAG查找实现，因此可以将堆栈跟踪与相应的代码相关联。

(3)响应长度对性能的影响

在后续的模型中，造成性能恶化的一个原因是响应长度的增加。这些模型可能在较重的基于逻辑的问题中表现得更好，但这些较长的回答在日常对话中是不可取的。工程师在询问有关Python库的问题时遇到过这种情况，希望得到直接的答案。它每次都会重复一整个关于建立库的介绍部分和有关问题的无用信息。

如果是这样的话，希望在GPT-5和其他竞争对手等新模型问世时看到对这一问题的一些修正，但就目前而言，这些模型的冗长现象将继续存在。

四、解析分析：定量结果

响应时间和内容生成

虽然对LLM响应的定性评估至关重要，但响应时间/生成速度和生成的内容量也会显著影响这些工具的有用性。下图显示了为错误响应对创建聊天完成的平均响应时间。

有趣的是，就生成聊天完成的平均响应时间而言，GPT-4 Turbo是响应最慢的模型。这是一个令人惊讶的结果，因为一般的理解表明，GPT-4 Turbo应该比GPT-4更快。

令牌生成和模型性能

下图通过测量每个模型生成的令牌的平均数量来解释这个令人惊讶的结果。这表明GPT-4 Turbo平均生成的令牌比GPT-4多得多。有趣的是，之前的图表显示GPT-4o生成的令牌最多，但仍然比GPT-4 Turbo快得多。

工程师们还看到，在OpenAI的最新模型GPT-4o mini中，这种更多令牌的趋势不会持续下去。与GPT-4 Turbo相比，令牌的平均数量有所减少，但仍远高于GPT-4。生成最少令牌数量的模型是GPT-3.5 Turbo，它与定性分析结果一致，工程师更喜欢较短的响应，而不是没有补充解释的较长响应。

每个令牌响应时间

在按模型检查响应时间和平均令牌计数之后，可以确定每个模型在响应时间和令牌生成方面的速度。

下图显示了按模型划分的每个令牌响应时间。在这里看到GPT-4比GPT-4 Turbo更快，但这是由于数据中的异常值。考虑到它倾向于产生更长的输出，其总体响应时间仍然比GPT-4长。这可能意味着GPT-4 Turbo在生成太多内容时是一个不太理想的模型。

注意：GPT-3.5、GPT 4和GPT-4o模型使用不同的令牌。

GPT-4o与GPT-4o-Mini的比较

有趣的是，与其他来源的研究结果相比，数据显示GPT-4o和GPT-4o-mini具有相似的反应速度。这种差异表明，可能需要更大的样本量来揭示他们表现中更明显的差异。另一种解释是，考虑到是通过总响应时间来测量每秒的令牌数，由于首次令牌响应时间(TTFT)和其他网络的相关瓶颈，其数值稍微偏低。

扩展模式

绘制响应时间与令牌计数的关系，并按模型分组，揭示了这些模型扩展中的不同模式。对于GPT-3.5、GPT-4o和GPT-4o-Mini扩展主要是线性的，令牌数量的增加会导致响应时间的相应增加。

然而，这种模式并不适用于较大和较旧的GPT-4系列模型，其中这两个变量没有一致的关系。这种不一致可能是由于样本量较小或专用于这些请求的资源较少，从而导致响应时间不同。鉴于在其他模型中观察到的线性关系，后一种解释更有可能。

GPT-4场景限制

最后一项分析来自生成这些错误-响应对。虽然GPT-4模型是胜任的，但对于需要长输入的任务(例如堆栈跟踪)，其场景长度明显受到限制。由于这个原因，不能生成一个错误响应对，因为组合的输入和输出将超过模型的8192个令牌场景窗口。

联合分析

在评估了定性数据后，很明显GPT-4 Turbo是完成这项任务的最佳模型。然而，将其与定量数据进行比较会引入响应时间和成本考虑。新的GPT-4o模型比所有其他模型快得多，也便宜得多，这是一种权衡。如果需要更好的性能，GPT-4 Turbo是首选。然而，如果成本和速度是优先事项，GPT-4o和GPT-4o-mini是更好的选择。

结论

这项研究提供了关于后期模型性能的混合证据。虽然一些较新的模型，例如GPT-4 Turbo和GPT-4o，由于能够包含简洁的代码片段而有所改进，但其他模型(例如GPT-4)由于冗长和不太实用的响应而表现不佳。

关键要点

• 代码片段很重要：提供代码片段和解释的模型更有效，更受开发人员的青睐。
• 场景至关重要：添加周围代码或源代码映射可以显著提高响应的质量。
• 平衡回复长度：简短的回复通常比冗长的回复更有帮助。
• 定期评估：持续评估模型性能，以确保使用最有效的工具来满足需求。
• 注意场景限制：注意场景长度的限制，并相应地制定计划。

通过关注这些因素，开发人员可以更好地利用LLM来解决错误，最终提高他们的生产力和解决方案的准确性。

正如引言中提到的，未来补充这项研究的实验可能包括对代码生成的更深入分析。一个可能的实验可能涉及从解决错误中获取建议，并为LLM提供额外的场景。在理想情况下，如果这项研究要重新进行，那么需要纳入更广泛的错误，包括更具挑战性的错误，并从更多样化的工程师那里获得评分。