語言建模的新時代已經到來，大型語言模型（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 并給出了可靠的代碼。

更多細節請參閱原論文。