图中同一个显示名称可以对应不同实体，合并依据和原文事实需要分别保留。
两份材料都提到“星河项目”，建图时是不是应该合成一个节点？如果它们分别属于两个独立空间，合并后可能把甲空间的负责人连到乙空间的截止时间上。名字看起来一致，事实却被错误拼接；图检索再流畅，也只是在一张有误的图上推理。
显示名字不适合作唯一身份
名称可能重名、改名、使用简称，也可能在不同版本中指代不同对象。可以为实体保存稳定内部标识，再把显示名称和别名作为属性，避免只用一段文本当作所有关系的主键。
内部标识并不需要包含全部含义，重要的是能区分对象，并在更新时维持一致。实体所属空间、类型、已知外部编号、关联时间等信息，可以作为消歧依据，但不能把每个看起来接近的字段都当成充分证明。
例如同名项目处于不同租户空间，通常就应先隔离。反过来，同一对象的全名与缩略名不同，也不意味着应该永久分开。消歧是在证据支持下建立身份关系，不是简单执行“同名合并、异名拆开”。
别名候选和确认合并分开
可以先产生可能同一实体的候选对，再根据明确标识、上下文和来源进行确认。相似度高或名称相同，可以作为找候选的线索，不应直接变成不可撤销的合并动作。
不确定时保留候选状态，允许下游知道关系尚未确认。这样比为了让图看起来整洁而强行选一个对象更诚实。若系统必须自动处理，应定义接受条件、拒绝条件和需要人工复核的范围，并保留相应理由。
还要注意传播效应：A 与 B 相似、B 与 C 相似，不必然说明 A 与 C 是同一个实体。简单把所有相似边做连通分量，可能让一条错误边把整个群组串起来。合并规则应检查群组内部约束，而不是只看局部两两分数。
事实本身要带着来源走
“实体甲依赖实体乙”这条关系，最好能定位到文档、版本和原文片段。抽取结果与原始事实之间保留映射，后续发现实体合并有误，才能知道哪些关系需要拆开、哪些报告需要重新生成。
来源数量也不能直接当成独立支持次数。同一段文字的转载、同文档的多个切块，可能只是一次信息被重复发现。可以保留发现路径，但不要因为计数变大就自动提高事实确定性。
如果不同来源描述冲突，还需要保留各自的时间与适用范围。新版本可能替代旧规则，也可能只是另一个环境的规则；简单按时间最新覆盖，仍可能误删有效事实。
错误合并必须能够撤销
只保存合并后的节点，删除原来的实体与事实来源，会让纠错非常困难。可以记录一次合并涉及哪些标识、采用什么依据、何时生效，以及旧标识怎样映射。更正时根据这份记录重新分配关系，而不是靠人工猜测每条边原来属于谁。
撤销也不能只拆节点。基于错误关系生成的社区报告、向量、缓存和最终摘要，可能仍然包含串接后的结论。需要定义派生内容的失效与重建范围，让读取端不会继续使用旧结果。
这并不意味着每次更正都必须全库重建。可以先追踪依赖，定位受影响部分，再根据系统能力采用局部重算或版本发布。重点是能说明当前读到的图和报告来自哪一版事实集合。
用最小反例检验流程
准备两个同名但不同空间的实体，给它们设置不同负责人；再准备同一实体的全名与缩写，附上相同稳定编号。一个合并流程应能区分这两类情况，还要在发现错误后还原各自关系。
这样的字典或小图实验只能核对身份与回滚规则，不能证明真实文档抽取准确率。真正效果还要有标注样本和误合并、漏合并的评测，尤其要观察错误是否继续污染后续摘要。
GraphRAG 的工程可信度，不只取决于找到多少关系，也取决于每条关系是否认得清对象、找得到出处、改得回来。若同名节点被拆开了，但社区报告仍引用合并后的旧结论，你会认为纠错已经完成吗？