這項由斯坦福大學(xué)Anjiang Wei領(lǐng)導(dǎo)，聯(lián)合伊利諾伊大學(xué)香檳分校、MIT、英特爾和Visa研究院共同完成的研究發(fā)表于2025年3月的arXiv預(yù)印本平臺（論文編號：arXiv:2503.23145v1），想要深入了解的讀者可以通過該編號在arXiv網(wǎng)站上查閱完整論文。

當(dāng)你第一次看到一個復(fù)雜的魔方，沒有任何說明書，只能觀察別人操作幾次，然后就要自己復(fù)原出同樣的圖案，這會是什么感覺？這正是計算機科學(xué)家們想要人工智能掌握的一種能力——從少量的輸入輸出例子中，推理出背后的程序邏輯，這個過程被稱為"歸納式程序合成"。

歸納推理是人類智能的核心特征之一，就像我們能夠從幾個例子中識別出規(guī)律，然后將這種規(guī)律應(yīng)用到新的情況中。比如，當(dāng)孩子看到幾組數(shù)字配對（2對應(yīng)4，3對應(yīng)9，4對應(yīng)16）后，很快就能推斷出這是平方關(guān)系，并正確回答5對應(yīng)什么?，F(xiàn)在，研究人員希望大型語言模型也能具備這種能力，不依賴自然語言描述，僅僅通過觀察程序的輸入輸出行為就能重構(gòu)出程序本身。

傳統(tǒng)的人工智能編程任務(wù)通常依賴自然語言描述，比如"寫一個函數(shù)計算兩個數(shù)的最大公約數(shù)"。但在現(xiàn)實世界中，程序員經(jīng)常面臨的挑戰(zhàn)更像是逆向工程：給你一個沒有源代碼的程序（比如一個二進(jìn)制可執(zhí)行文件），你需要通過運行它、觀察它的行為來理解它的工作原理，然后重新實現(xiàn)一個功能相同的程序。這種情況在軟件維護(hù)、安全分析和系統(tǒng)兼容性開發(fā)中非常常見。

以往的評估方法就像給學(xué)生出題時只提供標(biāo)準(zhǔn)答案，然后看學(xué)生能否一次性猜對。具體來說，研究人員會給模型10個固定的輸入輸出例子，然后要求模型寫出一個程序，最后用一些預(yù)設(shè)的測試用例檢驗程序是否正確。這種方法存在幾個明顯的問題：首先，僅僅10個例子往往不足以完全描述一個復(fù)雜程序的行為，就像僅憑幾個數(shù)據(jù)點很難準(zhǔn)確描繪一條復(fù)雜曲線；其次，如果模型的第一次嘗試失敗了，它沒有機會獲得反饋并改進(jìn)，這與真實的程序開發(fā)過程相去甚遠(yuǎn)；最后，現(xiàn)有的測試基準(zhǔn)大多局限于特定領(lǐng)域，比如字符串處理或SQL查詢，而不是通用的編程任務(wù)。

為了解決這些問題，研究團隊創(chuàng)建了一個名為CodeARC（代碼抽象和推理挑戰(zhàn)）的新評估框架。這個框架的設(shè)計理念更接近真實世界的逆向工程場景：AI模型可以像偵探一樣主動"詢問"目標(biāo)程序，通過輸入新的測試用例來觀察程序的反應(yīng)，然后基于這些觀察結(jié)果不斷改進(jìn)自己的理解和實現(xiàn)。

CodeARC的工作流程可以比作一個優(yōu)秀的廚師學(xué)習(xí)新菜譜的過程。廚師首先品嘗幾口成品菜肴（初始的輸入輸出例子），然后可以主動嘗試不同的食材搭配（查詢新的輸入輸出），觀察味道的變化。當(dāng)廚師認(rèn)為自己理解了配方后，就做出一道菜讓專家品嘗（提交程序給測試系統(tǒng)）。如果專家發(fā)現(xiàn)味道不對，會指出具體哪里有問題（提供反例），廚師就可以據(jù)此調(diào)整配方并重新嘗試。

在這個框架中，AI模型扮演的角色就像是那位學(xué)習(xí)的廚師。它首先觀察一些基本的輸入輸出例子，然后可以主動生成新的測試輸入來查詢目標(biāo)函數(shù)的行為。當(dāng)模型認(rèn)為自己理解了函數(shù)邏輯后，它會編寫一個候選程序。系統(tǒng)會使用一個"差分測試預(yù)言機"來檢驗這個程序是否正確。這個預(yù)言機就像是嚴(yán)格的美食評委，它會自動生成各種測試用例，比較候選程序和真實函數(shù)的輸出。如果發(fā)現(xiàn)不一致，它會提供具體的反例，讓模型知道在什么情況下自己的程序出錯了。

差分測試預(yù)言機的工作原理頗為巧妙。它不是簡單地用固定的測試用例集合，而是根據(jù)候選程序的具體實現(xiàn)動態(tài)生成測試用例。這就像一個聰明的老師，不會給所有學(xué)生出同樣的題目，而是根據(jù)每個學(xué)生的答案特點設(shè)計針對性的問題來檢驗他們的理解。比如，如果一個學(xué)生的數(shù)學(xué)公式在正數(shù)情況下是對的，老師就會特意測試負(fù)數(shù)情況；如果程序在處理普通列表時正確，測試工具就會嘗試空列表、重復(fù)元素或特殊數(shù)據(jù)類型。

為了構(gòu)建一個全面的評估基準(zhǔn)，研究團隊從三個知名的編程競賽和練習(xí)平臺收集了1114個Python函數(shù)：HumanEval（78個函數(shù)）、MBPP（131個函數(shù)）和APPS（905個函數(shù)）。這些函數(shù)涵蓋了從簡單的數(shù)學(xué)計算到復(fù)雜的算法問題，代碼長度從2行到74行不等，平均約9.5行。重要的是，研究團隊只保留了函數(shù)的實現(xiàn)代碼，完全去除了所有的自然語言描述，確保模型必須純粹依靠輸入輸出行為來推理程序邏輯。

特別值得注意的是，研究團隊創(chuàng)建了兩個版本的基準(zhǔn)測試。在"注釋版本"中，函數(shù)保持原有的描述性名稱（如`is_palindrome`），這些名稱可能給模型提供關(guān)于函數(shù)功能的提示。在"匿名版本"中，所有函數(shù)都被重命名為通用的標(biāo)識符`solution`，這樣就完全消除了名稱提示，更純粹地測試模型的歸納推理能力。這種設(shè)計讓研究人員能夠量化函數(shù)名稱對模型性能的影響。

研究團隊對18個不同的大型語言模型進(jìn)行了全面評估，包括開源模型（如LLaMA系列、Qwen系列）和閉源模型（如GPT-4、Claude等）。評估設(shè)置相當(dāng)嚴(yán)格：每個模型最多只能觀察30個輸入輸出例子（包括最初的10個），最多只能調(diào)用2次測試預(yù)言機來檢驗自己的程序。這個限制模擬了現(xiàn)實場景中的資源約束，迫使模型必須高效地利用有限的查詢機會。

實驗結(jié)果揭示了這項任務(wù)的挑戰(zhàn)性。即使是表現(xiàn)最好的模型OpenAI的o3-mini，在匿名版本上也只達(dá)到了52.7%的成功率，在注釋版本上達(dá)到59.5%。這意味著即使是最先進(jìn)的AI系統(tǒng)，也有將近一半的情況無法正確推理出程序邏輯。更令人驚訝的是，專門針對推理任務(wù)優(yōu)化的模型（如o3-mini、o1-mini、DeepSeek-R1）明顯優(yōu)于傳統(tǒng)的語言模型，這表明歸納程序合成確實需要特殊的推理能力。

模型規(guī)模對性能的影響也很明顯。在同一系列的模型中，參數(shù)量更大的版本通常表現(xiàn)更好，這符合"涌現(xiàn)能力"的觀察——某些復(fù)雜能力只有在模型達(dá)到一定規(guī)模后才會顯現(xiàn)。但有趣的是，這種規(guī)模效應(yīng)在不同模型系列中表現(xiàn)不一致，一些針對多模態(tài)任務(wù)優(yōu)化的大模型在純文本的編程任務(wù)上反而表現(xiàn)平平。

匿名化處理對所有模型都造成了性能下降，但下降幅度相對溫和（通常在5-10個百分點之間）。這個結(jié)果有兩重含義：一方面，函數(shù)名確實提供了有用的信息，幫助模型更快理解程序的意圖；另一方面，性能下降不太嚴(yán)重，說明優(yōu)秀的模型確實具備了一定的純歸納推理能力，不完全依賴語義提示。

更深入的分析揭示了現(xiàn)有評估方法的一個關(guān)鍵缺陷。研究人員發(fā)現(xiàn)，在最強的o3-mini模型生成的程序中，有67.6%能夠通過最初的10個輸入輸出例子，但只有38.9%能夠通過更嚴(yán)格的差分測試。這28.7%的差距清楚地表明，僅僅10個例子往往不足以唯一確定一個程序的完整行為。就像數(shù)學(xué)中的插值問題：給定幾個點，可能有無數(shù)條不同的曲線都能通過這些點，但只有一條是我們真正想要的。

這個發(fā)現(xiàn)為CodeARC的交互式評估協(xié)議提供了強有力的支持。通過允許模型主動查詢更多例子并獲得反饋，系統(tǒng)能夠更準(zhǔn)確地評估模型的真實能力。傳統(tǒng)的靜態(tài)評估方法可能會高估模型的性能，因為它們無法檢測到那些在有限例子上看起來正確但實際邏輯錯誤的程序。

為了進(jìn)一步驗證交互式元素的價值，研究團隊進(jìn)行了兩個關(guān)鍵的消融實驗。第一個實驗測試了不同數(shù)量的輸入輸出例子對性能的影響。結(jié)果顯示，當(dāng)可觀察的例子數(shù)量從10個增加到20個再到30個時，模型的成功率持續(xù)提升。這證明了更多的觀察數(shù)據(jù)確實有助于模型更準(zhǔn)確地理解目標(biāo)函數(shù)。

第二個實驗測試了不同數(shù)量的測試預(yù)言機調(diào)用對性能的影響。研究人員比較了允許1次、2次和3次測試的情況，發(fā)現(xiàn)每增加一次測試機會，模型的成功率都會顯著提升。這個結(jié)果特別重要，因為它證明了反饋和迭代改進(jìn)在程序合成中的關(guān)鍵作用。真實的編程工作很少是一次性成功的，而是一個不斷測試、調(diào)試和改進(jìn)的迭代過程。

論文中的一個案例研究生動地展示了這種交互式過程的價值。在這個例子中，模型需要判斷一個列表中的元素是否都是唯一的（沒有重復(fù)）。模型首先通過額外的查詢測試了一些邊界情況，比如包含不同數(shù)據(jù)類型的列表。然后，它實現(xiàn)了一個基于逐對比較的算法。然而，當(dāng)測試系統(tǒng)提供一個包含不可哈希元素（如列表）的反例時，模型的程序崩潰了，而真實函數(shù)能夠正確拋出類型錯誤。

面對這個反饋，模型展現(xiàn)了真正的學(xué)習(xí)能力。它意識到問題出在數(shù)據(jù)類型處理上，然后重新思考解決方案。在第二次嘗試中，模型采用了基于集合的方法（`len(lst) == len(set(lst))`），這種方法在遇到不可哈希元素時會自然地拋出類型錯誤，與目標(biāo)函數(shù)的行為完全一致。這個過程展示了AI模型如何通過反饋進(jìn)行自我糾正和改進(jìn)。

為了提升模型在這項任務(wù)上的性能，研究團隊還探索了微調(diào)技術(shù)。他們采用了一種創(chuàng)新的"知識蒸餾"方法：首先讓一個強大的教師模型（GPT-4o）在知道正確答案的情況下演示解題過程，包括如何查詢有用的測試用例、如何分析結(jié)果、如何編寫程序等。然后，讓學(xué)生模型（LLaMA-3.1-8B-Instruct）學(xué)習(xí)這些演示，但在實際測試時不給它正確答案。

這種微調(diào)方法在注釋版本上取得了31%的相對性能提升，在匿名版本上也有9.5%的提升。這個結(jié)果表明，通過學(xué)習(xí)高質(zhì)量的推理過程，較小的模型也能在一定程度上掌握歸納程序合成的技能。但是，提升的幅度仍然相對有限，說明這項任務(wù)的核心難點不僅僅是缺乏訓(xùn)練數(shù)據(jù)，而是需要深層的推理能力。

研究團隊還對比了兩種不同的差分測試工具：PYNGUIN和MOKAV。這兩個工具采用不同的策略生成測試用例，但都能有效地發(fā)現(xiàn)候選程序和目標(biāo)函數(shù)之間的差異。使用多個測試工具的設(shè)計增強了評估的魯棒性，減少了單一工具可能存在的盲點。

從技術(shù)角度來看，CodeARC的設(shè)計解決了程序等價性檢查這個根本性難題。理論上，判斷兩個程序是否完全等價是一個不可決定的問題，即不存在算法能夠在所有情況下給出正確答案。但是，差分測試提供了一個實用的近似解決方案：雖然無法保證100%的準(zhǔn)確性，但可以通過大量隨機測試用例來發(fā)現(xiàn)絕大多數(shù)的差異。這種方法在軟件測試領(lǐng)域已經(jīng)得到廣泛應(yīng)用，被證明是發(fā)現(xiàn)程序錯誤的有效手段。

這項研究的意義遠(yuǎn)超出了學(xué)術(shù)界的興趣。歸納程序合成能力在多個現(xiàn)實應(yīng)用中都有重要價值。在軟件維護(hù)領(lǐng)域，當(dāng)開發(fā)人員需要理解沒有文檔的遺留代碼時，這種能力可以幫助快速重構(gòu)或移植系統(tǒng)。在網(wǎng)絡(luò)安全領(lǐng)域，分析惡意軟件的行為模式需要從二進(jìn)制代碼中推斷程序邏輯。在自動化編程工具開發(fā)中，讓AI助手能夠從用戶的示例中學(xué)習(xí)編程意圖，將使編程變得更加直觀和高效。

此外，這種能力還與更廣泛的人工智能發(fā)展目標(biāo)相關(guān)。歸納推理是人類智能的核心特征之一，也是實現(xiàn)真正通用人工智能的關(guān)鍵能力。如果AI系統(tǒng)能夠像人類一樣從少量例子中抽象出規(guī)律，并將這些規(guī)律應(yīng)用到新的情況中，那么它們在很多領(lǐng)域的表現(xiàn)都會得到顯著提升。

研究結(jié)果也揭示了當(dāng)前大型語言模型的一些局限性。盡管這些模型在自然語言理解和生成方面表現(xiàn)出色，但在需要嚴(yán)格邏輯推理的任務(wù)上仍有很大改進(jìn)空間。特別是，模型往往難以處理需要精確邊界條件處理的程序邏輯，這在安全關(guān)鍵應(yīng)用中是一個重要問題。

CodeARC基準(zhǔn)測試的發(fā)布為研究社區(qū)提供了一個寶貴的工具。與以往的靜態(tài)評估基準(zhǔn)不同，這個框架鼓勵開發(fā)更智能的交互式AI系統(tǒng)。研究人員可以使用這個基準(zhǔn)來測試各種新的方法，比如強化學(xué)習(xí)、神經(jīng)符號推理、程序合成技術(shù)等?；鶞?zhǔn)的開源性質(zhì)也確保了研究結(jié)果的可重現(xiàn)性和可比較性。

從更長遠(yuǎn)的角度來看，這項研究可能會推動編程教育和工具的變革。如果AI系統(tǒng)能夠真正理解程序邏輯而不僅僅是模仿表面模式，那么它們就能成為更有效的編程助手。程序員可以通過提供例子而不是詳細(xì)規(guī)范來與AI協(xié)作，這將大大降低編程的門檻，讓更多人能夠參與軟件開發(fā)。

當(dāng)然，這項研究也面臨一些挑戰(zhàn)和限制。首先，評估框架雖然比以往更接近現(xiàn)實，但仍然是在相對簡化的環(huán)境中進(jìn)行的。真實的程序往往涉及復(fù)雜的狀態(tài)管理、并發(fā)處理、錯誤處理等問題，這些在當(dāng)前的基準(zhǔn)中還沒有完全體現(xiàn)。其次，目前的測試主要集中在相對較短的Python函數(shù)上，更大規(guī)模的程序合成仍然是一個未解決的挑戰(zhàn)。

另一個重要的考慮是計算資源的限制。差分測試雖然有效，但需要大量的測試用例生成和執(zhí)行，這在計算成本上比簡單的靜態(tài)測試要高得多。在實際應(yīng)用中，需要在測試覆蓋率和計算效率之間找到合適的平衡點。

隱私和安全也是需要考慮的因素。在某些情況下，目標(biāo)程序可能包含敏感信息或商業(yè)秘密，不能隨意暴露其輸入輸出行為。如何在保護(hù)隱私的同時進(jìn)行有效的程序分析，是一個值得進(jìn)一步研究的問題。

這項研究的方法論也具有啟發(fā)性，它展示了如何將復(fù)雜的AI評估問題轉(zhuǎn)化為更貼近現(xiàn)實的交互式任務(wù)。這種思路可能適用于其他需要多步推理和迭代改進(jìn)的AI應(yīng)用領(lǐng)域。比如，在科學(xué)假設(shè)生成、創(chuàng)意寫作、問題解決等任務(wù)中，都可以借鑒這種允許中間反饋和迭代改進(jìn)的評估框架。

研究團隊的跨機構(gòu)合作也值得注意。來自斯坦福大學(xué)、伊利諾伊大學(xué)香檳分校、MIT等學(xué)術(shù)機構(gòu)以及英特爾、Visa研究院等工業(yè)界的研究人員共同參與，體現(xiàn)了產(chǎn)學(xué)研結(jié)合的重要性。這種合作模式有助于確保研究既有理論深度又有實際應(yīng)用價值。

說到底，CodeARC不僅僅是一個新的基準(zhǔn)測試，更是對AI系統(tǒng)能力評估方式的一次重要探索。它提醒我們，真正的智能不僅在于記憶和模仿，更在于從有限的信息中抽象出規(guī)律、在面對挑戰(zhàn)時能夠自我調(diào)整和改進(jìn)。通過創(chuàng)建更貼近現(xiàn)實的評估環(huán)境，研究人員正在推動AI系統(tǒng)向更高層次的智能邁進(jìn)。

這項研究開啟了一個新的研究方向，但也留下了許多待解決的問題。如何讓AI系統(tǒng)更好地處理復(fù)雜的程序邏輯？如何在保持準(zhǔn)確性的同時提高推理效率？如何將這種能力擴展到更大規(guī)模的軟件系統(tǒng)？這些問題的答案將在未來的研究中逐步揭曉。有興趣的讀者可以通過arXiv編號2503.23145v1查閱這篇論文的完整內(nèi)容，深入了解技術(shù)細(xì)節(jié)和實驗結(jié)果。

Q&A

Q1：什么是歸納式程序合成？它和普通的AI編程有什么區(qū)別？ A：歸納式程序合成就是讓AI僅通過觀察程序的輸入輸出例子來推理出程序邏輯，就像看魔術(shù)表演后要猜出魔術(shù)的秘密一樣。普通AI編程有自然語言描述告訴它要做什么，但歸納式程序合成完全沒有文字說明，只能靠"察言觀色"來理解程序要干什么。

Q2：CodeARC的交互式測試比傳統(tǒng)方法好在哪里？ A：傳統(tǒng)方法像考試時只給標(biāo)準(zhǔn)答案讓學(xué)生猜，猜錯了也不知道錯在哪里。CodeARC讓AI可以主動"提問"（查詢更多輸入輸出），還會在答錯時給出具體的反例，讓AI知道哪里出了問題。這更像真實的學(xué)習(xí)過程，可以通過反饋不斷改進(jìn)。

Q3：目前最好的AI模型在這個任務(wù)上表現(xiàn)如何？實用嗎？ A：即使是最強的OpenAI o3-mini模型，成功率也只有52.7%，還不到及格線。這說明讓AI真正理解程序邏輯仍然是個巨大挑戰(zhàn)。目前還不夠?qū)嵱茫@個基準(zhǔn)測試為未來的改進(jìn)指明了方向，也讓我們更清楚地看到了AI推理能力的真實水平。