本文評估了軟件開發中的LLM，重點關注它們在解決錯誤方面的有效性。這是軟件開發人員工作流程中的一個關鍵任務。

大型語言模型(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提供額外的場景。在理想情況下，如果這項研究要重新進行，那么需要納入更廣泛的錯誤，包括更具挑戰性的錯誤，并從更多樣化的工程師那里獲得評分。

原文標題：Benchmarking OpenAI Models for Automated Error Resolution，作者：Reilly Oldham