DGL图节点ID映射错位问题的根源与系统性修复方案

DGL构建异构图时，节点ID在编码、图构造、NetworkX转换及结果回填各阶段，极易发生类型不一致或索引偏移，最终导致输出中`s`列出现重复值，且无法对应回原始ID。问题的根源，说白了就三点：整数类型混用（比如`torch.int64`、`numpy.int64`和Python原生的`int`之间乱切换）、节点编号没有全局对齐、以及`to_networkx()`这个函数在背后偷偷重编号，直接把ID给搞失真了。

一、根本症结：DGL的节点ID不是“原始标签”，而是连续索引

DGL里所有图结构（包括异构图）的节点ID，有一个硬性规定：必须是连续非负整数（0, 1, 2, ..., N−1），而且每个节点类型独立编号。很多人在代码里这样写：

num_nodes_dict = {    'sh': src_sh.max() + 1,    'b': src_b.max() + 1,    'd': src_d.max() + 1,    's': max(dst_sc_sh.max(), dst_s_b.max(), dst_s_d.max()) + 1}

表面上看没问题，但这里埋了个大坑。假设原始ID是`[101, 205, 307]`，`max()+1`算出来是308，但实际只用了3个节点。中间那295个空白ID就被空占了，导致图稀疏、内存浪费，更关键的是，后续`to_networkx()`会把所有308个槽位都当成节点，包括那些孤立无边的节点。

还有更隐蔽的问题：`dst_s_sh`, `dst_s_b`, `dst_s_d` 里的`s_id`，很可能来自不同的编码器。比如，对每张表的`s`列分别单独调用`LabelEncoder().fit()`，结果同一个原始商家ID（比如"shop_A"），在不同边关系里被映射成了不同的数字（比如5和12）。这直接破坏了节点的一致性，答案当然是错的。

那么，正确的做法是什么？全局统一编码。先把所有涉及`s`类型的原始ID收集起来，不管来自哪张表，一次性编码：

# ✅ 全局收集 & 统一编码
all_s_ids = pd.concat([
    e_data['s'].astype(str),
    l_data['s'].astype(str) if 's' in l_data.columns else pd.Series([]),
    c_data['s'].astype(str) if 's' in c_data.columns else pd.Series([])
]).unique()
s_encoder = LabelEncoder()
s_encoder.fit(all_s_ids)  # 所有s节点共用同一编码器

# 后续统一转换
e_data['s_id'] = s_encoder.transform(e_data['s'].astype(str))
l_data['s_id'] = s_encoder.transform(l_data['s'].astype(str))
c_data['s_id'] = s_encoder.transform(c_data['s'].astype(str))

二、to_networkx() 是ID失真的元凶：它会丢弃类型信息并重编号

DGL异构图调用`.to_networkx()`时，会发生什么？它会自动把异构图展平为同构图，并将所有节点强制重映射为0, 1, 2, ...的连续整数，原始的类型标识和ID语义全部丢失。举个例子：

这时候你算出来的`degree_centrality[node]`，里面的`node`是NetworkX的新ID（0-based连续索引），跟原始s ID八竿子打不着。直接赋值给`result_df['s_id']`，数据错位就是必然的了。

所以，一个更安全的替代方案是：绕过to_networkx()，直接用DGL原生API计算指标。DGL支持直接在异构图上提取子图或邻接关系。如果只需要s类型节点的度中心性，可以这样算：

# ✅ 纯DGL方式：获取s节点的入度（即指向s的边数）
in_degrees = hetero_graph.in_degrees(etype=('sh', 'sh_to_s', 's')) \
             + hetero_graph.in_degrees(etype=('b', 'b_to_s', 's')) \
             + hetero_graph.in_degrees(etype=('d', 'd_to_s', 's'))
# in_degrees[i] 对应 s类型节点 i 的总入度（i 是DGL内部ID）
# 将其映射回原始s标签
original_s_labels = s_encoder.inverse_transform(np.arange(len(in_degrees)))
s_centralities = pd.Series(in_degrees.numpy(), index=original_s_labels)

如果实在要用NetworkX，那必须显式维护一张ID映射表：

# ✅ 显式构建DGL→NX ID映射（仅针对s节点）
s_nodes_dgl = hetero_graph.nodes('s').numpy()  # [0, 1, 2, ..., N_s-1]
s_nodes_original = s_encoder.inverse_transform(s_nodes_dgl)  # ['shop_A', 'shop_B', ...]

# 转换为NetworkX图时，用节点属性保留原始ID
nx_g = nx.Graph()
nx_g.add_nodes_from(zip(s_nodes_dgl, [{'orig_id': x} for x in s_nodes_original]))
# ... 添加边（注意边两端也用dgl id）

# 计算后，通过属性回填
centrality_dict = nx.degree_centrality(nx_g)
# centrality_dict[key] 中 key 是DGL ID（如0,1,2...），非原始ID
result_df['s'] = s_nodes_original
result_df['degree_centrality'] = [centrality_dict.get(i, 0) for i in s_nodes_dgl]

三、类型陷阱：torch.int64 ≠ numpy.int64 ≠ Python int

代码里多种整数类型混用，也是个常见问题。`e_data['sh_id'].values.astype(np.int64)`是NumPy数组，`dgl.heterograph(...)`内部期望的是`torch.Tensor`，而`LabelEncoder.transform()`返回的又是`np.ndarray`。当`np.int64`数组传入DGL，虽然会被静默转为`torch.int64`，但后续如果跟`list(range(...))`（Python int）混用，索引时就可能触发隐式类型转换错误或广播异常。这种错误往往藏得很深，不容易排查。

所以，统一强制为torch.int64并验证形状，是个好习惯：

def safe_long_tensor(arr):
    return torch.as_tensor(arr, dtype=torch.int64)

src_sh = safe_long_tensor(e_data['sh_id'].values)
dst_s_sh = safe_long_tensor(e_data['s_id'].values)
# ... 其他同理

# 构建前校验
assert src_sh.dtype == torch.int64 and dst_s_sh.dtype == torch.int64
assert len(src_sh) == len(dst_s_sh), "边数量不匹配"

四、终极检查清单

总结：DGL的ID本质是稠密索引，不是业务ID。解决映射错位的核心逻辑很简单——业务ID → 全局编码 → DGL索引 → （可选）指标计算 → 逆编码回业务ID。跳过任何一个环节，结果都会对不上。务必抛弃“DGL会自动理解我的ID”这种直觉，全程显式地控制映射关系，才是正解。