GPT-4：我寫的程式碼你敢用嗎？研究顯示其API誤用率超過62%

語言建模的新時代已經到來，大型語言模型（LLM）能力非凡，不僅能理解自然語言，甚至能根據使用者需求產生客製化程式碼。

因此，越來越多的軟體工程師選擇查詢大型語言模型來解答程式設計問題，例如使用 API 來產生程式碼片段或偵測程式碼中的 bug。相較於搜尋 Stack Overflow 等網路程式設計論壇，大型語言模型可為程式設計問題檢索到更適合的定製版答案。

LLM 的速度很快，但這也掩蓋了其程式碼產生中的潛在風險。從軟體工程的角度來看，即便已經有許多研究成果問世（涉及避免句法錯誤以及提升對生成代碼的語義理解等方面），LLM 的生成代碼能力的穩健性和可靠性還沒有得到透徹的研究。

不同於網路程式設計論壇的情況，LLM 產生的程式碼沒有得到社群同儕的審查，因此可能出現API 誤用問題，例如在檔案讀取和變數索引中缺少邊界檢查、缺少檔案I/O 關閉、交易完成失敗等。即使產生的程式碼樣本可以執行或能正確執行功能，誤用也可能導致產品出現嚴重的潛在風險，例如記憶體洩漏、程式崩潰、垃圾資料收集失敗等。

更糟的是，提出這些問題的程式設計師還是最容易受到打擊的人，因為他們更有可能是API 新手，無法辨別產生的程式碼片段中的潛在問題。

下圖展示了一個軟體工程師向LLM 詢問程式設計問題的範例，可以看到Llama-2 能給出句法正確、功能正確、語法對齊的程式碼段，但卻存在不夠穩健可靠的問題，因為其中沒有考慮到文件已存在或資料夾不存在的情況。

因此，在評估大型語言模型的程式碼產生能力時，必須考慮程式碼的可靠性。

在評估大型語言模型的程式碼產生能力方面，大多數現有基準關注的重點是所產生程式碼的執行結果的功能正確性，這意味著只要產生的程式碼能夠滿足使用者的功能需求，使用者就能接受。

但在軟體開發領域，程式碼光是能正確執行可不夠。軟體工程師需要的是程式碼能正確且可靠地使用新 API，長期運作也不會有潛在風險。

此外，目前大多數程式設計問題的範圍都與軟體工程相距甚遠。其資料來源大都是網路上的程式設計挑戰賽網絡，如 Codeforces、Kattis、Leetcode 等。儘管成就非凡，但這還不足以為實際應用場景的軟體開發工作提供協助。

為此，加州大學聖迭戈分校的Li Zhong 和Zilong Wang 提出了RobustAPI，該框架可以評估大型語言模型生成的程式碼的可靠性和穩健性，其中包含一個編程問題資料集和一個使用抽象語法樹（AST）的評估器。

論文網址：https://arxiv.org/pdf/2308.10335.pdf

#其中資料集的目標是創建一個接近真實軟體開發的評估設定。為此研究者從 Stack Overflow 收集了有關 Java 的代表性問題。 Java 是最受歡迎的程式語言之一，得益於其一次編寫到處運行（WORA）的特性，被廣泛用於軟體開發。

對於每一個問題，研究者都提供了詳細的描述和相關的 Java API。他們還設計了一套用於呼叫大型語言模型來產生程式碼段及相應解釋的模板。

研究者也提供了一個評估器，其能使用抽象語法樹（AST）分析所產生的程式碼片段並將它們與預期的 API 使用模式進行比較。

研究者也依照 Zhang et al. (2018) 的方法將 AI 使用模式形式化地表示成了結構化的呼叫序列。這種結構化的呼叫序列能顯示可以如何正確使用這些 API 來消除潛在的系統風險。從軟體工程的角度來看，任何違反這種結構化呼叫序列的現像都將被視為失敗。

研究者從 Stack Overflow 收集了 1208 個真實問題，其中涉及 24 個代表性的 Java API。研究者也進行了實驗評估，其中不僅實驗了閉源的語言模型（GPT-3.5 和 GPT-4），也實驗了開源的語言模型（Llama-2 和 Vicuna-1.5）。對於模型的超參數設置，他們使用了預設設置，未進行進一步超參數調節。他們也設計了兩種實驗形式：零樣本（zero-shot）和單樣本（one-shot），即分別在 prompt 中提供零個或一個演示樣本。

研究者全面分析了 LLM 產生的程式碼並研究了常見的 API 誤用情況。他們希望藉此讓人們了解 LLM 在產生程式碼時誤用 API 的重要問題，同時這項研究也能為 LLM 的評估提供一個新的維度，而不只是常用的功能正確性。此外資料集和評估器也將開源。

本論文的貢獻總結如下：

• #提出了一個用於評估LLM 程式碼產生的可靠性和穩健性的新基準：RobustAPI。 
• 提供了一個完善的評估框架，其中包含一個由 Stack Overflow 問題組成的資料集和一個使用 AST 的 API 使用情況檢查器。研究者基於此框架分析了常用 LLM 的表現表現，包括 GPT-3.5、GPT-4、Llama-2 和 Vicuna-1.5。 
• 全面分析了 LLM 產生程式碼的表現。他們總結了每種模型常見的 API 誤用情況，並指出了可供未來研究改進的方向。

方法概覽

RobustAPI 是一個用於全面評估 LLM 產生程式碼的可靠性和穩健性的框架。

以下將描述建構該資料集時的資料收集過程和prompt 產生過程，然後將給出RobustAPI 中評估的API 誤用模式並討論誤用的潛在後果，最後也將給出用RobustAPI 檢測API 誤用情況的靜態分析，其中使用的方法是抽象語法樹。

結果發現，相較於關鍵字匹配等基於規則的方法，新方法能以更高的準確度評估 LLM 產生程式碼的 API 誤用情況。

資料收集

為了利用軟體工程領域的已有研究成果，研究者建構RobustAPI 時所立足的起點是來自ExampleCheck (Zhang et al. 2018) 的資料集。 ExampleCheck 是用於研究網路問答論壇中常見 Java API 誤用情況的框架。

研究者從該資料集選取了 23 個常見的 Java API，如下表 1 所示。這 23 個 API 涵蓋 5 個領域，包括字串處理、資料結構、行動裝置開發、加密和資料庫操作。

prompt 產生

RobustAPI 也包含一個prompt 模板，可用資料集中的樣本來填入。然後研究者收集 LLM 對該 prompt 的回應，再透過一個 API 使用檢查器來評估其程式碼可靠性。

在該 prompt 中，首先會給出任務介紹和所需的回應格式。然後，如果執行的實驗是少樣本實驗，則還會給出少樣本的演示。以下是一個範例：

示範樣本

#示範樣本已被證明有助於 LLM 理解自然語言。為了透徹分析 LLM 的程式碼產生能力，研究者設計了兩種少樣本設定：單樣本無關演示和單樣本相關演示。

在單一樣本無關示範設定中，為 LLM 提供的示範範例所使用的 API 是無關的。研究者假設這種演示範例能消除生成程式碼中句法錯誤。 RobustAPI 中使用的無關範例如下：

#

在單樣本相關示範設定中，為 LLM 提供的示範範例所使用的 API 與給定問題所使用的 API 一樣。這個範例包含一對問題和答案。這種演示範例中的問題並不包含在測試資料集中，而且研究者人工修正了其中的答案以確保其中不存在 API 誤用情況並且答案和問題的語義很好地對齊了。

 Java API 誤用

#研究者為RobustAPI 中的23 個API 總結了40 個API 規則，它們在這些API 的文檔中得到了驗證。這些規則包括：

(1) API 的守衛條件，這應該在 API 呼叫之前進行檢查。舉個例子，在 File.createNewFile () 之前應檢查 File.exists () 的結果。

(2) 所要求的 API 呼叫序列，即應以一定順序呼叫 API。例如，應在 File.write () 之後呼叫 close ()。

(3) API 的控制結構。例如，應把 SimpleDateFormat.parse () 包含在 try-catch 結構中。

以下給出一個範例：

#偵測API 誤用情況

為了評估程式碼中API 使用的正確性，RobustAPI 可根據API 使用規則偵測API 誤用情況，其做法是從程式碼片段擷取呼叫結果和控制結構，如下圖2 所示。

程式碼檢視器首先會檢查產生的程式碼段，看這段程式碼是某個方法中的一段程式碼，還是來自某個類的一個方法，以便它可以封裝該程式碼段並使用其建立抽象語法樹（AST）。

然後該檢查器會遍歷該 AST 並依序記錄所有的方法呼叫和控制結構，這會產生一個呼叫序列。

接下來，該檢查器會將這個呼叫序列與 API 使用規則進行比較。它會推斷每個方法呼叫的實例類型，並將該類型和方法用作鍵來檢索對應的 API 使用規則。

最後，檢查器會計算這個呼叫序列和 API 使用規則之間最長的公共序列。

如果這個呼叫序列和預期的 API 使用規則不匹配，則該檢查器就報告出現了 API 誤用。

 實驗結果

#研究者在4 個LLM 上評估了RobustAPI：GPT-3.5、GPT-4 、 Llama-2 和Vicuna-1.5 。

實驗中所使用的評估指標包括：API 誤用率、可執行樣本百分比、總體 API 誤用百分比。

實驗的目的是試圖回答以下問題：

• 問題1：這些LLM 在解答真實世界程式設計問題時的API誤用率是多少？
• 問題 2：無關的演示樣本會對結果產生什麼樣的影響？
• 問題 3：正確的 API 使用範例能降低 API 誤用率嗎？
• 問題 4：為什麼 LLM 產生的程式碼無法透過 API 使用檢查？

具體的實驗過程請參考原論文，這裡給出研究者得到的5 個發現：

發現1：目前最佳的大型語言模型對真實世界程式設計問題的答案普遍存在API 誤用問題。

發現2：在所有包含可執行程式碼的LLM 答案中，57-70% 的程式碼片段都有API 誤用問題，這可能對生產帶來嚴重後果。

發現3：無關樣本範例無助於降低API 誤用率，但會觸發更有效的答案，這能有效地用於模型效能的基準評​​測。

發現 4：某些 LLM 可以學習正確的使用範例，這能降低 API 誤用率。

發現 5：GPT-4 包含可執行程式碼的答案數最多。對於基準 API，不同的 LLM 的誤用率趨勢也不同。

此外，研究者在論文中也展示了一個基於 GPT-3.5 的典型案例：模型在不同的實驗設定下有不同的反應。

任務是要求模型幫助使用 PrintWriter.write API 將字串寫入一個檔案。

在零樣本和單樣本無關演示設定下，答案稍有不同，但都出現了API 誤用問題—— 沒有考慮例外情況。在給模型了正確的 API 使用範例後，模型學會如何使用 API 並給出了可靠的程式碼。

更多細節請參閱原文。

以上是GPT-4：我寫的程式碼你敢用嗎？研究顯示其API誤用率超過62%的詳細內容。更多資訊請關注PHP中文網其他相關文章！