花了好几个月优化GraphRAG的检索性能。

但结果发现，我一直优化的方向是错的……

最大的知识图谱问题通常出现在数据摄入阶段（即便大多数讨论都集中在检索上）。

每一份新文档都带来图污染的风险。

这就是为什么我现在把知识图谱摄入看作一个5步管道：

1/ 提取

将原始文本转化为实体和关系。

例如：人物 → 工作于 → 组织

目标是提取你所关注的本体中的内容。

2/ 解析

这一步标准化名称。

例如：

NYC → 纽约市 P Morgan → 摩根大通 Jon Smith → John Smith

最重要的是，此时尚未进行任何合并。

3/ 嵌入

接下来，嵌入实体的完整上下文（不仅仅是名称）。

考虑：

类型 属性 元数据 相关内容

因为身份存在于上下文中。

4/ 去重

许多系统在这一步失败。

因为：

苹果公司 ≠ 苹果这种水果 巴黎，法国 ≠ 巴黎，得克萨斯 两个人可能同名

解析解决的是命名问题。 去重解决的是身份问题。

这是两个完全不同的任务。

5/ 路由

最后，系统决定：

合并 人工审查 创建新节点

而最好的系统遵循一个简单的规则：

证据强度 = 操作权限强度。

弱证据 → 新节点 强证据 → 合并 不确定的证据 → 人工审查

因为错误的合并代价高昂。

一个重复节点令人烦恼。

但一个被污染的图谱会悄无声息地毒害检索质量数月。

我最大的收获是什么？

知识图谱的质量并非由你的检索策略决定……

而是取决于最初创建图谱的管道。

把这五步做好……检索就会变得容易得多。

P.S. 我在《解码AI杂志》中详细拆解了完整管道、实体解析、去重阈值、审查队列以及生产架构。

点此查看：https://decodingai.com/p/keep-knowledge-graph-clean…

如何为AI代理保持知识图谱的清洁

来源：https://www.decodingai.com/p/keep-knowledge-graph-clean

两个月前，我开始在知识图谱之上构建统一记忆层。读者们反复提出一个问题：如何处理实体解析和去重而不污染图谱？

我没有凭空猜测，而是花了大量时间研究 mem0、cognee 和 Neo4j 实际是如何解决这个问题的。这个反复出现的问题暴露了几乎所有人都共有的一个困惑：人们把实体解析和去重当作同一个步骤。

正是这个困惑导致了图谱被污染。人们将命名和身份压缩成一次模糊检查。

此外，如果合并步骤设计不当，两个不同的现实世界实体可能悄然合并，污染你的图谱。

结果是，你因信任而构建的图谱失去了可信度。图谱悄然腐烂。无人信任它，而你投入了整个记忆层却无人使用。

这种失败无形无迹，直到需要修复时才发现代价高昂。解决办法是将命名与身份分开。

我们将逐步介绍端到端的管道。这包括LLM提取、用于命名的实体解析、嵌入完整节点以及用于身份的去重。再加上大多数教程忽略的两个安全网。

我们已经在之前的文章中介绍了完整记忆系统设计（https://www.decodingai.com/p/understanding-neo4j-graph-agent-memory-system）和本体设计（https://www.decodingai.com/p/ship-a-knowledge-graph-ontology-in-5-minutes）。本文只聚焦于如何保持图谱清洁。读完后，你将能够设计一个随着增长依然保持清洁且可用的图谱。

为什么我们在产品中放弃了RAG（Product）

（https://www.youtube.com/watch?v=BtY6hqNpMNk）

placeholder（https://www.youtube.com/watch?v=BtY6hqNpMNk）

本文讲解如何保持图谱记忆层的清洁。在最近的一期播客中，我讨论了在此之前的一个决策：你是否真的需要检索。

我解释了为什么我们为一个金融顾问产品放弃了RAG。一位顾问的所有数据加起来只有64,000个token，因此加载完整上下文比RAG的曲折检索循环更有效。我使用的公式是：你的数据与上下文窗口的比率。

我们还讨论了后悔到处使用MCP、将“氛围编码”输出视为编译步骤，以及为什么一旦模型编写了代码，AI评估就变成了真正的工作。

观看本期节目：（https://www.youtube.com/watch?v=BtY6hqNpMNk）

输入一篇文档或一次对话轮次。输出一组规范的、已去重的节点，正确连接到现有图谱中。之间的所有步骤都是为了确保每个新节点命名正确、身份无误。

首先，LLM提取器读取文本，并以（实体，关系，实体）三元组的形式输出实体和关系。它锚定在POLE+O、事实和偏好的本体中。这确保了它只提取你实际关心的实体类型，正如我们在本文（https://www.decodingai.com/p/ship-a-knowledge-graph-ontology-in-5-minutes）中深入解释的那样。

例如，关于一个人在某个公司工作的句子会变成（人物） -[:WORKS_AT]->（组织）三元组。本体告诉提取器哪些类型是重要的。

如果仅使用LLM进行提取成本过高，你可以在此处使用成本分层级联：从快速的统计模型（如spaCy用于常见实体）开始，转向零样本模型（如GLiNER用于领域特定类型），最后回退到LLM处理复杂情况。

在触及图谱之前，我们必须决定这个新实体应该叫什么。系统将其名称与同类型的现有节点进行规范化。这是寻找规范名称的步骤，此时不进行任何合并。

从原始文档到清洁的图谱节点：提取、解析、嵌入、去重，然后是合并/标记/添加决策。 （https://substackcdn.com/image/fetch/$s_!qe_I!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9ae16fdb-fca4-480b-b88a-c43f8b35a461_1200x1009.png） 从原始文档到清洁的图谱节点：提取、解析、嵌入、去重，然后是合并/标记/添加决策。

接下来，我们计算一个覆盖实体完整上下文的嵌入。这包括其名称、类型和属性。我们嵌入的不仅仅是它的裸名。这使得后续的去重能够比较身份而非拼写。

我们将嵌入的节点与现有节点进行比较。这决定了它是否与图谱中已有的某个实体是同一个现实世界实体。

基于去重结果，系统做出最终路由决策。它要么合并到现有节点，要么将该对标记为人工审查，要么添加一个全新的节点。

一个新提到的公司被提取为一个带类型的实体。解析步骤将其规范化为规范名称。然后，用其完整上下文进行嵌入，以捕获其语义含义。再与同类型的现有节点进行比较以验证其身份。最后，它被添加、合并或标记为审查。

解析和去重是两个不同的决策，完成两项不同的工作。让我们分别深入探讨。

在解析过程中，我们为每个实体找到规范名称。它回答的是“我们应该叫它什么？”这个问题。

它处理拼写错误、缩写和表面形式的相似性。这些是人和文档写出同一事物的杂乱方式。它在一个短路链中使用精确、模糊和语义匹配。

短路链仅在未找到置信匹配时才将实体传递给下一个匹配器。如果精确匹配失败，则尝试模糊匹配。如果模糊匹配失败，则尝试语义匹配（仅对名称使用轻量嵌入）。

但仅针对同类型现有节点的名称进行匹配。你永远不会将人物名称与组织名称进行比较。

“NYC”解析为“纽约市”。“JP Morgan”解析为“摩根大通”。三种形式"John Smith"、"john smith"和"Jon Smith"都归结为一个规范的“John Smith”。

这是因为解析吸收了空白字符、大小写和拼写变体。模糊字符串匹配使用基于token的比较来处理单词顺序，并使用部分匹配来处理缩写。在这个阶段，系统只更新节点的canonical_name属性。尚未进行任何图谱合并。

解析通过精确→模糊→语义匹配（仅对同类型名称）来分配规范名称，同时从不合并节点。 （https://substackcdn.com/image/fetch/$s_!p1qh!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F37cc7c05-b7d4-4317-a222-5b4fa3ac46ea_1400x536.png） 解析通过精确→模糊→语义匹配（仅对同类型名称）来分配规范名称，同时从不合并节点。

通常，你还会跟踪每个节点的别名列表。每当通过模糊或语义匹配找到一个与当前canonical_name不匹配的新命中时，就将其添加到别名列表中。这样，在未来的检查中，你可以先检查别名列表来加速匹配。

相似名称不足以成为两个实体相同的强证据。这正是大多数人模糊的界限。模糊它正是导致静默污染的原因。

苹果公司不是苹果这种水果。它们类型不同，因此类型门控已经将它们分开。一个更难的例子是NVIDIA的CEO Jensen Huang与台北一位同名的医生。

他们名字相同，类型相同。但他们是两个不同的现实世界人物。仅凭命名相似性会愉快地将他们融合。

不过，规范名称对于GROUP BY操作非常有用，在查询和可视化时，我们可以快速理解数据。在人工审查期间，我们甚至可以发现重复项并手动解决。

这就是为什么身份是一个独立的决策。解析告诉我们如何称呼这个节点。它有意地没有告诉我们这个节点是否是重复的。

第二个更冒险的问题属于去重。

去重是身份层。它回答更难的问题：“这是同一个现实世界实体吗？”这是实际发生合并的步骤。[5]（https://neo4j.com/labs/agent-memory/explanation/resolution-deduplication/）

输入一个嵌入的节点。输出一个单一的路由决策：合并到现有节点、标记为审查、或创建新节点。

系统嵌入完整的实体上下文。然后将其与现有节点在完整上下文上使用语义和模糊相似度进行比较。更丰富的信号使其能够区分解析无法区分的两个同名同类型实体。

节点的上下文指的是实体的属性，例如其文本、图像、视频内容，甚至是元数据属性，如人物的电子邮件或出生日期，或者对象的型号或制造商。不过，你不需要嵌入所有内容（比如标识符），而是针对每个本体类型选择包含最高信号量的字段。

组合后的去重分数是一个明确的加权混合。它使用嵌入分数乘以0.7加上模糊分数乘以0.3。基于0到1的相似度分数，我们有三个区间。

高置信度（≥0.95）触发自动合并。中等置信度（0.85–0.95）将对标记为人工审查。低置信度（<0.85）创建新节点。

几乎确定的身份允许自动合并。不确定的中间区间升级处理。弱证据则直接成为新节点。

错误的合并会静默污染图谱。这种污染无形无迹，直到代价高昂时才被发现。以巴黎为例：两个地点节点都命名为“巴黎”。

一个是法国首都，另一个是德克萨斯州的巴黎。它们同名、同类型，并且裸名嵌入非常相似。但它们是两个不同的地方。

危险的部分是中间区间，即灰色地带。这是系统不确定、需要人类介入的地方。

去重对完整上下文相似度进行评分，然后路由到自动合并、人工审查或新节点——更强的证据对应更不可逆的操作。 （https://substackcdn.com/image/fetch/$s_!HtX8!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2cbddf49-7c66-407a-946e-57baa4d3c128_1400x785.png） 去重对完整上下文相似度进行评分，然后路由到自动合并、人工审查或新节点——更强的证据对应更不可逆的操作。

当去重分数落在中间区间（0.85–0.95）时，系统故意不合并。它将这对标记为待人类决定，因为合并是一项危险操作，我们应非常慎重。

源节点被“墓碑化”，即保留以用于取证查询，但跳过将来的匹配。真正撤消一次合并意味着重新摄入源数据。这种可逆性成本正是灰色地带存在的全部原因。

每当一个新实体被标记为人工审查时，就会创建一个新节点，并在图谱内部添加一条(:Entity)-[:SAME_AS {status:'pending', confidence}]->(:Entity)边。人工审查步骤将该status转换为confirmed或rejected。审查队列只是一个查询待处理SAME_AS边的Cypher查询，按置信度排序。

对于每一对标记的实体，审查者回答一个问题：这实际上是一个重复项、一个新节点，还是两者都不是？

这种情况通常发生在相关但不相同的实体上。Codex模型和Codex CLI是相关的，但不是同一个对象。同样地，CEO Jensen Huang与台北一位同名的医生也是如此。

这在实体生命周期的初期最为困难。当元数据稀缺时，相似度会飙升，你可能会将一个节点的属性污染到另一个节点上。

人工审查捕获了实时管道中浮现的不确定配对。但有些重复项从未被浮现出来。这就是“梦境管道”所填补的空白。

在系统摄入文档时，数据通常并行流入。如果两个实体同时被处理，解析和去重步骤永远无法将它们相互比较。

系统永远不会检查来自对话X的Claude Code和来自文档Y的Claude Code是否是同一个实体，因为在其中一个被写入时另一个在图谱中并不存在。

你每晚运行一次梦境管道。它只对最近摄入的节点重新运行去重过程。否则，你将不得不循环遍历图谱中的所有节点，随着图谱的增长，这会变得越来越昂贵。

它不会运行完整的解析链。因为嵌入在摄入时已经计算完毕，这是一个轻量操作。主要是数据库读写，没有新的模型调用。由于它主要增加I/O压力，请在有机流量低时运行，通常在夜间，因此得名梦境管道。

过去四个月，我一直在知识图谱之上构建统一记忆层，我学到保持图谱清洁是最困难的部分。保持知识图谱清洁是决定图谱是否会被使用的维护步骤。充满噪声、碎片和错误合并的图谱不会被信任，也不会被查询。

如果你想了解更多，记得我们还在之前的文章中介绍了通过知识图谱构建的完整记忆系统架构（https://www.decodingai.com/p/understanding-neo4j-graph-agent-memory-system）和本体设计（https://www.decodingai.com/p/ship-a-knowledge-graph-ontology-in-5-minutes）。

但我想知道的是：

**你用过哪些核心策略来保持知识图谱的清洁和可用性？有