1.結論寫在前面。
討論了推理任務作為評估 LLM 程式設計任務的替代方法的必要性。 介紹了支援多種推理任務的 CodeMind 框架，並將 CodeMind 用於大規模基礎理論研究，以評估最先進的 LLM 進行推理。 結果表明，一般來說，LLM知道結構是如何工作的，並且能夠推理程式規範，並跟蹤輸入到輸出到執行的演變。 但是，隨著它們變得越來越複雜，即控制流或資料流變得更加複雜，包含非基元型別並呼叫 API，它們的功能受到限制。 還有人指出，規範性推理對於從給定的程式規範生成至關重要，但這並不意味著模型也可以通過推理來執行。
二、**的簡要介紹。
2.1 ** 背景。
大型模型 （LLM） 在指令（指令調整）或由鏈結或思維樹（COT 或 TOT）和上下文學習提示時表現出卓越的程式設計技能。 然而，一些研究表明，LLM很難概括這種異常能力，特別是當資料集變得更加複雜時，或者當任務需要理解而不是自然語言時。 這主要是因為 LLM 被訓練為將合成與自然語言規範聯絡起來，即推理如何組合類似於他們看到的示例的結構，以滿足所解釋規範的要求。
為了說明推理任務如何評估 LLM，圖 1-A 顯示了 GPT-35.根據自然語言規範進行合成。 突出顯示與規格對應的結構，顏色匹配。 由於自然語言的歧義，這將返回列表中的最小數字，而不是索引中等於最小數字值的數字。 因此，對於給定的輸入 [2,5,4,3]，* 返回 2 而不是 4，斷言失敗。
評估 LLM 歸納推理的一種方法是包括特定的預期程式行為，並檢查生成的行為是否可以重現。 這需要一定程度的推理，稱之為規格推理。圖 1-b 顯示了新規範和相應的版本**。 給定指定的輸入輸出對，執行 ** 會導致測試通過，這表示 GPT-35. 能夠理解給定的規範並生成正確的規範。
在提示中包含測試資料是一種已知的做法，可以提高模型在程式設計任務中的效能。 然而，它只是推理的乙個弱指標，因為它仍然涉及與自然語言的關聯。 更深層次的推理是對給定輸入的執行輸出進行推理，這稱為執行推理 （ER）。 這項任務對 LLM 提出了更大的挑戰，要求他們在沒有任何自然語言交叉引用的情況下進行推理**。 圖 1-C 顯示 GPT-35 ER任務的COT推理。 儘管模型可以產生預期的輸出（如果通過測試驗證為正確），但它無法正確地推斷輸出是用相同的輸入執行的。
2.程式的 2 **。
為了實現推理評估的自動化，該文提出了CodeMind。 CodeMind 目前提供三種型別的歸納推理任務：獨立執行推理 （IER） 和依賴執行推理 （DER），用於評估 LLM 是否可以推理給定輸入在任何時候如何演變為輸出，或者它正確合成的內容。 規範推理 （SR） 評估 LLM 實現指定行為的程度。
2.2.1 codemind
程式規範定義了乙個函式 s：si so，其中 si 是程式所有可能輸入的集合，因此是一組相應的輸出。 根據實現合成的**，它通常是乙個函式 c：ci co。 如果程式滿足以下所有條件，則在規範方面定義程式是正確的：
ci ⊆ si，co ⊆ so，∀i ∈ ci，c(i)= s(i)
這要求模型推理輸入如何通過實現（執行推理）演變為給定的輸出，並實現這樣才能為給定的輸入（規範推理）生成正確的輸出。
2.2.1.1 執行推理。
考慮到上述形式化方法，執行推理任務的兩個定義如下。
定義 1：獨立執行推理 （IER）。 給定乙個程式 c：ci co 和一組輸入 i = if o = c（i），其中 o = l（i） 是 l** 的輸出，那麼 llm l 可以正確地推斷 ** 被執行。 請注意，在此任務中，不會處理規範，因此 LLM 可以評估 LLM 的推理，以用於存在真 i，o 對的任意推理。
IER 評估 LLM 對任意 ** 的一般歸納推理，這需要構造、算術和邏輯操作以及控制流的知識。 然而，即使對於人類開發人員來說，推理他們正在開發的內容也比武斷更容易。 此外，作為自洽性的衡量標準，LLM應該能夠推理出它們可以被正確合成的內容。 這需要以下推理任務。
定義 2：依賴於執行推理 （DER）。 給定乙個規範 s：si so，llm l 生成程式 c：ci co，並且一組輸入 i = if o= c（i），其中 o= l（i） 是 l** 的輸出，那麼 llm l 可以正確地推斷 ** 被執行。 這裡的假設是，當 llm l 生成乙個通過測試 i，o 的 **c 時，它應該能夠正確地 **o。
2.2.1.2 規範推理。
除了歸納執行推理外，模型還應該理解規範以合成正確的**。 規範推理任務的正式定義如下。
定義3：規範性推理 （SR）：給定乙個規範 s：si so，任意 i，o 在提示中用自然語言規範指定，其中 i si，o so，s（i）= o，llm l 生成程式 c：ci co，如果 c（i） = s（i），那麼 llm 可以正確地推理範數。 換句話說，當它們在提示中明確指定時，llm l 應該能夠通過 i，o 的測試。
2.2.1.3 評估 ** 推理。
模型在給定給定模型上的推理效能是使用正確推理分數 （CRS） 來衡量的，如果模型可以正確推理，則為 1，否則為 0。 **還引入了正確推理率 （CRR） 指標，這是乙個集體指標，用於衡量給定 LLM 對基準測試中多個程式進行推理的程度。 在基準 P 中計算 M 裝配體的 CRR：
2.3 ** 效果。
利用Codemind，進行了大規模的基礎理論研究，以評估LLM的推理能力。 選擇了九個模型，包括通用 LLM 和專用 LLM，並提示它們對用 J**A 和 Python 編寫的 5395 個程式執行 IER、DER 和 SR 任務。 這些程式來自五個程式設計基準，即 Humaneval、MBPP、Cruxeval、CodeNet 和 Atar。 **觀察：
1）LLM對**結構有很好的把握，這可能是由於與自然語言規範中的概念一致。訓練後的模型可以逐句解釋，並且通常遵循程式的執行。 然而，LLM的推理能力僅限於簡單的程式。 此外，儘管 GPT-3像 5 和 magiccoder 這樣的模型可以正確解釋 ** 的作用，但在跟蹤資料流和正確推理執行輸出時可能會失敗。 在綜合中實現與 GPT 模型相當的有效性的開源 LLM 在推理方面與它們有很大不同。
2）即使具有欺騙性，LLM也可以對規範中的測試資料進行推理，並將其引入合成推理過程。然而，他們的推理受到其固有侷限性的限制。 當推斷它們可以正確合成時，它們可以實現更高的效能。
3）在包含複雜程式的資料集上，基於綜合的排名模型（生成通過所有測試的模型）與推理效能之間的相關性可以忽略不計或不存在。這需要 codemind 任務和指標來補充 LLM** 評估。
4）巢狀結構、複雜的條件謂詞和迴圈條件、非平凡的算術和邏輯運算子以及API呼叫可以極大地挑戰LLM推理。
2.3.1 實驗設定。
*該研究包括來自 5 個程式設計資料集的 9 個 LLM 和 5395 個 J**A 和 Python 程式。 **法學碩士和課程選擇的細節如下所述。
主題：法學碩士:** 選擇了 9 個預訓練或指令優化模型，包括通用和專用 LLM。 選擇受到計算資源的限制，因此選擇引數少於 20b 且效能優於其他模型的模型。 **主題 LLM 是 GPT-4、GPT-35. Llama 2 （13B）， Mistral， Codellama （13B， 指令優化）， Starcoder （155b）、wizardcoder（15b，指令優化）、magiccoder（7b）、deepseekcoder（67b)。*遵循最佳實踐並為每個模型自定義提示模板（所有提示均公開提供，以供進一步調查）。 除了 GPT 模型之外，將溫度設定為零以確保結果的可重複性。 它對使用者開放，因此他們可以使用 CodeMind 來評估其他模型和溫度。
主題節目：選擇主題程式的標準是測試資料的存在（輸入和相應的預期輸出）以及同一程式在多種程式語言中的實現（以研究其對推理的影響）。 在幾個現有的基準中，選擇了Humaneval、MBPP、CodeNet、ATAR和Cruxeval中的程式。 選擇該程式的 J**a 和 Python 版本，因為它們是更廣泛使用的程式語言。 Humaneval 和 MBPP 是眾所周知的基準測試。 CodeNet 和 ATAR 是翻譯基準。 Cruxeval 是乙個相對簡單的 Python 程式基準測試，由 Codellama （34b） 生成，用於評估 LLM 的輸入和輸出。
圖 2 顯示了程式複雜度分布，終止為圈複雜度 （CC） 和程式碼行數 （LOC）。 CC 測量程式控制流圖 （CFG） 中獨立執行的路徑數。 指標為 cc = e n + 2p 計算，其中 e 和 n 分別是 cfg 中的邊數和節點數，p 是類中方法數。 一般來說，cc 越高表示過程越複雜。 對於推理任務，模型應推理給定輸入應採用哪種執行路徑來輸出。 因此，獨立路徑的數量越多，模型隨機成功的可能性就越小。 CC 可能與程式中的行數有關，但更多的行不會導致更高的 CC。 例如，沒有條件或迴圈構造的 10 行程式只有乙個執行路徑，而具有兩個巢狀條件語句的 8 行程式有 3 或 4 個執行路徑，具體取決於條件謂詞。
2.3.對 IER 上的 2 個 LLM 的評估。
為了評估 LLM 在 IER 任務上的效能，在兩種設定中給出提示：直接答案和 COT。 對於直接答案，每個模型都會提示給定輸入的輸出。 在 COT 設定下，首先指示模型在執行每個語句後通過值的輸出逐步模擬執行。 然後要求模型輸出給定輸入。 在這兩種設定中，提示都包含乙個上下文示例，其目的有兩個：介紹 IER 任務和指示響應格式。
由於 IER 只需要任何和相應的實數 i，o 對，** 使用所有 5395 主題程式提示 LLM。 表 1 顯示了 COT 提示的實驗結果。 從這些結果可以看出：
GPT模型在IER任務中優於其他模型，與最好的開源模型存在較大差距，為3392% （GPT-4） 和 1556(gpt-3.5)。在開源模型中，Magiccoder 的平均優勢為 4%，ATAR 資料集除外83%。
在包含 J**A 和 Python 樣本的資料集上，所有模型的效能都有所下降（平均下降 291%，*ATAR 平均下降 233%)。這可能是因為 J**A 實現了比 Python 更嚴格的語法和型別系統，這使得執行推理更具挑戰性。
COT 提示（模型在輸出前用語言表示執行過程）將模型的 IER 效能提高了 524%。然而，即使有 COT 提示，（開源）模型的準確性仍然不理想，需要從根本上改變。
再往下看，該模型在codenet和**atar程式的IER（即推理執行）方面比MBPP、Humaneval和CruXeval面臨更多的挑戰。 乙個可能的原因是這些過程的複雜性，如圖 2 所示。 對模型效能的詳細分析（圖 3）顯示，迴圈複雜度 （CC） 和正確推理率 （CRR）（Spearman 秩相關係數 （ROC））之間存在很強的負相關關係，這證實了該模型在處理更複雜的 **iers 時更加困難。 同時，一些模型，即 Llama 2、Codellama、MagicCoder、StarCoder 和 WizardCoder，在 CruxEval 上的效能不如 Humaneval，後者在 LOC 和 CC 方面不那麼複雜。 這需要進一步改進，以了解除 CC 之外還有哪些因素會影響模型的 CRR 效能。
2.3.對 DER 的 3 個 LLM 的評估。
關鍵問題是模型的有效性，以正確推理它生成的正確程式。 此評估需要生成任務和推理任務的組合。 **評估 DER 的管道包括三個步驟：
1）遵循最佳實踐，提示主題LLM生成**;
2）根據現有測試執行合成程式;
3） 對於通過測試的程式，使用選定的測試輸入並使用 COT 樣式提示模型進行推理。請注意，為確保公平性，評論也已從生成的內容中刪除。
*不包括 cruxeval、codenet 和 atar 中的程式，因為這些資料集不是為生成而設計的，並且缺乏適當的程式規範。 此外，無法複製駱駝 2 的生成結果，駱駝 2 也被排除在 LLM 主題之外。 與IER實驗類似，溫度設定為零，以考慮結果的非確定性和可重複性。 由於此設計決策，合成結果可能與現有排行榜不同。
表2顯示了該實驗的結果。 GPT模型在DER任務中還是比開源模型好，和最好的開源模型有區別1797 （GPT-4） 和 1313(gpt-3.5）差距。與 IER 相比，GPT 模型和開源模型之間的差距有所縮小。 **還可以觀察到，除了 Codellama 在 Humaneval 上的表現外，該模型在 DER 任務上的平均 CRR 比 IER 高 684%。
在得出模型更勝任對被評估為正確合成的程式進行推理的結論之前，將本實驗中的程式與 IER 實驗中的程式進行了比較。 如果為 true，則較低的複雜性可能是 DER 任務上較高 CRR 的根本原因。 圖 4 顯示了 MBPP 和 Humaneval 中程式的 CC 分布，與主題 LLM 生成的程式相比。 可以看出，合成與這些資料集中的基本程式一樣複雜，甚至更複雜。 因此，確認模型可以更好地推斷它們正確合成的內容。 然而，LLM的生成和推理能力之間仍然存在很大的差距，尤其是對於開源模型。
由於生成和推理在 DER 中是統一的，因此首先計算基於每個資料集上合成行和推理行的模型排名的 Spearman 秩相關係數。 結果顯示，MBPP呈強正相關（ = 0.85），但對人類的相關性可以忽略不計（= 0.）。17)。這些結果傳達了乙個強烈的資訊：基於生成能力 （pass@k） 排名的 LLM 可能與同一級別的推理能力排名有很大不同。 這需要像 CodeMind 這樣的框架來改進 LLM 的其他方面**。
2.3.4 規範推理 （SR） 評估。
規範推理 （SR） 為生成 LLM 的過程提供了新的視角，特別是它們如何利用輸入輸出規範。 為了評估 LLM 的 SR 能力，系統會提示 LLM 在以下三個設定下生成：
1） 包含真實輸入和輸出的自然語言規範。在此設定中，將隨機選擇現有測試並將其新增到規範中。 僅使用此測試來驗證生成的。
2）不包含輸入和輸出的自然語言規範。刪除在先前設定中新增到規範中的測試，並重新提示 LLM 進行構建。 僅使用先前設定中的測試來驗證生成的測試。 直觀地說，如果包含測試資料來幫助生成 LLM，則將觀察到 LLM 效能的下降。
3） 包含誤導性輸入和輸出的自然語言規範。
* 在第一次設定中更改測試的預期輸出，並將其新增到規範中。 使用原始測試來驗證生成的。 此更改會將預期輸出更改為與規範不一致的值。 例如，如果預期輸出為 true，則突變會將其更改為 false。 同樣，如果預期輸出是正整數，它將變異為負數，差異很大。 直觀地說，由於偏離自然語言規範，誤導性的輸入和輸出會進一步降低 LLM 的效能。
僅在 MBPP 和 Humaneval 程式上執行此實驗。 **humaneval 中的提示也經過預處理，最初包含輸入和輸出樣本。 表 3 中的結果表明，在規範中加入測試資料可使 LLMs7 的生成效能得到平均改善36%。在規範中引入欺騙性測試（相對於合法測試）會對 LLM 的生成效能產生負面影響（平均下降 10%）。 然而，所有模型和程式的平均效能下降僅為 265%。無論如何，這些結果證明了LLM推理和利用規範中測試資料的能力。
2.3.4 對結果進行深入分析。
*對 IER 結果的進一步分析，評估 LLM 的一般推理能力。 在第一步中，你想知道 LLM 是否知道不同的結構是如何工作的。 如果你不理解每個結構的邏輯，你就無法推理執行。
為此，根據實現中使用的構造，每個 5395 程式都使用以下標記進行標記：for、while、if、try、switch、巢狀迴圈、巢狀 if 和 basic。標記為基本程式沒有特殊的 ** 結構。 接下來，按標籤對程式進行聚類，並計算每個聚類的LLM的CRR。 圖 5 顯示了對 5 個表現最好的 LLM 的分析結果。 可以看出，該模型對條件語句的處理比遞迴更好，但 try-catch 或 try-except 語句除外。 此外，當涉及到巢狀結構時，CRR 值會顯著下降。
迴圈特性的影響：鑑於該模型在遞迴構造方面最困難，因此在下一步中將重點放在帶有 for、while 和巢狀迴圈標籤的程式上。 假設是，這種鬥爭是由於週期的長度或決定週期的長度。 前者質疑的是，隨著迴圈時間的變長，模型是否更難跟蹤程式資料流。 後者質疑模型推理乙個塊應該重複多少次的能力，無論它有多長。 圖 6 繪製了 J**A 程式中每個週期長度的正確與錯誤情況的分布以及 CRR 值。 子圖標籤顯示週期長度和 CRR 之間的 ROC 係數。 可以觀察到週期長度與模型的CRR之間存在中度至強負相關，即隨著週期長度的增加，CRR降低。 通過手動調查 IER 的錯誤情況，還注意到 LLM 大多無法正確推理迴圈條件。 如果不知道迴圈條件和迭代次數，就不可能正確地推理執行。 此外，還發現一些情況，儘管模型可以推理迴圈條件和迭代次數，但它會丟失迴圈中的資料流，從而錯誤地輸出輸出。
在下面的 ** 程式碼段（來自 CodeNet （j**a） 的 P03059）中，迴圈條件取決於常量變數 （c） 和變數 （time），其值在迴圈內發生變化。
我是技術創作者 輸入：3 5 7，預期輸出：10int a， b， c = scnextint();int amount = 0, time = a;for(int i = 2; time <= c + 0.5; i++)println(amount);
在這個相對簡單的程式中，所有模型都失敗了。 參見 COT 分析，GPT-35 知道迴圈條件，可以推導出前兩次迭代中的所有變數值。 但是，它再次停留在迴圈中。 starcoder 無法正確地推理迴圈條件，並在 ** 塊上迭代了六次。 magiccoder cot 只解釋了 **（正確的解釋），並沒有傳達它如何推理變數。
gpt-3.5, predicted output:15
analysis: enters for loop and iterates from 2 onwards
until the value of time exceeds c + 0.5. in first
iteration, amount becomes 5 and time becomes 6. in
second iteration, amount becomes 10 and time becomes
9. in third iteration, amount becomes 15 and time
becomes 12. 12 is greater than 7+0.5, loop exits.
starcoder, predicted output:105
analysis: it enters a for loop and it iterates from 2
to 7 to check each integer i in this range. in each
iteration, the value of i is passed to variable time.
the condition is met when i is 2,3,4,5,6 and 7.
magiccoder, predicted output:15
enters for loop and iterates from 2 to infinity. inside
the loop, it adds the value of b to variable amount.
then it calculates new value of time by multiplying a
with current iteration i. the loop continues until time
is greater than c+0.5. after the loop finishes, print
the final value of amount as output, which is 15.
下面的 ** 程式碼段中的迴圈條件很簡單（來自 CodeNet （j**a） 的 P02994）。 因此，大多數模型對迭代次數進行了正確的推理。
input: 5 2, expected output: 18
int n = scanner.nextint();
int l = scanner.nextint();
list diff = new arraylist();
for(int i = 1; i < n+1; i++)
diff.add(value);
removek = diff.indexof(collections.min(diff)) 1;
println(n*l + n*(n+1)/2 - n - l+ removek -1));
儘管如此，一些 LLM 仍然難以在迴圈中正確執行推理**。 Codellama 可以正確地推理迴圈迭代的次數，但它無法計算 diff 陣列中的值，從而導致錯誤的輸出。 Magiccoder 還可以正確地推理迴圈長度，並且與前面的例子類似，它可以正確地解釋 ** 的作用。 但是，它不能正確輸出（輸出為 10），因此無法判斷它是否像解釋的那樣被理解。
if-else 屬性:** 的手動調查顯示，LLM 難以處理條件結構有兩個原因：（1） 對分支的混淆和 （2） 對條件謂詞的錯誤推理。 關於前者，據觀察，LLM有時難以識別條件語句。 例如，無論採用哪個分支，它們總是進入“if”和“else”分支來推理執行。 然而，這種情況很少發生，在大多數情況下，LLM 很難正確解析條件謂詞，採用錯誤的分支，並錯誤地輸出。
數學和邏輯運算子的影響：了解數學和邏輯運算子的工作原理對於推斷輸入通過執行演變為輸出至關重要。 前面分析的觀察結果也強調了它們對推理程式控制流的重要性。 **對失敗的 IER 案例的手動調查揭示了程式中算術和邏輯運算子的普遍性，前者佔主導地位。 LLM 比算術運算子（例如，+ 和 -）和比較運算子（例如，、 和 &）更難推理位運算子（例如，例如，&）。
以下程式碼片段來自 MBPP（任務 311），包含多個算術和邏輯運算子。
儘管無法輸出，但 Starcoder 正確地知道大多數操作員是如何工作的。 例如，它可以推斷 n 和 n+1 的按位與用於確定整數 n 是否為 2 的冪。 它還可以推理迴圈條件，以檢查 n 的最低有效位是否設定為 0。 但是，它似乎不理解 return 語句的含義（將最低有效位設定為 1），因此無法生成正確的輸出。
codellama, predicted output:24
analysis: in the given inputs n is 5 and l is 2. the
sequence of numbers from 1 to 5 is [1,2,3,4,5]. the
differences between l and each number in the sequence
are [1,0,1,2,3]. the smallest difference is 0 at index
1. so, the index 1 is removed from the sequence. the
new sequence becomes [1,3,4,5]. the sum of the original
sequence [1,2,3,4,5] and the new sequence [1,3,4,5] is
calculated as (5*2+5*(5+1)/2-5-(2+1-1))=15+15-5-2=24.
輸出型別的效果:** 根據輸出型別對程式進行分類，並檢查 （1） LLM 是否能夠正確地 ** 輸出型別（型別匹配）和 （2） 它們是否能夠正確地推理主題程式中的輸出值（值匹配），以識別七種型別，即 int（例如 2）、decimal（例如 2）。34）、字串（例如，“codemind”）、二進位（例如，true 或 false）、列表（例如，[1,3,4,7]）和元組（特定於 python，例如，（2,7））。圖 7 顯示了這些結果的詳細資訊。 總體而言，LLM 實現了高型別匹配 （>80%），儘管它們很難獲得正確的值（值匹配）。 在不同的型別中，模型更難包含元組列表和十進位型別的輸出值。 元組和列表由多個專案組成，每個專案都可以在程式執行期間更改。 因此，該模型難以通過可能不同的執行路徑跟蹤輸入流，並對整個複雜輸出進行推理也就不足為奇了。 此外，由於此類操作涉及 API 呼叫，例如 min（）、next（）、charat（），因此對更改進行推理需要 LLM 了解 API 的工作原理，這需要額外的努力。
input: 10, expected output:14
def set_left_most_unset_bit(n):
if not (n & n + 1)):return n
pos, temp, count = 0, n, 0
while temp:
if not (temp & 1): pos = count
count += 1
temp>>=1
return (n | 1
analysis: the variable n is initialized to 10. the code
checks if n is a power of 2. if it is, the code returns
n. if it is not, the code calculates the position of
the leftmost unset bit. the code then returns the
result of n | 1 <
*貢獻是：
1）使用CodeMind框架進行推理，正式定義了三個歸納推理任務。CodeMind 是開源的，接受研究人員的貢獻，以將更多的推理任務整合到其中;
2）使用Codemind對LLM的推理進行大規模的基礎理論評估;
3）對結果進行全面深入的分析，列出了對LLM**推理能力產生負面影響的根本原因。該目錄將是乙個有價值的指南，用於開發更好的基準，以真正評估 LLM 程式設計能力。
*題目：Codemind： A Framework to Challenge Large Language Models for Code Reasoning