LLMs Meet Library Evolution: Evaluating Deprecated API Usage in LLM-based Code Completion(ICSE 2025 引用数46)

论文链接:LLMs Meet Library Evolution: Evaluating Deprecated API Usage in LLM-based Code Completion

论文开源仓库：AhmedNusayer/knowledge-conflict-codegen

动机

软件库的快速迭代发展，其中的api的动态变化给靠静态参数化知识进行推理的LLM 带来了巨大挑战，后续虽然RAG技术一定程度上可以提供最新的api规范知识，但是其随之产生的“context-memory conflict” 即当外部指令与模型内部参数知识发生矛盾。本文旨在调研这个问题，并且尝试解决这个问题。

核心贡献

1.构建了一个蕴含8个python库的包含实际api演化的benchmark，但是似乎没有开源。

构建数据集情况：

2.基于4种LLM及其变种进行系统实验，研究其遵循外部api更新代码的能力，核心研究了LLM是否真的遵循外部提供的信息，以及遵循的程度

3.研究了基于Chain-of-Thought (CoT) and Self-Reflection (SR)提示方式在对应实验任务上对相关LLM的优化效果

实验部分

本文核心任务是代码生成任务，核心是给一段原始待修改的代码+提示词，判断生成的代码是否正确。

作者先将api变化主要分成了三类：P1(api弃用)、P2(api修改)、P3(api添加)

对应这三类不同的情况，设计了三类不同的代码生成任务：

• P1(api弃用)任务：要求模型使用所提供文档中指定的替代 API 生成最新代码
• P2(api修改)任务：要求模型使用所提供文档中指定的修改后的 API 生成最新代码
• P3(api添加)任务：要求模型生成演示新引入的 API 用法的代码。

除了基础prompt，这里还有两个核心的内容：

update_description：总结 API 更改的性质（例如，函数 scipy.histogram 已弃用并从 SciPy 的主命名空间中删除。直接使用 numpy.histogram。）

API_doc： 更新的 API 的完整 API 文档 (Doc)，包括其签名、参数和使用说明

同时作者还探究了两种基于推理的提示词技术，Chain-of-Thought (CoT)和Self-Reflection (SR) ，这里简要介绍一下这两个技术主要是怎么做的：

Chain-of-Thought (CoT)：在提示词中显示加入提示”请一步一步思考“或者在提示词中显示加入修改的样例（few-shot）

Self-Reflection (SR)：引入两阶段生成过程，其中模型首先生成初始代码示例，然后严格审查其自己的输出。在反思阶段，明确要求模型检查生成的实现是否正确遵循提供的 API 文档和更新描述，识别任何不一致之处（特别是可能使用过时的 API 模式的情况），并相应地修改代码。

评估方式

API Adoption Rate

API Adoption Rate：衡量生成的代码是否尝试采用外部上下文中提供的更新的 API 规范（要求比较低，属于粗粒度的）：

P1（api弃用）任务中，只要代码至少使用了推荐的替代 API，即使它没有正确使用（即错误的参数）也算对；

P2（API 修改）任务中，只要生成的代码至少反映了修改的某些方面，例如使用修改后的参数结构，即使参数定位或数据类型不完全正确也算正确；

P3（api增加）任务，只要生成的代码尝试使用新引入的 API，即使它并不完整，也算正确

其中它使用了GPT5-mini作为自动评估模型，通过和纯人工评估对比，其获得了91.4%的准确率，说明其是相对比较可靠的。

Executable Rate

前一个指标代表静态检查，而可执行率可以考虑代码是否可以成功通过编译运行，可以将成功执行作为完全正确的指标，在docker虚拟环境中执行评估。

实验结果

1.实验发现仅靠更新的大致描述（UD），LLM的过期知识不足以推导生成最新规范的代码内容，格外提一嘴T3图上有个奇怪的数据，Deepseek-coder在P3任务上，1.3B的模型竟然稳定好于33B的模型，同样奇怪的还有基于P3任务下，在两种评估方式下，似乎中间规模参数的模型表现的比大规模参数的模型更好，具体成因尚不能解释。

2.当UD结合详细的API文档时候，两个评估方式下指标都大幅度提升，同时在结合CoT和SR这类提示词工程相关技术后有进一步提升。

3.在不同种类任务之间的表现差异上，显然P2-API修改场景下的代码生成是最有挑战性的，这和其修改前后高度相似应该是有一定关联。

4.同时发现基于CoT和SR的提升绝大多数的提升来着于SR，一种解释是SR将生成任务转换为验证任务。 UD+Doc 下的最初一代很容易出现由知识锚定或幻觉驱动的结构错误， SR 的自检为模型在最终输出之前捕获结构代码错误创造了第二次机会。在前向生成期间不可见但在根据提供的规范进行后向验证期间可检测到的错误。

样例分析

论文将失败分为两个层次。

第一层：完全没有采用 API 更新

在最佳配置 UD+Doc+CoT+SR 下，仍有 195 个样例没有采用更新后的 API。

总体分布为：

最主要的问题是：模型即使已经看到了新 API 文档，仍然像没有看到外部上下文一样，直接调用记忆中的旧接口。

不同 API 类型的失败模式也不同：

• P1 API 弃用：剩余失败很少，主要是新旧 API 混合使用；
• P2 API 修改：43.4% 的失败来自参数层面的遗漏，即使用了正确函数，但忽略了参数变化；
• P3 API 新增：63% 的失败来自幻觉 API，模型会编造一个看起来合理但实际不存在的函数。

这表明模型对函数名称级别的变化较敏感，但对参数级别的细微变化更容易忽略。

第二层：采用了 API，但代码无法运行

论文分析了 781 个已经采用新 API、但执行失败的样例。

其中 52.1% 的执行失败直接由 API 使用错误造成。

最典型的两类问题是：

1. 参数错误：使用不存在的参数、遗漏必需参数、参数名错误、类型错误或顺序错误。
2. 行为幻觉：虽然调用了正确 API，但错误假设其返回类型或运行行为，例如在返回结果上调用一个不存在的方法。

这说明静态检查“函数名是否正确”远远不够，必须真正执行代码，才能发现模型对 API 语义和行为的错误理解。

结论

1. LLM 中的旧 API 知识很难被完全覆盖

即使提示词明确提供了最新 API 更新和完整文档，模型仍然可能：

• 忽略外部信息；
• 继续使用旧 API；
• 使用旧参数形式；
• 将新旧调用方式混合；
• 根据旧知识推断新 API 的行为。

因此，RAG 或上下文注入并不能天然解决知识过时问题。模型内部参数知识与外部文档之间存在持续的 context-memory conflict。

2. 最新 API 文档应成为代码生成系统的核心输入

相比模型规模和提示词推理策略，完整 API 文档是实验中提升最大的因素。

论文建议 IDE 插件、Copilot 类工具和代码 RAG 系统自动完成：

1. 检测代码依赖的库和版本；
2. 检索对应版本的官方文档；
3. 注入函数签名、参数约束、返回类型和示例；
4. 避免只提供简短的版本更新说明。

3. Self-Reflection 应优先用于高冲突任务

SR 尤其适合：

• 已有 API 的参数或行为发生修改；
• 使用模型训练截止时间之后新增的 API；
• 文档与模型已有调用习惯明显冲突的任务。

相比让模型生成更长的思维链，更有效的做法是让模型在生成后，逐项对照文档验证代码。

4. 不能只评估 API 名称是否采用

模型可能选择了正确 API，但代码依然不能运行。因此，评测 API 演化能力时至少需要区分：

• 是否采用更新 API；
• 参数和上下文是否正确；
• 代码能否在目标库版本中执行；
• 运行行为是否符合 API 规范。

论文采用“先判断 Adoption，再执行代码”的两阶段评测，比单纯字符串匹配更能反映真实代码质量。

5. 需要持续更新的 API 演化基准

HumanEval、MBPP、SWE-bench 等传统基准通常无法专门检验训练截止时间之后的 API 变化。

论文建议构建持续更新的 benchmark：

• 随库版本发布不断加入新 API；
• 明确保证任务发生在模型知识截止时间之后；
• 覆盖弃用、修改和新增等多种演化模式；
• 在精调数据中加入 API 迁移样例，降低模型对旧调用方式的依赖。

这篇论文最重要的实验结论可以概括为：

给 LLM 提供最新 API 文档，能够显著提高它采用新 API 的概率，但无法保证代码可运行；参数修改等细粒度 API 演化最容易触发模型旧知识与外部文档之间的冲突。模型规模只能部分改善问题，而生成后的 Self-Reflection 检查，对修正参数错误和行为幻觉更有效。

从数值上看：

• 仅提供更新说明：74.64% 采用率、42.55% 可执行率；
• 加入完整文档：92.87% 采用率、66.36% 可执行率；
• 再加入 CoT 和 SR：采用率提升有限，但可执行率相对 UD+Doc 提升 11.33%；
• 即使在最佳提示策略下，错误参数和 API 行为幻觉仍是主要执行失败原因。