Reliable Graph-RAG for Codebases: AST-Derived Graphs vs LLM-Extracted Knowledge Graphs
Manideep Reddy Chinthareddy
cs.SE, cs.AI
2026-01-14
在Shopizer等三个Java仓库上，Tree-sitter抽出的确定性代码图15题全对；让LLM抽知识图会跳过377/1210个文件，端到端贵约20倍，正确率还更低。
问「哪些 Controller 用了购物车逻辑」这类问题，证据往往不在语义相近的那几个 chunk 里，而在 controller→service→repository 的注入链、接口实现和继承上。纯向量 RAG 会把实现类找来，把真正调用它的 Controller 漏掉，然后用框架常识补全，幻觉就从这里来。
GraphRAG 想靠图补上多跳。图从哪来，有两条路：让 LLM 读每个文件吐实体和依赖，或用 AST 确定性抽出类型和边。前者听起来更「懂语义」，索引阶段却可能静默漏文件。
三条管线共用同一套 15 道架构/追代码题，仓库是 Shopizer、ThingsBoard、OpenMRS Core，都是 Java。
正确性按是否命中真实实体和结构关系、有没有编造组件，标成正确/部分/错误。覆盖率用扫描文件数、嵌入 chunk 数、图节点数和跳过日志来量。
Shopizer 上 DKB 15/15 全对，LLM-KB 13/15（2 题部分正确），No-Graph 6/15，另有 4 部分、5 错误，架构发现题幻觉最多。三个仓库合计 45 题：DKB 43 正确 2 部分 0 错误；LLM-KB 38/5/2；No-Graph 31/9/5。ThingsBoard 上向量基线已经很强（14/15），DKB 打平，LLM-KB 掉到 12/15。
索引可靠性差得更明显。Shopizer 三个方法都扫到 1210 个 Java 文件，LLM-KB 跳过 377 个，文件成功率 0.688，嵌入 3465 chunk（相对 No-Graph 覆盖 0.641），图 842 节点；DKB 4873 chunk（0.902），1158 节点。ThingsBoard 和 OpenMRS 上 LLM 文件成功率分别是 0.806 和 0.650，chunk 覆盖 0.706 和 0.633；DKB 接近 0.99。
建图时间：Shopizer 上 DKB 2.81 秒，LLM-KB 200.14 秒。端到端费用（索引+15 题）Shopizer 为 0.04 / 0.09 / 0.79 美元；OpenMRS+ThingsBoard 合计 0.149 / 0.317 / 6.80 美元，LLM-KB 相对 No-Graph 约 46 倍。查询延迟三条管线都在 10–15 秒量级，LLM-KB 方差更大。
代码知识图不要交给 LLM 在索引期现抽。编译器看得见的注入、继承、实现，AST 几秒就能铺好，覆盖完整，多跳题更稳。LLM 抽图会在批处理和 schema 约束下漏文件，这些文件从此不再进入 embedding 和邻域扩展，盲区是系统性的。
向量 RAG 对付局部题够用。一旦问题要沿接口往上游找消费者，双向扩展加 InterfaceConsumerExpand 才是差值来源。代价是 DKB 只编码了很窄的边类型，动态行为和反射它看不见。
三个仓库都是 Java，换语言或换架构形态没有证据。AST 抽不到反射、运行时代码生成和纯动态分发。DKB 在 Shopizer 上 chunk 覆盖 0.902，因为嵌入和「能否解析出顶层类型」绑在一起，无类型工具文件会被丢掉，这是实现耦合，作者自己也承认。正确性是人工按题打的，没有多人一致性和逐题证据引用。LLM-KB 的边是更宽的 dependson，和 DKB 的 injects/extends/implements 不能按边数比谁更完整。