一个模型适配任意关系类型：异质图的语言模型化与少样本实践

项目标题里的“一个模型，任意关系类型”，第一次看到时我第一反应是营销话术。做过异质图（异构图）的人都知道，这行的痛点是 schema 定制：换一个业务域，节点类型、边类型一变，模型基本就得推倒重来，元路径要重新设计，参数要重新训，连评估脚本都得改。所以“任意关系类型”这五个字如果成立，意味着图模型从“一个数据集一个模型”走向“一个底座服务一堆图”，这是工程上质变，不是学术上刷点。

我花了几天时间把这套思路从头捋了一遍，也自己搭了个小规模的复现实验。这篇就把我理解到的核心设计、我踩过的坑、以及可以直接抄的实操流程全部摊开讲。适合两类人看：一类是在做推荐、风控、内容理解，手里握着多张异构数据表、每次上新业务都要重做一遍图模型的工程同学；另一类是刚接触异质图，想知道“图”和“语言模型”这两套东西到底怎么接上的同学。不需要你有很深的图神经网络基础，我会把该补的常识都补上。

1. 一个模型吃下任意关系类型，难点到底卡在哪

1.1 先把“关系类型”这个词说清楚

很多同学一上来就被“异质图”三个字唬住，其实拆开看很简单。普通图里所有节点是同一种东西，所有边也是同一种关系，比如社交网络里“人—关注—人”。异质图就是节点和边都分了类：节点可能是用户、商品、店铺、评论，边可能是购买、浏览、收藏、属于、评价。所谓关系类型，严格讲是一个三元组：源节点类型、边语义、目标节点类型，比如“用户—购买—商品”和“用户—浏览—商品”虽然两端类型一样，但是两种完全不同的关系类型，一个是交易意图，一个是兴趣信号。

这个区分极其重要，因为决定模型能不能“通用”的关键就在这儿。如果你的模型只认边的名字，那“购买”这个词换个业务就叫“下单”，模型又得重学；如果模型认的是“源类型—语义—目标类型”这个结构位置加上语义描述，它就有机会把“用户—购买—商品”上学到的东西迁移到“读者—订阅—专栏”上。这就好比一个人学会了“主语—动作—宾语”的句法结构，换一门语言的词汇他也能快速上手，但如果他只是死记硬背了某几句话，那换个场景就废了。

所以后面所有设计，本质都在回答一个问题：怎么把“关系类型”表示成一个可以增删、可以迁移、语义还能被模型理解的东西。

1.2 传统方案的三道坎，每一道都很要命

第一道坎是结构绑定。主流异质图神经网络（HGT、HAN 这一类）在建模时，关系类型通常对应一组独立的参数矩阵或者注意力头。关系类型有多少种，参数就有多少套。这意味着你新增一种边类型，模型结构就得改，改动之后旧参数还不能直接复用，得重训。业务上这是什么体验？你上个新功能，数据团队加了一张关联表，算法这边排期两周。这在快速迭代的场景里基本不可接受。

第二道坎是元路径靠人肉设计。“用户—购买—商品—属于—店铺—是同店—店铺”这种路径，需要领域专家手工枚举。枚举得好，效果起飞；枚举漏了，模型就是瞎子。更麻烦的是元路径数量随类型数组合爆炸，你没法穷举，只能凭经验挑几条，这就把大量结构信息浪费了。

第三道坎是少样本场景直接躺平。新业务上线时标签往往只有几十上百条，传统 GNN 参数多、先验少，几十条标签喂下去基本就是过拟合。而语言模型这边，预训练阶段已经吃进了海量文本，天然带着“购买意味着交易”“评论通常针对商品”这类世界知识，这部分先验如果能接进图任务里，少样本表现就有救。

三道坎叠在一起，就解释了为什么“一个模型通吃”听起来这么诱人——它不是把效果提升几个点的问题，而是把交付模式从“项目制”变成“产品制”的问题。

1.3 换思路：别把图当矩阵，把图当一段话

关键的思路转换在这里。传统 GNN 把图看成邻接矩阵加特征矩阵，做的是矩阵乘法和消息聚合。而语言模型只认一件事：token 序列。那能不能把一张异质图的局部结构，翻译成一段模型能读的“话”？

完全可以，而且翻译起来很自然。一个节点的邻域，本质上就是一堆事实陈述：“这个用户买了这个商品”“这个商品属于这个店铺”“这条评论针对这个商品”。这些本来就是自然语言能表达的东西，只不过我们平时用邻接矩阵存，没用文字写出来。一旦写成文字，语言模型读起来毫无障碍。

我在实验里做过一个直观对比。把同一个商品的邻域用两种方式喂给模型：一种是one-hot 的邻居 ID 列表，模型完全不知道这些 ID 有什么含义；另一种是带类型标注的文本描述，模型立刻就能说出“这个商品被大量用户收藏但购买少，可能是个高关注低转化品”。后者的 zero-shot 表现明显更好，因为它调用了预训练阶段积累的常识。

这套“图转文本”的做法有个隐藏好处：关系的可扩展性变成了词表的可扩展性。语言模型本来就支持扩词表，新增一种关系类型，无非是新增一个特殊 token 的事，模型主体一行代码都不用改。这才是“任意关系类型”能成立的工程基础。

2. 整体设计拆解：语言模型怎么“看懂”一张异质图

2.1 令牌化的三层结构：节点、关系、结构

把图变成序列，不是简单地把邻居名字拼起来就完事，得设计好三层信息怎么编码，缺一层模型就残废。

第一层是节点令牌。节点本身有 ID，但光有 ID 没用，必须有内容。所以节点令牌一般由“类型标记 + 属性文本”构成，比如<node_type:item> 无线耳机，价格 299，月销 1.2 万，退货率 3%。这里的属性文本是天然语言，模型理解起来零成本。ID 只用来做去重和引用，比如序列里第二次出现同一个节点就写成<ref:id_88>，省 token。

第二层是关系令牌。这是整套设计的灵魂。每种关系类型对应一个可学习的特殊 token，命名上强制遵循“源类型__语义__目标类型”的规范，比如<rel:user__buy__item>。这个 token 在词表里是一个独立条目，有自己的 embedding，但它承载的语义不是从零学的——训练时我会同时给它配一句自然语言描述（“用户购买了商品”），让文本描述和关系令牌在表示空间里对齐。

第三层是结构令牌，用来表达拓扑位置。包括跳数标记（<hop:1>、<hop:2>）、方向标记（正向/反向）、以及度数分桶（<deg:high>表示该节点连接数处于全网前 10%）。别小看这几个标记，异质图里“中心节点”和“边缘节点”的邻域信息密度差了一个数量级，模型不知道这个背景，很容易把采样偏差当成真实规律。

三层拼起来，一个节点的局部邻域就长这样：

<node:u_1024> 类型=用户，注册 3 年，近 30 天活跃 12 天 <rel:user__buy__item> <hop:1> <node:i_88> 类型=商品，无线耳机，299 元 <rel:user__browse__item> <hop:1> <node:i_203> 类型=商品，机械键盘，499 元 <rel:user__follow__shop> <hop:1> <node:s_7> 类型=店铺，数码专营

这段“话”人读得懂，模型也读得懂，信息密度比邻接矩阵高得多。我实测过 token 消耗，1-hop 采 15 个邻居，平均每个邻居 25 到 40 个 token，整体控制在 600 token 以内，绝大多数开源基座的上下文窗口都装得下。

2.2 关系令牌：新增一种关系只需要加一个词

这是我觉得最漂亮的一点，值得单独展开。

传统做法里，新增关系类型等于新增一组参数矩阵，参数量是hidden_dim × hidden_dim，几百万起步，而且和旧参数不共享，必须重训。关系令牌的做法是：新增一个 token，参数量是hidden_dim，7B 模型上大概 4096 个数，四舍五入等于零。

具体怎么加？三步：

1. 在 tokenizer 里注册新的特殊 token；
2. 调用resize_token_embeddings扩展 embedding 矩阵；
3. 训练时冻结原有词表 embedding，只训练新增的那几行，再配一个 LoRA 适配器。

这里有个细节必须讲清楚，不然容易翻车。新 token 的 embedding 是随机初始化的，如果直接开训，梯度信号很稀疏（一个关系类型在序列里可能只出现几次），学得非常慢。我的做法是给它一个文本初始化：先用关系类型的自然语言描述（“用户购买商品”）过一遍模型，取最后一层隐状态均值，作为这个关系令牌的初始向量。这么一搞，新关系类型从第 0 步就带着语义，收敛速度快很多，我这边实测能省掉大约三分之一的训练步数。

还有一个好处是关系类型的可组合性。因为关系令牌是按“源类型__语义__目标类型”命名的，模型在训练中见过“用户—购买—商品”和“用户—收藏—商品”，当遇到全新的“读者—订阅—专栏”时，虽然三个词都没见过，但“施事—动作—受事”的结构位置是见过的，模型能借助结构位置做类比推理。这就是我说的“学句法而不是背句子”。

我做过一个对照：让模型在 zero-shot 条件下处理一个训练时完全没出现过的关系类型。纯随机初始化的情况下准确率基本是瞎猜水平；做了文本初始化加结构位置对齐之后，准确率能到有监督版本的六成左右。这个数字不算惊艳，但考虑到零样本、零参数改动，工程价值很大。

2.3 指令混合：让模型学“关系语义”而不是背数据集

如果只用单一数据集做指令微调，模型很容易学歪——它会把“用户买商品”这个具体场景记死，换个领域就完了。这是所有微调方案的通病，业内叫“指令过拟合”。

解决办法是指令混合：从多个来源、多种 schema 的子图里分别构造指令，混在一起训。具体来源可以分三类。第一类是目标域自己的无标注数据，用自监督任务构造指令（掩码属性还原、边类型预测）。第二类是结构相似但领域不同的图，比如都是“用户—物品”二部图，一个来自电商，一个来自内容社区，让模型见识同一结构在不同语义下的表现。第三类是纯文本的关系描述，把关系类型写成句子，做文本蕴含或者分类任务，保持模型的语言能力不被图任务冲垮。

混合比例上我试过几组，比较舒服的是 5:3:2，目标域自监督占一半，跨域结构占三成，纯文本占两成。纯文本那一份千万别省，我第一版为了“专注图任务”把它去掉了，结果训完模型的语言能力明显退化，生成的解释开始胡说八道，下游 zero-shot 也跟着掉。这个坑我印象很深。

指令的模板也要多样化，不能所有任务都套一个壳。节点分类用“该节点的类别是？”，链接预测用“这两个节点之间是否存在某种关系？”，邻域描述用“请概括该节点的一阶邻域特征”。模板多样性带来的收益在跨域迁移时特别明显，我观察到的提升大概有三到五个点。

3. 核心细节解析：几个决定成败的实现要点

3.1 邻域采样与序列预算，别让 token 爆掉

图节点的度数分布是长尾的，热门商品可能有几万个邻居，你不采样直接塞，序列长度爆炸。所以采样策略和预算分配必须先定死。

我的配置是这样的：1-hop 最多采 20 个邻居，2-hop 最多采 30 个（每个 1-hop 邻居下挂 1 到 2 个），总 token 预算 768，超了就截断。采样的方式不是纯随机，而是分层加权：优先保留关系类型稀缺的邻居（比如某个用户只有一条“投诉”边，这条边信息量远大于他的一百条“浏览”边），同类型内部再按度数归一化随机采。这么做的道理很直白：信息量取决于稀有度和区分度，不取决于数量。

预算分配上给个具体算法，方便你直接抄：先算出每个关系类型在序列里的平均 token 消耗，再按各类型的重要度分配配额。比如“购买”类关系重要度高，给 30% 预算；“浏览”类重要度低，给 10%。如果某个类型超配额了，就按时间衰减或权重排序截断。这套逻辑写成代码不到二十行，但能显著降低无意义的长尾噪声。

提示：序列长度不是越长越好。我在 768 和 2048 两个预算下做过对比，2048 的版本在小样本任务上反而略差。原因不复杂，序列越长，关键信息被稀释得越厉害，模型抓不住重点。除非你的任务真的依赖远距离结构，否则别盲目堆长度。

还有个容易忽略的点：负采样。链接预测任务里，负样本不能纯随机采，否则模型学会的是“这两个节点类型不匹配”这种低级规律，一测就露馅。正确做法是采类型匹配但实际无边连接的节点对，难度更高，学出来的表示才有用。

3.2 关系令牌的初始化与训练策略

前面提了文本初始化，这里把完整的训练策略讲透，因为这块最容易出问题。

参数分组是这样的：新增的关系令牌 embedding 用较大学习率（我一般设 1e-3 到 3e-3），因为它要从零学；LoRA 适配器用常规学习率（1e-4 到 2e-4）；主干权重全部冻结。为什么主干要冻？两个原因。一是算力，全参微调 7B 模型在单机上基本别想，LoRA 能把可训练参数压到千分之一量级；二是防止灾难性遗忘，小样本场景下全参微调几乎必然把预训练知识冲掉。

顺便算一笔账，让你对参数量有个直观感受。假设词表新增 200 个关系令牌，隐藏维度 4096，那新增 embedding 参数量是 200 × 4096 ≈ 82 万。LoRA 这边，rank 取 8，作用在注意力层的 q、k、v、o 四个投影矩阵上，每个矩阵的低秩分解参数量是 2 × 8 × 4096 ≈ 6.6 万，四个就是 26 万，假设 32 层，总共约 840 万。加起来不到一千万，相对 70 亿的底座是 1.4% 左右。这就是“参数高效”的实际含义。

训练轮数不宜多，小样本场景下 3 到 5 轮就够，再多必然过拟合。我是按验证集损失早停，patience 设 2。另外有个小技巧：训练初期先只训关系令牌 embedding，把 LoRA 关掉，跑个几百步，等关系令牌的表示初步成型，再打开 LoRA 联合训练。这相当于先让模型学会“新词的意思”，再让它适应“新任务的问法”，分阶段比一锅炖效果稳。

3.3 自监督目标怎么设计才有信息量

没有标签的时候，自监督任务是唯一的监督信号，设计得好坏直接决定模型学没学到东西。我用了三个目标，各有分工。

第一个是掩码属性还原。随机遮蔽节点属性文本中的一部分（比如价格、类目），让模型根据邻域结构预测被遮的内容。这个任务逼着模型把结构信息和属性信息对齐，比如它要知道“连接了很多高端商品的用户，其购买力标签大概率不低”。

第二个是关系类型预测。给定两个节点和它们的上下文，让模型判断它们之间是什么关系类型。这个任务直接训练关系令牌的区分度，是“任意关系类型”能力的核心来源。这里负样本构造很关键，要从候选关系类型集合里采混淆项，比如“浏览”和“收藏”容易混，“购买”和“退货”容易混，专挑这些难例。

第三个是邻域对比。同一个节点的两个不同采样邻域作为正对，不同节点的邻域作为负对，做对比学习。这个目标的作用是让表示对采样噪声鲁棒——毕竟每次采样出来的邻居不一样，模型不能因为换了几个邻居就给出完全不同的判断。

三个目标的损失权重，我用的是 1 : 1 : 0.5。对比学习权重调低是因为它容易主导梯度，把另外两个目标压住。这个比例不是理论最优，是我在验证集上试出来的，你换数据集可能得重新调。

4. 从零跑通一次小样本实验：完整实操流程

4.1 数据与 schema 准备

假设手上有一份电商场景的异质图，节点类型有用户、商品、店铺、评论，关系类型有购买、浏览、收藏、属于、评价。第一步不是写模型，是写一份schema 描述文件，这东西后面所有环节都要用。

# schema.yaml node_types: user: description: "平台注册用户" attributes: [reg_days, active_days_30d, city_level] item: description: "在售商品" attributes: [category, price, monthly_sales, return_rate] shop: description: "商品所属店铺" attributes: [shop_level, main_category] review: description: "用户对商品的评价" attributes: [rating, text_len] relation_types: - name: "user__buy__item" src: user dst: item description: "用户购买了商品" - name: "user__browse__item" src: user dst: item description: "用户浏览过商品详情页" - name: "item__belong_to__shop" src: item dst: shop description: "商品归属于店铺" - name: "user__review__item" src: user dst: item description: "用户对商品发表了评价"

这份文件有三个作用：一是自动生成关系令牌的名字，保证命名规范统一，不会出现“buy”和“purchase”混用；二是提供自然语言描述，用于关系令牌的文本初始化；三是作为序列化模板的输入，程序化生成指令文本。我强烈建议把 schema 当成一等公民来管理，用版本控制管起来。我踩过的坑就是早期随手在代码里写死关系名，改一次业务就要全局搜索替换，痛不欲生。

4.2 序列化与词表扩展

序列化我写成了一个独立模块，输入是节点 ID 和 schema，输出是文本序列。核心逻辑是 BFS 采样加模板填充。

def serialize_neighborhood(node_id, graph, schema, budget=768): """把节点的局部邻域序列化成文本，控制在 token 预算内。""" lines = [] # 按关系类型分组，稀有类型优先保留 groups = graph.group_neighbors(node_id) ordered = sorted(groups.items(), key=lambda kv: kv[1].rarity, reverse=True) for rel_name, neighbors in ordered: quota = allocate_quota(rel_name, schema) # 按重要度分配 token 配额 used = 0 for nbr in neighbors.sample(weighted=True): line = render_line( rel_tok=f"<rel:{rel_name}>", hop="<hop:1>", node_desc=graph.describe(nbr, schema), ) used += count_tokens(line) if used > quota or count_tokens(lines) + used > budget: break lines.append(line) return "\n".join(lines)

渲染出来的单行大概长这样，和前面举的例子一致。这里有个细节值得说：graph.describe里属性的顺序是固定的，必须按 schema 里声明的顺序输出。为什么不随机打乱？因为在语言模型眼里位置是有信息的，属性顺序稳定反而帮助它形成“第几个位置对应什么字段”的模式，实测比随机打乱收敛快一点。

词表扩展和模型加载这部分，直接给可运行的骨架：

from transformers import AutoTokenizer, AutoModelForCausalLM from peft import LoraConfig, get_peft_model BASE = "your-open-base-model" # 7B 量级开源基座 tokenizer = AutoTokenizer.from_pretrained(BASE) model = AutoModelForCausalLM.from_pretrained(BASE, torch_dtype="bfloat16") # 1. 从 schema 收集所有关系类型，生成特殊 token rel_tokens = [f"<rel:{r['name']}>" for r in schema["relation_types"]] node_tokens = [f"<node_type:{n}>" for n in schema["node_types"]] struct_tokens = ["<hop:1>", "<hop:2>", "<deg:low>", "<deg:mid>", "<deg:high>"] special = rel_tokens + node_tokens + struct_tokens tokenizer.add_special_tokens({"additional_special_tokens": special}) model.resize_token_embeddings(len(tokenizer)) # 2. 用自然语言描述初始化关系令牌 init_relation_embeddings(model, tokenizer, schema) # 内部取描述文本隐状态均值 # 3. 冻结主干，只训 LoRA 和新增 token for name, p in model.named_parameters(): p.requires_grad = False for tid in tokenizer.convert_tokens_to_ids(special): model.get_input_embeddings().weight.requires_grad = True # 配合 mask 只训新增行 lora_cfg = LoraConfig( r=8, lora_alpha=16, lora_dropout=0.05, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_cfg)

代码里“只训新增行”那一步需要额外写一个梯度 mask，不然整个 embedding 矩阵都会被更新，那就等于把预训练词表也带偏了。这个细节很多教程会漏掉，但不做的话效果会明显下降，尤其是小样本场景，词表一动模型的语言先验就开始流失。

优化器分组也要配套写：

optimizer = torch.optim.AdamW([ {"params": new_token_embedding_params, "lr": 3e-3}, {"params": lora_params, "lr": 1.5e-4}, ], weight_decay=0.01)

学习率差二十倍，这是有意为之。新令牌要快速建立语义，LoRA 只需要轻微调整，两边用一个学习率必然有一边不合适。

4.3 参数高效微调配置与训练循环

训练配置直接给表格，方便对照。

训练循环本身没什么花活，但有两个实操细节我要强调。第一，指令要打乱混采，不能让模型连续看几十条同类型的指令，否则它会摸到“第几批次该做什么任务”的捷径。第二，损失只算答案部分，指令和图描述部分不参与 loss 计算，用 label mask 屏蔽掉。这一点如果做错，模型会花大量精力去学“怎么复述输入”，而不是“怎么回答问题”，这是我早期踩过的最蠢的坑，训了两天才发现 loss 曲线好看但下游一塌糊涂。

评估环节要分三组做，缺一不可：

1. 同域小样本：k=1、3、5，看节点分类的 Macro-F1。这是基本盘。
2. 跨域零样本：在训练时完全没出现过的关系类型上直接推理，看掉多少。这是检验“任意关系类型”成色的关键指标。
3. 消融对照：去掉文本初始化、去掉指令混合、去掉结构令牌，各跑一遍，确认每个模块真的在贡献。

我的实验结果大致是：k=5 时同域 Macro-F1 与调优过的传统 GNN 基本持平甚至略高；k=1 时优势明显，能高出五到八个点；跨域零样本大约是同域有监督的六成左右。这个表现我认为是“可用”而非“惊艳”，写论文可能不够，但做工程底座是够的。

5. 常见问题与排查实录

5.1 效果反而不如传统 GNN，八成是这几个原因

第一，关系令牌根本没学动。症状是训练 loss 下降很慢，或者下游表现和随机初始化的模型没区别。排查方法很简单：把关系令牌的 embedding 取出来，算一下不同关系类型之间的余弦相似度。如果所有关系令牌的向量几乎一模一样，说明模型压根没区分开它们。原因通常是训练样本里该关系类型出现次数太少（少于 50 次），或者学习率给低了。

第二，序列化把结构信息洗掉了。我见过一种写法，只把邻居的属性文本拼起来，关系令牌和跳数标记全省了。这样模型看到的就是一堆无序的文本片段，它根本不知道谁连谁，退化成文本分类器。异质图的价值全在结构上，序列化时宁可少放几个邻居，也要保留关系标记和跳数。

第三，评估泄漏。这个坑最隐蔽。如果你的训练集和测试集共用同一套关系类型，那模型可能只是记住了“这个关系类型对应的答案分布”，跨域一测就现原形。做通用性验证时，测试集必须包含训练时完全没出现的关系类型，而且这个隔离要在数据划分阶段就做好，不能训完再切。

第四，文本属性太长，关键字段被淹没。商品描述动辄几百字，全塞进去，价格、类目这些关键信号就被稀释了。我的处理是属性分级：核心字段（类目、价格、评分）必留，长文本字段截断到 50 字以内并且只保留前面部分，因为标题类文本的信息量集中在前半段。

5.2 问题速查表

还有两个我没写进表格但值得单独提的经验。一个是新关系类型的冷启动，如果你的业务要上一批全新关系，别指望直接 zero-shot，先给每种新关系构造 200 条左右的自监督指令（不需要人工标注，用结构自动生成），训个几百步，效果提升比调任何超参都明显。另一个是别迷信大基座，我对比过 7B 和更大规模，小样本图任务上 7B 完全够用，更大反而因为冻结参数太多、LoRA 容量相对不足而吃亏。算力省下来去做数据构造，回报率更高。

6. 这套思路适合谁用，边界在哪

6.1 什么场景值得上，什么场景别折腾

先说什么场景值得。第一类是多业务线共存、schema 频繁变动的团队。你有五条业务线，每条线的异质图 schema 都不一样，以前要维护五个模型，现在一个底座加五套关系令牌，运维成本差一个量级。第二类是冷启动严重的新业务，标签几十条，传统模型根本训不动，语言模型的先验这时候就是救命稻草。第三类是需要可解释性的场景，因为整个输入是文本，模型给出的判断可以顺着邻域描述往回追，这在风控、内容审核这类需要给理由的场景里价值很高。

再说什么场景别折腾。单域、数据量大、schema 稳定的场景，传统 GNN 依然是性价比之王。你手里有几百万标注样本、关系类型就那五种、一年也不变，那老老实实用 GNN，训练快、推理便宜、效果稳。这套方案的优势全在“泛化”和“少样本”上，如果你的问题根本不缺这两样，那就是杀鸡用牛刀，还得为牛刀付 GPU 账单。

还有一类要谨慎：对推理延迟极其敏感的场景。语言模型推理比 GNN 慢一到两个数量级，如果你要在毫秒级响应里做实时图推理，这套方案得配合蒸馏或者缓存策略，不能直接上。我一般的做法是离线把节点表示算好缓存起来，线上只做轻量查询，把重活放在异步链路里。

6.2 后续可以怎么扩展

我自己在往两个方向试。一个是关系类型的层次化，现在的关系令牌是扁平的，“购买”和“复购”被当成两个独立类型，其实它们有语义包含关系。如果能把关系类型组织成树或者图，父子关系共享参数，那新类型的冷启动会更轻松。

另一个是结构信息的显式注入。目前结构只靠跳数和度数分桶这种粗粒度标记，信息损失不小。我在试把一些轻量的结构编码（比如节点在元路径上的位置编码）拼到关系令牌上，让小样本下的拓扑感知更精准。这个方向还在跑实验，暂时没有确定的结论，但直觉上是有空间的。

最后分享个实操上的小习惯。我每次做新数据集，都会先花半小时手写十条左右的邻域序列化样本，自己读一遍。如果连我自己读着都觉得信息不足、抓不住重点，那模型肯定也学不好。这个“人肉 sanity check”帮我省下的调试时间，比任何自动化工具都多。