LLM會寫程式碼≠推理+規劃！AAAI主席揭密：程式碼資料品質太高｜LeCun力贊

自從ChatGPT發布後，各種基於大模型的產品也快速融入了普通人的生活中，但即便非AI從業者在使用過幾次後也可以發現，大模型經常會胡編亂造，產生錯誤的事實。

不過對於程式設計師來說，把GPT-4等大模型當作「程式碼輔助生成工具」來用的效果明顯比「事實檢索工具」要好用很多，因為程式碼產生往往會涉及到複雜的邏輯分析等，所以也有人將這種推理（廣義規劃）能力歸因於大型語言模型（LLM）的湧現。

學術界也一直在就「LLM能否推理」這個問題爭論不休。

最近，電腦科學家、亞利桑那州立大學教授Subbarao Kambhampati（Rao）以「LLM真的能推理和規劃嗎？」（Can LLMs Really Reason & Plan?）為題，全面總結了語言模型在推理和規劃方面的研究成果，其中也談到了LLM的程式碼產生與推理能力的關聯。

影片連結：https://www.youtube.com/watch?v=uTXXYi75QCU

PPT連結：https://www.dropbox.com/scl/fi/g3qm2zevcfkp73wik2bz2/SCAI-AI-Day-talk-Final-as-given.pdf

一句話總結：LLM的程式碼產生品質比英文（自然語言）產生品質更高，只能說明「在GitHub上進行近似檢索」要比「通用Web上檢索」更容易，而不能反映出任何潛在的推理能力。

造成這種差異的原因主要有兩個：

1. 用於LLM訓練的程式碼資料品質比文字品質更高

2. 形式語言中「語法和語意的距離」比高度靈活的自然語言低

圖靈獎得主Yann LeCun也表示贊同：自回歸LLM對編碼非常有幫助，即便LLM真的不具備規劃能力。

Rao教授是AAAI的主席，IJCAI的理事，以及Partnership on AI的創始董事會成員；他的主要研究方向為：

1. 面向人類的AI系統（Human-Aware AI Systems）：可解釋的人工智慧互動。人工智慧系統的規劃與決策。人機組隊。主動決策支援。可學習的規劃模型和Model Lite規劃。可解釋的行為和解釋。人為因素評估。

2. 自動規劃（Automated Planning，AI）：度量、時間、部分可訪問和隨機世界中的規劃合成、啟發式方法。規劃的多目標最佳化。用富有表現力的動作推理。行程安排。加速學習以幫助規劃者。約束滿足與運籌學技術。規劃在自動化製造和空間自主方面的應用。

3. 社群媒體分析與資訊整合（Social Media Analysis & Information Integration）：社群媒體平台上的人類行為分析。資訊整合中用於查詢最佳化和執行的自適應技術。源發現和源元資料學習。

程式碼生成≠推理+規劃

已故的電腦科學家Drew McDermott曾經說過，規劃只是一種語言的自動編程，每個原語都對應於可執行的操作（planning is just automatic programming on a language with primitives corresponding to executable actions）。

也就是說，廣義的規劃可以寫成程序，如果GPT-4或其他大模型可以正確地產生程式碼，那也證明了LLM具有規劃能力。

比如說去年5月，英偉達、加州理工等研究團隊合作開發出了Voyager（旅行者）智能體，也是Minecraft（《我的世界》遊戲）中首個基於LLM的具身、終身學習智能體（embodied lifelong learning agent），可以持續探索世界，獲得各種技能，並在沒有人為幹預的情況下進行新的發現。

論文連結：https://arxiv.org/abs/2305.16291

Voyager的核心思想是讓LLM輸出程式碼來執行任務，並且在模擬器中運行，包含三個關鍵元件：最大化探索（exploration）的自動課程（curriculum ）；用於儲存和擷取複雜行為的可執行程式碼的不斷增長的技能庫；新的迭代提示機制，包含環境回饋、執行錯誤和自我驗證以改進程式。

Voyager透過黑盒查詢與GPT-4進行交互，因此無需對模型參數進行微調。

雖然有其他類似Voyager的工作可以利用LLM以程式碼產生的方式完成規劃，但這也並不能證明LLM具有規劃能力。

從原理上來說，LLM本質上是近似檢索器（approximate retrieval），能否成功規劃取決於訓練資料的品質。

在自然語言生成上，LLM需要吞噬大量數據，其中許多數據在事實基礎或價值體系上都存在很大分歧，例如地平論者和疫苗反對者也有自己的一套理論，可以寫出令人信服的文章。

而在程式碼生成上，訓練資料主要來自GitHub上的開源程式碼，其中大部分都是「有效資料」，而且軟體工程師的價值體系對程式碼的品質影響微乎其微，這也可以解釋為什麼程式碼產生的品質要比文本補全的品質更高。

儘管如此，但程式碼產生的本質上仍然是近似檢索，其正確性無法保證，所以在使用GitHub Copilot等輔助工具時，經常可以看到有人抱怨花了太長時間在生成程式碼的調試上，生成的程式碼往往看似運作良好，但背地裡蘊藏bug

程式碼看起來能正常運作的部分原因可以歸結為兩個原因：

1. 系統中存在一個輔助工具（增量解釋器），可以標記處明顯的執行異常，可以讓人類程式設計師在調試過程中註意到；

2. 語法上正確的程式碼段在語意上也可能是正確的，雖然無法完全保證，但語法正確是可執行的先決條件（對於自然語言也是如此）。

語言模型的自我驗證

在少數情況下，例如上面提到的Voyager模型，其開發者聲稱：生成的程式碼品質已經足夠好，可以直接在世界上運行，但仔細閱讀就會發現，這種效果主要依賴於世界對規劃模糊性的寬容。

某些論文中也會採用「LLM自我驗證」（self-verify，self-critique自我批評）的方式，即在運行程式碼之前在目標場景中嘗試執行驗證一次，但同樣，沒有理由相信LLM具有自我驗證的能力。

下面兩篇論文就對模型的驗證能力產生質疑。

論文連結：https://arxiv.org/abs/2310.12397

這篇論文系統性地研究LLMs的迭代提示的有效性在圖著色（Graph Coloring）的背景下（一個典型的NP完全推理問題），涉及到命題可滿足性以及實際問題，如調度和分配；文中提出了一個原則性的實證研究GPT4在解決圖著色實例或驗證候選著色的正確性的表現。

在迭代模式中，研究人員要求模型來驗證自己的答案，並用外部正確的推理機來驗證所提出的解決方案。

結果發現：

1. LLMs在解決圖著色實例方面很差；

2. 在驗證解決方案方面並沒有更好的表現-因此在迭代模式下，LLMs批評LLM產生的解決方案無效；

3. 批評的正確性和內容（LLMs本身和外部求解器）似乎在很大程度上與迭代提示的表現無關。

第二篇論文研究了大模型能否透過自我批判來改善規劃。

論文連結：https://arxiv.org/abs/2310.08118

這篇論文的研究結果表明，自我批評似乎會降低規劃生成性能，在使用GPT-4的情況下，無論是外部驗證器還是自我驗證器都在該系統中產生了非常多的誤報，損害了系統的可靠性。

且回饋訊號為二元（正確、錯誤）和詳細資訊對規劃產生的影響都很小，即LLM在自我批評、迭代規劃任務框架下的有效性值得懷疑。