[Paper] 可靠的 Graph‑RAG 用于代码库：AST 派生图 vs LLM 提取的 Knowledge Graphs

Source: arXiv - 2601.08773v1

（未提供需要翻译的正文内容。如需翻译，请提供完整的文本。）

Overview

本文研究了如何在软件工程任务（如在复杂的 Java 代码库中导航）中提升检索增强生成（Retrieval‑Augmented Generation，RAG）的可靠性。通过比较三种检索管道——普通向量搜索、LLM 生成的知识图谱以及基于抽象语法树（AST）构建的确定性图谱，作者展示了直接从 AST 构建的图谱在多跳架构查询方面提供了最佳的覆盖率、准确性和成本效益。

关键贡献

• 三管线基准 在真实的 Java 项目（Shopizer、ThingsBoard、OpenMRS）上，涵盖索引时间、查询延迟、覆盖率、成本以及答案正确性。
• 确定性 AST 派生知识图谱 (DKB) 使用 Tree‑sitter 和双向遍历构建，几秒钟内完成，几乎覆盖所有文件。
• 实证证据 表明 LLM 提取的知识图谱 (LLM‑KB) 漏掉了代码库的大量部分，并且索引成本更高。
• 演示 纯向量 RAG 在多跳架构推理上表现不佳，且出现更高的幻觉率。
• 实用指南 用于在构建代码助手工具或自动化文档系统时选择检索策略。

方法论

1. 代码库与查询 – 本研究使用三个开源 Java 代码库（Shopizer、ThingsBoard、OpenMRS）。对每个代码库执行一套精心挑选的 15 条“架构与代码追踪”问题（例如 “OrderController 调用了哪个服务？”）。
2. 检索管道
   • 无图 RAG：对分块的源文件进行传统的向量相似度搜索。
   • LLM‑KB：提示 LLM 提取实体（类、方法、接口）及其关系，然后对生成的知识图谱节点进行嵌入。
   • DKB：使用 Tree‑sitter 解析代码，遍历 AST 提取声明、继承、方法调用和依赖边的确定性图；对每个节点进行嵌入。
3. 指标 – 对每个管道记录：
   • 索引时间（图构建 + 嵌入）
   • 查询延迟（检索 + 生成）
   • 语料覆盖率（索引中表示的源文件百分比）
   • 成本（LLM API 调用、计算时间）
   • 答案正确性（人工按 0‑2 评分）。
4. 评估 – 将答案与从代码和文档中得到的真实答案进行比较。将幻觉（不正确但看似合理的陈述）单独记录。

结果与发现

要点： 确定性 AST 派生的图在覆盖率和答案质量上始终优于 LLM 生成的图，同时构建成本更低、速度更快。普通向量搜索在任何需要跨多个代码实体进行推理的查询上都表现不佳。

实际影响

• 面向开发者的工具 – IDE 插件或基于聊天的代码助手可以采用 AST 派生的图谱，提供精准的多步骤导航（例如，“展示从控制器到数据库层的完整调用链”）。
• 成本效益的扩展 – 由于 DKB 索引速度快且成本低，大型单体仓库可以频繁刷新，而不会产生高额的云费用。
• 降低幻觉 – 确定性的图谱为 LLM 提供了具体的依据，降低了编造不存在关系的可能性——这是生产级代码助手的关键安全因素。
• 混合流水线 – 团队可以保留轻量级向量存储用于主题搜索，同时叠加 AST 图谱以处理结构化查询，实现两者的最佳结合。
• 合规性与审计 – 确定性的图谱提供了可验证的产物（AST），可供审计，而不像不透明的 LLM 生成的知识库那样难以追溯。

限制与未来工作

• 语言范围 – 实验仅限于 Java；扩展到动态类型语言（Python、JavaScript）可能需要额外的启发式方法。
• 图的丰富度 – 当前基于 AST 的图捕获了声明和调用边，但省略了运行时信息（例如反射、DI 容器的 wiring），这些信息可能影响准确性。
• LLM 提示工程 – 本研究对 LLM‑KB 使用了单一的提示策略；更复杂的提示或微调模型可能缩小覆盖差距。
• 用户研究验证 – 人本评估（开发者满意度、解决问题时间）留待未来工作。
• 与 CI/CD 的集成 – 在持续集成流水线中自动化 DKB 更新并衡量其对代码审查辅助的影响仍是一个待探索的方向。

作者

• Manideep Reddy Chinthareddy

论文信息

• arXiv ID: 2601.08773v1
• 分类: cs.SE, cs.AI
• 出版日期: 2026年1月13日
• PDF: 下载 PDF