研究指编译率不适用于评估LLM漏洞修复并提议diff_F1
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载编译率为何不可靠
这项研究把编译通过率当作衡量大模型修复 C/C++ 安全漏洞的主要指标，并认为它并不科学。作者围绕 Big-Vul 中的 203 个易受攻击函数，使用三个开源代码大模型（参数量从 350M 到 6.7B）和三种提示策略，做了五组对照实验。结论之一是编译率对真正改善生成代码的干预几乎不敏感；其二是它更多反映评测框架与数据集本身的偏差，而非模型水平，约 64% 的编译失败无法归因于模型，且这一比例在不同模型间几乎不变。此外，同一个补丁在只改动一个编译器标准标志时，编译率会变化 1.8 到 2.7 倍，而回归数为零。
排序与优化目标的反常
研究还发现，编译率给出的三个模型排序，与基于参考相似度的指标排序正好相反。更值得注意的是，当把编译率当作优化目标时，它会奖励那些并未真正修复问题的输出：引入编译器反馈循环后，编译率上升，但生成结果与人工修复的相似度反而下降。人工检查发现，新出现的可编译输出中包含删除式和占位符式的假修复。作者因此认为，编译率不适合作为单函数漏洞修复的进展代理。作为常见替代方案的整函数 CodeBLEU 同样失效——把易受攻击的原始输入原样复制一份，其得分竟高于所有模型的输出。
变更感知筛选的作用
论文还考察了 diff_F1，这是一种只对编辑区域打分的变更感知筛选方法。对于空操作，它给出恰好为零的分数；对于观察到的部分删除式取巧补丁，它给出接近零的分数，但并非覆盖全部此类情况；同时它仍会认可真实的部分编辑。基于这些表现，作者提出它可以作为更深入的、基于执行的验证之前的一道低成本筛查。作者明确说明，diff_F1 并不是修复质量指标，并在文中报告了它存在不足的地方。整体结论是，面向大模型漏洞修复的评测应当转向变更感知且以执行为依据的方式。
为什么值得看
揭示当前LLM代码修复评估核心指标的严重缺陷，为从业者选择更抗作弊、更可靠的评测方案提供实证依据。
信源1 家
关键事实
相关 · 论文
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。