PatchHolmes：基于 Agentic 列表式选择的补丁检索

Hugging Face Daily Papers 论文
agentic-retrieval vulnerability-detection code-search llm-agents security listwise-ranking open-source

摘要

PatchHolmes 已被 AACL-IJCNLP 2026 接收，它采用 agentic 列表式选择方法，将软件漏洞与其修复 commit 进行配对。在冻结的开源权重模型上，该方法每次查询读取约 96k tokens，让智能体通读完整候选列表，从而在 Recall@1 上达到 59.95%，远超逐点基线的 34.61%。

补丁检索（patch retrieval），即查找修复已知漏洞的 commit，是漏洞管理工作流程的基础，然而主流漏洞公告数据库中 60% 至 63% 的 CVE 缺少补丁链接。我们提出 PatchHolmes，一个两阶段的补丁检索系统：第一阶段采用混合检索器，第二阶段接入 agentic 检索循环。与逐点（pointwise）方法对每个候选独立打分不同，PatchHolmes 的 Phase 2 智能体以列表方式（listwise）阅读 top-100：它一次性查看完整的候选列表，通过四个带预算限制的工具选择性地阅读 3 到 10 个 commit，然后提交一个最优 commit。在 GitHubAD 上，PatchHolmes 的 Recall@1 比逐点二分类器 Favia 高出 25.34%，比检索 + CoT 基线 IRCoT 高出 31.40%，且每个 CVE 仅需一次智能体对话，而 Favia 需要十次；在候选集完全相同的条件下，该智能体相比直接采用检索器的 top-1 候选，将 Recall@1 提升了 27.32%；同一个智能体未经任何修改迁移到 PatchFinder_top10 后，将 Recall@1 从 PatchFinder 自身 top-1 选择的 24.28% 提升至 39.86%。在 Qwen 系列内部替换 LLM 主干模型，Recall@1 的变化不到 1%；另一个模型家族（gpt-oss）的结果同样远高于无智能体的下限，说明收益来源于列表式智能体循环；整个系统在冻结的开源权重模型上运行于本地 Git 仓库，无需微调，也不依赖外部搜索 API。
查看原文
查看缓存全文

缓存时间: 2026/10/01 04:20

论文解读 - PatchHolmes：基于列表级选择的智能体补丁检索

来源：https://huggingface.co/papers/2609.38807

已收录于 AACL-IJCNLP 2026 主会议.

每一个软件漏洞都需要与修复它的 commit 配对. 安全公告需要这种配对，严重性评分、受影响版本追踪和供应链扫描器也同样需要.

❌ 在 GitHub Advisory Database 和 National Vulnerability Database 中，有 60% 到 63% 的条目缺失这种配对.

检索困难的原因有三个：

❌ 候选池过大. 一个仓库最多可包含 140 万个 commit，而 49% 的漏洞影响的是拥有超过 5,000 个 commit 的仓库. ❌ 候选内容过长. 我们语料库中平均的 commit diff 约有 15,000 个 token. 而先前方法使用的文本编码器只读取前 512 个.

❌ 词语对不上. 漏洞报告描述的是症状，比如 “buffer overflow”；而修复它的 commit 描述的是 bug 本身，比如 “out-of-bounds read”.

🔍 这篇论文的灵感源于一次失败.

此前最好的智能体系统会为 10 个候选分别发起独立调用来逐一评分：是或否，外加一个置信度.

在 jQuery 的跨站脚本漏洞 CVE-2015-9251 上，系统将全部十个候选都标记为 “是”、置信度 5. 由于没有任何区分，排名第一的候选只是列表中恰好排在最前面的那个——而那是一个与该代码路径无关的重构.

✅ 我们的改进：让智能体一次看到整个列表.

PatchHolmes 一次性读取前 100 个候选，然后通过四个有预算限制的工具逐个打开 commit，最终提交一个答案. 搜索分四步收敛：仓库中多达 140 万个 commit，第一阶段后剩余 100 个候选，智能体实际打开 5 个 commit，提交 1 个答案. 在那个 jQuery 案例中，它按列表顺序 1、2、9、4、3 阅读了五个 commit，最终选中了那个阻止 JavaScript 响应被自动执行的补丁.

📊 结果. Recall@1 是指提交的唯一 commit 即为正确答案的漏洞占比，数值越高越好.

✅ PatchHolmes 达到 59.95%，而逐点打分系统仅为 34.61%，通用的检索加推理基线仅为 28.55% ✅ 在相同候选池下，智能体将 Recall@1 从 32.63% 提升到 59.95% ✅ 将同一个智能体原封不动迁移到另一个基准的候选池，Recall@1 从 24.28% 提升到 39.86% ✅ 在同一模型族内更换语言模型，Recall@1 变化不到 1 个百分点 ✅ 每个漏洞约消耗 96,000 个输入 token、8 次工具调用，读取 5 个 commit

整个系统基于冻结的开源权重模型，在本地 Git 克隆上运行. 无需微调，也无需付费搜索 API，因为这两者都会随着待办积压的增大而增加成本.

🙏 这是与 Stevens Institute of Technology 的 Yingming Zhou、Jiangrui Zheng、Shudong Hao 和 Xueqing Liu 的合作成果.

相似文章

当 Attribution Patching 存在偏差：诊断与二阶修正

arXiv cs.LG

本文诊断了 attribution patching 中的系统性误差——这是一种用于语言模型因果定位的基于梯度的近似方法——并提出了一种使用 Hessian-vector product 的二阶修正，该修正以极小的额外计算成本提高了可靠性。

PhoenixRepair：重新思考软件代理中的修复策略探索

arXiv cs.AI

PhoenixRepair 是一个多智能体框架，系统性地探索多个候选编辑位置，并对补丁生成进行迭代反思和优化。在 MiniMax-M2.5 模型上，它在 SWE-bench-Verified 上达到了 76.0% 的 Pass@1 率，并在 DeepSeek-V3.1 模型上相比 SWE-agent 取得了 7.8% 的相对提升，达到了最先进水平。

AI生成的安全漏洞补丁需要人工审查

Lobsters Hottest

Off-by-1 Labs（1Password）的研究发现，对于复杂且最近披露的漏洞，LLM生成的补丁有53.9%的概率存在缺陷，通常无法解决问题或引入新的漏洞。该研究强调AI生成的补丁需要人工审查，并发布了相关工具、数据集和论文。

SkillSeek：在市场规模下重新审视智能体技能检索

Hugging Face Daily Papers

AACL-IJCNLP 2026 Findings 论文表明，经典词法检索（BM25 加上一个小型交叉编码器）在 4 种场景中的 3 种上与智能体式技能检索持平甚至更优，而成本仅约为后者的一半，因此作者主张智能体式检索应作为备选方案而非默认方案。