[Paper] 自然语言摘要实现多仓库缺陷定位，使用LLMs在微服务架构中

Source: arXiv - 2512.05908v1

概览

本文解决了现代微服务环境中最令人头疼的问题之一：在系统跨越数十个代码仓库时，找到导致 bug 的确切代码片段。通过将代码转换为分层的自然语言摘要，作者将 bug 定位转化为纯粹的 “文本‑到‑文本” 检索问题，使大型语言模型（LLM）能够比传统的代码中心技术更高效地处理。

关键贡献

• 层次化自然语言摘要：为微服务代码库中的每个文件、目录和仓库自动生成简洁的自然语言描述。
• 两阶段 NL‑to‑NL 检索：
  1. 仓库路由 – 快速将搜索空间缩小到最相关的仓库。
  2. 自上而下定位 – 使用相同的自然语言查询依次在仓库 → 目录 → 文件层级中钻取。
• 可扩展评估：在拥有 46 个仓库、约 110 万行代码的工业系统 DNext 上测试，达到 Pass@10 = 0.82 和 MRR = 0.50，远超经典信息检索基线以及 GitHub Copilot、Cursor 等代理式 RAG 工具。
• 可解释性：检索路径（仓库 → 目录 → 文件）以纯文本形式暴露，帮助开发者了解为何推荐特定位置。
• LLM‑友好设计：始终保持在 LLM 的 token 窗口内（纯自然语言），规避了原始代码检索时的上下文长度限制。

方法论

1. 代码摘要
   • 通过微调的 LLM（如 GPT‑4‑Turbo）读取每个源文件并生成简短、易读的描述（例如 “通过 JWT 处理用户认证”）。
   • 摘要向上聚合：目录摘要由其文件摘要合成，仓库摘要由其目录摘要合成。
2. 索引构建
   • 将所有摘要连同层级标识一起存入向量库（如 FAISS）。
3. 两阶段检索
   • 阶段 1 – 仓库路由：将 bug 报告（自然语言）嵌入后与仓库级摘要匹配，选出 top‑k 仓库。
   • 阶段 2 – 自上而下定位：在每个选中的仓库内部，使用相同查询先匹配目录摘要，再匹配文件摘要，得到候选文件的排序列表。
4. 打分与排序
   • 查询与摘要嵌入的余弦相似度作为主要得分；轻量级的重排序步骤会加入元数据（如最近的提交活动）进行调优。

整个流水线只需一次纯 NL‑to‑NL 过程，避免了通常噪声大且计算量大的跨模态嵌入（代码 ↔ 文本）。

结果与发现

• 召回率更高：该方法在前 10 条结果中找到正确文件的概率为 82%，是纯代码搜索的两倍。
• 排序更佳：MRR 为 0.50 表明正确文件平均排在列表前列。
• Token 效率：每个文件的摘要约 30 个 token，即使在大型代码库中，整体索引仍能保持在 LLM 上下文限制之内。
• 可解释性：开发者可以阅读中间的目录和仓库摘要，了解推理链，这在黑箱 RAG 输出中是做不到的。

实际意义

• 加速调试：团队可以将摘要流水线接入现有的 Issue 跟踪工具（Jira、GitHub Issues），即时获得排序后的文件建议。
• 企业 AI 信任：层次化的透明结构（仓库 → 目录 → 文件）满足合规和审计需求，解释 “为什么” 与 “是什么” 同等重要。
• 可扩展工具：由于索引纯文本化，可存储在低成本向量数据库中，并在代码变更时增量刷新，适用于 CI/CD 流程。
• LLM 成本节约：始终停留在自然语言域，减少了相较于全代码 RAG 需要嵌入大量源代码的昂贵调用。
• 跨团队协作：在所有权分散的微服务生态中，仓库路由步骤自动将 bug 报告指向正确的所有者，降低交接摩擦。

局限性与未来工作

• 摘要质量依赖：方法依赖 LLM 生成准确、简洁的摘要；噪声或过时的摘要会误导检索。
• 动态代码：快速变化的仓库需要频繁重新摘要，论文指出新鲜度与计算成本之间的权衡。
• 语言覆盖：实验聚焦于 Java 代码库；将其扩展到多语言微服务（如 Go、Python、Rust）可能需要针对性提示。
• 细粒度定位：当前方法止步于文件层级，精确到行或函数仍是未解挑战。
• 用户研究：虽然量化指标表现突出，但真实开发者的采纳度和主观感受尚未评估。

结论：通过将 bug 定位重新构造为纯自然语言推理任务，作者展示了一种实用、可解释且性能出色的替代传统代码搜索的方法，这有望成为大规模微服务组织中 AI 辅助调试的基石。

作者

• Amirkia Rafiei Oskooei
• S. Selcan Yukcu
• Mehmet Cevheri Bozoglan
• Mehmet S. Aktas

论文信息

• arXiv ID: 2512.05908v1
• 分类: cs.SE, cs.AI, cs.CL, cs.IR
• 发表时间: 2025 年 12 月 5 日
• PDF: Download PDF