對 OpenAI 模型進行基準測試以實現自動錯誤解決 原創
作者 | Reilly
整理 | 星璇
本文對軟件開發領域的法學碩士學位進行了評估，重點關注其解決錯誤的有效性，這是軟件開發人員工作流程中的一項關鍵任務。
大型語言模型 (LLM) 正在日益塑造軟件開發的未來，為代碼生成、調試和錯誤解決提供了新的可能性。這些人工智能驅動工具的最新進展促使人們更深入地研究它們的實際應用及其對開發人員工作流程的潛在影響。
本文探討了 LLM 在軟件開發中的有效性，特別關注錯誤解決。根據我在 Raygun 從事 AI 錯誤解決工作期間對整個行業的觀察和見解，我將分析 LLM 的當前功能及其對未來開發實踐的影響。討論將權衡這些技術融入我們日常工作時出現的有希望的進步和挑戰。
一、用于軟件開發的 OpenAI 模型
OpenAI 已成功發布了更新、更快、據稱更智能的模型。雖然基準測試網站證實了這些結果，但我們看到越來越多的軼事數據聲稱這些模型感覺更笨。
大多數現有基準測試僅關注這些模型的邏輯推理方面，例如完成 SAT 問題，而不是關注定性響應，尤其是在軟件工程領域。我的目標是使用錯誤解決作為基準對這些模型進行定量和定性評估，因為它在開發人員的工作流程中很常見。
我們的全面評估將涵蓋多個模型，包括 GPT-3.5 Turbo、GPT-4、GPT-4 Turbo、GPT-4o 和 GPT-4o mini。我們將使用真實的堆棧跟蹤和發送給我們的相關信息來評估這些模型如何處理錯誤解決。我們將徹底檢查響應速度、答案質量和開發人員偏好等因素。此分析將提供從這些模型中提取最佳響應的建議，例如提供更多上下文（如源映射和源代碼）對其有效性的影響。
二、實驗方法
如上所述，我們將評估以下模型：GPT-3.5 Turbo、GPT-4、GPT-4 Turbo、GPT-4o 和 GPT-4o Mini。使用的具體變體是截至 2024 年 7 月 30 日 OpenAI API 提供的默認模型。
為了進行評估，我們從各種編程語言（包括 Python、TypeScript 和 .NET）中選擇了 7 個實際錯誤，每種語言都與不同的框架結合使用。我們通過從我們的帳戶和個人項目中抽取現有錯誤作為代表性樣本來選擇這些錯誤。暫時性錯誤或未指向直接原因的錯誤未被選中。
姓名 | 語言 | 解決方案 | 困難 |
Android 缺少文件 | .NET 核心 | 嘗試讀取的 .dll 文件不存在 | 簡單的 |
除以零 | Python | 空數組導致除以零的錯誤 - 沒有錯誤檢查 | 簡單的 |
站點 ID 無效 | TypeScript | 從 Alexa 請求信封中提取的停止 ID 無效 - Alexa 模糊測試發送了無效的 xyzxyz 值 | 難的 |
IRaygunUserProvider 未注冊 | .NET 核心 | IRaygunUserProvider 未在 DI 容器中注冊，導致無法在 MAUI 中創建 MainPage | 中等的 |
JSON 序列化錯誤 | .NET 核心 | 強類型對象映射與提供的 JSON 對象不匹配，這是由于 Raygun 客戶端發送了不合規的錯誤負載造成的 | 難的 |
主頁未注冊 ILogger | .NET 核心 | 添加了 ILogger，但是沒有將 MainPage 作為單例添加到 DI 容器中，導致 ILogger<MainPage> 在創建 MainPage 時出錯 | 中等的 |
Postgres 缺少表 | .NET 核心/Postgres | Postgres 在被 C# 程序調用時缺少表，導致堆棧跟蹤混亂 | 簡單 - 中等 |
然后，我們使用了 Raygun 的 AI Error Resolution 中的模板系統提示，該提示整合了發送給我們的崩潰報告中的信息。我們通過 OpenAI 的 API 在所有模型上直接測試了這一點。此過程生成了 35 個 LLM 錯誤響應對。然后，這些對被隨機分配給我們的工程師，他們根據準確性、清晰度和實用性按 1 到 5 的等級對它們進行評分。我們抽樣了 11 名工程師，包括軟件工程師和數據工程師，他們的經驗水平各不相同，從擁有幾年經驗的工程師到擁有幾十年經驗的工程師都有。
除了偏好評分之外，我們還將對模型的性能進行分析。該分析將重點關注兩個關鍵方面：響應時間和響應長度，然后我們將利用這兩個方面得出這些模型有效性的多項指標。
三、開發人員偏好：定性結果
1.一般觀察
我們根據工程師的評分繪制了圖表。雖然該分析側重于錯誤解決上，但將這些發現與此前討論的其他動機因素進行比較是必不可少的。例如，模型在錯誤解決方面的有效性可能與它們在代碼生成或調試等任務中的表現不同，這可能會影響整體的結論。這種更廣泛的視角有助于我們了解大型語言模型對開發人員工作流程不同方面的不同影響。
2.意外的發現
我們假設 GPT-4 是最好的模型，但我們的軟件工程師給它的評分最差。我們可以使用軟件工程師的反饋和一些分析數據來為這個結果提供可能的解釋，我們將在下一節中展示這些數據。這些假設來自我與另一位密切關注這項研究的工程師的討論。
GPT-4 Turbo 及以后的模型在建議更改時會包含代碼片段，工程師們報告說這讓他們更好地理解了解決方案。GPT-4 沒有生成代碼片段，并且解決方案比 GPT-3.5 Turbo 更長，這表明工程師不喜歡不包含補充資源的較長響應。
3.錯誤模式
我們還觀察到，JSON 驗證錯誤在所有模型變體中的排名始終很低，因為單獨的堆棧跟蹤無法為該錯誤提供良好的解決方案；這促使我們及時進行工程設計，并了解在向 LLM 尋求幫助時哪些信息是有幫助的。
4.上下文影響
（1）對于 .NET 錯誤
.NET 錯誤包括所有這些測試用例，除了除以zero error和invalid stop ID，如上表所述。結果是，LLM 和工程師唯一知道的上下文是堆棧跟蹤、標簽、breadcrumbs和自定義數據。我們看到這些錯誤的報告分數較高，可能是因為 Raygun 的工程師主要使用 .NET。然而，在我們測試不同語言的情況下，我們仍然觀察到了良好的結果。
（2）其他語言
根據工程師的評論，原因在于，在 Python 和 TypeScript 兩種情況下，堆棧跟蹤都帶有周圍的代碼上下文。在 Python 中，周圍的代碼上下文是堆棧跟蹤的一部分，而在 TypeScript 錯誤中，它來自包含源代碼的源映射。有了這些附加信息，LLM 可以生成直接解決錯誤的代碼片段，這也有助于對后續一系列 GPT-4 變體進行評級。
5.性能評定
（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 和其他競爭對手等新模型問世時看到對此進行一些修正，但就目前而言，這些模型的冗長之處仍將存在。
四、分析：定量結果
1.響應時間和內容生成
雖然對 LLM 響應進行定性評估至關重要，但響應時間/生成速度和生成的內容量也會顯著影響這些工具的實用性。下圖顯示了創建錯誤響應對的聊天完成的平均響應時間。
有趣的是，GPT-4 Turbo 是生成聊天完成的平均響應時間最慢的模型。這是一個令人驚訝的結果，因為一般理解認為 GPT-4 Turbo 應該比 GPT-4 更快。
圖片
2.Token生成和模型性能
下圖通過測量每個模型生成的平均 token 數量解釋了這一令人驚訝的結果。這表明 GPT-4 Turbo 平均生成的 token 數量明顯多于 GPT-4。有趣的是，上圖顯示 GPT-4o 生成的 token 數量最多，但速度仍然比 GPT-4 Turbo 快得多。
圖片
我們還發現，這種代幣數量增加的趨勢并沒有在 OpenAI 的最新模型 GPT-4o mini 中延續。與 GPT-4 Turbo 相比，平均代幣數量有所減少，但仍遠高于 GPT-4。生成代幣數量最少的模型是 GPT-3.5 Turbo，這與定性分析結果一致，工程師更喜歡較短的響應，而不是較長的響應且沒有補充解釋。
3.每個Token的響應時間
檢查完模型的響應時間和平均令牌數后，我們可以確定每個模型在響應時間和令牌生成方面的速度。
下面是按模型顯示每個 token 響應時間的圖表。在這里，我們看到 GPT-4 比 GPT-4 Turbo 更快，但這是由于數據中的異常值。鑒于它傾向于生成更長的輸出，其整體響應時間仍然比 GPT-4 更長。這可能意味著當 GPT-4 Turbo 生成的內容過多時，它就不是一個理想的模型。
圖片
注意：GPT-3.5、GPT 4 和 GPT-4o 模型使用不同的標記器。
4.GPT-4o 與 GPT-4o Mini 的比較
有趣的是，數據顯示 GPT-4o 和 GPT-4o mini 的響應速度相似，這與其他來源的發現形成鮮明對比。這種差異表明，可能需要更大的樣本量才能揭示它們性能上更明顯的差異。另一種解釋是，鑒于我們是通過總響應時間來衡量每秒的令牌數，由于第一個令牌時間 (TTFT) 和其他與網絡相關的瓶頸，我們稍微將值偏低。
5.擴展模式
按模型分組繪制響應時間與令牌數的關系圖，可以揭示這些模型擴展的不同模式。對于 GPT-3.5、GPT-4o 和 GPT-4o Mini，擴展大多是線性的，令牌數的增加會導致響應時間相應增加。
然而，這種模式并不適用于 GPT-4 系列中較大和較舊的模型，因為這兩個變量沒有一致的關系。這種不一致可能是由于樣本量較小或專用于這些請求的資源較少，導致響應時間不同?？紤]到在其他模型中觀察到的線性關系，后一種解釋更有可能。
圖片
6.GPT-4 上下文限制
生成這些錯誤-響應對后，我們得出了最后一個分析結論。雖然 GPT-4 模型很有能力，但其上下文長度對于需要長輸入的任務（例如堆棧跟蹤）而言受到很大限制。因此，無法生成一個錯誤-響應對，因為組合的輸入和輸出將超出模型的 8192 個 token 上下文窗口。
7.綜合來看
在評估定性數據后，很明顯 GPT-4 Turbo 是這項任務的最佳模型。但是，將其與定量數據進行比較會引入響應時間和成本考慮因素。新的 GPT-4o 模型比所有其他模型都快得多，而且便宜得多，這是一個權衡。如果需要稍微好一點的性能，GPT-4 Turbo 是首選。但是，如果成本和速度是優先考慮因素，GPT-4o 和 GPT-4o mini 是更好的選擇。
五、結論
總之，我們的研究提供了有關后期模型性能的混合證據。雖然一些較新的模型（如 GPT-4 Turbo 和 GPT-4o）由于能夠包含簡潔的代碼片段而有所改進，但其他模型（如 GPT-4）由于響應冗長且不太實用而未能達到要求。
六、關鍵要點
- 代碼片段很重要：提供代碼片段和解釋的模型更有效，也更受開發人員的青睞。
- 上下文至關重要：添加周圍代碼或源映射可顯著提高響應的質量。
- 平衡回復長度：較短、簡潔的回復通常比較長、冗長的回復更有幫助。
- 定期評估：持續評估模型性能，以確保您使用最有效的工具來滿足您的需求。
- 注意上下文限制：了解上下文長度限制并據此制定計劃。
通過關注這些因素，開發人員可以更好地利用 LLM 來解決錯誤，最終提高他們的工作效率和解決方案的準確性。
未來可以補充這項研究的實驗可能包括對代碼生成的更深入的分析，如引言中所述。一個可能的實驗可能涉及從錯誤解決中獲取建議并為 LLM 提供額外的背景信息。理想情況下，如果要重做這項研究，最好包括更廣泛的錯誤類型，包括更具挑戰性的錯誤，并從更多樣化的工程師那里收集評級。
本文轉載自??51CTO技術棧??，作者：星璇
