📄 论文信息

论文：Evaluating LLMs Code Reasoning Under Real-World Context

作者：Changshu Liu

链接：arXiv:2604.12881

会议：ICSE-Companion '26 / ICES SRC (ACM Student Research Competition)

提交日期：2026 年 4 月 14 日

🎯 核心问题：为什么现有 Code Reasoning Benchmark 不靠谱？

代码推理（Code Reasoning）是评估 LLM 理解程序执行行为能力的关键任务。这项能力直接影响代码翻译、程序修复、代码生成等下游任务的质量。然而，现有 benchmark 存在一个根本性缺陷：它们测试的代码和真实项目代码之间存在巨大鸿沟。

现有 benchmark 的三大问题：

  • 代码来源过于简单：CRUXEval 用 LLM 生成的短小程序，Avatar/HumanEval 用人写的编程挑战题，都远离生产级代码的复杂度
  • 类型系统被简化：几乎所有 benchmark 都只用原始类型（int、str），而真实项目大量使用复合类型和自定义类型
  • 依赖关系被剥离：方法间的调用链、第三方 API 使用、类继承关系等真实代码的核心特征被忽略了

📊 关键数据：从 CRUXEval 到 R2Eval，LLM 表现断崖式下跌

R2Eval 从 10 个广泛使用的 Python 项目（scikit-learn、Django、requests、seaborn、sphinx、pytest、astropy、xarray、matplotlib、sympy）中抽取 135 个推理问题，测试了 6 个主流 LLM：

Input Prediction（反向推理：给输出猜输入）：

  • o4-mini：20.00%（CRUXEval 92.59%，↓72.59）
  • Gemini-2.5-Pro：15.56%（CRUXEval 91.85%，↓76.29）
  • DeepSeek-R1：21.48%（CRUXEval 94.81%，↓73.33）
  • GPT-4.1：14.81%（CRUXEval 87.41%，↓72.60）

Output Prediction（正向推理：给输入猜输出）：

  • o4-mini：28.15%（CRUXEval 91.85%，↓63.70）
  • Gemini-2.5-Pro：34.07%（CRUXEval 88.89%，↓54.82）
  • DeepSeek-R1：31.85%（CRUXEval 87.41%，↓55.56）
  • GPT-4.1：28.15%（CRUXEval 87.41%，↓59.26）

平均来看，Input Prediction 下降 64.32%，Output Prediction 下降 52.22%。最强的 o4-mini 在 CRUXEval 上超过 90%，到了 R2Eval 只剩 20-28%。

🔧 技术方案：自定义类型序列化 + 反验证

R2Eval 的核心技术创新在于处理真实项目中的复杂数据类型：

  • 自定义类型序列化：真实项目中的对象（如 scikit-learn 的 BaseWCSWrapper）没有 __str__() 实现，直接打印只会得到内存地址。R2Eval 用静态+动态程序分析，将复合类型递归分解为原始类型，序列化为 JSON 格式
  • 反序列化验证：为避免文本比较的假阴性，R2Eval 将 LLM 的预测结果反序列化为对象，用运行时测试验证正确性
  • 依赖注入：每个推理问题不仅提供目标方法代码，还包含相关的方法依赖和类上下文

🔑 关键洞察

1. Reasoning LLM 没有带来质的飞跃

o4-mini、Gemini-2.5-Pro、DeepSeek-R1 等推理模型在 CRUXEval 上确实比非推理模型好约 13%。但到了 R2Eval，这个优势变得微不足道 — 最强的推理模型也只比非推理模型好几个百分点。说明在真实代码复杂度面前，推理增强的效果被大幅稀释。

2. 反向推理比正向推理更难

Input Prediction（给输出猜输入）比 Output Prediction（给输入猜输出）下降更严重。论文推测这是因为真实项目的复杂代码结构和丰富依赖关系，使得反向推理（逆向追溯数据流）的难度显著增加。这和 Harness Engineering 的核心洞察一致 — 真实代码库中的因果链条远比 playground 代码复杂。

3. 类型复杂度才是真正的瓶颈

CRUXEval 只用原始类型，LLM 得心应手。但真实项目中的自定义类、嵌套数据结构、第三方库对象，让 LLM 彻底懵了。这说明 LLM 对"类型系统"的理解还停留在表面 — 它们能处理 int、str 的推理，但面对 sklearn 的 BaseEstimator 或 Django 的 QuerySet 就束手无策了。

🤔 引发思考

这篇论文对 Harness Engineering 社区有直接的启示意义：

  • 环境设计（Harness）比模型能力更重要：R2Eval 证明了模型在 playground 上的高分不等于真实能力。Harness Engineering 的核心主张——通过精心设计的环境（测试、反馈、渐进式披露）来弥补模型缺陷——在这篇论文中得到了实证支持
  • 代码推理的工程化路径：既然 LLM 无法直接处理复杂类型，那就需要工程化手段（如类型序列化、依赖注入、运行时验证）来辅助。这和 SWE-CI/TDAD 的思路一脉相承
  • Benchmark 设计本身就是工程问题：R2Eval 的类型序列化 pipeline 就是一个典型的 Harness — 用工程手段把真实世界的复杂度转化成 LLM 能处理的形式

📎 相关阅读

逍遥云初 | 2026.04.16