新智元報道
編輯：LRS
【新智元導讀】代碼能否跑起來的不是判斷可靠性的標準，用語言模型寫代碼還需要考慮生產環境下的預期外輸入。
大型語言模型（LLM）在理解自然語言和生成程序代碼方面展現出了非凡的性能，程序員們也開始在編碼過程中使用Copilot工具輔助編程，或是要求LLM生成解決方案。
經過幾版迭代后，目前LLM生成的代碼已經很少有語法錯誤了，也更貼合用戶輸入的文本、符合預期語義，但針對LLM代碼生成的可靠性和魯棒性仍然缺乏徹底的研究。
代碼的可執行并不等同于可靠，軟件的開發環境、部署環境都存在很大的不確定性。
如果直接使用LLM生成的代碼，可能會因為AP誤用（misuse）導致更嚴重的問題，例如資源泄漏、程序崩潰；最糟糕的是，使用LLM代碼生成服務的用戶大多數都是新手開發人員，很難識別出「貌似可運行代碼」下的隱藏問題，進一步增加了漏洞代碼在現實中的應用風險。
現有的代碼評估基準和數據集主要專注于小任務，例如面試中的編程問題，可能不符合開發人員在工作中的實際需求。
最近，來自加州大學的兩位華人研究人員發布了一個用于評估生成代碼可靠性和魯棒性的新數據集RobustAPI，包括從StackOverflow中收集得到的1208個編碼問題，涉及24個主流JAVA API的評估。
論文鏈接：https://arxiv.org/pdf/2308.10335.pdf
研究人員總結了這些API的常見誤用模式，并在當下常用的LLM上對其進行評估，結果表明，即使是GPT-4，也有高達62%的生成代碼包含API誤用問題，如果代碼被實際部署，可能會導致意想不到的后果。
論文相關的數據和評估器不久后將開源。
方法
數據收集
為了利用軟件工程領域現有的研究成果，RobustAPI沒有從零構建，而是基于在線問答論壇中頻繁出現的Java API誤用數據集ExampleCheck
研究人員從數據集中選擇了23個流行的Java APIs，涵蓋了字符串處理、數據結構、移動開發、加密和數據庫操作等。
然后再從Stack Overflow中爬取與上述API相關的問題，只選擇問題中包含在線答案的，可以保證RobustAPI是可回答的（answerable），能夠更有效地評估LLM在「人類容易犯錯問題」上的代碼能力。
收集數據后將問題轉換為JSON格式，包含四個字段：
1. id，為樣本分配的唯一標識符
2. api，用來提示大型語言模型問題相關API
3. question，包括問題的標題和描述
4. origin，樣本的原始URL
提示生成（prompt generation）
研究人員設計了一個提示模板，并用數據集中的樣本進行填充，再從LLMs收集回復內容，并實現一個API使用檢查器來評估代碼的可靠性。
在少樣本演示下進行實驗時，每個示例都提供回復的格式，然后在最后放入數據集中的問題及相應API提示，模擬新手用戶詢問時提出的問題。
LLM在對話時可以識別特殊標簽的結構，所以研究人員將問題和答案封裝起來指示LLM生成問題的答案。
演示樣本（Demonstration Samples）
為了深入分析LLMs的代碼生成能力，研究人員設計了兩個少樣本實驗：
1. one-shot-irrelevant，使用不相關的API（如Arrays.stream）作為語言模型的提示樣例。
研究人員假定該示例可以消除生成代碼中的語法錯誤。
2. one-shot-relevant，使用相同的API作為示例，包括一組問題和答案。
JAVA API誤用
研究人員在使用API時，需要充分理解API的使用規則，以便實現理想的API效果。
一個典型的例子是文件操作，通過RandomaccessFile打開和寫入文件時，需要注意兩條使用規則：
1. 讀取文件可能會引發異常。
如果在讀取預期字節之前達到緩沖區限制，API將拋出IndexOutOfBoundsException異常；當該文件同時被其他進程關閉時，API將拋出ClosedChannelException。
為了處理這些異常，正確的實現應該將API包含在try-catch塊中。
2. 使用后應應該關閉文件通道，否則的話，如果此代碼片段位于在多個實例中并發運行的長期程序中，文件資源可能會耗盡，代碼需要在所有文件操作后調用close API
另一個容易被誤用的API使用規則的例子是一個特殊的數據對象TypedArray，需要開發人員調用recycle來手動啟用垃圾收集，否則，即使不再使用此TypedArray，Java虛擬機中的垃圾收集也不會被觸發。
在沒有垃圾回收的情況下使用該API會導致未釋放的內存消耗，在生產環境部署后，在大工作負載和高并發性下會降低甚至掛起軟件系統。
在RobustAPI數據集中，研究人員總結了40個API使用規則，具體包括：
1. API的保護條件，在API調用之前應該檢查，例如File.exists應該在調用File.createNewFile之前；
2. API的調用順序，例如close的調用應該在File.write之后；
3. API的控制結構，例如SimpleDataFormat.parse應該被try-catch結構所包圍。
檢測API誤用
現有的評估LLMs生成的代碼的研究通常使用人工編寫或自動測試生成的測試用例，但即使是高覆蓋率的測試用例也只能覆蓋語義正確性，無法模擬生產環境中的各種意外輸入，無法對代碼的可靠性和健壯性進行完善的評估。
為了解決這個難題，研究人員使用靜態分析的方法，在不運行測試用例的情況下，通過代碼結構分析代碼誤用，可以保證對整個程序的全面覆蓋，并且比測試解決方案的效率更高。
為了評估代碼中API用法的正確性，先從代碼片段中提取調用結果和控制結構，然后根據API使用規則檢測API誤用。
代碼檢查器（code checker）首先檢查代碼片段，判斷是一個方法的片段還是一個類的方法，然后就可以對代碼片段進行封裝，并從代碼片段中構造抽象語法樹（AST）。
然后檢查器遍歷AST，按順序記錄所有的方法調用和控制結構，從而生成一個調用序列；檢查器將調用序列與API使用規則進行比較，判斷每個方法調用的實例類型，并使用類型和方法作為鍵來檢索相應的API使用規則。
最后，檢查器計算調用序列和API使用規則之間的最長公共序列：如果調用序列與預期的API使用規則不匹配，則報告API誤用。
實驗結果
研究人員使用4個語言模型（GPT-3.5，GPT-4，Llama-2，Vicuna-1.5）在RobustAPI上進行評估。
將可編譯且包含API誤用的答案除以所有可編譯的答案后，計算得到各個語言模型的誤用率。
從實驗結果上來看，即便是最先進的商業模型，如GPT-3.5和GPT-4也存在誤用的問題。
在零樣本設置下，Llama的API誤用率最低，不過大多數Llama的答案中都不包含代碼。
一個與直覺相反的發現是，雖然AI target=_blank class=infotextkey>OpenAI官方宣稱GPT-4比GPT-3.5在代碼生成上的性能提升達到40%，但實際上GPT-4的代碼誤用率要更高。
這一結果也表明，代碼在現實世界生產中的可靠性和健壯性沒有得到業界的重視，并且該問題存在巨大的改進空間。
參考資料：
https://arxiv.org/abs/2308.10335
