告别"大海捞针"：LLM+自然语言摘要，破解多仓库微服务漏洞定位难题
论文信息
- 论文原标题：Natural Language Summarization Enables Multi-Repository Bug Localization by LLMs in Microservice Architectures
- 主要作者及研究机构 ：
- Amirkia Rafiei Oskooei（Intellica商业智能咨询公司R&D中心 / 伊兹密尔技术大学计算机工程系）
- Mehmet Cevheri Bozoglan（Intellica商业智能咨询公司R&D中心）
- S. Selcan Yukcu（Intellica商业智能咨询公司R&D中心）
- Mehmet S. Aktas（伊兹密尔技术大学计算机工程系）
- 发表会议：2026 International Conference on Software Engineering (ICSE 2026)
- 引文格式（GB/T 7714） ：
Rafiei Oskooei A, Bozoglan M C, Yukcu S S, et al. Natural Language Summarization Enables Multi-Repository Bug Localization by LLMs in Microservice Architectures[C]//Proceedings of 2026 International Conference on Software Engineering. New York: ACM, 2026: 1-9. - 论文链接：arXiv:2512.05908v1 [cs.SE]
一段话总结
本文提出一种基于自然语言摘要 的多仓库微服务架构漏洞定位方法，通过将代码库转化为文件、目录、仓库级别的分层自然语言知识库 ，采用"仓库路由→自上而下定位"的两阶段搜索策略，有效解决了传统方法面临的语义鸿沟、LLM上下文限制和多仓库路由难题；在包含46个仓库、110万行代码的工业级数据集DNext上评估，该方法实现0.82的Pass@10和0.50的MRR，显著优于UniXcoder、GitHub Copilot等检索基线和智能RAG系统，同时提供可解释的"仓库→目录→文件"搜索路径，提升企业AI工具的可信度。
思维导图
研究背景
在如今的软件开发中，微服务架构早已成为工业级系统的主流选择------一个复杂系统会被拆分成几十个甚至上百个独立仓库（比如电商系统的"用户账户""订单管理""支付服务"等），代码总量轻松突破百万行。但这也给"漏洞定位"带来了巨大麻烦：
想象一下，开发人员收到一个漏洞报告："修改用户姓名的PATCH请求能更新版本号，但添加外部引用时版本号不变"。要在46个仓库、7000多个文件中找到问题所在，就像在茫茫大海里捞针。
传统漏洞定位方法面临三个"迈不过去的坎"：
- 语义鸿沟：漏洞报告是"大白话"，比如"版本号没更新"，而代码里是"revision++""conditional check"等技术术语，两者像"鸡同鸭讲"，匹配难度极大；
- LLM"看不全"：就算用GPT-4这样的大模型，也受限于上下文窗口，没法一次性"读完"百万行代码，只能零散检索；
- 找不到"正确仓库"：微服务的漏洞可能涉及多个仓库，但传统工具默认"在单个仓库里找"，第一步就走错了方向，后续再努力也白费。
比如GitHub Copilot这样的智能工具，虽然能在单个仓库里检索代码，但面对多仓库场景时，就像"近视眼找东西"------只能看到眼前的仓库，根本不知道该先打开哪个仓库找起。而传统的代码检索工具（如UniXcoder），则因为"大白话"和"代码话"的隔阂，经常找错文件，准确率惨不忍睹。
简单说，现有工具要么"跨不过语言鸿沟"，要么"迈不出单个仓库"，都没法满足工业级微服务架构的漏洞定位需求。
创新点
这篇论文的厉害之处，在于它没有纠结于"怎么优化代码检索"，而是直接换了个思路，带来了四个核心创新：
-
范式创新：从"搜代码"到"读摘要"
传统方法是"漏洞报告→代码"的跨模态检索，而本文把所有代码都"翻译成"自然语言摘要（比如把一段验证逻辑代码总结为"负责金融账户PATCH操作的版本号更新验证"），变成"漏洞报告→摘要"的同模态推理，直接消除语义鸿沟------LLM最擅长的就是理解自然语言，这下可谓"扬长避短"。
-
架构创新：分层知识库，适配微服务复杂性
不是简单给每个文件写摘要，而是构建"仓库→目录→文件"的三层结构：仓库摘要讲"这个服务是干嘛的"，目录摘要讲"这个模块负责什么功能"，文件摘要讲"这个文件的具体角色"。就像给图书馆做分类：先按学科找大类（仓库），再按主题找书架（目录），最后找具体书籍（文件），效率自然翻倍。
-
流程创新：两阶段搜索，先找"仓库"再找"文件"
专门解决多仓库路由问题：第一步先筛选出最可能的3个仓库，第二步再在这些仓库里自上而下找文件。避免了"在所有仓库里乱找"的无效消耗，让搜索更聚焦。
-
价值创新：可解释+可复用，适配企业需求
不同于传统AI工具的"黑箱输出"，该方法能清晰展示"哪个仓库→哪个目录→哪个文件"的推理路径，开发人员能验证每一步逻辑，大幅提升信任度；同时，构建的分层知识库还能复用在代码搜索、新员工培训、架构分析等场景，一举多得。
研究方法和思路
这篇论文的方法可以拆解为"离线建库"和"在线定位"两大步骤，逻辑清晰且可落地：
第一步：离线构建分层自然语言知识库（相当于"给代码库做一本详细目录"）
1. 生成仓库级"种子上下文"（顶层摘要）
先给每个仓库写一份"总说明"，输入的素材包括：
- 仓库的目录结构（比如哪些文件夹是"控制器"、哪些是"服务层"）；
- 关键代码片段（线性化处理，方便LLM理解）；
- 所有项目文档（README、UML图、配置文件等，用OCR和多模态模型提取文字）。
通过LLM生成一份能体现"这个仓库的核心功能和架构角色"的摘要------这就是"种子上下文"，相当于给这个仓库定了"基调"，确保下层摘要不偏离整体定位。
2. 自底向上聚合，生成分层摘要（构建"目录树"）
- 文件级摘要：给每个代码文件写摘要，提示词里不仅包含文件本身的代码，还带上第一步的"仓库种子上下文"。这样生成的摘要不会只讲"代码做了什么"，而是会说明"这个文件在整个服务中扮演什么角色"（比如"负责金融账户的PATCH请求版本号验证"）。
- 目录级摘要 ：把一个目录下所有文件的摘要汇总，让LLM生成一份"这个目录的整体功能"摘要（比如"用户账户模块的验证逻辑目录"）。
最终形成"仓库摘要→目录摘要→文件摘要"的三层知识库，每个层级都用自然语言描述，完全适配LLM的理解能力。
第二步：在线两阶段漏洞定位（相当于"按目录找答案"）
阶段1：搜索空间路由（找对"仓库"）
输入漏洞报告，让LLM对比所有仓库的摘要，找出最可能包含漏洞的Top-3仓库。这一步解决了"先找对地方"的核心问题------比如漏洞涉及"支付逻辑"，就会优先筛选出"支付服务仓库"，而不是在"用户账户仓库"里浪费时间。
阶段2：自上而下定位（找对"文件"）
在筛选出的3个仓库里，分两步缩小范围：
- 目录级筛选：用漏洞报告对比仓库内的所有目录摘要，找出Top-k个最相关的目录（比如"验证逻辑目录"）；
- 文件级排序：只分析这些目录下的文件摘要，让LLM生成Top-10最可能有漏洞的文件。
整个过程就像"查字典"：先按部首找（仓库），再按页码找（目录），最后找具体字词（文件），一步一步缩小范围，既高效又精准。
实验方法
为了验证方法的有效性，论文做了严格的对比实验：
- 数据集：选用工业级数据集DNext（电信行业微服务系统），规模接近真实企业场景（46个仓库、7077个文件、110万行代码、87个真实漏洞工单）；
- 基线对比：选了两类主流方案------传统代码检索（UniXcoder、GraphCodeBERT）和智能RAG工具（GitHub Copilot v1.104、Cursor v1.5）；
- 公平性保障：所有LLM-based方法统一使用GPT-4.1模型，避免模型差异影响结果；
- 评估指标：用Pass@k（前k个结果是否有正确文件）、Recall@k（前k个结果覆盖多少正确文件）、MRR（正确文件的排名情况）三个核心指标，全面衡量定位效果。
主要成果和贡献
一、核心实验结果（直接看"碾压级"表现）
1. 漏洞定位核心性能
| 方法类型 | 具体方法 | Pass@10（前10个有正确文件的比例） | Recall@10（前10个覆盖正确文件的比例） | MRR（平均倒数排名） |
|---|---|---|---|---|
| 传统代码检索 | UniXcoder | 0.23（仅23%） | 0.16 | 0.14 |
| 传统代码检索 | GraphCodeBERT | 0.62（62%） | 0.34 | 0.18 |
| 智能RAG工具 | GitHub Copilot | 0.61（61%） | 0.27 | 0.25 |
| 智能RAG工具 | Cursor | 0.57（57%） | 0.49 | 0.27 |
| 本文方法 | 分层搜索 | 0.82（82%） | 0.49 | 0.50 |
关键结论：
- 本文方法的Pass@10高达82%，意味着82%的漏洞能在Top-10结果中找到正确文件，比第二名GraphCodeBERT高20个百分点；
- MRR达到0.50，是GitHub Copilot的2倍，说明正确文件的排名更靠前，开发人员不用翻太多结果；
- Recall@10与Cursor持平（0.49），但Cursor的Pass@10仅57%，说明本文方法"找对文件"的概率更高。
2. 仓库路由性能（阶段1关键结果）
| 方法 | Pass@3（前3个有正确仓库的比例） | Recall@3（前3个覆盖正确仓库的比例） | MRR |
|---|---|---|---|
| GitHub Copilot | 0.82 | 0.82 | 0.77 |
| Cursor | 0.91 | 0.91 | 0.72 |
| 本文方法 | 0.93 | 0.93 | 0.67 |
关键结论：本文方法的仓库路由准确率达93%，几乎能确保第一步找对仓库，为后续定位打下基础。
3. 消融实验（验证目录筛选的重要性）
| 方法状态 | Pass@10 | Recall@10 | MRR | 平均令牌量 |
|---|---|---|---|---|
| 含目录筛选（完整方法） | 0.82 | 0.49 | 0.50 | 75K |
| 不含目录筛选 | 0.67（-18%） | 0.31（-37%） | 0.23（-54%） | 108K（+44%） |
关键结论：移除目录筛选后，性能断崖式下跌，MRR直接减半，还多消耗44%的令牌（成本更高），证明"仓库→目录→文件"的分层结构是性能核心。
二、核心贡献（给行业带来的实际价值）
- 解决工业级痛点：首次提出适配多仓库微服务架构的漏洞定位方案，打破传统方法的"单仓库假设"，能处理百万行级代码的定位需求；
- 性能大幅提升：在真实工业数据集上，Pass@10和MRR远超主流基线，让漏洞定位从"靠运气"变成"有保障"；
- 提升AI工具信任度：提供可解释的"仓库→目录→文件"推理路径，解决AI开发工具的"黑箱问题"，符合企业级应用对透明度的要求；
- 知识库复用价值：构建的分层自然语言知识库，不仅能用于漏洞定位，还能支撑代码搜索、新员工入职培训、架构合规检查等多个开发场景，降低企业工具投入成本。
三、开源与数据集说明
- 数据集：DNext为工业级专有数据集，未开源，但论文详细披露了其规模（46仓库、1.1M代码行等）和实验设置，确保结果可复现；
- 代码：论文未提及开源计划，但方法逻辑清晰，可基于公开LLM（如GPT-4、Llama 3）和代码解析工具（如Tree-sitter）复现核心流程。
3. 详细总结
一、研究背景与问题
- 应用场景：大型微服务架构的多仓库漏洞定位，此类系统存在代码规模大、服务间交互复杂的特点。
- 核心挑战 ：
- 语义鸿沟：漏洞报告的自然语言与代码技术术语缺乏语义重叠；
- LLM上下文限制：无法整体理解大规模代码库；
- 多仓库路由缺失：传统方法默认单仓库，难以先定位漏洞所属仓库。
- 现有方法缺陷 ：
- 基于原始代码的检索增强生成（RAG）需跨模态匹配，效率低；
- 智能RAG工具（如GitHub Copilot）缺乏多仓库路由机制，不适用于微服务架构。
二、研究方法：自然语言分层知识库+两阶段搜索
（一）知识库构建（离线过程）
- 仓库级种子上下文生成 ：
- 输入资源：仓库目录树、线性化代码片段、项目文档（README、UML图OCR结果等）；
- 生成方式：通过LLM生成涵盖架构角色和核心功能的摘要，作为下层摘要的上下文基础。
- 自底向上分层聚合 ：
- 文件级摘要：基于原始代码+仓库种子上下文，生成描述文件架构角色的摘要（知识树叶子节点）；
- 目录级摘要：聚合所属文件摘要，生成目录功能摘要（知识树中间节点）；
- 最终形成"仓库→目录→文件"的分层自然语言知识库。
（二）两阶段漏洞定位（在线推理）
| 阶段 | 核心目标 | 执行逻辑 | 关键参数 |
|---|---|---|---|
| 阶段1：搜索空间路由 | 定位漏洞所属仓库 | LLM对比漏洞报告与所有仓库摘要，生成Top-3候选仓库 | 评估指标：Pass@3、Recall@3 |
| 阶段2：自上而下定位 | 筛选故障文件 | 1. 目录级筛选：匹配漏洞报告与候选仓库的目录摘要，确定Top-k目录；2. 文件级排序：分析目录内文件摘要，生成Top-10故障文件 | 评估指标：Pass@10、Recall@10、MRR |
三、实验设计与结果
实验基础信息
| 项目 | 详情 |
|---|---|
| 数据集 | DNext（电信行业工业级微服务系统） |
| 数据集规模 | 编程语言：Java；仓库数：46；代码文件数：7077；代码行数：~1.1M；漏洞工单：87个；平均每个工单故障文件数：7.2个 |
| 实验工具 | 所有LLM-based方法统一使用GPT-4.1模型 |
| 基线方法 | 1. Flat Retrieval：UniXcoder、GraphCodeBERT（基于代码嵌入余弦相似度检索）；2. Agentic RAG：GitHub Copilot（v1.104）、Cursor（v1.5） |
| 评估指标 | Pass@k（前k结果中包含至少1个正确文件的比例）、Recall@k（前k结果中覆盖正确文件的比例）、MRR（平均倒数排名） |
（三）定性分析案例
- 条件逻辑漏洞：传统方法仅检索"Account"相关文件，本文方法通过理解文件架构角色，定位到负责补丁操作验证的核心服务类和验证器；
- 引用完整性漏洞：传统方法仅匹配"ServiceOrder"主题文件，本文方法通过推理组件交互逻辑，找到缺失完整性检查的验证器类。
四、研究价值与局限性
（一）核心价值
- 技术价值：提出"代码→自然语言"的范式转换，避免跨模态检索，适配LLM语义理解能力；
- 实用价值 ：
- 可扩展：支持多仓库微服务架构，解决工业级系统漏洞定位难题；
- 可解释：提供"仓库→目录→文件"的透明搜索路径，提升开发者对AI工具的信任；
- 可复用：分层知识库可支撑代码搜索、新员工入职培训、架构分析等多个开发任务。
（二）局限性
- 初始知识库构建成本高：DNext项目构建成本约80美元，且需在主要版本迭代后更新；
- 评估范围有限：仅基于Java语言的微服务项目，未验证Python、Go等语言及单体架构的适用性。
五、未来研究方向
- 优化知识库更新调度算法，降低增量维护成本；
- 扩展评估数据集，验证方法在多语言、多架构场景的通用性；
- 与现有代码代理工具集成，实现"漏洞定位→修复"的端到端流程。
关键问题与答案
问题1：该方法如何解决微服务架构中"多仓库路由"这一核心难题？其路由性能表现如何？
答案：该方法通过构建仓库级自然语言摘要，将"多仓库路由"转化为自然语言匹配问题------利用LLM对比漏洞报告与所有仓库的架构角色摘要，生成Top-3候选仓库，实现精准路由。性能上，该方法的仓库路由Pass@3达0.93、Recall@3达0.93，显著优于GitHub Copilot（Pass@3=0.82）和Cursor（Pass@3=0.91），能有效覆盖跨服务模糊漏洞的相关仓库。
问题2：分层搜索（仓库→目录→文件）在该方法中起到什么作用？移除中间层级会产生哪些影响？
答案：分层搜索的核心作用是"逐步缩小搜索空间"，为LLM提供认知支架，避免其在大规模文件中"大海捞针"。移除目录筛选（中间层级）后，实验结果显示：Pass@10从0.82降至0.67（下降18%），MRR从0.50降至0.23（下降54%），Recall@10从0.49降至0.31（下降37%），同时平均提示令牌量增加44%（从75K增至108K），证明分层设计是兼顾准确性、效率和成本的关键。
问题3：与传统代码检索和智能RAG工具相比，该方法的核心优势是什么？在工业级场景中的落地价值体现在哪里？
答案：核心优势：① 范式优势：将跨模态（自然语言→代码）检索转化为同模态（自然语言→自然语言）推理，消除语义鸿沟；② 架构优势：原生支持多仓库路由，适配微服务架构；③ 可解释性优势：提供透明的搜索路径，解决AI工具"黑箱"问题。落地价值：① 性能领先：在1.1M行代码的工业系统上实现Pass@10=0.82，大幅优于传统检索工具（UniXcoder Pass@10=0.23）和智能RAG（GitHub Copilot Pass@10=0.61）；② 成本可控：知识库离线构建，在线推理效率高；③ 复用性强：分层知识库可支撑代码搜索、架构分析等多个开发场景，提升工具投入回报率。
总结
这篇论文针对多仓库微服务架构的漏洞定位难题，提出了一种"范式转换"级别的解决方案：通过将代码转化为分层自然语言摘要，把跨模态检索变成同模态推理，既发挥了LLM的语义理解优势，又解决了上下文限制和多仓库路由问题。
在工业级数据集上的实验证明，该方法的定位准确率（Pass@10=0.82）和排名质量（MRR=0.50）远超传统代码检索和主流智能RAG工具，同时提供可解释的推理路径，完美契合企业级开发工具的需求。
虽然该方法存在"初始知识库构建成本高""仅验证Java场景"等局限性，但它开辟了"用自然语言表示代码"的新方向------未来，随着大模型能力的提升和知识库维护成本的降低，这种"读摘要"而非"读代码"的开发工具范式，有望在更多软件工程场景中落地，为开发者减负增效。