語言建模的新時代已經(jīng)到來，大型語言模型（LLM）能力非凡，不僅能理解自然語言，甚至能根據(jù)用戶需求生成定制代碼。

因此，越來越多的軟件工程師選擇查詢大型語言模型來解答編程問題，比如使用 API 來生成代碼段或檢測代碼中的 bug。相比于搜索 Stack Overflow 等網(wǎng)絡(luò)編程論壇，大型語言模型可為編程問題檢索到更加合適的定制版答案。

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

不同于網(wǎng)絡(luò)編程論壇的情況，LLM 生成的代碼沒有得到社區(qū)同行的審查，因此可能出現(xiàn) API 誤用問題，例如在文件讀取和變量索引中缺少邊界檢查、缺少文件 I/O 關(guān)閉、交易完成失敗等。即使生成的代碼樣本可以執(zhí)行或者能正確執(zhí)行功能，誤用也可能導(dǎo)致產(chǎn)品出現(xiàn)嚴(yán)重的潛在風(fēng)險，比如內(nèi)存泄漏、程序崩潰、垃圾數(shù)據(jù)收集失敗等。

更糟糕的是，提出這些問題的程序員還是最容易受到打擊的人，因為他們更有可能是 API 新手，無法辨別生成的代碼段中的潛在問題。

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

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

在評估大型語言模型的代碼生成能力方面，大多數(shù)現(xiàn)有基準(zhǔn)關(guān)注的重點是所生成代碼的執(zhí)行結(jié)果的功能正確性，這意味著只要生成的代碼能夠滿足用戶的功能需求，用戶就能接受。

但在軟件開發(fā)領(lǐng)域，代碼光是能正確執(zhí)行可不夠。軟件工程師需要的是代碼能正確且可靠地使用新 API，長期運行也不會有潛在風(fēng)險。

此外，當(dāng)前大多數(shù)編程問題的范圍都與軟件工程相距甚遠。其數(shù)據(jù)源大都是網(wǎng)上的編程挑戰(zhàn)賽網(wǎng)絡(luò)，比如 Codeforces、Kattis、Leetcode 等。盡管成就非凡，但這還不足以為實際應(yīng)用場景的軟件開發(fā)工作提供幫助。

為此，加州大學(xué)圣迭戈分校的 Li Zhong 和 Zilong Wang 提出了 RobustAPI，該框架可以評估大型語言模型生成的代碼的可靠性和穩(wěn)健性，其中包含一個編程問題數(shù)據(jù)集和一個使用抽象語法樹（AST）的評估器。

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

其中數(shù)據(jù)集的目標(biāo)是創(chuàng)建一個接近真實軟件開發(fā)的評估設(shè)置。為此研究者從 Stack Overflow 收集了有關(guān) Java 的代表性問題。Java 是最流行的編程語言之一，得益于其一次編寫到處運行（WORA）的特性，被廣泛用于軟件開發(fā)。

對于每一個問題，研究者都提供了詳細的描述和相關(guān)的 Java API。他們還設(shè)計了一套用于調(diào)用大型語言模型來生成代碼段及相應(yīng)解釋的模板。

研究者還提供了一個評估器，其能使用抽象語法樹（AST）分析所生成的代碼段并將它們與預(yù)期的 API 使用模式進行比較。

研究者也按照 Zhang et al. (2018) 的方法將 AI 使用模式形式化地表示成了結(jié)構(gòu)化的調(diào)用序列。這種結(jié)構(gòu)化的調(diào)用序列能表明可以如何正確使用這些 API 來消除潛在的系統(tǒng)風(fēng)險。從軟件工程的角度看，任何違反這種結(jié)構(gòu)化調(diào)用序列的現(xiàn)象都將被視為失敗。

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

研究者全面分析了 LLM 生成的代碼并研究了常見的 API 誤用情況。他們希望借此讓人們了解 LLM 在生成代碼時誤用 API 的重要問題，同時這項研究也能為 LLM 的評估提供一個新的維度，而不只是常用的功能正確性。此外數(shù)據(jù)集和評估器還將開源。

本論文的貢獻總結(jié)如下：

• 提出了一種用于評估 LLM 代碼生成的可靠性和穩(wěn)健性的新基準(zhǔn)：RobustAPI。 
• 提供了一個完善的評估框架，其中包括一個由 Stack Overflow 問題構(gòu)成的數(shù)據(jù)集和一個使用 AST 的 API 使用情況檢查器。研究者基于此框架分析了常用 LLM 的性能表現(xiàn)，包括 GPT-3.5、GPT-4、Llama-2 和 Vicuna-1.5。 
• 全面分析了 LLM 生成代碼的表現(xiàn)。他們總結(jié)了每種模型常見的 API 誤用情況，并指出了可供未來研究改進的方向。

方法概覽

RobustAPI 是一個用于全面評估 LLM 生成代碼的可靠性和穩(wěn)健性的框架。

下面將描述構(gòu)建該數(shù)據(jù)集時的數(shù)據(jù)收集過程和 prompt 生成過程，然后將給出 RobustAPI 中評估的 API 誤用模式并討論誤用的潛在后果，最后還將給出用 RobustAPI 檢測 API 誤用情況的靜態(tài)分析，其中使用的方法是抽象語法樹。

結(jié)果發(fā)現(xiàn)，相比于關(guān)鍵詞匹配等基于規(guī)則的方法，新方法能以更高的準(zhǔn)確度評估 LLM 生成代碼的 API 誤用情況。

數(shù)據(jù)收集

為了利用軟件工程領(lǐng)域的已有研究成果，研究者構(gòu)建 RobustAPI 時立足的起點是來自 ExampleCheck (Zhang et al. 2018) 的數(shù)據(jù)集。ExampleCheck 是用于研究網(wǎng)絡(luò)問答論壇中常見 Java API 誤用情況的框架。

研究者從該數(shù)據(jù)集選取了 23 個常見的 Java API，如下表 1 所示。這 23 個 API 覆蓋 5 個領(lǐng)域，包括字符串處理、數(shù)據(jù)結(jié)構(gòu)、移動端開發(fā)、加密和數(shù)據(jù)庫操作。

prompt 生成

RobustAPI 還包含一個 prompt 模板，可使用數(shù)據(jù)集中的樣本來填充。然后研究者收集 LLM 對該 prompt 的響應(yīng)，再通過一個 API 使用檢查器來評估其代碼可靠性。

在該 prompt 中，首先會給出任務(wù)介紹和所需的響應(yīng)格式。然后，如果執(zhí)行的實驗是少樣本實驗，則還會給出少樣本的演示。下面是一個示例：

演示樣本

演示樣本已被證明有助于 LLM 理解自然語言。為了透徹地分析 LLM 的代碼生成能力，研究者設(shè)計了兩種少樣本設(shè)置：單樣本無關(guān)演示和單樣本相關(guān)演示。

在單樣本無關(guān)演示設(shè)置中，為 LLM 提供的演示示例使用的 API 是無關(guān)的。研究者假設(shè)這種演示示例能消除生成代碼中句法錯誤。RobustAPI 中使用的無關(guān)示例如下：

在單樣本相關(guān)演示設(shè)置中，為 LLM 提供的演示示例使用的 API 與給定問題所用的 API 一樣。這種示例包含一對問題和答案。這種演示示例中的問題并不包含在測試數(shù)據(jù)集中，而且研究者人工修正了其中的答案以確保其中不存在 API 誤用情況并且答案和問題的語義很好地對齊了。

 Java API 誤用

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

(1) API 的守衛(wèi)條件，這應(yīng)該在 API 調(diào)用之前進行檢查。舉個例子，在 File.createNewFile () 之前應(yīng)檢查 File.exists () 的結(jié)果。

(2) 所要求的 API 調(diào)用序列，即應(yīng)當(dāng)以一定順序調(diào)用 API。比如，應(yīng)在 File.write () 之后調(diào)用 close ()。

(3) API 的控制結(jié)構(gòu)。比如，應(yīng)把 SimpleDateFormat.parse () 包含在 try-catch 結(jié)構(gòu)中。

下面給出一個例子：

檢測 API 誤用情況

為了評估代碼中 API 使用的正確性，RobustAPI 可根據(jù) API 使用規(guī)則檢測 API 誤用情況，其做法是從代碼段中提取調(diào)用結(jié)果和控制結(jié)構(gòu)，如下圖 2 所示。

代碼檢查器首先會檢查生成的代碼段，看這段代碼是某個方法中的一段代碼，還是來自某個類的一個方法，以便它可以封裝該代碼段并使用其構(gòu)建抽象語法樹（AST）。

然后該檢查器會遍歷該 AST 并按順序記錄所有的方法調(diào)用和控制結(jié)構(gòu)，這會生成一個調(diào)用序列。

接下來，該檢查器會將這個調(diào)用序列與 API 使用規(guī)則進行比較。它會推斷每個方法調(diào)用的實例類型，并將該類型和方法用作鍵來檢索相應(yīng)的 API 使用規(guī)則。

最后，該檢查器會計算這個調(diào)用序列和 API 使用規(guī)則之間的最長公共序列。

如果這個調(diào)用序列和預(yù)期的 API 使用規(guī)則不匹配，則該檢查器就報告出現(xiàn)了 API 誤用。

 實驗結(jié)果

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

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

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

• 問題 1：這些 LLM 在解答真實世界編程問題時的 API 誤用率是多少？
• 問題 2：無關(guān)的演示樣本會對結(jié)果產(chǎn)生什么樣的影響？
• 問題 3：正確的 API 使用示例能降低 API 誤用率嗎？
• 問題 4：為什么 LLM 生成的代碼無法通過 API 使用檢查？

具體的實驗過程請參閱原論文，這里給出研究者得到的 5 個發(fā)現(xiàn)：

發(fā)現(xiàn) 1：當(dāng)前最佳的大型語言模型對真實世界編程問題的答案普遍存在 API 誤用問題。

發(fā)現(xiàn) 2：在所有包含可執(zhí)行代碼的 LLM 答案中，57-70% 的代碼段都有 API 誤用問題，這可能給生產(chǎn)帶來嚴(yán)重后果。

發(fā)現(xiàn) 3：無關(guān)樣本示例無助于降低 API 誤用率，但會觸發(fā)更有效的答案，這能有效地用于對模型性能的基準(zhǔn)評測。

發(fā)現(xiàn) 4：某些 LLM 可以學(xué)習(xí)正確的使用示例，這能降低 API 誤用率。

發(fā)現(xiàn) 5：GPT-4 包含可執(zhí)行代碼的答案數(shù)量最多。對于基準(zhǔn) API，不同的 LLM 的誤用率趨勢也不同。

此外，研究者還在論文中展示了一個基于 GPT-3.5 的典型案例：模型在不同的實驗設(shè)置下有不同的反應(yīng)。

任務(wù)是要求模型幫助使用 PrintWriter.write API 將字符串寫入一個文件。

在零樣本和單樣本無關(guān)演示設(shè)置下，答案稍有不同，但都出現(xiàn)了 API 誤用問題 —— 沒有考慮例外情況。在給模型提供了正確的 API 使用示例后，模型學(xué)會了如何使用 API 并給出了可靠的代碼。

更多細節(jié)請參閱原論文。