薛定谔的代码仓库:LLM 是学会了 SWE-bench,还是记住了它?

TL;DR 针对仓库级基准的数据泄漏，**SchrodingerRepo** 动态变换仓库表示（保留可执行行为但抹去命名/布局等熟悉线索），发现主流 LLM 在 SWE-bench 上的表现会因失去记忆线索而下降，揭示了其部分依赖记忆而非真正推理。

问题

问题背景

仓库级代码评测基准（如 SWE-bench）已成为评估编码代理的核心标准，它们要求模型在真实开源仓库中定位并修复 issue。然而这类基准大量依赖公开仓库，这些仓库很可能出现在大模型训练语料中，导致评测分数被高估。

现有方法局限

现有评测使用静态仓库表示，即测试时仓库代码与线上版本一致，模型可能已经见过这些代码或其相关数据。即使模型没有直接记忆答案，它也可能熟悉仓库的命名约定、文件布局、实现模式等“仓库侧线索”，从而在无需真正理解仓库结构的情况下完成局部修复。这种数据泄漏让评测难以区分模型是在进行稳健的仓库推理，还是依赖于记忆的浅层模式匹配。同时，现有扰动方法（如变量重命名）往往只改变表面标识符，不能系统性消除多层级线索。

为什么这个问题难/重要

要构造一个既能保持原仓库可执行行为、又能有效侵蚀熟悉线索的等效仓库，需要在语义等价性与扰动强度之间取得平衡。过于保守的变换无法消除记忆，过于激进的变换可能破坏功能或引入新错误。这个问题直接关系到编码代理评测的可信度：如果模型依赖记忆，那么现有排行榜上的高分并不能反映其处理从未见过代码库的真实能力。业界需要一套动态实例化的评测协议，让每个测试实例在评估时才随机生成，从根本上减少静态泄漏的可能性。

行业类比

这类似于在自动驾驶评测中，若测试路线固定且公开，感知模型可能对特定场景过拟合；只有动态生成未见过但语义等价的路线，才能检验模型的泛化能力。

核心洞察

• 将测试仓库视为评估时的潜在变量，动态实例化而非静态复用，这颠覆了传统泄漏检测的范式。现有 SWE-bench 变体或静态扰动方法多基于固定快照做去污染或一次性混淆，而 SchrodingerRepo 在每次评估环境进入时生成行为等价的仓库变体，本质上是测量代理对‘未见仓库视图’的泛化能力，而非对特定快照的记忆。
• 四个变换层次并非随机扰动，而是定向侵蚀命名约定、文件布局、实现模式等仓库侧线索，同时保持可执行行为不变。这实现了对‘代码推理’与‘仓库记忆’的分离：实验发现性能下降与交互成本上升主要源于探索和定位难度增加，而非任务自身变难，直接证明当前编码代理部分依赖表面仓库线索，在持续集成或重构场景下可能脆弱。

方法

输入

SchrodingerRepo 以标准 repository-level 基准实例为输入，每个实例包含问题描述（issue statement）和对应的原始仓库代码快照。评估时，编码代理进入环境后会获得动态生成的仓库表示，而非静态原始仓库。

关键模块

该框架通过四个转换级别逐步侵蚀仓库中可记忆的显式线索，同时保持可执行行为不变：

1. 问题陈述重建：将原始 issue 中引用的具体标识符（类名、函数名、文件路径等）进行抽象化或替换，消除问题描述与代码的直接映射关系。
2. 命名空间重映射：对仓库内所有标识符（变量、函数、类、模块名）进行系统性重命名，破坏常见的命名约定。
3. 文件内布局重排序：重新排列源文件内部的定义顺序（如函数、类的声明顺序），改变代码阅读时的结构线索。
4. 功能保持重写：对实现逻辑进行等价变换（如提取子函数、改写循环结构、调整条件判断），使代码形式与原始实现显著不同但行为完全一致。

每个级别转换后均执行有效性检查（validity checks），确保仓库仍能通过原有测试。代理在转换后的仓库上解决问题后，其生成的补丁通过补丁恢复（patch recovery）机制映射回原始仓库上下文，以便与 ground truth 对比。

输出

最终输出为：1）动态实例化的仓库表示（每次评估时随机应用各级转换，消除静态记忆优势）；2）代理在转换后仓库上生成的补丁（经恢复后评估）；3）性能指标（任务解决率）与交互成本指标（探索步骤、token 消耗等）。

与同类方法的差异点

与静态扰动或数据污染缓解方法不同，SchrodingerRepo 将仓库表示视为评估时潜在变量，每次进入环境时动态生成新变换，杜绝了代理针对固定扰动形式的过拟合。

实验

实验设计概述

• 在 SWE-bench Verified 与 SWE-QA 两个仓库级基准上，对多款主流 LLM 驱动的 coding agent 进行评估。
• 核心方法是 SchrodingerRepo 框架，对测试仓库动态施加四级变换：问题陈述重构、命名空间重映射、文件内布局重排、功能保持重写。
• 变换后的仓库保留原始可执行行为，但移除命名、路径、布局等熟悉线索；随后让 agent 解决同一批 issue，记录解决率与交互成本。

关键发现

• 移除熟悉仓库线索后，所有模型的解决率均出现一致性下降，表明模型先前的高分部分来自对仓库側记忆特征的利用。
• 交互成本显著上升，额外开销主要发生在仓库探索与定位阶段，而非最终补丁生成阶段。
• 框架的层级化设计可区分模型对不同类型线索的依赖程度，为诊断泛化能力提供细粒度信号。

与基线对比解读

• 相比静态扰动类工作，SchrodingerRepo 将仓库表示视为评估时的隐变量，每次实例化唯一，更贴近真实开发中遇到陌生代码库的场景。
• 该工作揭示常规基准可能高估模型泛化能力：模型在熟悉仓库上表现好，但变换后性能下降，说明需要评估在重构或未见仓库上的定位与理解。
• 工程启示：评估 coding agent 时应纳入动态仓库表示，避免仅依赖流行开源仓库的固定版本；同时应监控交互成本，因为探索困难会直接影响实际部署效率。

行业影响

落地场景

SchrödingerRepo 主要服务于企业级 代码智能体 的评测与选型,尤其是需要长期维护私有代码库的团队。例如:电商平台的订单/库存服务在接入自动修复 agent 前,可对内部仓库做功能保持改写、命名空间重映射,生成语义等价但布局不同的测试实例,验证 agent 是否真正理解业务逻辑而非匹配常见开源模板。另一场景是代码评审自动化:内容平台或金融系统的 PR 审查工具可借此剔除对 SWE-bench 风格记忆,确保评审建议来自上下文推理。

商业价值

• 降本:减少因模型在公开基准上虚高、上线后误修代码导致的回滚与事故成本;动态变换增加探索成本,倒逼模型提升定位效率而不是靠记忆捷径。
• 增收/体验:更可靠的 agent 意味着更高自动化覆盖率,开发者可将精力转向架构设计;用户端功能迭代更快。
• 风险控制:在合规要求高的医疗/金融代码库,评测结论更真实,降低错误代码上线风险。

与现有产品/工作流接口

可作为独立 evaluation gate 插入 CI/CD:维护一份内部仓库的变换配置(namespace mapping、layout reorder、rewrite rules),在每次模型更新或 prompt 变更时触发动态评测。与 LLMOps 平台(如 LangSmith、W&B、MLflow)对接,记录 resolve rate、交互轮数、定位耗时等指标。对于已部署的代码助手(如 Copilot、CodeWhisperer),可将 SchrödingerRepo 生成的私有仓库变体作为回归集,监控线上推理是否出现记忆退化。

局限

• 论文主要基于 **SWE-bench Verified** 和 **SWE-QA** 两个数据集进行评估，两者都源自 Python 开源项目，任务类型集中在 issue 修复。这限制了结论向其他语言（如 Java、C++）、其他任务（如功能添加、代码重构）或非开源内部代码库的泛化能力。此外，四个变换级别虽覆盖命名、布局、实现模式，但未改变代码的算法逻辑或依赖拓扑，记忆化可能仍能通过深层语义关联绕过前三个浅层变换，只有在 Level 4 的 functionality-preserving rewrite 下才受到较强挑战。
• 论文承认 **SchrodingerRepo** 动态实例化仓库可能无意中改变了任务难度，因为它们采用 `functionality-preserving` 变换可能引入新的边界条件或降低代码可读性，导致代理性能下降并非完全源于消除记忆线索，而是任务本身变难。文中尝试通过人类评估验证变换保持等价性，但未完全排除模型对变换后代码风格不适应带来的额外成本，而非稳健推理能力不足。另外，该框架依赖 LLM 自身进行部分变换（如问题陈述重建），可能引入 LLM 偏差，影响变换的客观性。
• 与现有静态扰动方法（如变量重命名、文件重排）相比，**SchrodingerRepo** 的变换更系统且针对仓库级线索，但仍属于事后扰动，未从根本上解决训练数据污染。它无法识别或量化模型在训练阶段具体记忆了哪些仓库片段，只能通过性能下降间接推断。此外，评估成本较高，因为每个实例需要动态生成变换后的仓库，且代理交互成本显著上升，限制了其在快速迭代或大规模基准上的应用。