大型語言模型程式設計工作流程：規劃驅動程式設計

核心概念

本文提出了一種名為 LPW 的大型語言模型程式設計工作流程，該流程通過在程式碼實作之前生成並驗證解決方案計畫，來提高程式碼生成的準確性，並通過將執行結果與計畫驗證進行比較來改進除錯過程。

摘要

論文資訊
Lei, C., Chang, Y., Lipovetzky, N., & Ehinger, K. A. (2024). Planning-Driven Programming: A Large Language Model Programming Workflow. arXiv preprint arXiv:2411.14503.
研究目標
本研究旨在解決大型語言模型 (LLM) 在程式碼生成方面效率低下和推理能力有限的問題，特別是在初始程式碼生成和後續程式碼優化方面。
方法
研究提出了一種名為 LPW 的 LLM 程式設計工作流程，該流程包含兩個階段：解決方案生成階段和程式碼實作階段。在解決方案生成階段，LLM 首先制定一個解決方案計畫，將問題分解成可管理的子問題，然後通過可見測試案例驗證生成的解決方案計畫。在程式碼實作階段，LLM 根據解決方案計畫及其驗證結果生成程式碼草稿。如果生成的程式碼未通過可見測試，則計畫驗證將作為預期的自然語言解決方案，用於指導修正錯誤的過程。此外，研究還提出了一種 LPW 的採樣變體 SLPW，它首先生成多個解決方案計畫和計畫驗證，為每個計畫及其驗證生成一個程式，並根據需要優化每個程式，直到其中一個程式成功通過可見測試。
主要發現
實驗結果表明，與現有方法相比，LPW 和 SLPW 在 HumanEval、MBPP、APPS 和 CodeContest 等多個基準測試中顯著提高了程式碼生成的準確性。
主要結論
LPW 和 SLPW 為基於 LLM 的程式碼生成提供了一種有效的工作流程，通過在程式碼實作之前驗證解決方案計畫的正確性，並利用計畫驗證來指導程式碼優化，從而提高了程式碼生成的效率和準確性。
研究意義
本研究為基於 LLM 的程式碼生成提供了一種新的思路，即借鑒傳統軟體開發模型的思想，將分析和設計步驟放在程式碼實作之前，從而提高程式碼生成的效率和準確性。
局限性和未來研究方向
未來的研究可以探索如何進一步提高 LPW 和 SLPW 在處理更複雜程式設計問題時的性能，例如如何處理涉及多個函數或類的程式設計問題。此外，還可以研究如何將 LPW 和 SLPW 應用於其他程式設計語言和程式設計任務。

统计

與最先進的 LLM 除錯器 LDB 相比，LPW 在所有基準測試中使用 GPT-3.5 作為骨幹網路時，Pass@1 準確率提高了約 4%，在使用 Llama-3 作為骨幹網路時，MBPP 的 Pass@1 準確率最高提高了 16.4%。
使用 GPT-3.5 時，SLPW 在所有基準測試中均比 LPW 提高了約 1%，並在 HumanEval、HumanEval-ET、MBPP 和 MBPP-ET 上分別達到了 89.6%、77.4%、77.2% 和 58.2% 的最佳準確率。
在使用 Phi-3 作為骨幹網路時，SLPW 在 MBPP 上比 LPW 的準確率最高提高了 5.6%，在 HumanEval 上比基準線提高了 45.1%。
在使用 GPT-4o 骨幹網路時，LPW 和 SLPW 在所有基準測試中均優於 LDB，SLPW 在所有基準測試中均達到了新的最先進的 Pass@1 準確率，特別是在 HumanEval 上達到了 98.2%。
對於 APPS 和 CodeContests，LPW 和 SLPW 的準確率分別超過 62% 和 34%，比使用 GPT-4o 骨幹網路的 LDB 分別高出約 10% 和 5%。

从中提取的关键见解

Planning-Driven Programming: A Large Language Model Programming Workflow

by Chao Lei, Ya... 在 arxiv.org 11-25-2024

https://arxiv.org/pdf/2411.14503.pdf

更深入的查询

如何將 LPW 和 SLPW 應用於需要與外部 API 或資料庫互動的更複雜的程式設計任務？

將 LPW 和 SLPW 應用於需要與外部 API 或資料庫互動的更複雜程式設計任務，需要解決以下幾個挑戰：

外部依賴的表示: LPW 和 SLPW 需要理解外部 API 或資料庫的功能和使用方法。這可以通過以下方式實現：

擴展問題描述: 在問題描述中加入外部 API 或資料庫的相關資訊，例如 API 文件、資料庫 schema 等。
使用特定領域的提示: 設計針對特定 API 或資料庫的提示，引導 LLM 生成正確的程式碼。
微調 LLM: 使用包含外部 API 或資料庫互動的程式碼資料集對 LLM 進行微調，使其學習如何與這些外部依賴進行互動。

狀態管理: 與外部 API 或資料庫互動的程式通常需要管理狀態，例如連線狀態、查詢結果等。LPW 和 SLPW 需要能夠理解和處理這些狀態資訊。這可以通過以下方式實現：

在解決方案計畫中明確表示狀態: 將狀態管理步驟納入解決方案計畫中，例如建立連線、執行查詢、關閉連線等。
使用程式碼範例: 在提示中提供包含狀態管理的程式碼範例，引導 LLM 生成正確的程式碼。

錯誤處理: 與外部 API 或資料庫互動的程式容易出現錯誤，例如網路錯誤、資料庫錯誤等。LPW 和 SLPW 需要能夠處理這些錯誤。這可以通過以下方式實現：

在解決方案計畫中加入錯誤處理步驟: 例如檢查 API 回應狀態碼、捕獲資料庫異常等。
使用斷言: 在程式碼中加入斷言，驗證 API 回應或資料庫查詢結果是否符合預期。

測試: 測試與外部 API 或資料庫互動的程式碼更加困難，因為需要模擬外部依賴的行為。這可以通過以下方式實現：

使用 Mock 物件: 使用 Mock 物件模擬外部 API 或資料庫的行為，以便在不實際呼叫外部依賴的情況下測試程式碼。
使用測試資料庫: 使用專門用於測試的資料庫，避免影響生產環境的資料。

總之，將 LPW 和 SLPW 應用於更複雜的程式設計任務需要對其進行擴展，使其能夠理解和處理外部依賴、狀態管理、錯誤處理和測試等問題。

如果解決方案計畫本身存在缺陷，LPW 和 SLPW 如何避免生成錯誤的程式碼？

LPW 和 SLPW 的設計理念中，已經考慮到解決方案計畫可能存在缺陷的情況，並通過以下機制來盡量避免生成錯誤的程式碼：

計畫驗證: LPW 和 SLPW 會使用 LLM 對生成的解決方案計畫進行驗證。在計畫驗證階段，LLM 會根據解決方案計畫模擬程式執行過程，並將模擬結果與預期結果進行比較。如果發現不一致，則會標記計畫存在缺陷，並嘗試進行修正。

多樣化取樣: SLPW 會生成多個解決方案計畫，並對每個計畫進行驗證。這樣可以降低單一計畫缺陷導致最終程式碼錯誤的風險。即使其中一個計畫存在缺陷，其他計畫也可能生成正確的程式碼。

程式碼測試: LPW 和 SLPW 會使用可見測試集對生成的程式碼進行測試。如果程式碼無法通過所有可見測試，則會被視為錯誤程式碼，並觸發程式碼修正流程。

迭代式修正: LPW 和 SLPW 採用迭代式修正策略。如果解決方案計畫或程式碼存在缺陷，則會根據錯誤資訊進行修正，並重新進行驗證和測試。這個過程會一直持續到生成正確的程式碼或達到最大迭代次數為止。

需要注意的是，儘管 LPW 和 SLPW 已經引入多種機制來避免生成錯誤的程式碼，但由於 LLM 本身的局限性以及解決方案計畫的複雜性，仍然無法完全保證生成的程式碼是完全正確的。因此，在實際應用中，仍然需要對 LPW 和 SLPW 生成的程式碼進行人工審查和測試，以確保其正確性和可靠性。

LPW 和 SLPW 的設計理念是否可以應用於其他領域，例如自然語言理解或機器翻譯？

LPW 和 SLPW 的設計理念是將複雜任務分解成多個步驟，並利用 LLM 的能力逐步解決問題。這種「規劃-執行-驗證-修正」的迭代式方法，其實也適用於其他需要邏輯推理和問題解決能力的領域，例如自然語言理解或機器翻譯。
以下是一些 LPW 和 SLPW 設計理念在其他領域的應用例子：

自然語言理解:

問答系統: 可以將問題分解成多個子問題，並利用 LLM 分別尋找答案，最後整合所有答案生成最終答案。
文本摘要: 可以利用 LLM 生成多個候選摘要，並根據一致性、流暢度等指標進行評估和選擇。
情感分析: 可以利用 LLM 識別文本中的關鍵詞和短語，並根據這些資訊推斷文本的情感傾向。

機器翻譯:

語義解析: 可以將源語言句子解析成語義表示，並利用 LLM 生成目標語言的語義表示，最後根據目標語言語法生成最終譯文。
多樣化翻譯: 可以利用 LLM 生成多個候選譯文，並根據流暢度、準確性等指標進行評估和選擇。
後編輯: 可以利用 LLM 對機器翻譯結果進行後編輯，修正語法錯誤、調整詞序等，提高譯文質量。
總之，LPW 和 SLPW 的設計理念強調了將複雜任務分解、利用 LLM 逐步解決問題，並通過驗證和修正機制提高結果的準確性。這種方法具有良好的通用性和擴展性，可以應用於自然語言理解、機器翻譯等多個領域，為解決複雜問題提供新的思路和方法。