TensorBench: 在基于编译器的张量框架上对代码代理进行基准测试

# TensorBench：基于编译器的张量框架上的编码智能体基准测试  
来源：https://arxiv.org/html/2606.05570  

Bobby Yan  
计算机科学系  
斯坦福大学  
斯坦福，加利福尼亚州 94305  
[email protected]  

&Fredrik Kjolstad  
计算机科学系  
斯坦福大学  
斯坦福，加利福尼亚州 94305  
[email protected]  

###### 摘要  

仓库级别的编码基准测试在任务难度与评估可靠性之间存在权衡：挑战前沿模型的任务通常涉及大型代码库且测试覆盖率不完整，而人工审查又无法规模化。我们提出了 TensorBench，这是一个包含 199 个功能添加与重构任务的基准测试，基于一个开源、基于编译器的张量框架，该框架通过一等公民支持稠密与稀疏张量来扩展 PyTorch。任务涵盖新的稀疏格式、稠密优化通道、IR 变换、调度器修改、运行时组件以及高级数值算子。TensorBench 通过应用智能体的补丁并运行框架的测试套件（包括已有的随机回归测试以及智能体添加的任何测试）来对每次运行进行评分。对于功能添加任务，通过意味着修补后的仓库保留了测试过的已有行为，并满足智能体为请求功能添加的检查。我们评估了涵盖三个前沿模型家族和一个开放权重模型的七个编码智能体。在该标准下，通过率从最强智能体的 64.8% 到最弱智能体的 22.1% 不等。不同智能体通过的测试子集各不相同：成对 Cohen's κ 范围从 -0.07 到 0.43，两个最强智能体的 κ=0.05。  

## 1 引言  

代码生成基准测试在任务难度与评估可靠性之间存在权衡。简单的任务（如完成一个函数或修复一个局部 bug）可以通过单元测试可靠评估，但随着模型性能在这些基准测试上趋于饱和，该领域已转向更难的仓库级任务。在这种设置下，评估信号较弱，因为仓库测试套件并非设计用于捕捉智能体引入的 bug[1]，并且人工审查无法规模化。为了将能力提升与评分噪声区分开来，仓库级基准测试需要将困难任务与表面编辑不太可能满足的评估标准配对。  

我们提出 TensorBench，一个基于编译器的张量框架的仓库级基准测试。张量编译非常适合此设置：许多更改需要仓库级的工程工作，而外部可见行为具有明确定义的参考输出。实现一个新的张量操作、稀疏张量格式、内部表示（IR）变换、调度器优化通道或代码生成特性通常需要在编译管道的多个部分进行协调更改。对于许多任务，生成的核可以通过可信的参考进行检查；对于结构性编译器更改，相同的测试还可以检查现有的下降、调度和代码生成不变性是否保持不变。  

TensorBench 根据最终的仓库行为进行评分，而不是与参考补丁的相似性。许多任务要求对共享的编译器机制进行编辑——稀疏格式处理、迭代格、IR 下降、调度、代码生成或运行时内核——因此继承的回归测试套件是一个重要信号：这些路径中的错误通常会影响许多现有算子，并且会被随机化、参数化的测试暴露出来。对于稀疏和混合稀疏-稠密算子，这些测试通常与稠密 PyTorch 进行比较；对于稠密优化和调度更改，它们可能与现有的未优化路径进行比较。这个信号仍然只是一个兼容性检查。新功能的行为主要受智能体添加的任何测试约束，因此通过不应被解释为补丁满足了自然语言请求的每一个合理解释或边界情况。  

TensorBench 根据最终的仓库状态进行评分，而不是与参考补丁的相似性。尽管任务要求新功能，但其中许多需要编辑共享的编译器机制：稀疏格式处理、迭代格、IR 下降、调度、代码生成或运行时内核。因此，继承的测试套件是一个重要的正确性信号：在共享下降、调度或代码生成路径中的一个小错误可能会传播到许多生成的核和张量表达式，并且很可能会被针对现有算子的随机化和参数化测试暴露出来。对于稀疏和混合稀疏-稠密算子，这些测试通常与稠密 PyTorch 进行比较；对于稠密优化和调度更改，它们可能与现有的未优化路径进行比较。因此，通过意味着补丁保留了测试过的现有行为，并满足智能体为新功能编写的测试。由于新功能的行为主要通过智能体编写的测试进行检查，因此通过不应被解释为功能完备性的证据。  

我们从四个 CLI 脚手架（Claude Code、Codex CLI、Gemini CLI、OpenHands）评估了七个编码智能体。这些智能体覆盖了三个前沿模型家族和一个开放权重模型。所有运行都使用基于 Docker 的框架进行评分，该框架在全新的容器中应用智能体的统一差异，构建 C++ 运行时，并运行完整的测试套件。最强的智能体（Claude 4.7）在补丁后测试套件标准下通过了 64.8% 的任务，比同一任务集上的 Claude 4.6 提高了 22.1 个百分点；其破坏已有测试的比例为 16%，低于 Claude 4.6 的 27%。智能体之间的逐任务成对一致性较低（κ∈[−0.07,0.43]），并且任意两个智能体的联合通过率比两者中较好的高出 6–20 个百分点。基准测试代码、预测和智能体的轨迹可在 https://tensorbench.org/ 获取。  

## 2 TensorBench  

TensorBench 要求智能体在六个方面扩展目标框架：用户面向的 API（*API*）、稀疏张量格式（*Format*）、中间表示更改（*IR*）、调度器优化通道（*Scheduler*）、代码生成特性（*Codegen*）和运行时组件（*Runtime*）；附录 A.1 给出了完整的分类学。代码库的两个特性使得基准测试成为可能：一个支持沿每个轴进行非平凡扩展的架构，以及一个随机化的回归测试套件，该套件涵盖多种形状、稀疏模式、格式和编译器路径。  

### 2.1 目标框架  

Scorch[20] 是一个公开发布、开源的基于编译器的张量框架（约 11,000 行 Python 代码和一个约 450 行的 C++ 运行时头文件，该头文件会被预置到每个 JIT 发射的内核中）。它通过一等公民支持稀疏*和*稠密张量来扩展 PyTorch，并设计为即插即用的替代品：`import scorch as torch` 提供了 PyTorch 的接口，但底层由编译后的内核支持，并额外支持在稀疏张量上调用 `einsum`、`matmul` 和其他张量操作，且可以任意按维度组合格式。编译器使用三级 IR（CIN → LLIR → JIT 编译的 C++）。相同的下降管道可以发射稀疏-稀疏收缩、稠密矩阵乘法和混合稀疏-稠密内核。优化通道（如循环重排、分块、工作区插入和稀疏预取插入）适用于两种模式，TensorBench 任务通常要求智能体添加或扩展这些通道。附录 LABEL:app:scorch 给出了完整的架构。  

### 2.2 任务制定  

每个 TensorBench 任务将一个自然语言的功能或重构描述与一个固定的基础提交配对，该提交标识了要编辑的仓库状态。成功通过补丁后的测试套件来衡量：每次运行通过当且仅当该套件中的每个测试都通过，包括继承的回归测试和智能体添加的任何专门测试。我们在整篇论文中报告这个通过/失败标签。  

### 2.3 数据集构建  

TensorBench 包含 199 个任务：194 个*功能添加*任务和 5 个*重构*任务。每个任务有一个用于下面计数的主要类别：API（n=99）、Scheduler（37）、Runtime（28）、Format（20）、IR（8）和 Codegen（7）。单个任务可能涉及多个类别；附录 A.1 给出了完整的按类别细分及示例。在 199 个描述中，131 个明确提到了稠密行为，151 个明确提到了稀疏特定结构。集合有重叠，因为许多任务跨越两种模式：循环分裂适用于稠密和稀疏循环，稀疏池化具有稠密内部面板，混合稀疏-稠密内核出现在线性代数中。描述说明了请求的行为以及智能体应添加的测试。为了使基准测试构建可扩展，任务不提供测试输入；期望智能体编写自己的测试。评分使用智能体的测试和已有的套件。  

图 1 追踪了一个任务的端到端流程。`feature_outer_product` 任务来自 API 类别，要求一个稀疏外积 API。智能体的补丁展示了一个典型的 API 任务实现路径：它构建一个 CIN 表达式，通过 `CINLowerer` 和 `LLIRLowerer` 下降，然后通过 `load_inline` 进行 JIT 编译。许多 API 任务共享这种结构：一个小的用户可见的添加需要更改纯 IR 和代码生成任务直接修改的同一三级 IR。  

```markdown
Implement a sparse outer product operation `outer(a, b)` in `ops.py` that takes two 1D sparse vectors and produces a 2D sparse matrix. The CIN expression is `C[i,j] = A[i] * B[j]` (equivalent to `einsum "i,j->ij"`). This is a dimension-increasing operation—verify that the iteration lattice correctly handles it with no reduction variable. The format inference should produce an appropriate output format based on the inputs. The result has `nnz_a * nnz_b` non-zeros when both inputs are sparse. Write tests covering: sparse–sparse, sparse–dense, dense–dense, parity against `torch.outer(a.to_dense(), b.to_dense())`, multiple sparse formats, and edge cases like zero vectors. [...]  

Task prompt (abridged)
```

[⬇ 代码块省略，原文已保留]

```python
def outer(a, b, output_format=None):
    # ... input coercion omitted ...
    assert a.dim() == 1 and b.dim() == 1
    # ... format inference omitted ...
    C = TensorVar("C", fmt=output_format)
    A = TensorVar("A", fmt=a.format)
    B = TensorVar("B", fmt=b.format)
    i, j = IndexVar("i"), IndexVar("j")
    cin = ForAll(i, ForAll(j, TensorAssign(C[i,j], A[i]*B[j])))
    llir = CINLowerer().lower_IndexStmt(cin)
    cpp = LLIRLowerer().lower_llir(llir)
    module = load_inline(name="kernel",
        cpp_sources=[header_cpp, cpp], ...)
    return STensor(...)

Agent-produced patch (excerpt)
```

[⬇ 代码块省略，原文已保留]

```python
def test_outer_sparse_sparse():
    a_t = torch.tensor(
        [1., 0., 2., 0., 3.])
    b_t = torch.tensor(
        [7., 8., 0., 9.])
    a = STensor.from_torch(a_t)\
            .to_sparse("s")
    b = STensor.from_torch(b_t)\
            .to_sparse("s")
    result = outer(a, b)
    assert result.shape == (5, 4)
    assert torch.allclose(
        result.to_torch(),
        torch.outer(a_t, b_t))

Agent-added test (excerpt)
```

**图 1：** 来自 API 类别的 TensorBench 任务示例：`feature_outer_product`。**顶部：** 智能体的提示。**左下：** Claude 4.7 生成的代码摘录。**右下：** 智能体添加的测试之一。  

### 2.4 评分方法  

上游测试套件（每个基础提交 160–280 个测试函数，在参数化之后）主要由随机化的正确性测试组成。一个典型的测试会分配具有随机值和选定稀疏模式（对于稠密情况可能为 0%）的操作数张量，运行被测操作，并将结果与适当的参考实现进行比较。对于稀疏和混合稀疏-稠密算子，参考通常是稠密 PyTorch（通过 `torch.allclose`）；对于优化和调度更改，参考可能是现有的未优化执行路径。随机种子是显式的，稀疏率和形状在不同测试中变化，并且参数化会扫描多种格式组合，包括 CSR、DCSR、COO 和稠密张量。这些随机化扫描可以捕获孤立的手写示例经常遗漏的错误：坐标列表迭代中的差一错误、迭代格中缺失的项、稀疏-稀疏乘法的中断交叉逻辑，以及稠密-稠密矩阵乘法中编译错误的内循环。上游开发者维护这个套件作为项目的主要回归预防机制，我们直接使用它进行评分；附录 LABEL:app:test-pattern 逐字复制了一个规范的测试。因此，通过的补丁必须保留该套件覆盖的输入、格式和编译器路径上的内核行为，而不仅仅是智能体检查过的示例。  

#### 补丁后测试套件标准  

我们要求每个补丁后的测试都通过。已有的随机化套件检查现有编译器行为在稀疏格式转换、迭代逻辑、代码生成路径和支持的张量算子上的保留情况。对于新请求的行为，特定于任务的检查来自智能体添加的测试。因此，一次通过的运行表明实现和智能体添加的测试内部一致，同时保留了仓库的现有行为。它并不确立补丁满足自然语言请求的所有可能解释或边界情况这一更强的主张。第 3.6 节中的对抗性行为审计会检查智能体添加的测试或补丁结构是否利用了该标准，例如通过空洞的测试、API 不匹配、削弱现有测试或进行没有实质性代码更改的补丁。审计不判断功能正确性。表 1 中的通过率应与附录 LABEL:tab:audit-adversarial 中的审计率一起阅读。  

#### 对任务质量的鲁棒性  

TensorBench 对不完善的任务描述不太敏感，因为它对最终的仓库状态进行评分，而不是对完全指定的实现配方的遵从性。对于一个规定不充分的请求，有能力的智能体可以选择一个合理的解释，实现它，并添加使该解释明确的测试；然后回归套件会检查更改是否保留了现有的仓库行为。