SWE-bench 类基准通常把 Issue 描述当作问题陈述，把对应 PR 的补丁当作测试预言机，用于评估大语言模型解决真实软件问题的能力。这项研究指出，构建流程中的关键前提——PR 与其引用的 Issue 准确对应——在复杂代码仓库中并不总是成立。
PR-Issue 错位会影响评测基础
常见的数据构建方式，是从 PR 描述中提取 Issue 引用，再将两者配成一个评测实例。但仓库开发和维护过程并非严格的一题一解：PR 与 Issue 之间可能存在范围、目标或实现层面的偏差。论文系统检查了 SWE-bench Verified，发现 13.6% 的实例存在错位，覆盖五种模式和十一种细粒度场景。摘要没有披露这些模式的具体定义，因此目前不能进一步判断各类错位的占比与严重程度。
这类问题值得重视，因为基准默认模型应根据 Issue 生成与 PR 补丁相符的修改。如果问题陈述和测试依据本身不一致，模型即使合理解决了 Issue，也可能无法满足由 PR 补丁衍生的验证条件；反过来，通过测试也未必意味着完整解决了原始问题。
PAIChecker 如何进行核验
论文提出多智能体系统 PAIChecker，用于规模化检查 SWE-bench 类数据中的 PR-Issue 错位。系统采用三个阶段：先识别具体错位模式，再综合不同智能体给出的标签，最后通过代码级验证逐步确认。相比只对 Issue 和 PR 文本做一次判断，这一设计把模式识别、交叉判断与代码证据分开处理，目标是提升检测的准确性、泛化能力和可验证程度。
在 SWE-Gym 与 SWE-bench Multilingual 上，PAIChecker 使用四种大语言模型作为骨干均取得最佳表现，二分类准确率最高分别达到 92.12% 和 91.67%。不过摘要没有提供各骨干模型、对照方法、数据规模及误报漏报情况，因此这些结果仍需结合正文实验设置理解。
我的判断
这项工作的价值不只是清洗一批样本，而是提醒开发者：代码基准的可信度取决于 Issue、PR、补丁和测试之间是否形成一致证据链。PAIChecker 的分阶段多智能体方案适合用于新基准构建和现有数据复核，但它检测的是配对质量，不等同于全面验证任务难度、测试完备性或评分公平性。13.6% 的发现说明问题并非个例，但能否推广到更多仓库和构建流程，还需要更广泛的数据验证。