2026 年 7 月中旬，两个最受关注的图式 RAG 开源项目在 GitHub stars 上出现交叉：LightRAG 反超了 Microsoft GraphRAG。知乎把最近一个月知乎和 B 站的讨论捋完，我想对还在选型观望的人说：别把这次排位赛理解成"轻量版打败了正版"，两者从来不是同一个方案的轻重版本，真正决定你该用哪个的，是你的知识库每天在回答什么问题。
先搞懂"核心资产"差异：社区摘要 vs 双层增量检索
GraphRAG 与 LightRAG 都试图解决这个缺口，但两者并不是同一个方案的轻重版本。知乎Microsoft GraphRAG 的核心资产是层级化社区摘要：先从文本里抽取实体、关系和声明，用 Leiden 算法聚成层级社区，再从底层到高层生成摘要；查询时 Global Search 拿着这些预生成的摘要组装答案，天然适合"整个语料在讲什么、不同主题如何关联"这类全局问题。
这种"先摘要、后查询"的设计也决定了它的成本结构：标准方案中图抽取约占索引总成本的 75%，微软自己的文档也提醒索引可能是一项昂贵操作，建议先从小数据集验证。知乎而且摘要是预生成的，文档库一更新基本要重跑全量索引，对频繁更新的知识库这是绕不开的负担。
LightRAG 走的是另一条路：同时维护实体关系图和文本向量，低层检索回答具体事实、高层检索回答主题与关系；对新增数据生成局部图，再与已有图合并，从而避免每次重建整个全局索引。知乎两个框架的图最终都落在属性图模型上：节点带类型和属性，关系本身也能挂时间、角色这类键值，这和把一切拆成三元组的路线完全不同。
选型答案藏在问题类型里
第一类：单片段就能回答的问题。如果你问的是"产品 A 的保修期是多少"“这条制度条款对应哪个文件”，需要的是找到一段正确的文本，当问题的本质是"找到一段正确的文本"时，全文检索、关键词检索或者向量 RAG 通常已经足够。知乎硬上图检索反而可能引入不相关的邻居节点，增加上下文噪声。
第二类：相似性推荐。核心是"相似"而不是"相连"，语义相似度就是最重要的排序依据，向量检索主角位。但如果叠加"兼容已有配件、不依赖某个供应商"这类关系约束，向量候选 + 图过滤的混合检索才开始值得考虑。
第三类：实体关系问答 + 频繁更新。"产品 A 用的某个零件刚被召回，会影响哪些保修服务和客户订单"这类问题要沿着关系遍历，知识库又每周每天都有新增，LightRAG 的增量更新和多模式切换在工程上更顺手。当前官方仓库把 mix 作为默认模式，但生产系统仍应基于问题类型、时延和成本动态选择。知乎
第四类：全库主题总结。"整个知识库的主要矛盾和趋势是什么"这类宏观问题不存在一个高度相似的单独片段，GraphRAG 的 Global Search 对全库主题和宏观总结更有针对性。知乎
落到实践，更现实的做法是查询路由：不让所有请求都走图检索，而且图检索一侧本身就有实体链接、路径检索、图查询检索等多种路径。简单问题走普通 RAG，实体关系问题走 LightRAG local 或 mix，全局问题再走 GraphRAG Global Search。知乎
真正的门槛都在建图之后：脏图、成本、部署坑
最近一个月社区里共鸣最多的吐槽是"脏图比没有图更糟"：实体消歧没做好，图谱里全是自环和"类似于""属于"这类弱关系，真正有价值的关系被淹没。脏图比没有图更糟——它会用一堆假关系污染你的回答。知乎严重的时候错误还会沿着遍历传播：一条错误的边能把多个原本不相关的事实全部带入上下文，图检索并不会自动让数据更可信，它只是更有效地利用图中已有的关系。
LightRAG 用户还有一个专属坑：实体合并的依据是名字，两个实体即使描述不同，只要名字相同就会被合并，这会导致图谱中的节点语义混乱。知乎典型例子是"特斯拉公司"和"发明家特斯拉"被硬揉进同一个节点，描述变成"既关联电动汽车又关联交流电系统"。如果你的数据里别名、简称多，选型前务必先抽查合并结果，或者在合并前加一步 LLM 判别。
成本方面引用一个社区实测：作者在部署146万字的文档的知识图谱时Deepseek V3 api花了45块，embedding的额度均在免费范围内。知乎补两句背景：他搭的是跳过社区摘要的轻量版图，跑微软完整管线成本会更高；但这个案例至少说明，个人和小团队规模下"建图"已经不是用不起的事，真正的成本在反复重跑和维护。
真要自己部署 Microsoft GraphRAG 2.4.0，记住几个社区踩过的坑：部署GraphRAG建议使用python3.11（有issue称3.10的python版本会在索引时触发asyncio.exceptions.CancelledError）。知乎另外 tokens_per_minute 和 requests_per_minute 两个字段默认是 auto，可能会大幅度降低索引速度，用能并发的 API 时一定要改成限制数或 null。
不想自己维护流水线，可以把建图交给集成平台：RAGFlow 从 v0.16.0 起把知识图谱构建做进了数据集解析，构建方法分 General（用 GraphRAG 的 prompts）和 Light（用 LightRAG 的 prompts，默认选项），新上传的文件开始解析时，已生成的图会自动更新。RAGFlow官方文档官方文档同样在开头明确警告：构建知识图谱会消耗大量内存、算力和 tokens，按需开启。
换框架之前，先跑一次小规模验证
把选型结论压缩成一张表：
你问得最多的是 | 更合适的选择 |
|---|---|
单片段直答、FAQ、条款查询 | 向量 RAG 优先，先别建图 |
全库主题总结、报告归纳、事件脉络 | Microsoft GraphRAG（Global Search / 社区摘要） |
实体关系问答、知识库频繁更新 | LightRAG（mix 默认 + 增量更新） |
不想自己维护抽取流水线 | RAGFlow 等内置 KG 的平台（Light 方法默认） |
实体别名多、数据质量要求高 | 无论选谁，先做实体消歧与评测 |
谁的结论都别全信，包括这篇。应先建立小规模人工标注集，评测实体覆盖、关系准确率和别名合并率，再扩大索引规模。知乎再补两个工程指标：单文档索引成本和 P95 查询延迟——很多时候这两个数的差距，比 stars 排位更有说服力。
还有一个更简单的自检问题：如果删除实体之间的关系，我们是否仍然能够可靠地回答这个问题？如果答案是肯定的，那么图检索大概率是锦上添花，而非雪中送炭。知乎
值得继续观察的三个信号
一是成本曲线还在快速改写：2026年6月微软发布的LazyGraphRAG把索引成本降低99.9%。知乎如果这个数字能在社区复测里站住，"GraphRAG 太贵用不起"的结论就要修正，观望党可以重点追复测文。
二是图的两大范式正在靠拢。今天知乎上线的《The Great Graph Divide》讨论把 RDF/OWL 与属性图的根上差异梳理了一遍：属性图边可以挂键值，RDF 边不能。知乎RDF 要表达边属性得靠 reification 多绕一圈，而 GraphRAG、LightRAG 建的图都站在属性图这边；同时 Neo4j 这类 LPG 数据库又在补强 schema，两派边界在模糊——这意味着图的导出格式和生态工具往后只会更互通。
三是向量 + 图融合正在成为共识。无论是 BYOKG 式"自带图谱"把实体链接、路径检索、图查询检索组合起来，还是集成平台的多模型检索，方向都一样：让简单问题走简单链路，复杂问题才过图。
stars 反超只是社区给"工程门槛"投的一票；你自己那一票，应该投给知识库里那几十道真实问题。先把问题类型分清楚、小规模验证跑起来，再谈框架，比追任何排位都稳。
