现象
在 FalkorDB 中查询 HAS_REPORT 边的 Top 10 节点时，发现有 4 个 community_report 节点各有 4 条 HAS_REPORT 边指向它们。按照设计，每个 community 应该唯一对应一个 report，为什么会出现一对多？
Edge type: HAS_REPORT
Rank Title Count
1 技术部核心团队：后端架构与系统设计 4
2 产品部：用户增长与商业化策略 4
3 运维部：服务稳定性与监控体系 4
4 测试部：质量保障与自动化测试 4
理论上每个 community 只有一个 report，每个 report 只属于一个 community，HAS_REPORT 应该是 1:1 的关系。
用一个通俗的例子来理解
想象你在管理一个公司的组织架构
假设你的公司有这样的部门结构：
技术部 (278人)
└── 后端组 (253人)
“后端组”是”技术部”的子部门。现在 HR 要给每个部门写一份部门简介。
HR 发现”后端组”的核心成员和”技术部”高度重叠（后端组的人就是技术部的主力），于是 AI 给两个部门生成了几乎一模一样的简介：
| 部门 | 简介标题 | 部门人数 |
|---|---|---|
| 技术部 (community 1491) | “核心技术团队：后端架构与系统设计” | 278人 |
| 后端组 (community 2790) | “核心技术团队：后端架构与系统设计” | 253人 |
两份简介的标题和内容完全相同（因为描述的本质上是同一群人），只有”部门人数”（size）不同。
由于内容相同，系统给它们算出了相同的 ID（基于内容的 hash）。
对应到我们实际发现的 4 组问题数据：
| 部门类比 | 实际 community | 简介标题 | 人数(size) |
|---|---|---|---|
| 技术部 | community 1491 | “技术部核心团队：后端架构与系统设计” | 278 |
| └── 后端组 | community 2790 | “技术部核心团队：后端架构与系统设计” | 253 |
| 产品部 | community 200 | “产品部：用户增长与商业化策略” | 796 |
| └── 产品一组 | community 1100 | “产品部：用户增长与商业化策略” | 631 |
| 运维部 | community 1909 | “运维部：服务稳定性与监控体系” | 180 |
| └── 运维一组 | community 3073 | “运维部：服务稳定性与监控体系” | 178 |
| 测试部 | community 953 | “测试部：质量保障与自动化测试” | 21 |
| └── 测试一组 | community 2343 | “测试部：质量保障与自动化测试” | 19 |
问题出在哪里？
当把这些数据导入图数据库时：
第一步：创建 report 节点
以”技术部”和”后端组”为例。系统看到 parquet 里有两行数据（同一个 ID，不同的 community），就无脑创建了两个节点：
Report 节点 A: {id: "abc123", community: 1491, size: 278} -- 技术部的简介
Report 节点 B: {id: "abc123", community: 2790, size: 253} -- 后端组的简介
第二步：创建 HAS_REPORT 边
系统遍历每个 report 记录，用 id 去匹配 report 节点：
-- 处理技术部 (community 1491)
MATCH (c:communities {community: 1491})
MATCH (r:community_reports {id: "abc123"}) -- 匹配到 2 个节点（A 和 B）！
CREATE (c)-[:HAS_REPORT]->(r)
-- 结果：技术部 → 节点A, 技术部 → 节点B（2 条边）
-- 处理后端组 (community 2790)
MATCH (c:communities {community: 2790})
MATCH (r:community_reports {id: "abc123"}) -- 同样匹配到 2 个节点！
CREATE (c)-[:HAS_REPORT]->(r)
-- 结果：后端组 → 节点A, 后端组 → 节点B（2 条边）
最终结果：这个 report 标题下有 4 条 HAS_REPORT 边（2 个部门 × 2 个同 ID 节点 = 4）。
而正确的结果应该是：技术部 → 技术部的简介（1 条），后端组 → 后端组的简介（1 条），共 2 条。
根因分析
问题由两个因素叠加导致：
1. Leiden 层级聚类产生了内容相同的 Report
GraphRAG 使用 Leiden 算法做层级社区发现。当子社区的成员与父社区高度重叠时，LLM 为它们生成了内容几乎相同的 report。由于 report ID 是基于内容的 hash，内容相同 → ID 相同。
实际数据验证：
| report id | communities | sizes | 层级关系 |
|---|---|---|---|
| 6516e2f4… | 2790, 1491 | 253, 278 | 2790 是 1491 的子社区 |
| feda9fa0… | 1100, 200 | 631, 796 | 1100 是 200 的子社区 |
| d8f25d09… | 2343, 953 | 19, 21 | 2343 是 953 的子社区 |
| 223c76c6… | 3073, 1909 | 178, 180 | 3073 是 1909 的子社区 |
2. 导入逻辑缺乏去重和精确匹配
导入代码中：
# 创建节点：无条件 CREATE，不去重
"UNWIND $batch AS p CREATE (n:community_reports) SET n = p"
# 创建边：只按 id 匹配，没有加 community 条件
"MATCH (r:community_reports {id: p.rid})" # 匹配到多个同 ID 节点 → 笛卡尔积
解决方案
HAS_REPORT 创建时精确匹配
在创建 HAS_REPORT 边时，同时匹配 id 和 community，避免笛卡尔积：
# Before (有 bug)
"MATCH (r:community_reports {id: p.rid}) "
# After (修复)
"MATCH (r:community_reports {id: p.rid, community: p.cnum}) "
这样每个 community 只会匹配到属于自己的那个 report 节点，创建 1 条边。
教训：在图数据库中用 MATCH + CREATE 模式创建关系时，如果匹配条件不够精确（目标节点有重复），就会产生意料之外的笛卡尔积。始终确保 MATCH 条件能唯一定位到目标节点。