💻 computer science

Learned or Memorized ? Quantifying Memorization Advantage in Code LLMs

该论文提出了一种基于扰动的量化方法来评估代码大语言模型的“记忆优势”，通过对 8 个开源模型在四大任务领域的测试发现，记忆风险高度依赖于具体模型和任务类型，且 CVEFixes 与 Defects4J 等常被质疑存在数据泄露的基准测试实际上表现出较低的记忆优势，表明模型更多依赖泛化能力而非直接记忆。

原作者： Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

发布于 2026-04-16

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是在给现在的"AI 程序员”们做一场**“突击体检”，目的是搞清楚它们到底是真的学会了编程**，还是仅仅在死记硬背题库。

下面我用几个生活中的比喻，把这篇论文的核心内容讲给你听：

1. 核心问题：是“学霸”还是“背题家”？

现在的 AI 写代码能力很强，但大家心里都犯嘀咕：它们是真的理解了代码逻辑，还是因为训练数据里包含了考试题目（比如 GitHub 上的开源代码、常见的编程题库），所以只是把答案背下来了？

这就好比一个学生：

真学霸（泛化能力强）： 理解了数学公式，换个数字、换个问法，他都能算出正确答案。
背题家（死记硬背）： 只记住了原题和答案。一旦题目稍微改几个字（比如把“求和”改成“求积”，或者把变量名从 x 改成 a），他就懵了，直接交白卷。

2. 论文的方法：给题目“动点手脚”

为了区分这两种情况，作者们发明了一个**“捣乱测试法”**（Perturbation-based approach）。

想象一下，你给 AI 出一道题：“写个函数计算 1 到 10 的平方和”。

正常情况： AI 答对了。
捣乱测试： 作者们把题目稍微改一下，比如改成：“写个函数，把前 10 个自然数每个都四次方后加起来”（意思一样，但说法变了），或者把代码里的变量名 n 改成 my_number。

关键逻辑是：

如果 AI 是背题家：题目稍微变个样，它就像断了线的风筝，性能瞬间崩塌（因为它只记得原题的样子）。
如果 AI 是真学霸：题目变个样，它依然能稳稳地写出正确答案（因为它懂逻辑）。

作者给这种“题目一变就崩”的程度起了个名字叫**“记忆优势”**（Memorization Advantage）。数值越高，说明它越依赖死记硬背；数值越低，说明它越靠真本事。

3. 主要发现：意想不到的反转

作者测试了 8 种流行的 AI 模型和 19 个著名的编程测试集，发现了一些很有趣的现象：

🌟 发现一：有些“老题库”其实很安全

以前大家总怀疑像 Defects4J（找 Bug 的题库）和 CVEFixes（修复安全漏洞的题库）被 AI 背下来了，因为 AI 在这些题上得分很高。

结果： 作者一“捣乱”，发现 AI 在这些题上非常稳！哪怕题目变了，AI 依然能修好 Bug。
结论： 看来 AI 是真的学会了怎么找 Bug 和修漏洞，而不是在背答案。这给这些数据集“洗清了冤屈”。

🌟 发现二：有些模型是“偏科生”

StarCoder 这个模型，在 APPS（一个编程竞赛题库）上表现得很奇怪。题目稍微一变，它的分数就暴跌。
结论： 这说明 StarCoder 很可能把 APPS 题库背得滚瓜烂熟，但并没有真正理解里面的逻辑。一旦换个问法，它就露馅了。

🌟 发现三：任务越难，越容易“露馅”

代码总结（Code Summarization）： 让 AI 把代码翻译成中文。这个任务大家表现都很好，非常稳。说明 AI 对“代码和语言的关系”理解得很透彻。
生成测试用例（Test Generation）： 让 AI 给代码写测试。这个任务大家表现都很脆弱，题目一变就容易出错。说明 AI 在这方面的“举一反三”能力还比较弱。

4. 为什么这很重要？

这就好比我们在招聘程序员：

如果只靠死记硬背（高记忆优势），一旦公司换了新的技术栈，或者遇到了没见过的 Bug，这个程序员就废了。
如果靠真正理解（低记忆优势），他就能适应各种新环境，解决新问题。

这篇论文告诉我们：

别光看分数： 以前大家看 AI 在某个榜单上得分高就觉得它强，现在知道，得分高可能是因为题目被“背”了。
要换个方式考： 以后评估 AI，不能只让它做原题，得给它变着花样出题，看看它是不是真的懂了。
有些模型更靠谱： 比如 QwenCoder 和 CodeLlama 在大多数任务上表现得更“抗造”，说明它们更像真学霸。

总结

这篇论文就像给 AI 界做了一次**“去伪存真”**的大扫除。它告诉我们：现在的 AI 确实很聪明，能真正理解很多编程概念，但也有一些模型在特定领域还在“死记硬背”。

未来的方向是：我们要设计更聪明的考试（动态题库、变着花样出题），逼着 AI 从“背题家”进化成真正的“编程大师”。

1. 研究背景与问题 (Problem)

核心挑战：大语言模型（LLM）在代码生成、理解等任务上表现优异，但由于训练数据集（如 GitHub 代码库）通常不公开，导致难以检测数据泄露（Data Leakage）。如果模型在训练阶段已经见过评估基准（Benchmark）中的数据，其表现提升可能源于“记忆”而非“泛化”。
现有局限：
- 缺乏透明度：训练数据细节通常被商业或隐私原因隐藏。
- 检测困难：传统方法需要模型内部细节或部分训练数据，难以实施。
- 评估偏差：许多广泛使用的基准（如 Defects4J, CVEFixes）被怀疑存在数据污染，导致对模型真实能力的误判。
研究目标：提出一种不依赖内部模型细节的方法，通过量化模型对输入扰动的敏感性，来区分“记忆”与“泛化”，从而评估代码 LLM 的真实能力。

2. 方法论 (Methodology)

论文提出了一种基于扰动敏感性（Perturbation Sensitivity）的评估框架，核心假设是扰动敏感性假设（Perturbation Sensitivity Hypothesis, PSH）：

核心逻辑：
- 记忆（Memorization）：如果模型只是记住了训练数据中的特定片段，当输入发生微小扰动（如变量重命名、提示词改写）时，性能会急剧下降。
- 泛化（Generalization）：如果模型真正理解了底层逻辑和模式，即使输入发生扰动，其性能下降应该是渐进且平缓的。
记忆优势（Memorization Advantage, $ma$）：定义为模型处理“已见数据”（原始输入）与“未见数据”（扰动后输入）时的性能差异。
- 公式： $ma(M, x, y) = |p_\theta(y|x) - p_\theta(y|x'(x))|$ ，其中 $x'$ 是 $x$ 的扰动版本。
实验流程：
1. 输入扰动：
  - 自然语言扰动（NL2Code）：使用 BART 模型对提示词进行同义改写，按余弦距离排序生成不同强度的扰动版本。
  - 代码扰动（Code2Code/Code2NL）：对代码中的标识符（变量名、函数名）进行随机重命名（Alpha-renaming），保持语义不变但改变语法结构。
2. 性能测量：对每个扰动级别，多次采样生成输出，计算与参考输出的距离（如编辑距离），量化性能下降幅度。
3. 敏感性计算：计算连续扰动级别间性能下降的最大值作为敏感性分数。分数越高，表明模型越依赖记忆；分数越低，表明泛化能力越强。
4. 统计检验：使用 Mann-Whitney U 检验（Bonferroni 校正）来识别不同模型或基准间敏感性分布的显著差异。

3. 实验设置 (Experimental Setup)

模型：评估了 8 个开源代码 LLM，涵盖不同架构和训练方法：
- DeepSeek-Coder-V2 (16B), Qwen2.5-Coder (14B), StarCoder (15B), CodeLlama (13B), Codestral (22B), OpenCoder (8B), WizardCoder (33B), Magicoder (7B)。
基准数据集：覆盖 4 大类任务，共 19 个基准：
1. 代码生成 (Code Generation)：HumanEval, APPS, MBPP, CodeContest 等。
2. 测试生成 (Test Generation)：BigCodeBench, TestEval, QuixBugs。
3. 程序修复 (Program Repair)：Defects4J, ConDefects, QuixBugs。
4. 漏洞检测 (Vulnerability Detection)：CVEFixes, VulDetectBench, DiverseVul 等。
5. 代码摘要 (Code Summarization)：CodeSearchNet, TLCode-Sum。

4. 关键结果 (Key Results)

4.1 任务类别差异

代码摘要（Code Summarization）：所有模型表现出最低的敏感性（< 0.3），表明模型在此任务上具有极强的泛化能力，不易受扰动影响。
测试生成（Test Generation）：敏感性显著较高（0.4 - 0.7），表明生成测试用例比生成代码本身更难泛化，模型更依赖特定模式。
程序修复与漏洞检测：表现出极大的敏感性差异，从 <0.1 到 >0.8 不等，说明不同任务对泛化能力的要求不同。

4.2 模型差异

StarCoder：在 APPS 基准上表现出极高的敏感性（~0.8），显著高于其他模型，暗示该模型可能在 APPS 数据集上存在严重的记忆/数据泄露。
QwenCoder 和 CodeLlama：在大多数基准上保持较低的敏感性（<0.4），显示出更稳健的泛化能力。
结论：参数量相近的模型，因架构设计和训练方法不同，泛化能力差异巨大。

4.3 对争议基准的重新评估（重要发现）

Defects4J：传统上被怀疑存在数据泄露，但本研究发现其敏感性显著较低（0.2-0.4），表明模型在此基准上表现好是因为真正泛化了 Bug 修复模式，而非死记硬背。
CVEFixes：表现出极低的敏感性（<0.1），挑战了该基准存在数据泄露的普遍担忧。模型似乎成功泛化了常见的漏洞模式。
MBPP：尽管看似基础，但所有模型在此基准上的敏感性都较高，暗示其问题可能需要更具体的知识模式，难以通过通用泛化解决。

5. 主要贡献 (Key Contributions)

方法论创新：首次将提示词/代码扰动敏感性分析系统性地应用于量化代码 LLM 的“记忆优势”，提供了区分记忆与泛化的实证框架。
大规模实证评估：对 8 个 SOTA 模型在 19 个基准上的表现进行了全面评估，覆盖了生成、理解、修复和安全等核心软件工程任务。
挑战既有假设：通过数据证明，广泛使用的基准（如 CVEFixes 和 Defects4J）并未表现出预期的数据泄露特征，模型在这些任务上可能具备真实的泛化能力。
揭示模型差异：发现即使参数量相似，不同模型（如 StarCoder vs. CodeLlama）的敏感性模式截然不同，强调了架构和训练策略对泛化能力的关键影响。
任务洞察：指出代码摘要是泛化最好的任务，而测试生成和上下文相关的程序修复是目前模型泛化能力最薄弱的环节。

6. 意义与启示 (Significance)

评估框架的改进：传统的性能指标（如 Pass@k）不足以评估模型真实性能。未来的评估应包含扰动敏感性分析，以检测潜在的过拟合或记忆效应。
基准构建建议：
- 推荐使用动态基准（Dynamic Benchmarks），定期更新以防止数据泄露。
- 在报告性能时，应同时报告扰动敏感性分数。
模型开发指导：单纯增加参数量或训练数据可能不如优化架构设计和训练方法（如指令微调）对提升泛化能力有效。
安全领域警示：在漏洞检测等安全关键领域，模型敏感性分布极广（从<0.1 到>0.8），意味着某些模型可能仅靠记忆漏洞特征工作，这在面对新型漏洞时存在巨大风险。

总结

该论文通过引入“扰动敏感性”这一指标，为理解代码大语言模型的“黑盒”行为提供了新的视角。它不仅揭示了当前模型在不同任务上的泛化边界，还纠正了学术界对某些经典基准存在数据泄露的过度担忧，为构建更可靠、更透明的代码 AI 评估体系奠定了重要基础。