✨ 要点🔬 技术摘要
想象一下，你拥有一个非常天才、超级聪明的机器人助手，它为你编写计算机代码。这个机器人是在一个庞大的旧代码库上训练出来的，因此它懂得如何以“老办法”行事。但在现实世界中，软件工具（称为 API）不断升级，就像智能手机应用更新其按钮或改变文件保存方式一样。
问题在于，这个机器人不会自动学习这些新规则。如果你让它使用工具的新版本，它可能会顽固地继续使用旧版本，或者变得困惑并写出导致崩溃的代码。
模型编辑 是研究人员用来尝试“教导”机器人这些新规则的一种技术，而无需从头重建整个机器人。这就像试图向一个已经充满记忆的头脑发出特定指令，希望它只更新那一项内容，而不忘掉其他一切。
这篇论文就像是一次严格的压力测试，旨在检验这些“教学技巧”是否真的有效。以下是他们发现的简化说明：
1. “虚假成功”的陷阱
研究人员构建了一个包含 2,040 个编程谜题的特殊测试厨房。他们更改了特定工具的规则（例如重命名函数或添加必需步骤），并要求机器人使用新规则来解决这些谜题。
他们发现，许多机器人看似通过了测试，但实际上是在作弊 。
类比 ：想象你告诉一位厨师：“用新的电动刀切这根胡萝卜。”厨师完美地切好了胡萝卜，但他并没有使用电动刀，而是使用了藏在口袋里的一把钝黄油刀。结果 ：测试显示“成功！”，因为胡萝卜被切开了。但机器人并没有真正学会新规则；它只是找到了一种“变通方法”来完全绕过新工具。当研究人员强制机器人仅 使用新工具（移除变通方法）时，成功率急剧下降。
2. “一次性修复”与“雪球效应”
研究人员测试了两种场景：
单次编辑 ：教导机器人一条新规则。连续编辑 ：教导机器人一条新规则，然后另一条，再一条，就像雪球滚下山坡一样。
发现 ：
单次编辑 ：即使只教导一条规则，机器人也常常难以应对。它们要么写出无法运行的代码（语法错误），要么写出能运行但未正确使用新工具的代码。连续编辑 ：这简直是一场灾难。一旦试图连续教导机器人多条新规则，机器人的“大脑”似乎就崩溃了。其性能降至接近零。这就像试图在烤箱已经预热时往蛋糕面糊里添加新配料；整个混合物都塌陷了。
3. 它们在哪里失败了？
研究人员不仅统计了多少次失败，还深入分析了如何 失败。他们将过程分解为几个阶段：
编译（能运行吗？）： 代码甚至能启动吗？API 采用（它使用了新工具吗？）： 它是否真正使用了更新后的指令？执行（它起作用了吗？）： 它是否解决了问题？
发现 ：
当教导一条 新规则时，机器人失败的主要原因甚至是无法让代码开始运行（编译错误）。
当教导多条 规则时，机器人失败得更加严重，常常产生连计算机都无法阅读的胡言乱语或重复的无意义内容。
4. “记忆”与“搜索”问题
该论文测试了不同的“教学方法”。
有些方法试图将新规则记忆 在一个单独的笔记本中（基于记忆的方法）。这些方法在保持机器人其他技能 intact 方面表现尚可，但在正确应用新规则方面仍然挣扎。
其他方法试图搜索 机器人的大脑，并手术式地修改特定部分（定位后编辑）。这些方法非常脆弱；它们往往会破坏机器人编写其他 任务代码的能力，而不仅仅是新任务。
结论
该论文得出结论，当前用于“编辑”代码编写 AI 的方法尚未准备好投入现实世界应用 。
它们经常用看似成功实则不然的“变通方法”来欺骗我们。
当你尝试更新它们超过一次时，它们很容易崩溃。
它们难以区分“编写能运行的代码”与“编写正确使用新工具的代码”。
简而言之，我们目前还不能仅仅通过“修补”这些 AI 机器人来让它们跟上软件更新的步伐。我们需要更好的方法来教导它们，而不会导致它们忘记其他一切，或开始胡言乱语。
技术摘要：理解代码大语言模型中模型编辑的鲁棒性
问题陈述
用于代码的大语言模型（LLM）正日益集成到软件开发工作流中，然而它们在预训练后保持静态，而软件生态系统（如 Android、NumPy、pandas）却随着 API 更新持续演进。虽然模型编辑提供了一种轻量级的替代方案，用于在无需完全重新训练的情况下纳入这些更新，但现有编辑方法是否能在代码大语言模型中可靠地诱导正确的 API 迁移，目前尚不明确。
该领域的一个关键挑战在于区分真正的 API 采用 与基于变通方法的成功 。在代码生成中，模型可能通过替代实现（例如使用不同的算法或库）绕过更新的 API 从而通过测试用例，而非正确地迁移到新接口。此外，现有评估往往依赖表面形式指标（如 BLEU、精确匹配）或聚合任务成功率，这无法将编辑效果与先前的预训练暴露区分开来，也无法区分语法失败（编译错误）与语义失败（行为不正确）。此外，编辑方法在连续编辑 （随时间累积多个 API 更新）下的稳定性在很大程度上仍未被探索。
方法论
基准构建
作者引入了一个源自HumanEval 、MBPP 和APPS 的受控基准，包含2,040 个问题 ，涵盖140 种独特的合成 API 修改 。
合成修改 ：为了最小化预训练暴露带来的混淆，作者对标准解决方案应用了五种类型的合成 API 更改：
R1 ：API 重命名。S1–S4 ：参数修改（添加可选/必需参数、重新排序参数、更改返回类型）。
数据划分 ：该基准被划分为三个不同的划分：
可靠性 ：用于应用编辑（469 个实例）。泛化性 ：评估编辑后的模型是否在未见过的问题上正确使用更新后的 API（647 个实例）。特异性 ：评估在未修改 API 涉及的任务上性能是否得以保持（924 个实例）。
执行沙箱
一个自定义的执行沙箱在标准 Python 语义下强制执行编辑后的 API。它在执行模型生成的代码之前，用修改后的版本替换原始 API 定义。这确保了评估针对的是 API 适应，而非语言本身的变更。
评估框架
本研究在两种模式 （单次编辑 和连续编辑 ）下，对三种开源代码大语言模型 （CodeLlama-7B、CodeQwen1.5-7B、DeepSeek-Coder-6.7B）评估了七种最先进的编辑方法 。
指标 ：
Compiles@k ：至少有一个 k k k Pass@k ：至少有一个样本通过所有测试的概率。Successful Adoption@k ：解决方案正确使用编辑后 API 的 Pass@k。Workaround@k ：解决方案通过测试但避开编辑后 API 的 Pass@k。
Shapley 归因 ：将 Pass@k 分解为**可编译性（C C C 和 编译后正确性（Q Q Q 错误分类法 ：一种分类系统，将结果分为成功采用、变通成功，以及在编译、API 适应、执行和行为阶段的失败。
主要贡献
受控基准与沙箱 ：引入了一个包含合成 API 修改的基准和一个执行环境，该环境将编辑效果与预训练记忆隔离，并在评估期间强制执行更新后的 API。系统性实证研究 ：对三种模型和两种编辑模式下的七种编辑方法进行了全面评估，揭示了当前方法无法实现稳健的 API 更新。错误分类法与分解 ：开发了一种分类法，区分真正的 API 迁移与变通行为，并将失败定位到特定阶段（编译与编译后），提供了编辑失败的细粒度视图。
结果
单次编辑模式
泛化失败 ：编辑后的模型在需要修改后 API 的未见问题上泛化能力差。虽然基于记忆的方法（GRACE、A-GRACE）和微调（FT-L）比“定位后编辑”方法（ROME、MEMIT、PMET）表现出更高的韧性，但性能仍显著下降。变通方法普遍存在 ：相当一部分看似成功的案例是基于变通方法的。例如，在 CodeLlama 上使用 FT-L 时，Pass@5 为 0.40，但只有 0.17 对应成功采用，而 0.23 源于变通方法。“定位后编辑”方法通常表现出 Pass@k 与成功采用之间更大的差距。失败模式 ：Shapley 分解显示，泛化失败主要由编译错误驱动 （CF 范围从 43% 到 60%），而特异性失败 （在未修改任务上的回归）更多是编译后错误 （CF 范围从 5% 到 40%）。不可变通子集 ：当在严格需要目标 API 的问题子集上评估（消除变通方法）时，性能急剧下降。许多方法 - 模型组合的 Pass@k 崩溃至接近零，表明即使代码能够编译，也很少能正确实现编辑后的 API 行为。
连续编辑模式
灾难性崩溃 ：在连续编辑下，大多数方法 - 模型组合在泛化性和特异性上均崩溃至接近零的 Pass@k。不稳定性 ：MEMIT、PMET 和 ROME 等方法通常无法产生可用输出，或退化为重复的 token 序列（例如 defdefdef...）或语法错误。编译驱动的失败 ：与单次编辑不同，连续编辑导致的失败主要是编译驱动 的（CF 通常达到 100%），表明累积的编辑破坏了模型生成语法有效代码的能力。例外情况 ：GRACE 和 FT-L 表现出更好的稳定性，尽管与编辑前的基线相比，它们仍遭受显著的性能下降。
意义与主张
该论文声称，当前的模型编辑方法尚不足以支持代码大语言模型中现实的 API 迁移 。这项工作的主要意义在于证明：
聚合指标具有误导性 ：高 Pass@k 分数往往掩盖了未能采用更新 API 的事实，因为模型经常依赖变通方法。编辑引入不稳定性 ：即使是单次编辑也可能破坏模型生成可编译代码的能力，而连续编辑通常导致模型完全崩溃。评估必须细化 ：有效的代码编辑评估需要区分编译失败、API 适应错误和行为失败，并且必须明确测量是否实际使用了编辑后的接口。
作者总结道，该领域的进步不仅需要更准确的编辑方法，还需要支持在演进的软件生态系统中进行可靠、组合式更新的评估框架和基准设计。
每周获取最佳 machine learning 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。