🤖 machine learning

The Path Not Taken: Duality in Reasoning about Program Execution

该论文指出大语言模型在代码推理中存在局限性，提出了通过“预测程序行为”与“推断输入修改”这一双重推理范式来评估模型对程序执行因果理解的必要性，并构建了包含 445 对实例的 DexBench 基准以验证该方法的有效性。

原作者： Eshgin Hasanov, Md Mahadi Hassan Sibat, Santu Karmaker, Aashish Yadavally

发布于 2026-04-24

📖 1 分钟阅读☕ 轻松阅读

原作者： Eshgin Hasanov, Md Mahadi Hassan Sibat, Santu Karmaker, Aashish Yadavally

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文提出了一种全新的方法来测试大型语言模型（LLM，比如现在的各种 AI 编程助手）是否真的“懂”代码，而不仅仅是“背”代码。

为了让你更容易理解，我们可以把写代码和运行程序想象成开车，把 AI 想象成一位新来的导航员。

1. 以前的测试：只看“单行道”

以前的测试方法（就像现在的很多基准测试）是这样的：

测试员：“请开这辆车，输入‘去公园’，告诉我最后车停在哪里，以及经过了哪些路。”
AI：“好的，车停在了公园门口，经过了 A 路、B 路。”

问题在于：AI 可能只是背下了“去公园=走 A 路+B 路”这个答案。如果它没真正理解交通规则（代码逻辑），一旦路稍微变一下，或者问它“如果我想去超市该怎么走”，它可能就懵了。它只是在做“填空题”，而不是在“开车”。

2. 这篇论文的新想法：双向推理（Duality）

作者认为，要真正测试一个导航员（AI）懂不懂开车，不能只问它“怎么走”，还得问它“怎么改路线”。他们提出了**“双路径推理”的概念，就像考驾照时的“正向驾驶”和“反向改道”**。

任务一：正向推理（Forward Reasoning）—— “预测路况”

测试员：“现在输入是‘去公园’，请告诉我车会经过哪些路，最后停在哪？”
AI：需要像老司机一样，一步步模拟开车过程，预测结果。

任务二：反向推理（Counterfactual Reasoning）—— “如果我想去超市呢？”

测试员：“刚才我们去了公园。现在如果我想去超市（这是新的目标），你需要把输入改成什么，才能让车走另一条路到达超市？”
AI：这需要它理解：“哦，原来是因为输入是‘公园’，所以车在路口左转了。如果我想让它右转去超市，我必须把输入改成‘超市’，这样它才会在那个路口做出不同的选择。”

核心比喻：

正向是看它能不能看懂地图。
反向是看它能不能修改指令来改变结果。
真正的理解：只有当 AI 既能准确预测结果，又能精准地通过修改输入来“操控”结果时，我们才相信它真的懂了代码的因果关系，而不是在瞎猜。

3. 他们做了什么？（DEXBENCH 基准测试）

作者建立了一个叫 DEXBENCH 的测试场，里面有 445 个这样的“双任务”题目。

他们选了 13 种不同的 AI 模型（从小的到大的，从开源的到闭源的）来考试。
题目包括：预测代码运行时会覆盖哪些行（正向），以及修改输入让代码去覆盖原本没覆盖到的那一行（反向）。

4. 发现了什么有趣的现象？

测试结果让人大跌眼镜，就像发现了一些“偏科”的学霸：

单项冠军 $\neq$ 全能冠军：
有些 AI 在“预测结果”上得分很高，但在“修改输入去改变结果”上却一塌糊涂。就像有的司机很会看导航，但让他自己改路线时却完全迷路了。这说明单独考一项是不够的。
模型越大不一定越强：
有些中等大小的模型（比如 32B 参数的），在“双向推理”上反而比那些巨大的模型（70B+）表现更好。这说明光堆参数（把模型做大）并不能保证它真的学会了逻辑推理。
“会思考”的模型不一定行：
有些专门经过“强化推理训练”的模型，在理解代码执行流程上，反而不如那些普通的模型。这暗示了目前的“推理训练”可能并没有真正教会它们理解代码的底层逻辑。
闭源模型依然很强：
像 Claude Sonnet 4、Grok-4 这些闭源的大模型，在双向测试中表现最好，但即使是它们，在面对复杂的代码逻辑时，也会犯错（比如搞错 API 的用法）。

5. 总结：这对我们意味着什么？

这篇论文告诉我们：

不要只看 AI 能不能写出代码，要看它是否真的理解代码运行时的“因果关系”。
未来的 AI 评估不能只问“结果是什么”，还要问“怎么改才能变结果”。
目前的 AI 虽然很强，但在动态理解程序执行（就像在复杂的交通网中实时决策）方面，还有很大的提升空间。

一句话总结：
以前的测试是问 AI“这道题答案是多少”，现在的测试是问 AI“如果你想要这个答案，你应该怎么出题？”只有能同时回答这两个问题的 AI，才是真正懂代码的“老司机”。

《未选择之路：程序执行推理中的二元性》技术总结

1. 研究背景与问题定义

大型语言模型（LLMs）在软件工程领域（如代码生成、测试和调试）展现出巨大潜力，但其对程序执行的深层理解能力仍存在不一致性。现有的评估基准（Benchmarks）主要关注单一测试用例下的程序属性预测（如代码覆盖率、输入输出映射）。这种评估方式存在两个核心缺陷：

视角狭窄：仅评估模型在特定输入下沿单一路径的执行能力，忽略了程序因输入不同而可能产生的多条执行路径（多态性）。
数据污染风险：基于固定输入 - 输出对的基准容易被模型在训练阶段“死记硬背”，导致评估结果虚高，无法真实反映模型的因果推理能力。

本文指出，理解程序执行本质上具有二元性（Duality）：既需要预测给定输入下的观测行为（前向推理），也需要推断为了达到特定行为目标应如何修改输入（后向/反事实推理）。现有的单一路径评估无法全面捕捉这种因果逻辑。

2. 方法论：DEXBENCH 基准与二元推理框架

作者提出了 DEXBENCH，一个基于“双路径”推理的基准测试框架，旨在通过两个互补的任务来评估 LLM 对程序执行的因果理解：

2.1 核心概念：二元推理 (Dual-Path Reasoning)

执行路径 (Execution Path, $\pi_{exec}$ )：给定输入 $I_{exec}$ ，程序实际运行的路径。
反事实路径 (Counterfactual Path, $\pi_{cf}$ )：为了达到特定行为目标（如覆盖未执行的分支），需要修改输入 $I_{exec}$ 后程序运行的替代路径。
共享执行空间：两条路径通常共享部分初始执行空间，仅在分支点（Branching Points）因状态不同而分叉。

2.2 两个互补任务

前向推理 (Forward/Execution Reasoning)：
- 任务：给定程序 $P$ 和输入 $I_{exec}$ ，预测其观测行为（在 DEXBENCH 中定义为语句覆盖率，即哪些代码行被执行）。
- 形式化： $R_{exec}: (P, I_{exec}) \mapsto \phi(\tau_{exec})$ 。
后向推理 (Backward/Counterfactual Reasoning)：
- 任务：给定程序 $P$ 、原始输入 $I_{exec}$ 和目标行为 $\phi^*$ （例如：覆盖某个未被执行的分支 $b$ ），推断需要如何修改输入得到 $I_{cf}$ ，使得程序沿反事实路径执行。
- 形式化： $R_{cf}: (P, I_{exec}, \phi^*) \mapsto I_{cf}$ 。
联合评估 (Dual-Path Evaluation)：
- 只有当模型同时正确预测原始覆盖率且成功生成能触发目标分支的输入时，才算成功。这强制模型建立一致的因果表示。

2.3 基准构建 (DEXBENCH)

数据来源：从 CruxEval、HumanEval 和 PythonSaga 三个真实世界数据集中提取 Python 程序。
筛选标准：保留包含条件/循环结构，且存在未覆盖分支（覆盖率 < 100%）的程序。
规模：共 445 个成对实例，涵盖不同复杂度（代码行数 10-78，圈复杂度 2-19）。
评估指标：使用 pass@k 指标。联合成功指标定义为 $S_{dual} = S_{exec} \land S_{cf}$ 。

3. 实验结果

研究评估了 13 种 LLM（包括 9 种开源和 4 种闭源模型，涵盖不同规模和推理能力）：

3.1 主要发现

单一任务表现无法代表联合能力：
- 许多模型在“仅执行推理”或“仅反事实推理”上表现尚可，但在联合评估中表现大幅下降。
- 例如，在复杂数据集（PythonSaga）上，即使是顶尖闭源模型（如 Gemini 2.5 Flash）的联合通过率（pass@1）也仅为 4.3%，远低于其在单一任务上的表现。
模型缩放定律的局限性：
- 小模型（<10B）在联合任务上几乎完全失败。
- 反直觉现象：在某些情况下，中等规模模型（如 Qwen2.5-32B）在双路径推理上的表现优于其更大规模的版本（Qwen2.5-72B）。
- 推理微调的局限：专门针对推理能力进行后训练（Post-training）的模型（如 QwQ-32B）并未在双路径任务上显著优于非推理版本的基座模型（Qwen2.5-32B），甚至在某些数据集上表现更差。
闭源模型的优势：
- 闭源模型（Claude Sonnet 4, Grok-4 Reasoning, GPT-5 Mini）在联合评估中表现最佳，但即便如此，随着程序复杂度增加，性能仍显著下降。

3.2 误差分析

不对称性：模型往往擅长预测行为（前向），但不擅长逆向推导输入（后向），或者反之。
错误类型：
- 前向推理：主要错误源于指令理解偏差、跳过语句或幻觉。
- 后向推理：主要错误源于对 API 语义的误解（如 split 与 splitlines 混淆）或控制流逻辑错误，导致无法生成满足约束的输入。
提示词敏感性：增加提示词复杂度（如引入思维链或约束选项）对部分模型（如 Grok-4）有帮助，但也暴露了其对复杂推理链的敏感性。

4. 关键贡献

提出了程序执行推理的“二元性”理论：论证了理解程序执行必须同时包含前向预测和后向反事实推理，二者共同构成了对因果逻辑的完整评估。
构建了 DEXBENCH 基准：首个专门针对双路径推理的基准，包含 445 个成对实例，强制模型在共享执行空间内进行因果推理，有效缓解了数据污染问题。
揭示了现有 LLM 的深层缺陷：
- 证明了单一路径评估不足以衡量动态代码理解能力。
- 发现模型规模扩大和推理微调并不必然带来双路径推理能力的提升。
- 指出了模型在维持因果一致性（Causal Consistency）方面的脆弱性。

5. 意义与影响

评估范式的转变：DEXBENCH 提供了一种更严格、更具区分度的评估框架，能够识别那些仅靠模式匹配但缺乏真正执行理解能力的模型。
指导模型开发：研究结果表明，当前的推理微调策略可能未触及程序执行的核心因果逻辑，未来的模型训练需要更关注状态管理和控制流的因果推理。
实际应用价值：双路径推理能力对于软件测试（覆盖引导的模糊测试）、调试（定位导致特定行为的输入）和程序修复等实际工程任务至关重要。

总结：本文通过引入“二元推理”视角和 DEXBENCH 基准，有力地证明了当前 LLM 在动态代码理解上仍存在显著短板，特别是缺乏对程序执行流因果关系的深层把握。未来的研究需致力于提升模型在复杂控制流下的状态追踪与逆向推理能力。