作者 | Reilly

整理 | 星璇

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

這一研究對(duì)軟件開發(fā)領(lǐng)域的法學(xué)碩士學(xué)位進(jìn)行了評(píng)估，重點(diǎn)關(guān)注其解決錯(cuò)誤的有效性，這是軟件開發(fā)人員工作流程中的一項(xiàng)關(guān)鍵任務(wù)。

大型語言模型 (LLM) 正在日益塑造軟件開發(fā)的未來，為代碼生成、調(diào)試和錯(cuò)誤解決提供了新的可能性。這些人工智能驅(qū)動(dòng)工具的最新進(jìn)展促使人們更深入地研究它們的實(shí)際應(yīng)用及其對(duì)開發(fā)人員工作流程的潛在影響。

本文探討了 LLM 在軟件開發(fā)中的有效性，特別關(guān)注錯(cuò)誤解決。根據(jù)我在 Raygun 從事 AI 錯(cuò)誤解決工作期間對(duì)整個(gè)行業(yè)的觀察和見解，我將分析 LLM 的當(dāng)前功能及其對(duì)未來開發(fā)實(shí)踐的影響。討論將權(quán)衡這些技術(shù)融入我們?nèi)粘９ぷ鲿r(shí)出現(xiàn)的有希望的進(jìn)步和挑戰(zhàn)。

一、用于軟件開發(fā)的 OpenAI 模型

OpenAI 已成功發(fā)布了更新、更快、據(jù)稱更智能的模型。雖然基準(zhǔn)測試網(wǎng)站證實(shí)了這些結(jié)果，但我們看到越來越多的軼事數(shù)據(jù)聲稱這些模型感覺更笨。

大多數(shù)現(xiàn)有基準(zhǔn)測試僅關(guān)注這些模型的邏輯推理方面，例如完成 SAT 問題，而不是關(guān)注定性響應(yīng)，尤其是在軟件工程領(lǐng)域。我的目標(biāo)是使用錯(cuò)誤解決作為基準(zhǔn)對(duì)這些模型進(jìn)行定量和定性評(píng)估，因?yàn)樗陂_發(fā)人員的工作流程中很常見。

我們的全面評(píng)估將涵蓋多個(gè)模型，包括 GPT-3.5 Turbo、GPT-4、GPT-4 Turbo、GPT-4o 和 GPT-4o mini。我們將使用真實(shí)的堆棧跟蹤和發(fā)送給我們的相關(guān)信息來評(píng)估這些模型如何處理錯(cuò)誤解決。我們將徹底檢查響應(yīng)速度、答案質(zhì)量和開發(fā)人員偏好等因素。此分析將提供從這些模型中提取最佳響應(yīng)的建議，例如提供更多上下文（如源映射和源代碼）對(duì)其有效性的影響。

二、實(shí)驗(yàn)方法

如上所述，我們將評(píng)估以下模型：GPT-3.5 Turbo、GPT-4、GPT-4 Turbo、GPT-4o 和 GPT-4o Mini。使用的具體變體是截至 2024 年 7 月 30 日 OpenAI API 提供的默認(rèn)模型。

為了進(jìn)行評(píng)估，我們從各種編程語言（包括 Python、TypeScript 和 .NET）中選擇了 7 個(gè)實(shí)際錯(cuò)誤，每種語言都與不同的框架結(jié)合使用。我們通過從我們的帳戶和個(gè)人項(xiàng)目中抽取現(xiàn)有錯(cuò)誤作為代表性樣本來選擇這些錯(cuò)誤。暫時(shí)性錯(cuò)誤或未指向直接原因的錯(cuò)誤未被選中。

然后，我們使用了 Raygun 的 AI Error Resolution 中的模板系統(tǒng)提示，該提示整合了發(fā)送給我們的崩潰報(bào)告中的信息。我們通過 OpenAI 的 API 在所有模型上直接測試了這一點(diǎn)。此過程生成了 35 個(gè) LLM 錯(cuò)誤響應(yīng)對(duì)。然后，這些對(duì)被隨機(jī)分配給我們的工程師，他們根據(jù)準(zhǔn)確性、清晰度和實(shí)用性按 1 到 5 的等級(jí)對(duì)它們進(jìn)行評(píng)分。我們抽樣了 11 名工程師，包括軟件工程師和數(shù)據(jù)工程師，他們的經(jīng)驗(yàn)水平各不相同，從擁有幾年經(jīng)驗(yàn)的工程師到擁有幾十年經(jīng)驗(yàn)的工程師都有。

除了偏好評(píng)分之外，我們還將對(duì)模型的性能進(jìn)行分析。該分析將重點(diǎn)關(guān)注兩個(gè)關(guān)鍵方面：響應(yīng)時(shí)間和響應(yīng)長度，然后我們將利用這兩個(gè)方面得出這些模型有效性的多項(xiàng)指標(biāo)。

三、開發(fā)人員偏好：定性結(jié)果

1.一般觀察

我們根據(jù)工程師的評(píng)分繪制了圖表。雖然該分析側(cè)重于錯(cuò)誤解決上，但將這些發(fā)現(xiàn)與此前討論的其他動(dòng)機(jī)因素進(jìn)行比較是必不可少的。例如，模型在錯(cuò)誤解決方面的有效性可能與它們在代碼生成或調(diào)試等任務(wù)中的表現(xiàn)不同，這可能會(huì)影響整體的結(jié)論。這種更廣泛的視角有助于我們了解大型語言模型對(duì)開發(fā)人員工作流程不同方面的不同影響。

2.意外的發(fā)現(xiàn)

我們假設(shè) GPT-4 是最好的模型，但我們的軟件工程師給它的評(píng)分最差。我們可以使用軟件工程師的反饋和一些分析數(shù)據(jù)來為這個(gè)結(jié)果提供可能的解釋，我們將在下一節(jié)中展示這些數(shù)據(jù)。這些假設(shè)來自我與另一位密切關(guān)注這項(xiàng)研究的工程師的討論。

GPT-4 Turbo 及以后的模型在建議更改時(shí)會(huì)包含代碼片段，工程師們報(bào)告說這讓他們更好地理解了解決方案。GPT-4 沒有生成代碼片段，并且解決方案比 GPT-3.5 Turbo 更長，這表明工程師不喜歡不包含補(bǔ)充資源的較長響應(yīng)。

3.錯(cuò)誤模式

我們還觀察到，JSON 驗(yàn)證錯(cuò)誤在所有模型變體中的排名始終很低，因?yàn)閱为?dú)的堆棧跟蹤無法為該錯(cuò)誤提供良好的解決方案；這促使我們及時(shí)進(jìn)行工程設(shè)計(jì)，并了解在向 LLM 尋求幫助時(shí)哪些信息是有幫助的。

4.上下文影響

（1）對(duì)于 .NET 錯(cuò)誤

.NET 錯(cuò)誤包括所有這些測試用例，除了除以zero error和invalid stop ID，如上表所述。結(jié)果是，LLM 和工程師唯一知道的上下文是堆棧跟蹤、標(biāo)簽、breadcrumbs和自定義數(shù)據(jù)。我們看到這些錯(cuò)誤的報(bào)告分?jǐn)?shù)較高，可能是因?yàn)?Raygun 的工程師主要使用 .NET。然而，在我們測試不同語言的情況下，我們?nèi)匀挥^察到了良好的結(jié)果。

（2）其他語言

根據(jù)工程師的評(píng)論，原因在于，在 Python 和 TypeScript 兩種情況下，堆棧跟蹤都帶有周圍的代碼上下文。在 Python 中，周圍的代碼上下文是堆棧跟蹤的一部分，而在 TypeScript 錯(cuò)誤中，它來自包含源代碼的源映射。有了這些附加信息，LLM 可以生成直接解決錯(cuò)誤的代碼片段，這也有助于對(duì)后續(xù)一系列 GPT-4 變體進(jìn)行評(píng)級(jí)。

5.性能評(píng)定

（1）GPT-4 Turbo 后性能下降

圖片

從 GPT-4 Turbo 及以后的評(píng)分來看，我們發(fā)現(xiàn)評(píng)分有所下降，尤其是在達(dá)到 GPT-4o 之后，盡管這些結(jié)果仍然比 GPT-4 更好，而且大多數(shù)都比 GPT-3.5 Turbo 更好。如果我們將 JSON 序列化錯(cuò)誤作為異常值刪除，我們?nèi)匀豢梢杂^察到 GPT-4 Turbo 之后性能的下降。這個(gè)結(jié)果清楚地表明，GPT-4 系列的性能在 GPT-4 Turbo 時(shí)達(dá)到頂峰，隨后下降。

（2）上下文對(duì)于非描述性堆棧跟蹤的重要性

JSON 序列化錯(cuò)誤導(dǎo)致的這種糟糕表現(xiàn)可能是由于需要有關(guān)底層問題的支持信息。僅查看堆棧跟蹤很難確定錯(cuò)誤，因?yàn)榇嬖诙鄠€(gè)故障點(diǎn)。同樣，這涉及到包含更多上下文（例如源代碼和變量值）的主題，以提示問題可能出在哪里。這里的增強(qiáng)功能可能是對(duì)源代碼進(jìn)行 RAG 查找實(shí)現(xiàn)，因此可以將堆棧跟蹤與相應(yīng)的代碼關(guān)聯(lián)起來。

（3）響應(yīng)長度對(duì)性能的影響

后期模型性能下降的一個(gè)原因是響應(yīng)長度增加。這些模型在處理邏輯性更強(qiáng)的問題時(shí)可能會(huì)表現(xiàn)更好，但這些較長的響應(yīng)在日常對(duì)話中并不受歡迎。我在詢問有關(guān) Python 庫的問題時(shí)遇到過這種情況，我希望得到直接的答案。每次，它都會(huì)重復(fù)一整段關(guān)于設(shè)置庫的介紹部分以及與我的問題有關(guān)的無用信息。

如果是這樣的話，我們希望在 GPT-5 和其他競爭對(duì)手等新模型問世時(shí)看到對(duì)此進(jìn)行一些修正，但就目前而言，這些模型的冗長之處仍將存在。

四、分析：定量結(jié)果

1.響應(yīng)時(shí)間和內(nèi)容生成

雖然對(duì) LLM 響應(yīng)進(jìn)行定性評(píng)估至關(guān)重要，但響應(yīng)時(shí)間/生成速度和生成的內(nèi)容量也會(huì)顯著影響這些工具的實(shí)用性。下圖顯示了創(chuàng)建錯(cuò)誤響應(yīng)對(duì)的聊天完成的平均響應(yīng)時(shí)間。

有趣的是，GPT-4 Turbo 是生成聊天完成的平均響應(yīng)時(shí)間最慢的模型。這是一個(gè)令人驚訝的結(jié)果，因?yàn)橐话憷斫庹J(rèn)為 GPT-4 Turbo 應(yīng)該比 GPT-4 更快。

圖片

2.Token生成和模型性能

下圖通過測量每個(gè)模型生成的平均 token 數(shù)量解釋了這一令人驚訝的結(jié)果。這表明 GPT-4 Turbo 平均生成的 token 數(shù)量明顯多于 GPT-4。有趣的是，上圖顯示 GPT-4o 生成的 token 數(shù)量最多，但速度仍然比 GPT-4 Turbo 快得多。

圖片

我們還發(fā)現(xiàn)，這種代幣數(shù)量增加的趨勢并沒有在 OpenAI 的最新模型 GPT-4o mini 中延續(xù)。與 GPT-4 Turbo 相比，平均代幣數(shù)量有所減少，但仍遠(yuǎn)高于 GPT-4。生成代幣數(shù)量最少的模型是 GPT-3.5 Turbo，這與定性分析結(jié)果一致，工程師更喜歡較短的響應(yīng)，而不是較長的響應(yīng)且沒有補(bǔ)充解釋。

3.每個(gè)Token的響應(yīng)時(shí)間

檢查完模型的響應(yīng)時(shí)間和平均令牌數(shù)后，我們可以確定每個(gè)模型在響應(yīng)時(shí)間和令牌生成方面的速度。

下面是按模型顯示每個(gè) token 響應(yīng)時(shí)間的圖表。在這里，我們看到 GPT-4 比 GPT-4 Turbo 更快，但這是由于數(shù)據(jù)中的異常值。鑒于它傾向于生成更長的輸出，其整體響應(yīng)時(shí)間仍然比 GPT-4 更長。這可能意味著當(dāng) GPT-4 Turbo 生成的內(nèi)容過多時(shí)，它就不是一個(gè)理想的模型。

圖片

注意：GPT-3.5、GPT 4 和 GPT-4o 模型使用不同的標(biāo)記器。

4.GPT-4o 與 GPT-4o Mini 的比較

有趣的是，數(shù)據(jù)顯示 GPT-4o 和 GPT-4o mini 的響應(yīng)速度相似，這與其他來源的發(fā)現(xiàn)形成鮮明對(duì)比。這種差異表明，可能需要更大的樣本量才能揭示它們性能上更明顯的差異。另一種解釋是，鑒于我們是通過總響應(yīng)時(shí)間來衡量每秒的令牌數(shù)，由于第一個(gè)令牌時(shí)間 (TTFT) 和其他與網(wǎng)絡(luò)相關(guān)的瓶頸，我們稍微將值偏低。

5.擴(kuò)展模式

按模型分組繪制響應(yīng)時(shí)間與令牌數(shù)的關(guān)系圖，可以揭示這些模型擴(kuò)展的不同模式。對(duì)于 GPT-3.5、GPT-4o 和 GPT-4o Mini，擴(kuò)展大多是線性的，令牌數(shù)的增加會(huì)導(dǎo)致響應(yīng)時(shí)間相應(yīng)增加。

然而，這種模式并不適用于 GPT-4 系列中較大和較舊的模型，因?yàn)檫@兩個(gè)變量沒有一致的關(guān)系。這種不一致可能是由于樣本量較小或?qū)Ｓ糜谶@些請(qǐng)求的資源較少，導(dǎo)致響應(yīng)時(shí)間不同?？紤]到在其他模型中觀察到的線性關(guān)系，后一種解釋更有可能。

圖片

6.GPT-4 上下文限制

生成這些錯(cuò)誤-響應(yīng)對(duì)后，我們得出了最后一個(gè)分析結(jié)論。雖然 GPT-4 模型很有能力，但其上下文長度對(duì)于需要長輸入的任務(wù)（例如堆棧跟蹤）而言受到很大限制。因此，無法生成一個(gè)錯(cuò)誤-響應(yīng)對(duì)，因?yàn)榻M合的輸入和輸出將超出模型的 8192 個(gè) token 上下文窗口。

7.綜合來看

在評(píng)估定性數(shù)據(jù)后，很明顯 GPT-4 Turbo 是這項(xiàng)任務(wù)的最佳模型。但是，將其與定量數(shù)據(jù)進(jìn)行比較會(huì)引入響應(yīng)時(shí)間和成本考慮因素。新的 GPT-4o 模型比所有其他模型都快得多，而且便宜得多，這是一個(gè)權(quán)衡。如果需要稍微好一點(diǎn)的性能，GPT-4 Turbo 是首選。但是，如果成本和速度是優(yōu)先考慮因素，GPT-4o 和 GPT-4o mini 是更好的選擇。

五、結(jié)論

總之，我們的研究提供了有關(guān)后期模型性能的混合證據(jù)。雖然一些較新的模型（如 GPT-4 Turbo 和 GPT-4o）由于能夠包含簡潔的代碼片段而有所改進(jìn)，但其他模型（如 GPT-4）由于響應(yīng)冗長且不太實(shí)用而未能達(dá)到要求。

六、關(guān)鍵要點(diǎn)

1. 代碼片段很重要：提供代碼片段和解釋的模型更有效，也更受開發(fā)人員的青睞。
2. 上下文至關(guān)重要：添加周圍代碼或源映射可顯著提高響應(yīng)的質(zhì)量。
3. 平衡回復(fù)長度：較短、簡潔的回復(fù)通常比較長、冗長的回復(fù)更有幫助。
4. 定期評(píng)估：持續(xù)評(píng)估模型性能，以確保您使用最有效的工具來滿足您的需求。
5. 注意上下文限制：了解上下文長度限制并據(jù)此制定計(jì)劃。

通過關(guān)注這些因素，開發(fā)人員可以更好地利用 LLM 來解決錯(cuò)誤，最終提高他們的工作效率和解決方案的準(zhǔn)確性。

未來可以補(bǔ)充這項(xiàng)研究的實(shí)驗(yàn)可能包括對(duì)代碼生成的更深入的分析，如引言中所述。一個(gè)可能的實(shí)驗(yàn)可能涉及從錯(cuò)誤解決中獲取建議并為 LLM 提供額外的背景信息。理想情況下，如果要重做這項(xiàng)研究，最好包括更廣泛的錯(cuò)誤類型，包括更具挑戰(zhàn)性的錯(cuò)誤，并從更多樣化的工程師那里收集評(píng)級(jí)。

想了解更多AIGC的內(nèi)容，請(qǐng)?jiān)L問：

51CTO AI.x社區(qū)

http://www.scjtxx.cn/aigc/