AI 编程助手最费钱也最不靠谱的动作，是拿着一个模糊的问题在你的仓库里反复 grep。graphify 换了个思路：先用 tree-sitter 把代码解析成一张知识图谱，之后所有问题都查图，不再翻文件。这篇我在本机真装真跑了 httpx 和 FastAPI 两个仓库——12.8 秒建图、零 token、39 倍压缩是真的，中文查询查不到、一次 update 把图从 8355 撑到 25685 个节点也是真的。另外扒了它为什么用 NetworkX 而不是 Neo4j（代价是 6.5% 的边被合并掉）、graphify-out/ 那 13 个产物里只有 5 个该进 git、怎么接自己的 LLM 网关不用 Gemini key，以及和 Aider、Serena、Potpie、GraphRAG、SCIP、Repomix 五条路线的横向对比。附可直接抄的 .gitignore 和 .graphifyignore。

我这个博客仓库有 611 篇 Markdown、791 个文档源文件，可我问 AI “我以前是怎么讲鉴权的”，它照样答不上来。存了等于没存。这篇给一套后端工程师能长期跑下去的方案：先按“AI 知道 / AI 不知道”把知识分层，再用“源文件是唯一事实源、索引全部可重建”的四层结构去存，组织上 Tree 做骨架 Graph 做补充，检索上从目录到混合检索到图检索三级递进。附可抄的目录结构、frontmatter 规范、reindex 脚本骨架、工具三档选型，和一份精选论文清单。

传统 RAG 把文档切碎成 chunk 各自嵌入，遇到"多个实体互相牵连"的问题就抓瞎。GraphRAG 用知识图谱补上了关系，却贵得离谱、更新一次能烧掉几百万 token。这篇精读港大与北邮的 LightRAG 论文（arXiv:2410.05779），先把传统 RAG 的老毛病摊开，再拆 LightRAG 的图索引 + 双层检索 + 增量更新，最后落到一张选型对照表。

传统 RAG 在处理复杂多跳问题时力不从心，GraphRAG 通过引入知识图谱为检索增强生成带来了结构化推理能力。本文从痛点分析、核心架构、Leiden 社区检测算法到工程实践，全面深入剖析 GraphRAG。