[Paper] Model See, Model Do? 曝光感知的 Bug‑vs‑Fix 偏好评估 in Code LLMs

Source: arXiv - 2601.10496v1

概览

大型语言模型（LLM）如今已成为代码生成和自动调试的常用工具，但它们仍可能生成带有错误的代码片段，这些错误往往是从训练数据中复制而来。本文提出了一种 面向曝光的评估框架，用于衡量模型在先前“见过”错误代码与修复代码的情况下，在完成或排序代码时的偏好如何受到影响。通过探查这种偏差，作者揭示了一种隐藏的风险：LLM 可能会无意中传播记忆中的错误。

关键贡献

• 曝光感知基准: 将 ManySStuBs4J 错误修复数据集与在 Stack‑V2 语料库上进行的 “Data Portraits” 成员资格测试相结合，以推断每个有缺陷或已修复的变体是否可能出现在模型的训练集里。
• 分层分析: 按曝光状态（均未见、仅见到错误、仅见到修复、两者皆见）对示例进行分组，并在这些层次上评估模型行为。
• 双重评估视角:
  • 生成: 测量模型在代码补全场景中重新生成错误行与修复行的频率。
  • 似然评分: 使用多种 token 概率度量（最小/最大 token 概率、Gini 系数等）来判断模型认为哪个变体更可能。
• 实证发现: 表明当错误在训练期间被曝光时，模型更倾向于重新生成错误代码，而基于似然的评分通常更倾向于正确的修复——但在仅错误曝光的情况下，Gini 度量例外。
• 风险阐述: 强调标准的错误修复评估可能因数据曝光而产生偏差，暗示大语言模型可能无意中传播历史编码错误。

方法论

1. 数据集准备 – 作者从 ManySStuBs4J 开始，这是一个经过策划的真实 Java 单语句错误及其对应修复的集合。
2. 曝光估计 – 使用 Data Portraits（一种快速成员测试技术），将每个有错误和已修复的代码片段与 Stack‑V2 语料库（可能被许多代码 LLM 使用的公开数据）进行比对。这为每个变体生成一个二元的 “已见 / 未见” 标记。
3. 分层 – 示例被划分为四类：
   • None：错误代码和修复代码均未在语料库中出现。
   • Bug‑only：仅错误版本出现在语料库中。
   • Fix‑only：仅修复版本出现在语料库中。
   • Both：两种变体均出现。
4. 模型探测 – 两类 LLM（例如 Codex、StarCoder）在 代码补全 模式下被查询，提示它们填写缺失的行。输出被分类为再现错误、再现修复或其他。
5. 可能性打分 – 对于每个提示，模型的 token 级别概率使用多种指标进行聚合：
   • 最小 token 概率
   • 最大 token 概率
   • 平均 token 概率
   • 基尼系数（衡量概率集中程度）
     得分更高的变体被视为模型的 “偏好”。
6. 统计分析 – 作者比较不同曝光层级下的生成频率和打分偏好，使用卡方检验和置信区间评估显著性。

结果与发现

• Exposure distribution：67 % 的 bug‑fix 对没有曝光（两种变体均未出现）。当出现曝光时，修复版本出现的频率高于 bug 版本。
• Generation bias：
  • 整体来看，模型重新生成buggy 行的概率约为fixed 行的 2 倍。
  • 在 bug‑only 桶中，这一偏差显著上升：约 80 % 的补全会重新生成 bug 代码。
  • 在 fix‑only 桶中，改进幅度较小；bug 行仍出现在约 55 % 的补全中。
• Likelihood scoring：
  • Min/Max token‑probability 指标在所有曝光条件下始终为fixed 变体打出更高分。
  • 当仅看到 bug 变体时，Gini coefficient 的偏好会翻转，倾向于 bug 而非 fix。
• Interpretation：基于 token‑probability 的评分似乎捕捉到了对正确代码的内在偏好，而生成过程则受到训练数据中记忆模式的强烈影响。

Practical Implications

• Debug‑assistant reliability: 依赖大型语言模型（LLMs）进行自动化 bug 修复的工具必须考虑模型可能已经记住了有缺陷的模式，尤其是当训练数据中包含了该错误的完整实例时。
• Evaluation pipelines: 仅将生成的代码与真实修复进行对比的基准测试，如果忽视了模型的曝光情况，可能会高估模型的能力。加入曝光感知的分层评估可以提供更真实的评估结果。
• Data curation: 代码语料库的策展者在为 LLM 训练准备数据时，应考虑 过滤或标注 已知的 bug，以降低这些错误被传播的风险。
• Prompt engineering: 添加明确的 “fix this bug” 提示或提供突出错误的上下文信息，可以减轻模型重复记忆错误的倾向。
• Safety nets: 在生成代码后集成静态分析或自动生成测试的步骤，能够在代码进入生产环境前捕获记忆中的 bug。

限制与未来工作

• 曝光推断是近似的：通过数据画像进行成员资格测试无法保证某段代码片段确实出现在模型的训练集里，尤其是针对私有或专有数据源。
• 语言与数据集范围：本研究聚焦于 Java 单语句错误；对于多行修复、其他语言或更复杂的重构，结果可能有所不同。
• 模型多样性：仅评估了少数公开已知的代码大语言模型；更新的或领域特定的模型可能表现不同。
• 未来方向：
  • 将框架扩展到多语言、多语句的错误语料库。
  • 探索缓解策略（例如，曝光感知的微调、对比训练）。
  • 研究曝光如何与其他偏差（如风格一致性或 API 使用模式）相互作用。

Bottom line: 虽然 LLM 在基于 token 概率评估时表现出对正确代码的有希望倾向，但其生成行为仍可能被记忆的错误所劫持。识别并考虑曝光问题对于构建可信赖的 AI 驱动开发工具至关重要。

作者

• Ali Al‑Kaswan
• Claudio Spiess
• Prem Devanbu
• Arie van Deursen
• Maliheh Izadi

论文信息

• arXiv ID: 2601.10496v1
• 分类: cs.SE, cs.AI
• 发表时间: 2026年1月15日
• PDF: 下载 PDF