这四套 graph-RAG 系统之间的质量差距，大致相当于「一个好答案」与「一个略好一点的答案」之差；而「一次语料更新要花多少钱」的差距是两个数量级。这种不对称本该决定选型，也就是说要先回答的不是「谁检索得最好」，而是「我的图多久变一次，变的时候它会发生什么」。此外还有一件四家都没解决的事：它们都靠字符串匹配来合并重复实体，而一个被漏掉的重复就是一个假节点——你的检索评测永远不会把它标出来。
速览
四个项目在功能清单上看着像互相替代，实际上是在回答不同的问题。下表按「写入的形状」排序，因为那才是要紧的那根轴。
| 项目 | 为什么而造 | 写入模式 | 一次更新的代价 |
|---|
| Microsoft GraphRAG |
对静态文档语料提整体性问题 |
批量构建，含社区发现与社区摘要 |
重算社区层级——实际上就是重建索引 |
| LightRAG |
以普通 RAG 的价钱拿到带图味道的检索 |
增量插入，图之上不再叠层级 |
按新增文档计价，而不是按整个语料 |
| Graphiti |
事实会失效的智能体记忆 |
按情节改写，并作废被推翻的边 |
每个情节一次模型调用，持续付费 |
| Cognee |
一台由你自己拼装并加以约束的记忆引擎 |
在可插拔存储之上编排管线与 DAG |
取决于你的管线重跑什么——粒度由你定 |
没有哪一行在四根轴上全强，而这是结构性的、不是成熟度问题——低成本更新与全语料摘要本就互相拉扯。
Microsoft GraphRAG——深入
那个昂贵的步骤换来了什么
GraphRAG 的标志性动作发生在建索引时，而不是查询时。抽取出实体与关系之后，它在图上跑社区发现，然后让模型为每个社区、以及社区的社区写摘要，从而产出一层层越来越抽象的语料描述。正是这套层级让它能回答任何一个文本块里都不包含的问题——「这一万份事故报告里反复出现的主题是什么」——因为答案是从摘要里组装出来的，而不是从原文里检索出来的。
为什么它不该当默认选项
同一个设计让更新变得残酷。加进新文档会改变社区归属，从而改变摘要，进而改变它们上面那层摘要；诚实的做法是重建，而已公开的大语料全量建索引记录，模型开销可以到四位数、五位数。微软自家的 LazyGraphRAG 变体之所以存在，正是为了把这笔开销推迟到查询时，这本身就说明问题有多真实。GraphRAG 在一个静止不动的语料上物有所值——一份封存的档案、一批监管申报文件、上个季度的工单——而一旦新文档每天都在进来，它就不再值了。
LightRAG——深入
要图，但不要那层层级
LightRAG 保留了图，砍掉了社区摘要。检索分两个层次跑：低层键拉出具体实体及其邻域，高层键拉出更宽的主题，两组结果在生成前合并。这比 GraphRAG 的层级是个更小的点子，却在人们真正会提的那些查询上保住了大部分好处——而那些查询压倒性地是局部的。
成本论证，以及它的边界
已见诸报道的数字把 LightRAG 放在「GraphRAG 答案质量的 70–90%，建索引开销只是零头」这个区间，而增量插入只触及新增的那部分材料。具体比值当作参考即可——它高度依赖语料与模型——但方向没有争议，而且差距大到举证责任落在 GraphRAG 一边。它的边界正是它换出去的那样东西：LightRAG 里没有任何机制会修订一条已有的边，也没有任何东西为整个语料做摘要，所以一个真正全局的问题会退化成一次更宽的检索，而不是一次综合。
Graphiti——深入
双时间维度的边就是它的全部产品
Graphiti 不是一套披着图外衣的文档问答系统。它摄入的是情节——一轮对话、一个工具结果、一个事件——而每一条边除了摄入时间之外还带一个有效区间。当新的情节与既有事实相矛盾时，旧边是被作废而不是被删除，于是这张图既能回答「现在什么是真的」，也能回答「去年三月我们当时相信什么」。对智能体记忆来说这就是刚需，因为智能体记忆是一串会过期的断言，而不是一份语料。
它反过来要求什么
每一次写入都要经过一次模型调用，由它判定什么变了、又作废了什么，所以摄入成本随对话量而不是随语料规模伸缩——这是一种不同形状的账单，很多团队会在这里翻车。它还重度依赖可靠的结构化输出；schema 遵从性不扎实的服务商与小模型会产出畸形抽取与摄入失败，这让模型选择成了功能性依赖，而不是一个调参旋钮。见结构化输出。
Cognee——深入
一个框架，而不是一种主张
Cognee 是四者中最可拼装的：摄入、归一化与查询都是由你组装的任务与 DAG，它接得上多种图存储——Kuzu、Neo4j、FalkorDB——以及多种向量存储，而不是只随附一种。它还认真对待本体，而这件事的分量比听上去更重：把抽取约束到一份声明好的 schema 上，是提升图质量最有效的那一根杠杆，而恰恰是这根杠杆，另外三家大体上都留给你临场发挥。
可拼装的代价
别人替你做的那些决定，现在都归你。切块、抽取提示词、消歧策略、一次重跑到底触及什么——全是你的；如果你有一份值得强制执行的领域 schema，这完全正确；如果你想要一个到周五就能用的默认配置，这完全错误。
横向比较
写入模式就是那个决定
构建、追加、改写。这几套系统之间的其他一切差异，都是从「选了哪一种」推出来的。
问一问你的语料在做什么，这个领域就自己排好了序。一份被冻结、拿来问主题的档案指向 GraphRAG，而且没有别家干得了这活。一个每天都在长、以局部问题为主的知识库指向 LightRAG；为了略好一点的答案反复去付 GraphRAG 的建索引成本，是一笔你会在账单上察觉到的坏买卖。一条「昨天的偏好今天就不对了」的用户交互流指向 Graphiti，而前两者根本无法表示这种矛盾——它们会把两个事实一起留着，让模型自己挑。一个有真实本体、且工程团队愿意扛下这条管线的领域，指向 Cognee。
四者共享那个真正要紧的失败
被高亮的那一阶段，是每套系统都留给你的那一阶段，也是决定这张图描述的是你的领域、还是它的一个略微走样版本的那一阶段。
流行的 graph-RAG 实现——LightRAG 与 GraphRAG 都在其中——是用字符串匹配来给抽取出的实体去重的。这会漏掉大小写差异、缩写、同义词、译名与拼写错误，于是 Acme Corp、Acme Corporation 与 ACME 变成三个节点。在向量索引里，一条重复只是一行冗余，让你损失一点召回。在图里，它是一个假节点，也就意味着假的边，也就意味着每一次经过那片区域的遍历，走的都是一个并不存在的结构。返回的答案依旧流畅、依旧带着引用，所以答案质量类的评测浮不出它；你得靠抽样这张图本身去发现它，而不是靠给输出打分。
无论你选哪一套，都要为一道消歧环节留预算：先用嵌入做候选分块，再用一个模型或一套规则去确认合并，并且要在图被查询之前跑，而不是等有人抱怨之后。研究方向是明确的——专门的实体消歧与三元组反思阶段能可测量地清洗 LLM 建出的图——但今天四者中没有一家给你开箱即用的东西。相关：图 RAG——先想清楚这张图究竟值不值得建。
图数据库不是那个选择
人们很容易从数据库开始选。别这样：Cognee 明确可在 Kuzu、Neo4j 与 FalkorDB 之间移植，Graphiti 也支持数种后端，而存储层很少决定这套系统能不能成。决定它的是抽取与消歧两个阶段。我们的图数据库对比单独讲那一层，而它是一个下游决定。
什么时候选哪一个
| 场景 | 选 | 为什么 | 要当心 |
|---|
| 封存的档案，被拿来问主题与规律 |
Microsoft GraphRAG |
社区摘要是这里唯一能回答全语料级问题的机制 |
承诺之前先把全量建索引的开销算出来；重建索引才是那笔经常性成本 |
| 每天都在长的知识库，问题以局部为主 |
LightRAG |
增量插入，用建索引开销的一个零头换来大部分答案质量 |
全局问题会退化成宽检索，而不是综合 |
| 基于对话与事件的智能体记忆 |
Graphiti |
唯一通过作废边来建模「一个事实停止为真」的模式 |
摄入成本随流量伸缩；需要一个结构化输出可靠的模型 |
| 有真实本体的受监管领域 |
Cognee |
受 schema 约束的抽取加可插拔存储；管线归你 |
切块、提示词与消歧也归你——要为此配人 |
还有一个四家厂商都不会向你提的选项：先让一条混合检索基线在一份写下来的查询集上失败，再去建图。建图会给你的流水线加进一个昂贵且非确定性的抽取阶段，而人们带到 graph RAG 面前的问题中，有相当大一部分用混合检索加重排就能答，运营成本只是零头。
常见问题
Microsoft GraphRAG 过时了吗？
没有，但它的适用面比它的知名度窄。社区摘要层级至今仍是回答「关于整个语料」这类问题最强的可用机制，这里没有别家能复制它。它不该当默认选项的原因是语料一变，更新成本就是重建而不是插入。
我能用 Graphiti 做文档问答吗？
能，而且你会在为一套自己用不上的机件付钱。Graphiti 的价值在于让一个事实可以被取代的双时间维度边——而一份静态文档集并不需要这个属性。做文档的话，LightRAG 或 GraphRAG 与工作负载更匹配。
实体消歧到底有多要紧？
比在这四者之间怎么选更要紧。字符串匹配去重会把命名变体变成互相独立的节点，而一个假节点会产出假的边，此后每一次经过那片区域的遍历都会照着走。因为生成出的答案依旧流畅，输出质量类的评测检测不到它——你必须去抽样图本身。
我需要一个专门的图数据库吗？
起步阶段通常不需要。Cognee 可在 Kuzu、Neo4j 与 FalkorDB 之间移植，Graphiti 支持数种后端，而在原型规模上内嵌存储完全够用。等抽取与消歧两个阶段跑通之后再选存储，因为决定这套系统有没有用的是那两个阶段。
我到底该不该建知识图谱？
只有在一条混合检索基线于一份写下来的问题集上可测量地失败之后才该建。建图会加进一个非确定性、按语料计价的抽取阶段，而许多被归因为「我们需要一张图」的问题，靠更好的切块加一个重排器就答上了。