Understanding Robustness of Model Editing in Code LLMs: An Empirical Study

• ArXiv URL: http://arxiv.org/abs/2511.03182v1

• 作者: Umar Farooq; Vinaik Chhetri

• 发布机构: Louisiana State University; University of Kentucky

---

TL;DR

本文通过一项在受控环境中进行的系统性实证研究发现，现有的模型编辑方法在更新代码大语言模型（code LLMs）以适应API演进时，表现出有限且不稳定的适应能力，普遍导致模型性能显著下降，且多数成功案例依赖变通方案而非真正采纳新API。

关键定义

本文为评估模型编辑的鲁棒性，提出并沿用了一套清晰的评估框架和术语，其中核心概念包括：

1. 即时编辑 (Instant Editing)：一种评估设定，指对模型进行单次、孤立的API更新，旨在检验模型能否在不受其他编辑干扰的情况下，精确、稳定地集成单个知识变更。
2. 序列编辑 (Sequential Editing)：一种评估设定，指对模型进行一系列累积的API更新，模拟软件生态系统持续演进的真实场景。此设定用于评估模型在连续吸收新知识时，性能是否会饱和、衰退或产生干扰。
3. 可靠性子集 (Reliability Subset)：用于评估模型在接受编辑的、已见过的任务上的表现，衡量编辑操作的直接正确性与稳定性。
4. 泛化性子集 (Generalization Subset)：用于测试模型在未见过的新任务中，能否正确应用已被编辑的API知识，衡量编辑效果的迁移能力。
5. 特异性子集 (Specificity Subset)：包含与编辑目标无关的任务，用于检测编辑操作是否对模型在其他不相关任务上的性能产生负面影响（即回归或意外副作用）。

相关工作

当前的软件开发越来越依赖于代码大语言模型（code Large Language Models, LLMs），如CodeLlama、GPT系列等，它们在代码生成、重构和修复等任务中展现了强大的能力。然而，这些模型在预训练后通常是静态的，而编程语言、库和API却在不断快速演进，导致模型生成的代码可能过时或不兼容，从而降低了其可靠性。

完全重新训练模型以跟上这些变化的成本极其高昂。因此，模型编辑 (model editing) 作为一种轻量级替代方案应运而生，它旨在通过修改模型的一小部分参数来更新或修正其内部知识，而无需从头开始训练。在自然语言处理领域，模型编辑主要关注事实性知识的修正（例如，“X国的首都是Y”更新为“Z”），并要求这种修改是局部的，不影响模型在其他无关问题上的表现。

然而，将模型编辑应用于代码领域面临更严苛的挑战。一次成功的代码编辑不仅要保证生成的代码语法有效 (syntactic validity) 且能够编译通过，还必须实现功能正确 (functional correctness)（即通过所有单元测试），并与新API的语义对齐 (semantic alignment)。此外，模型可能会生成“变通方案”——不使用新API但仍能通过测试的代码，这会造成编辑成功的假象。

尽管需求迫切，但目前对代码LLMs模型编辑的系统性研究非常有限。已有工作（如CLMEEval）主要依赖可能存在数据泄露风险的旧数据集，且评估侧重于文本层面的正确性，缺乏编译和执行层面的验证。

本文旨在解决这一核心问题：现有的模型编辑方法在应用于代码LLM以适应不断变化的API时，其鲁棒性、泛化性和稳定性究竟如何？它们是实现了真正的语义适配，还是仅仅进行了表面的、不可靠的修复？

本文方法

为系统性地评估代码LLM中模型编辑的鲁棒性，本文设计并执行了一项全面的实证研究。其核心方法论并非提出一种新的编辑算法，而是构建了一个严谨、可控的评测框架，以深入剖析现有方法的表现。

研究设计

本文的评测框架围绕六个关键维度展开，如下表所示。

维度	具体内容
模型 (Models)	三个主流开源代码LLM：CodeLlama-7B, CodeQwen1.5-7B, DeepSeek-Coder-6.7B
方法 (Methods)	五种代表性的模型编辑方法：FT, GRACE, MEMIT, PMET, ROME
编辑机制 (Regimes)	即时编辑 (Instant Editing) 和 序列编辑 (Sequential Editing)
评测子集 (Subsets)	可靠性 (Reliability), 泛化性 (Generalization), 特异性 (Specificity)
正确性指标 (Metrics)	三个层次：编译成功、部分测试通过、完全测试通过 (Pass@k, k=1,3,5)
API采纳情况 (Adoption)	分析是正确采纳、错误采纳还是采用变通方案

模型与编辑方法

本文选取了五种代表了模型编辑领域三种主流范式的方法进行评估：

方法	范式	核心机制
FT (Constrained Fine-Tuning)	全局优化	微调模型少量参数，并施加约束以防止在无关数据上性能下降。
GRACE	外部记忆	不修改原模型参数，通过一个外部的键值记忆模块（码本）来存储和应用编辑。
ROME (Rank-One Model Editing)	局部修改	定位并精准修改单个关键前馈网络（FFN）层的权重矩阵，以植入新知识。
MEMIT	局部修改	ROME的扩展，通过识别和修改多个层的MLP权重来支持批量编辑。
PMET	局部修改	优化了FFN隐藏状态的更新方式，旨在消除其他组件（如MHSA）的噪声，实现更精确的编辑。

编辑机制

为模拟不同应用场景，研究采用了两种编辑机制：

• 即时编辑 (Instant Editing)：单独应用和评估每一个API变更，检验单次编辑的精确性和稳定性。
• 序列编辑 (Sequential Editing)：累积应用多个API变更，模拟软件随时间持续演进的真实情况，考察方法的累积效应和鲁棒性。

数据集与环境

为了实现可控且可复现的评估，本文构建了一个基于合成API废弃 (synthetic API deprecations) 的基准测试。该基准在两个广泛使用的Python代码生成数据集HumanEval和MBPP之上进行构建。

核心思想：将数据集中原有的标准库函数（如 \(os.path.join\)）替换为功能相同但名称和用法不同的自定义函数（如 \(my_os_path_join\)）。这样做有两大优势：

1. 杜绝数据泄露：确保所有被测模型在其预训练语料中都未见过这些新的API，从而保证评估的是模型的适应能力而非记忆。
2. 强制执行验证：在测试环境中，旧的API被移除，只有正确使用新API的代码才能编译和执行成功。

数据集统计	值
问题总数	797
涉及的独立API数量	65
可靠性子集 (Reliability)	259 个问题 (33%)
泛化性子集 (Generalization)	328 个问题 (41%)
特异性子集 (Specificity)	210 个问题 (26%)

评测指标与研究问题

本文从四个核心研究问题（RQs）出发，对实验结果进行分析：

1. RQ1: 单次编辑的鲁棒性如何？
2. RQ2: 连续的累积编辑会产生什么影响？
3. RQ3: 编辑是带来了真正的语义适配，还是仅仅是表面的变通？
4. RQ4: 编辑在哪些环节会失败？

评估在三个正确性层次上进行，并使用代码生成任务中标准的 \(Pass@k\) 指标（即模型生成k个候选答案中至少有一个通过的概率）。

创新点

本文方法论的创新之处在于其严谨的评估框架，而非提出新编辑模型。

• 受控的合成基准：通过合成API变更，首次为代码LLM的编辑评估提供了一个无数据泄露、公平可比的环境。
• 编译器集成与执行验证：评估超越了传统的文本匹配，引入了编译和单元测试，直接衡量代码的实际可用性。
• 多维度的鲁棒性评估：通过可靠性、泛化性和特异性三个子集，系统地剖析了编辑操作的直接效果、迁移能力和副作用。
• 区分真实采纳与变通方案：深入分析模型输出，区分了真正学会使用新API的情况和绕过新API但碰巧通过测试的情况。

实验结论

本文通过全面的实验，揭示了当前模型编辑方法在应用于代码LLM时的严重局限性。

• 单次编辑显著降低模型性能：
  • 即使是单次、孤立的编辑（即时编辑），也会对模型性能造成普遍的负面影响。在某些情况下，代码的语法有效性下降高达86个百分点，功能正确性（即使在表现最好的设定下）也下降了45个百分点。
  • 在所有方法中，GRACE在保持不相关任务性能（特异性）方面表现最好，能有效将变更局部化。但即使是GRACE，在泛化任务上的性能也下降了多达45个百分点。
  • 增加采样次数（\(Pass@k\)中的k增大）虽能将成功率提升8-10个百分点，但无法解决鲁棒性差的核心问题。
• 序列编辑导致性能崩溃：
  • 当连续进行API更新（序列编辑）时，所有模型的性能都迅速恶化，正确率在几次更新后就下降了60%到80%。大多数模型的性能在最初的10-20次编辑内就已崩溃。
  • GRACE在序列编辑中表现出相对较好的韧性，能维持更长时间的中等性能，但最终也无法避免衰退。CodeQwen1.5-7B是三款模型中最具韧性的，而DeepSeek-Coder-6.7B则最早失效。
• 编辑效果多为表面修复，而非真正采纳：
  • 在所有通过测试的生成结果中，模型真正正确采纳新API的情况仅占约6%。绝大多数“成功”案例依赖于变通方案 (workarounds)，例如重新实现已废弃的功能，而不是使用新的API。
  • GRACE是唯一对“正确采纳”有显著贡献的方法，但其效果同样随序列编辑次数的增加而减弱。FT虽在序列编辑中略有增益，但也引入了大量“错误采纳”（使用新API但代码功能错误）。
• 常见的失败模式分析：
  • 多数方法（ROME, MEMIT, PMET）生成的代码常包含结构性错误，如导入失败或语法问题，导致无法编译。
  • FT和GRACE能更好地保留代码的可编译性，但生成的代码常常功能不正确（只通过部分测试）或在多次采样中表现不稳定。
  • 一个令人担忧的现象是，近30%的“成功”编辑在不相关的任务上引入了新的bug（回归）。

总结

研究结果清晰地表明，当前主流的模型编辑方法在应用于代码LLM时，其适应能力非常有限且极不稳定。它们无法可靠地处理软件生态系统中的API演进，不仅难以实现真正的语义适配，还常常导致模型原有能力的退化。本文的研究强调，为了让代码LLM在不断变化的软件环境中保持其实用性和可靠性，迫切需要开发专门为代码领域设计的、能够结合参数更新与程序级推理的新型编辑技术。