AI消息速览

LLM 漏洞修复中的编译率指标失效与 diff_F1 变化感知筛选

事件日期 2026-09-22 · 学术前沿 · 已接受

事件日期2026-09-22
信息日期2026-09-22
入库日期2026-09-23
通道学术前沿
状态已接受
来源arXiv 论文

知识卡片:LLM 漏洞修复中的编译率指标失效与 diff_F1 变化感知筛选

一句话结论

基于五项控制实验,本文认为编译率(compile rate)不能可靠衡量单函数 C/C++ 漏洞修复进展:它受评估框架、数据集伪影和编译器标志影响,甚至会在被当作优化目标时奖励“非修复”。作者提出仅对编辑区域评分的 diff_F1 作为变化感知筛选,但明确它并非修复质量指标。

事件概述或研究问题

大语言模型(LLM)越来越多用于自动修复 C/C++ 安全漏洞,而“编译率”常被报告为进展代理,即生成的补丁能否编译通过。本文追问:编译率对单函数漏洞修复是否科学可靠?自然备选的 whole-function CodeBLEU 是否可行?能否用变化感知指标先筛掉明显非修复?

实验覆盖 Big-Vul 的 203 个易受攻击函数、三个开源代码 LLM(350M 到 6.7B 参数)和三种提示策略,共五项控制实验。

方法/产品要点

  • 数据:Big-Vul 中 203 个易受攻击函数。
  • 模型:三个开源代码 LLM,参数规模 350M 到 6.7B。
  • 提示策略:三种。
  • 实验设计:五项控制实验。
  • 评估指标:编译率、参考相似度指标、whole-function CodeBLEU,以及作者考察的 diff_F1。
  • diff_F1:一种变化感知筛选,只对补丁编辑区域评分。
  • 优化循环:研究中包含编译器反馈循环,用于检验编译率作为优化目标时的行为。

主要结果或产业意义

  1. 编译率几乎不响应一个能显著改善生成代码的干预。
  2. 编译失败主要由评估框架和数据集伪影主导,而非模型质量;约 64% 的编译失败不可归因于模型,且这一比例在模型间几乎不变。
  3. 在相同补丁下,仅改变一个编译器标准标志,编译率会变化 1.8 到 2.7 倍,且零回退。
  4. 编译率对三个模型的排序与参考相似度指标给出的排序相反。
  5. 当编译率被用作优化目标时,它会奖励非修复:编译器反馈循环提高编译率,但生成结果与人类修复的相似度下降;人工检查发现,新编译通过的输出中存在删除式和占位符式非修复。
  6. whole-function CodeBLEU 也失败:未修改的易受攻击输入副本得分高于所有模型。
  7. diff_F1 对 no-op 给零分,对部分(但非全部)删除式游戏补丁给接近零分,同时仍奖励真实的部分编辑;因此它可能作为深入执行分析前的廉价筛选。但作者强调它不是修复质量指标,并报告了其不足之处。

产业意义:若用编译率衡量 LLM 漏洞修复进展,可能误导模型选择、基准排名和优化方向;安全修复需要变化感知、执行落地的评估。

为什么重要

  • 编译通过不等于漏洞被修复;代理指标可能制造虚假进展。
  • 评估框架和数据集伪影可主导结果,基准本身需要审计。
  • 编译器反馈循环作为优化目标时,会出现 Goodhart 定律式失效:指标变好,真实修复变差。
  • 对学术和工业实践而言,应避免仅汇报编译率,转向补丁区域变化、执行验证和人工审查等更可靠的评估方式。
  • 与既有关于 LLM 代码自修复评估的卡片形成方法学呼应:评估指标可能捕捉不到真实修复能力。本条增量在于专门针对 C/C++ 漏洞修复、单函数场景,量化 compile rate 的五种失效模式,并讨论 diff_F1 作为变化感知筛选。

局限与不确定性

  • 本卡片仅基于 arXiv 摘要,全文细节、实验设置和统计结果待核实。
  • 结论范围限于 203 个 Big-Vul 单函数、三个开源代码 LLM(350M 到 6.7B)和三种提示策略;是否适用于更大模型、闭源模型、其他数据集、多函数或仓库级修复,待核实。
  • diff_F1 的公式、阈值、计算细节及其对全部删除式游戏补丁的识别能力待核实;作者已说明它不是修复质量指标,且对删除式游戏补丁的识别并不完整。
  • 编译器标准标志的具体名称、人工检查规模、统计显著性和五项实验的完整设计待核实。
  • 出版与版本信息按来源材料保留:arXiv ID 2609.26749v1,Published/Updated 2026-09-22T17:32:05Z。

可用于图书/PPT/简报的角度

  • “编译通过 ≠ 漏洞修复”:用五个失效模式说明代理指标陷阱。
  • 评估指标审计:框架伪影与数据集伪影可能主导结果,甚至使模型排名反转。
  • Goodhart 定律案例:当编译率成为优化目标,编译器反馈循环会奖励删除式或占位符式非修复。
  • 变化感知评估:diff_F1 作为廉价筛选,执行落地验证作为深层分析。
  • 安全漏洞修复的产业实践:不要仅以编译率汇报进展,应报告执行验证、补丁区域变化和人工审查。
  • 与 LLM 代码生成评估、软件工程基准可靠性、AI 安全修复等主题交叉。

原始材料

  • 英文标题:Metrics Failure in LLM-Based Code Vulnerability Repair: An Empirical Study and a Change-Aware Screen
  • 英文关键词:材料未给出正式关键词列表;据摘要可提取:compile rate; LLM-based code vulnerability repair; C/C++ security vulnerabilities; Big-Vul; diff_F1; CodeBLEU; execution-grounded evaluation(正式关键词待核实)
  • arXiv ID:2609.26749v1
  • Authors:Om Nepal, Sushant Aryal, Oluseyi Olukola, Nick Rahimi
  • Published:2026-09-22T17:32:05Z;Updated:2026-09-22T17:32:05Z
  • Primary category:cs.SE;Categories:cs.SE, cs.AI, cs.CR
  • Abstract URL:https://arxiv.org/abs/2609.26749v1
  • PDF URL:https://arxiv.org/pdf/2609.26749v1
  • 来源:arXiv 摘要页与摘要文本

发现内容有误?

免登录提交,管理员审核并完成修正后才会公开修订说明。

值得关注

编译通过不等于漏洞被修复;代理指标可能制造虚假进展。 评估框架和数据集伪影可主导结果,基准本身需要审计。 编译器反馈循环作为优化目标时,会出现 Goodhart 定律式失效:指标变好,真实修复变差。 对学术和工业实践而言,应避免仅汇报编译率,转向补丁区域变化、执行验证和人工审查等更可靠的评估方式。 与既有关于 LLM 代码自修复评估的卡片形成方法学呼应:评…

相关主题

对应的教材知识点

教材知识点匹配尚未完成。