Assessing Coherency and Consistency of Code Execution Reasoning by Large Language Models

这篇论文提出了一种名为 CES (Code Execution Simulation，代码执行模拟) 的新任务，旨在评估大语言模型（LLM）在模拟程序执行过程中的推理连贯性（Coherency）和一致性（Consistency）。

以下是对该论文的详细技术总结：

1. 研究背景与问题 (Problem)

尽管 LLM 在代码补全、合成和修复方面表现出色，但它们在代码推理方面的能力仍存在争议。现有的评估方法（如 CruxEval, CodeMind, REval）存在以下局限性：

• 缺乏中间状态评估：大多数方法仅关注输入/输出预测，忽略了中间程序状态，无法判断模型是否真正理解了执行逻辑。
• 无法检测“可疑的正确”：模型可能通过数据泄露、幻觉或自然语言捷径（Natural Language Shortcuts）直接猜出正确答案，而实际上并未正确模拟执行过程。现有的方法无法区分这种“运气好”的成功和真正的推理能力。
• 缺乏连贯性分析：现有方法通常针对单个语句单独提问，缺乏对整个程序执行流的连贯性评估，无法定位推理在何处开始偏离真实执行。
• 缺乏跨测试的一致性评估：未能评估模型在不同测试用例（覆盖不同执行路径）下推理的一致性。

2. 方法论 (Methodology)

2.1 CES 任务设计

CES 要求 LLM 在单次提示（Prompt）中，针对给定的代码和输入，预测以下关键决策点的状态：

• 循环属性：循环变量（Loop Variables）和循环迭代器（Loop Iterables，如 zip 的结果）。
• 分支属性：条件谓词（Predicates）、子谓词以及分支走向（Branch Taken）。
• 返回属性：最终的输出值。

CES 采用**流敏感（Flow-sensitive）**的提示策略，利用静态分析动态调整上下文示例（In-context Examples），并强制模型预测所有关键中间状态，从而统一了输出预测和中间状态预测。

2.2 核心评估指标

论文提出了两个核心维度来评估 LLM 的推理能力：

A. 推理连贯性 (Reasoning Coherency)
CES 定义了三个规则来判断模拟过程是否符合常识逻辑，即使预测值本身是错误的：

1. 组合逻辑一致性：复合属性（如 zip(evens, odds)）的预测值必须与其子属性（evens 和 odds）的预测值在逻辑上匹配。
2. 条件与分支一致性：条件谓词的预测值必须与分支走向的预测值一致（例如，如果谓词为真，分支必须被选中）。
3. 输出与状态一致性：如果中间状态预测错误，但最终输出预测正确，则判定为不连贯（Incoherent）。这用于识别“可疑的正确”输出（即通过幻觉或捷径猜对答案）。

B. 推理一致性 (Reasoning Consistency)
基于控制流图（CFG）中的**主路径（Prime Paths）**覆盖，将模型在不同测试用例下的表现分为三个等级：

• 强一致性 (Strong Consistency)：模型能正确模拟覆盖不同主路径的测试用例。
• 弱一致性 (Weak Consistency)：模型仅能正确模拟覆盖相同主路径的测试用例，但在不同路径上失败。
• 随机一致性 (Random Consistency)：模型表现无规律，无法稳定复现推理。

2.3 诊断分析

CES 能够自动定位模拟发散点（Simulation Divergence Point），即模型推理首次偏离真实执行的位置（如循环迭代器计算错误、条件判断错误等）。

3. 实验设置

• 对象：评估了 16 个 LLM（包括 3 个推理模型如 o4-mini, DeepSeek-R1, Gemini-2.5-Pro），涵盖 CodeLlama, DeepSeekCoder, GPT-4 等。
• 数据集：HumanEval（164 个 Python 程序），每个程序采样 3 个测试用例。
• 对比任务：将 CES 结果与 Bug 预测、定位和修复任务进行对比，以验证 LLM 是否真正利用了执行推理。

4. 主要结果 (Key Results)

4.1 推理连贯性表现

• 整体表现：在 HumanEval 上，LLM 平均有 81.42% 的模拟是连贯的。
• 正确与错误输出：在连贯的模拟中，46.92% 产生了正确的输出，53.08% 产生了错误的输出。
• 可疑的正确：前沿模型（如 GPT-4, DeepSeek-R1）表现出较高的不连贯推理比例（约 25%），这通常归因于自然语言捷径或幻觉。例如，模型可能错误地模拟了循环，但通过猜测函数名或数据泄露得出了正确答案。
• 模型差异：经过执行数据微调的模型（如 SemCoder-S）在连贯性上表现更好，但指令微调（Instruction-tuning）有时反而引入了自然语言捷径，导致不连贯推理增加。

4.2 推理一致性表现

• 一致性极低：LLM 在不同测试用例间的推理一致性非常差。
  • 随机一致性：48.87% 的情况。
  • 弱一致性：45.37% 的情况。
  • 强一致性：仅 5.76%。
• 这表明 LLM 难以进行路径敏感的推理，无法在不同输入下稳定地模拟相同的执行逻辑。

4.3 诊断发现

• 发散点：在包含循环的程序中，最常见的发散点是**循环迭代器（Loop Iterables）的预测错误；在包含条件判断的程序中，则是谓词（Predicates）**预测错误。
• 嵌套结构：嵌套的循环和条件语句显著增加了推理难度。

4.4 CES 与 Bug 相关任务的关联

• 缺乏执行推理：研究发现，LLM 在 Bug 预测、定位和修复任务中的成功，很少依赖于真正的执行推理。
• 可疑成功：通过 CES 验证发现，许多在 Bug 任务中“成功”的案例，其 CES 模拟是不连贯的，或者发散点位于 Bug 位置之前。这意味着模型可能仅依靠模式匹配、自然语言描述或数据泄露来“猜”对答案，而非真正理解代码逻辑。
• 验证价值：CES 能有效剔除 Bug 任务中的“虚假成功”，揭示 LLM 在未见过的 Bug 或不同上下文中泛化能力的不足。

5. 主要贡献 (Key Contributions)

1. 提出 CES 任务：首个将输出预测与中间状态预测统一，并引入连贯性概念来区分真实推理与捷径/幻觉的评估框架。
2. 定义一致性谱系：提出了基于主路径覆盖的强/弱/随机一致性指标，量化了 LLM 跨测试用例的推理稳定性。
3. 系统性诊断工具：开发了自动化工具，能够定位模拟发散点并识别“可疑的正确”输出，为理解 LLM 代码推理的局限性提供了细粒度视角。
4. 揭示现有任务缺陷：通过对比 CES 与 Bug 相关任务，证明了当前 LLM 在编程任务中的高成功率可能主要源于数据泄露和模式匹配，而非真正的代码理解，这对评估基准的可靠性提出了挑战。

6. 意义与影响 (Significance)

• 提升评估可信度：CES 提供了一种系统性的方法来“审查”LLM 在代码任务中的成功是否真实，防止因数据泄露或捷径导致的评估虚高。
• 指导模型改进：研究指出 LLM 在路径敏感分析和复杂控制流推理上的弱点，为下一代“执行感知（Execution-aware）”代码大模型的训练策略（如强化执行模拟、减少自然语言捷径依赖）提供了明确方向。
• 推动基准测试：强调了在评估 LLM 时，不仅要看最终结果，更要关注推理过程的连贯性和一致性，这对构建更可靠的代码生成和修复系统至关重要。

总结：这篇论文通过 CES 任务揭示了一个令人担忧的事实：尽管 LLM 在代码任务上表现优异，但其推理过程往往是不连贯且不一致的，许多成功是“运气”或“捷径”的结果。CES 为未来更严格、更真实的代码推理评估奠定了坚实基础。