面向编程大语言模型中隐式软件世界模型的评估

# 编码大语言模型中隐式软件世界模型的评估初探  
**来源**: https://arxiv.org/html/2606.27406  

\{jbabstract\}  
软件工程，无论是人类还是 AI 智能体执行，都需要理解软件的行为逻辑。我们将支撑此种推理的内部模型称为**软件世界模型**，并将现有的代码执行基准视为其研究较为深入的一部分——即控制流。在本文中，我们将可观测的轴转向执行资源，从而朝着更全面的评估迈进一步：除了测试结果和异常类外，我们还预测峰值内存、墙钟时间，以及方法和行粒度下的排序型分析器输出。我们使用 SWE-bench Verified 作为数据来源，以确保测试贴近真实世界的软件工程任务。所有参与测试的模型，包括前沿模型，均表现平平且行为脆弱，这表明模型对软件*如何执行*的理解显著欠缺，而不仅是关于源码*如何编写*。

## 1 引言  
评估编码大语言模型最直接的方式是考察其编写代码的能力。函数级基准测试如 HumanEval[undefg (https://arxiv.org/html/2606.27406#bib.bibx8)] 和 MBPP[undefd (https://arxiv.org/html/2606.27406#bib.bibx5)] 根据生成的解决方案能否通过保留的测试套件进行评分；仓库级基准如 SWE-Bench[undefj (https://arxiv.org/html/2606.27406#bib.bibx11)] 和 Aider-Polyglot[undef (https://arxiv.org/html/2606.27406#bib.bibx1)] 根据生成的补丁能否修复真实 bug 或实现功能进行评分；而仓库级基准如 Commit0[undefv (https://arxiv.org/html/2606.27406#bib.bibx23)] 要求模型仅根据其规范和单元测试套件重现整个 Python 仓库。这些评估衡量的是模型在代码生成方面的能力。

另一类基准评估编码大语言模型对程序执行的理解。CRUXEval[undefi (https://arxiv.org/html/2606.27406#bib.bibx10)] 在 800 个短 Python 函数上，根据给定输入预测输出（反之亦然）。REval[undeff (https://arxiv.org/html/2606.27406#bib.bibx7)] 将函数执行分解为预测代码覆盖率、路径上的程序状态、下一条执行的语句以及最终输出。ThrowBench[undefs (https://arxiv.org/html/2606.27406#bib.bibx20)] 预测运行时异常类型。BigO(Bench)[undefe (https://arxiv.org/html/2606.27406#bib.bibx6)] 对渐进复杂度进行分类。CodeMind[undefl (https://arxiv.org/html/2606.27406#bib.bibx13)] 将三项推理任务整合到 1,450 个短程序中。RE2-Bench[undefm (https://arxiv.org/html/2606.27406#bib.bibx14)] 在仓库规模上评估推理代码。这些推理基准大多操作于孤立、通常是合成生成的 Python 函数、类或短程序，并且主要关注返回值或其衍生。

然而，基于控制流推理代码执行，只是软件工程师日常实践技能中的一个切片——预测构建如何解析依赖、测试套件在某个改动下如何表现、服务在运行时如何响应、并发代码如何交错、补丁如何与周围仓库交互。我们使用术语**软件世界模型**来指代这种对软件系统行为的更广泛内部模型，其中控制流是研究最充分的一面。根据已有用法，我们区分**隐式世界模型**——即由在通用代码语料上训练的编码大语言模型自发获得的能力——与**显式世界模型**，即专门为此目的训练的模型，如最近的 CWM[undefh (https://arxiv.org/html/2606.27406#bib.bibx9)]。

对隐式软件世界模型的完整评估将涵盖构建与依赖解析、测试与 CI 行为、运行时错误、部署与运行时环境、并发性，以及连接这些环节的智能体级仓库工作流——这远超一篇论文的工作量。作为这一方向的第一步，我们仍停留在研究最充分的代码执行这个方面，但将其推向更真实的软件上下文。我们试图解决当前代码执行评估中的两个空白。第一，大多数推理基准中使用的函数级代码片段与实际软件复杂性不匹配——实际软件的行为依赖于周围的库实现。第二，返回值只是软件实际执行众多方面中的一个。为弥合这些差距，我们 (1) 设计了一组捕捉更宽执行行为切面的度量标准，(2) 收集了一个基于 SWE-bench Verified 的库级案例数据集，以及 (3) 展示了一系列近期代码能力较强的大语言模型（包括商业模型和开放权重模型）的结果。我们将此贡献定位为进一步扩展软件世界模型评估的模板——不仅限于代码执行。数据包可在 Hugging Face 获取111https://huggingface.co/collections/JetBrains-Research/dl4c26-evaluation-of-software-world-model，代码可在 GitHub 获取222https://github.com/JetBrains-Research/cwm-execution-tracer。

## 2 数据  
我们从 SWE-bench Verified[undefj (https://arxiv.org/html/2606.27406#bib.bibx11)] 构建数据集，这是一个包含 500 个真实 GitHub issue 及经过验证的黄金补丁的精选集合，涵盖 12 个 Python 仓库。我们从原本失败、经黄金补丁修复后通过的测试对中构建样本。为使任务对大多数模型具有可解性，我们仅保留所需上下文少于 500K 字符的示例。由于 SWE-bench Verified 中 Django 样本占主导，我们随后将数据降采样至 435 个示例，同时保持仓库层面的多样性。

为收集真实可观测值，对于每个实例，我们向 SWE-bench Docker 容器注入一个定制的基于 `sys.settrace`/`sys.monitoring` 的追踪器，并运行指定的测试。我们在打补丁前后分别运行该过程，以捕获同一测试的不同行为。追踪器记录本节将进一步详述的多项可观测值。

**测试结果。** 追踪器记录每个测试是通过还是失败。如果测试引发 `AssertionError` 或其他异常，我们将其计为失败。对于失败的测试，我们额外记录异常类名。

**墙钟时间。** 我们将墙钟时间记录为函数执行开始到结束之间的经过时间。为减少其他测量的干扰，我们仅在不进行额外追踪的干净运行中记录此项。

**峰值内存。** 测试运行所需的内存。我们将其记录为测试执行过程中记录到的内存消耗最大值，按行粒度测量。

**分析器。** 对于每次运行，我们记录四种分析类型，由两种分析范围（方法级和行级）与两种分析指标（时间和内存）的笛卡尔积形成。我们以毫秒记录墙钟时间，以千字节记录内存。对于方法分析器，我们记录完全限定函数名；对于行分析器，我们按格式 `<文件名>:<行号>` 记录行。在所有情况下，我们记录按相应指标排序的前 20 行，并将分析范围限制在仓库内部。

## 3 度量标准  
我们针对三个性质不同的预测任务，各自采用不同的度量系列。结果预测通过分类准确率评估；资源预测通过对数尺度上的线性校准进行评估（因为墙钟时间和内存跨度达数个数量级）；而分析器则作为排序任务评估。所有度量指标按实例计算，并在整个数据集上聚合。

**测试失败。** 我们将测试失败预测视为二分类任务，并报告精确率、召回率和 F1 值。

**墙钟时间和峰值内存的线性校准。** 这两个量跨度达数个数量级，因此我们在 `log10` 尺度上进行评估。我们拟合线性模型 `ŷ = a y* + b`，其中 `ŷ = log10(预测值)`，`y* = log10(实际值)`，并报告斜率 `a`（校准度）、截距 `b`（系统偏差）和平均绝对误差（MAE）。另外，我们对于模型的零预测，时间用 0.01 ms 替代，峰值内存用 10KB 替代。这些值小于我们数据集中所有真实数值，但允许我们计算对数尺度上的度量。

**分析器排序。** 对于四个排序列表（函数 `×` {时间, 内存} 和行 `×` {时间, 内存}），我们报告两种排序度量：召回率和 NDCG。`Recall@k` 对于样本若实际最耗资源的方法/行位于预测的前 `k` 个方法/行中则为 1，否则为 0。`DCG@k` 定义为 `∑_{i=1}^{k} r_i / log2(i+1)`，其中 `r_i` 是位于排序第 `i` 位的预测函数或行所对应的测量时间/内存。我们报告 `NDCG@5`——即 `DCG@5` 除以最优 `DCG@5` 进行归一化——以及 `Recall@5`。为衡量模型估计执行范围的能力，我们还额外计算执行率，即预测的方法或行中实际在运行时被执行的占比。

## 4 实验设置  

**模型。** 我们通过 Anthropic API 评估三个 Anthropic 模型：`claude-haiku-4-5`[undefa (https://arxiv.org/html/2606.27406#bib.bibx2)]、`claude-sonnet-4-6`[undefc (https://arxiv.org/html/2606.27406#bib.bibx4)] 和 `claude-opus-4-7`[undefb (https://arxiv.org/html/2606.27406#bib.bibx3)]。通过 OpenAI API 评估 `gpt-5-mini`[undefn (https://arxiv.org/html/2606.27406#bib.bibx15)]、`gpt-5.2`[undefp (https://arxiv.org/html/2606.27406#bib.bibx17)]、`gpt-5.4`[undefq (https://arxiv.org/html/2606.27406#bib.bibx18)] 和 `gpt-5.5`[undefr (https://arxiv.org/html/2606.27406#bib.bibx19)]。我们在本地运行五个开放权重模型：来自 OpenAI 的 `gpt-oss-120b`[undefo (https://arxiv.org/html/2606.27406#bib.bibx16)]；来自阿里巴巴的 `Qwen3.5-397B-A17B`[undefu (https://arxiv.org/html/2606.27406#bib.bibx22)]、`Qwen3-235B-A22B-Instruct` 和 `Qwen3-30B-A3B-Instruct`[undeft (https://arxiv.org/html/2606.27406#bib.bibx21)]；以及来自 FAIR 的 `CWM`[undefh (https://arxiv.org/html/2606.27406#bib.bibx9)]。

**上下文。** 用户消息由两个块组成。**第一个块**是包含所有已执行代码的库切片。对于每个至少有一行被执行的文件，我们包括模块前导部分（第一个类或函数定义之前的所有内容），随后是每个至少有一行被执行的函数（或封装在类骨架中的方法体）。对于有被执行行的类，我们还保留方法之外的所有内容，如类定义及其字段。剩余预算（如有）最多 500K 字符，则由未执行的函数和方法填充。**第二个块**是测试文件，窗口长度最多 60K 字符，以目标测试函数为中心。提示模板见附录 A (https://arxiv.org/html/2606.27406#A1)。

**任务。** 模型被指示返回一个包含十个字段的 JSON 对象：`reasoning`（2–4 句解释）、`outcome`（passed、failed 或 error）、`failure_line` 和 `exception_type`（当 outcome 为 passed 时为 null）、`peak_bytes` 和 `wall_ms`（分别为整数和浮点数），以及四个每项最多 20 个条目的排序列表：`hot_methods_time`、`hot_methods_alloc`、`hot_lines_time` 和 `hot_lines_alloc`。这些字段直接对应于第 2 节 (https://arxiv.org/html/2606.27406#S2) 中描述的可观测值，并由第 3 节 (https://arxiv.org/html/2606.27406#S3) 中的度量标准评分。

## 5 结果与讨论  

**表 1：** 测试失败预测，按 F1↓ 排序。  
**表 2：** 峰值内存消耗预测校准（log10 尺度）。理想：斜率=1，偏差=0。按 MAE↓ 排序。  
**表 3：** 墙钟时间预测校准（log10 尺度）。理想：斜率=1，偏差=0。按 MAE↓ 排序。  
**表 4：** 内存分析器排序质量。*exec*：预测名称中出现在执行轨迹中的比例。NDCG@5 和 recall@5 评估相对于真实分配文件的排序质量。按方法 NDCG@5↓ 排序。  
**表 5：** 时间分析器排序质量。*exec*：预测名称中出现在执行轨迹中的比例。NDCG@5 和 recall@5 评估相对于真实时间文件的排序质量。按方法 NDCG@5↓ 排序。  

表 1 (https://arxiv.org/html/2606.27406#S5.T1) 报告了测试结果分类；表 2 (https://arxiv.org/html/2606.27406#S5.T2) 和表 3 (https://arxiv.org/html/2606.27406#S5.T3) 报告了资源预测校准；表 4 (https://arxiv.org/html/2606.27406#S5.T4) 和表 5 (https://arxiv.org/html/2606.27406#S5.T5) 报告了分析器排序质量。

我们注意到，所有模型，包括通过 API 可用的前沿模型，在所提任务上的得分都不高。对于测试结果预测，大多数模型的 F1 得分持续偏低，很大程度上是因召回率极低所致。对于峰值内存和墙钟时间，模型预测存在系统性偏差，每个模型的斜率和偏差都显著偏离最优值 (1,0)。对于所有类型的分析，最佳 `recall@5` 从未达到 0.2，表明模型极少能识别出最耗资源的实体。对于测试结果预测，我们注意到大多数模型召回率较低，表明存在很强的倾向于测试通过的偏差。我们将其归因于 LLM 倾向于遵循代码的自然语言语义而非其结构，这一点在 [undefk (https://arxiv.org/html/2606.27406#bib.bibx12)] 中有所展示。优化测试以从 LLM 获取无偏预测，可能是软件工程领域一个有前景的研究方向。

对于峰值内存消耗和时间，除了系统性误差的存在和强度外，我们还注意到偏差本身具有普遍性。我们观察到一致的斜率压缩（模型的预测更接近平均值）以及高估偏差（对于大多数模型，差异至少为一个数量级）。CWM 的特殊情况可以通过 247 个案例解释，其中它预测执行时间为 0 ms，并在推理中解释为无法精确计算。这种保守估计使得模型在预测特定任务带来的负载时实用性较低333（根据一个趣闻观察，在本文的实验过程中，运行由 Sonnet 4.6 监督，它总是系统性地误判完成运行所需的时间，总是预测约 20 分钟，而实际用时要么是 2 小时要么是 7 分钟）。大多数情况下，分析任务的预测被未被实际执行的行号和方法主导。我们还测量了通过正确排序模型预测获得的集合的 NDCG@5，并注意到显著提升（方法分析平均提升约 ×1.5，行分析提升约 ×2），这表明幻觉执行范围并非唯一问题——正确的排序对模型来说也具有挑战性。

总体而言，我们注意到较小模型，特别是开放权重模型，倾向于预测“整齐”的数字，尤其像“12345 ms”这种特别奇怪的数字，在 Qwen3-30B 的输出中占主导。这在附录 B (https://arxiv.org/html/2606.27406#A2) 中展示的预测值与实测值散点图中尤其明显。令人惊讶的是，CWM 在代码生成和推理方面的表现并未迁移到关于软件的推理上——虽然它能生成连贯的推理轨迹和输出，但在大多数实验中落后于 Qwen3-30B（一个规模相近的模型）。这些发现进一步强化了我们的观点：需要更广泛的评估框架。