去年接手一个知识图谱问答的活儿，离线单轮准确率做到 87%，上线两周被真实用户打回原形。原因很朴素：用户不按模板提问。第一轮问“这款设备有哪些型号”，第二轮直接来一句“那第二个的续航呢”，系统当场愣住，要么答非所问，要么把上一轮的实体又当成新实体重新链接一遍。这件事让我彻底认清，知识图谱问答真正的难点从来不在“把一句话翻译成查询语句”那一步，单轮语义解析已经被研究得比较透了，难的是多轮对话里“下一步该做什么”的决策：现在该直接回答，还是反问澄清，还是先在图上多跳一层做确认，还是干脆承认不知道。这篇就围绕基于元学习的知识图谱动态问答系统对话策略优化，把我在这个方向上踩过的坑和最终跑通的方案完整拆一遍，包括元任务怎么构造、策略网络的状态怎么设计、奖励怎么算、新图谱冷启动怎么用几十条轨迹完成适应。适合做过知识图谱问答、也做过强化学习策略训练，正被样本效率和跨领域迁移折磨的同学参考，纯新手也能看懂其中的思路取舍。

1. 项目整体设计与思路拆解

1.1 对话策略为什么是 KGQA 落地的真正瓶颈

先把问题摆清楚。知识图谱问答系统的典型链路是：用户问句进来，做实体链接和关系识别，在图上检索子图，做路径推理，生成答案。单轮场景下这条链路是线性的，每一步都有明确输入输出，出错也能定位。但多轮对话把这条线性链路打断了，因为每一轮的输入不再只是当前问句，还包括前面所有轮次累积下来的上下文状态，而这个状态本身是不完整的、带噪声的、随时可能被用户修正的。

我见过最多的做法是写规则：如果实体链接置信度低于阈值就反问，如果识别到指代词就回溯上一轮实体，如果图谱里检索不到结果就道歉。这套规则在第一个业务域里能跑到 90% 以上的完成率，一旦换到第二个域，规则几乎全部失效。原因在于阈值是拍脑袋定的，指代回溯的逻辑假设了对话结构规整，而真实用户的对话结构非常随意，会跳话题、会自我纠正、会中途加约束。规则系统的维护成本随业务域数量线性增长，最后变成一坨没人敢动的 if-else。

另一条路是强化学习，把对话当成马尔可夫决策过程，状态是对话历史加图谱检索结果，动作是回答、澄清、扩展、兜底这几类，奖励来自任务是否完成。这条路理论上正确，实际落地时会撞上一堵墙：样本效率。一个中等规模的图谱，策略要收敛到可用水平，通常需要几万到几十万条交互轨迹，而真实业务里冷启动阶段根本拿不到这么多数据，标注成本也扛不住。更麻烦的是，每上一个新图谱就要重训一遍，训练周期以周计，业务方等不起。

这就是为什么我把目光转向元学习。元学习要解决的不是“怎么把当前图谱上的策略学好”，而是“怎么学到一套初始参数，使得面对新图谱时只需要极少量的交互就能调整到可用水平”。这个目标和 KGQA 的落地痛点几乎是严丝合缝的，因为企业侧的真实场景就是图谱一个接一个地上，每个图谱的交互数据都很少。

1.2 元学习在这里解决的到底是哪个“学习”问题

这里必须把概念掰开，否则很容易走偏。元学习在 KGQA 里至少有三种用法，混在一起谈就会失去焦点。

第一种是元学习用在语义解析器上，让模型面对新关系类型时能 few-shot 学会识别。第二种是元学习用在子图推理器上，让多跳路径打分函数能快速适配新图谱的拓扑特征。第三种，也是我这个项目的主线，是元学习用在对话策略网络本身，让策略的初始化参数具备“快速适应新图谱、新对话风格”的能力。

三者的差别在于优化目标的位置。前两者优化的是感知和推理，输出是答案；第三者优化的是决策，输出是动作。决策问题的特殊性在于，它的监督信号极其稀疏，一轮对话往往只有最后一步才有明确的对错反馈，中间每一步的好坏都需要靠奖励塑形去推断。稀疏信号加上小样本，普通监督学习基本没戏，而元学习的双层优化结构恰好能在“少量轨迹”这个约束下榨出信息。

具体做法是把每个图谱、或者每个业务子域、或者每一类对话模式，抽象成一个元任务。元任务内部再切成支持集和查询集。内循环在支持集上做几步梯度下降，得到一个任务特定的临时参数；外循环在查询集上评估这个临时参数的表现，把梯度回传到初始参数上。训练结束时，我们得到的不是一个能直接用的策略，而是一个“离所有任务的最优参数都不太远”的起点。新图谱上线时，拿这个起点做三到五步内循环更新，就能得到可用的策略。

这个思路的价值在于，它把“训练周期”从周级别压缩到小时级别。我实测过一个新图谱，从接入到策略可用，用不到两百条真实交互轨迹配合元任务检索，整个适应过程在单卡上跑了十几分钟。

1.3 系统分层与模块边界

真正动手写代码之前，我先把整个系统切成了五层，每一层只对上下相邻层负责。这个切分不是为了好看，是因为元学习训练过程中会频繁做“冻结部分参数、只更新部分参数”的操作，如果模块边界模糊，梯度会到处乱流，调试时会非常痛苦。

分层的核心原则是：图谱层的输出必须是固定维度的向量，不能是变长的图结构。这个约束看起来是妥协，实际上是为了让策略层能稳定地做元学习。变长结构在不同任务之间维度不一致，内循环那几步梯度下降会因为输入分布差异过大而震荡。

还有一条隐含约束：策略层不直接访问原始图谱，只能访问状态层聚合后的向量。这样做牺牲了一部分表达能力，换来的是策略网络和图谱实现解耦，换图谱时只要保证状态层输出维度不变，策略层的元训练成果可以直接复用。

2. 知识图谱侧的动态建模

2.1 多跳子图检索与路径编码的具体做法

策略层拿到的状态好不好，八成取决于子图检索这一步。我的做法是先从问句里抽种子实体，抽不到就用上一轮确认过的实体做兜底，然后从种子节点出发做两到三跳扩展，得到一个候选子图。这里有个细节很多人会忽略：扩展的跳数不能固定。固定两跳会让简单问题引入大量噪声节点，固定三跳在小图谱上又会直接覆盖全图。我的处理是先用一个轻量打分器估计问题复杂度，简单问题一跳，复杂问题两到三跳，再用一个基于节点度数的剪枝策略把每跳的邻居数限制在 Top-K，K 取 16 到 24 之间。

子图拿到之后要做编码。我用的是关系感知的图注意力，每一层聚合时把关系类型也编码进去，这样“产品-属于-系列”和“产品-替代-型号”这两种边在嵌入空间里是可区分的。层数控制在两层到三层，再深就会出现过平滑，实测三层的节点区分度反而不如两层。

路径编码是另一条线。除了节点嵌入，我还把从种子节点到候选答案的路径序列单独用一个单向 GRU 编码，路径上的每一步是“关系类型加节点类型”的拼接。为什么要单独做路径编码？因为多跳问答的答案正确性往往取决于路径是否合理，而节点嵌入的池化会把这个顺序信息抹掉。路径编码的输出和子图池化后的向量拼在一起，一起送进状态层。

注意：子图检索要用带版本号的缓存。图谱是动态的，边会新增也会失效，如果缓存不设 TTL，策略会基于过期子图做决策，表现为“上一轮还能答对，这一轮同样的问法答错”，排查起来极其费劲。

2.2 图谱动态演化下的增量同步策略

标题里“动态”两个字不是装饰。真实业务图谱每天都在变，新增实体、修正关系、下线旧节点。如果每变一次就重建索引、重训策略，系统没法用。我的方案是把图谱变更做成事件流，每个变更事件带一个单调递增的版本号，子图检索时把版本号写进缓存键，缓存有效期设得比较短，五分钟到十五分钟，具体看图谱变更频率。

策略层这边不感知具体变更内容，只感知一个布尔特征：当前会话使用的知识版本和最新版本是否一致。不一致时，策略会倾向于多做一次澄清或者重新检索，而不是直接用旧结果回答。这个设计很小，但在实测中把“因图谱更新导致的错误回答”压下去了接近一半。

还有一个容易被忽视的点：时间敏感的关系。有些关系是有有效期的，比如某个配置在某时间段内有效。这类边我在存储时加了时间戳属性，检索时按当前时间过滤。如果不做这一步，策略训练时会学到一些在训练集上成立、线上却已经失效的模式，这类错误在离线评估里完全看不出来。

2.3 把多轮对话切片成元任务的关键手法

元任务构造是整个项目里最费脑子的部分，直接决定元学习能不能学到东西。切得太粗，任务之间差异过大，内循环几步梯度下降根本适应不了；切得太细，任务之间几乎一样，元学习退化成普通训练，学不到“快速适应”的能力。

我的切法是三层嵌套。最外层按图谱切，一个图谱算一个大任务域。中间层按对话模式切，把对话分成“属性查询型”“对比型”“纠错追问型”“多约束收窄型”几类，每一类算一个子任务。最内层按难度切，简单、中等、困难三档，难度用所需的平均轮数和图谱跳数来定义。最终的元任务是最内层的组合，这样既保证了任务之间的差异性，又保证了单个任务内部有足够的一致性。

每个元任务内部，支持集取 16 到 32 条完整轨迹，查询集取 8 到 16 条。轨迹的采样要注意覆盖不同的起始状态，不能全是“第一轮就问得很清楚”的简单样本，否则内循环学到的只是“直接回答”这一个动作。

任务相似度是冷启动时的关键。我用了三个特征拼成一个指纹向量：关系类型分布的 JS 散度、节点度分布的分位数、图嵌入的均值向量。新图谱进来时，算指纹，在元任务库里检索最近的五个任务，把这五个任务的支持集合并起来做内循环。实测下来，用检索到的任务做初始化，比随机初始化少走大概三分之二的适应步数。

3. 对话策略网络的元学习实现

3.1 状态表示：把“我有多不确定”显式写进特征

状态设计上我犯过一个典型错误：一开始只把对话历史和子图嵌入拼起来，结果策略学不会澄清。原因很简单，模型看不到“自己有多不确定”，它只能从子图嵌入里隐式推断，而这个信号太弱，被其他维度淹没了。

后来我把不确定度做成显式特征，情况立刻好转。完整的状态向量由五部分拼接而成：

加起来 460 维，再过一个两层 MLP 压到 256 维作为策略网络输入。这个维度是我调出来的，太小会丢信息，太大会让内循环那几步更新变得不稳定，因为参数多、样本少，容易过拟合到支持集上。

不确定度那八个特征值得单独说。实体链接熵是候选实体分布的信息熵，熵高说明链接模糊，该澄清；候选分数间隔是第一名和第二名的分数差，间隔小说明两个候选难分伯仲，也该澄清；子图覆盖率是检索到的子图覆盖问题涉及的关系类型的比例，覆盖率低说明图谱里可能压根没有答案，该兜底。这几个特征看起来是手工特征，但在小样本场景下，手工特征比让网络自己学要可靠得多。

3.2 动作空间与终止条件的设计取舍

动作我定了五个：直接回答、澄清反问、图谱扩展确认、给出候选让用户选、兜底转人工。动作数不能再多了，每多一个动作，内循环需要的样本量就往上跳一档。

终止条件只有两种：用户明确表示满意或继续追问新问题，算任务成功；用户重复提问、表示不满、或者直接离开，算任务失败。中间过程不算终止，这样能保证每条轨迹的回报信号是清晰的。

有个细节我调了很久：澄清动作的输出形式。一开始澄清只给一个反问句，用户回答“是”或“不是”，信息量太低。后来改成给两到四个候选让用户选，信息量上去了，但候选太多用户会烦。最后定在最多三个候选，实测用户接受度最高，且澄清一次的信息增益足够策略继续推进。

提示：动作集合一旦定下来，在元训练和线上推理期间就不能改。动作空间变化会导致策略网络输出层维度变化，之前训好的初始化参数直接作废，等于重来。

3.3 MAML 风格的双层优化代码实现

核心训练循环我用的是 FOMAML，也就是一阶近似，省掉二阶导。二阶导在图上做反向传播的开销太大，而且实测下来一阶和二阶的最终效果差距在 1.5 个百分点以内，不值得为这点差距付出三倍的训练时间。

import torch import torch.nn as nn import torch.nn.functional as F class PolicyNet(nn.Module): def __init__(self, state_dim=460, hidden=256, n_actions=5): super().__init__() self.backbone = nn.Sequential( nn.Linear(state_dim, hidden), nn.LayerNorm(hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.LayerNorm(hidden), nn.ReLU(), ) self.actor = nn.Linear(hidden, n_actions) self.critic = nn.Linear(hidden, 1) def forward(self, state): h = self.backbone(state) return self.actor(h), self.critic(h).squeeze(-1) def inner_loop_update(model, support_states, support_actions, support_returns, alpha=0.02, steps=3): """在单个任务的支持集上做几步梯度下降，返回临时参数""" fast_weights = {k: v.clone() for k, v in model.state_dict().items()} for _ in range(steps): logits, values = forward_with_weights(model, fast_weights, support_states) log_prob = F.log_softmax(logits, dim=-1) chosen = log_prob.gather(1, support_actions.unsqueeze(1)).squeeze(1) adv = support_returns - values.detach() policy_loss = -(chosen * adv).mean() value_loss = F.mse_loss(values, support_returns) entropy_bonus = -(log_prob.exp() * log_prob).sum(-1).mean() loss = policy_loss + 0.5 * value_loss - 0.01 * entropy_bonus grads = torch.autograd.grad( loss, fast_weights.values(), create_graph=False ) fast_weights = { k: w - alpha * g for (k, w), g in zip(fast_weights.items(), grads) } return fast_weights

上面这段是内循环。forward_with_weights是一个用函数式方式拿参数前向传播的辅助函数，作用是让梯度只流到 fast_weights 上，不动原始参数。这个写法比torch.func.functional_call手写更啰嗦一点，但兼容性好，调试时能单步看每一层。

外循环就是在批次内所有任务上累加查询集损失，然后对初始参数做一次更新：

def meta_train_step(model, task_batch, meta_optimizer, beta=5e-4): meta_optimizer.zero_grad() total_query_loss = 0.0 for task in task_batch: fast_w = inner_loop_update( model, task.support_states, task.support_actions, task.support_returns, alpha=0.02, steps=3, ) logits, values = forward_with_weights( model, fast_w, task.query_states ) log_prob = F.log_softmax(logits, dim=-1) chosen = log_prob.gather(1, task.query_actions.unsqueeze(1)).squeeze(1) adv = task.query_returns - values loss = -(chosen * adv.detach()).mean() + 0.5 * F.mse_loss(values, task.query_returns) total_query_loss = total_query_loss + loss avg_loss = total_query_loss / len(task_batch) avg_loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0) meta_optimizer.step() return avg_loss.item()

这里有个我调了很久的细节：外循环损失里价值函数那一项要不要保留 adv.detach()。答案是必须 detach，否则策略损失和价值损失会互相污染，出现“为了降价值损失而扭曲策略”的怪现象，表现是策略长期卡在某个动作上不动。

3.4 奖励函数设计与关键参数的计算过程

奖励设计是整个项目里最需要讲清楚“为什么”的部分，因为它直接决定策略学出什么行为。

我最终的奖励结构是稀疏主奖励加密集塑形项：

轮次成本为什么取 0.05？这需要算。假设一个任务三步答对，累积回报是 1 - 3×0.05 = 0.85。五步答对是 0.75。两者差距 0.1，足以让策略倾向于三步，但又不会大到让策略宁愿冒险答错也不愿多问一轮。如果把轮次成本调到 0.2，五步答对只剩 0，四步答对是 0.2，策略会变得极度激进，宁可瞎答也不澄清，实测澄清率会掉到 3% 以下，任务完成率反而下降。

折扣因子取 0.95，六轮对话的累积折扣大约是 0.74，保证远期奖励还有足够权重。再小就会让策略过度短视，只盯着下一轮。

奖励归一化这一步不能省。不同任务的累积回报量级差异很大，简单任务可能一两轮就结束，复杂任务六七轮，直接混在一起训练会让价值函数学到一个巨大的方差。我的做法是在任务内部做回报标准化，减去该任务支持集上的回报均值、除以标准差，把量级统一到零均值单位方差附近。

3.5 训练稳定性：一阶近似、梯度裁剪与任务归一化

元学习的训练不稳定是出了名的，我前后踩了三类坑。

第一类是内循环发散。表现是内循环第三步之后损失突然飙升到 NaN。原因基本是两个：alpha 太大，或者任务内部样本分布太散。我的处理是把 alpha 从 0.1 一路降到 0.02，同时在任务采样阶段做了一个粗过滤，把轨迹长度方差过大的任务剔掉。

第二类是外循环震荡。损失曲线呈现明显的锯齿状，忽高忽低。这个通常是任务批大小太小导致的，一个批次里某个任务特别难，就会把整体梯度带偏。把任务批从 4 提到 8，配合梯度累积到等效 32，震荡基本消失。

第三类是元过拟合。这个最隐蔽，离线元训练损失一直在降，但新图谱上适应效果越来越差。原因是元训练集里的任务太相似，模型记住了特定任务的模式而不是学会适应。解决办法是提高任务多样性，具体是把对话模式的类别从 4 类扩到 6 类，并且强制每个批次里的任务至少来自三个不同的模式类别。

注意：梯度裁剪一定要做，而且要在 meta_optimizer.step() 之前做。我见过有实现把裁剪放在内循环里，那是错的，内循环的梯度是通过 autograd.grad 拿的，裁剪应该作用于外循环的累积梯度。

4. 从离线到线上的完整实操流程

4.1 数据流水线与对话状态标注

数据这块我走了不少弯路，先讲结论：不要指望用纯人工标注。人工标注多轮对话成本极高，一条完整轨迹标下来要十几分钟，而且标注一致性很差，不同标注员对“这一轮该澄清还是该直接答”的判断分歧很大。

我的做法是半自动。先把线上日志里的真实对话拉出来，用规则跑一遍得到伪标签，再用一个小模型做一致性校验，把规则和小模型判断一致的样本作为高置信样本，不一致的挑出来人工复核。这样人工工作量能压到全量的两成左右。

标注的核心字段有三个：每一轮的候选实体集合、每一轮的最佳动作、最终任务结果。候选实体集合必须完整记录，不能只记最终选中的那个，因为策略训练时需要看到全部分布才能学不确定度。

还有一点：轨迹要做长度分层。大量短轨迹（两三轮结束）和少量长轨迹（六七轮）混在一起，会让价值函数学偏。我的做法是按长度分桶，每个元任务的支持集从固定桶里采样，保证长度分布可控。

4.2 训练脚本的关键参数与实测配置

完整的超参数配置我整理成了表，这些都是我反复调过、最终稳定下来的值：

训练时间上，单卡跑完一万步元训练大概需要十到十四个小时，任务批 8、每批支持集 24 条轨迹的规模。这个耗时是可以接受的，因为元训练是离线的，只做一次，后续新图谱上线只跑内循环。

4.3 线上推理与冷启动适配的落地方式

线上推理分两条路径。老图谱走常规路径，直接加载该图谱对应的适配后参数，一遍前向出动作，延迟控制在 40 毫秒以内。新图谱走冷启动路径，流程是：算图谱指纹、检索最近的五个元任务、把这五个任务的支持集合并、做三步内循环、得到初始策略、上线同时开启在线轨迹记录。

冷启动阶段的策略我加了一个保守约束：置信度低于阈值时强制走高置信动作，也就是澄清或兜底，不允许在不确定的情况下直接回答。这个约束会在在线轨迹积累到一定量后自动解除。实测下来，保守约束能把冷启动期的严重错误率压到很低，代价是前几十轮对话的轮次偏多，用户体验稍微啰嗦一点，但比答错强太多。

在线轨迹回流有个细节：只回流策略实际执行的动作和结果，不回流“如果当时选另一个动作会怎样”的反事实。反事实估计需要额外的模型，在样本极少时不可靠，会让后续微调跑偏。等轨迹积累到几百条之后，可以考虑引入简单的离策略评估，但那是后话。

适应效果的衡量指标我用的是“达到 80% 目标成功率的交互步数”。老图谱上这个数字是三到五步，新图谱冷启动平均在十八到二十五步之间，视图谱结构相似度浮动。相似度高的能压到十二步左右。

4.4 效果验证与灰度上线节奏

离线评估不能只看成功率，那样会掩盖策略退化。我用的是一组指标联合看：

策略熵这个指标容易被忽略但非常重要。如果熵长期趋近于零，说明策略塌缩到单一动作，通常是奖励设计或训练不稳定导致的，这种情况下成功率可能还行，但一旦遇到分布外的问题就会彻底失效。

灰度节奏我是分三档：5% 流量跑一周看指标稳定性，20% 跑一周看长尾对话，50% 跑两周看整体业务指标。每一档都要对比“平均轮次”和“人工接管率”，这两个指标最能反映用户体验的真实变化。

5. 常见问题与排查技巧实录

5.1 内循环不收敛的四种典型表现

内循环不收敛是最高频的问题，表现有四种，对应原因完全不同。

第一种是损失直接 NaN，基本是 alpha 太大或者输入特征有未归一化的维度。排查方式是打印每一步内循环的损失和梯度范数，如果第一步就爆炸，先查特征归一化，把所有维度的均值方差打出来看有没有离群。

第二种是损失下降几步后又回升，这是典型的学习率过大，在支持集上过拟合后又反弹。把 alpha 从 0.05 降到 0.02 通常就解决了，实在不行降到 0.01，代价是适应步数增加。

第三种是损失几乎不动，这种情况多半是支持集样本太少或者任务太难。检查支持集轨迹数是否低于 8，如果低于这个数，内循环的梯度噪声会盖过信号。

第四种是不同任务之间的内循环表现差异极大，有的任务三步就收敛，有的十步还在震荡。这是任务异质性问题，需要在任务构造阶段做过滤，把轨迹长度方差过大的任务剔除，或者把这类任务单独归成一类，用不同的内循环步数。

提示：调试内循环时，先把外循环冻结，只在单个任务上反复跑内循环，看损失曲线形态。这一步能排除掉大部分干扰因素。

5.2 奖励黑客与策略退化的识别方法

奖励黑客在对话策略里特别隐蔽，因为它的表现形式往往是“指标看起来变好了”。

我遇到过最典型的一次是策略学会了疯狂澄清。原因是澄清命中给 +0.15，而任务成功给 +1.0，表面上看成功奖励更大，但一个任务可能澄清三次才成功，累积塑形奖励 0.45，再加上成功的 1.0，总共 1.45，比直接一次答对还高。策略很快发现澄清是稳赚不赔的动作，于是所有情况都先澄清一遍。

识别方法是看动作分布随训练步数的变化曲线。正常情况下直接回答应该占大头，澄清占两到三成。如果澄清占比一路涨到六成以上，基本可以确定是塑形奖励过密。解决办法是把澄清命中的奖励降到 0.05，并且加一个约束：连续两次澄清不给奖励，防止策略刷分。

另一次退化是策略学会了“永远兜底”。原因是训练集里困难任务的占比过高，且失败惩罚只有 -1.0，而兜底转人工避免了失败惩罚。这个问题的根源是训练任务分布和线上分布不匹配，线上简单任务占绝大多数，训练集里却塞了大量困难任务。解决办法是按线上分布重新做任务采样，简单任务占比提到六成以上。

5.3 图谱更新导致的答案漂移排查

动态图谱带来的问题最难查，因为现象是间歇性的，同样的问法今天对明天错。

排查第一步是确认版本一致性。把会话日志里的知识版本号和当时图谱的实际版本号对比，如果对不上，说明缓存没失效。我后来在缓存键里强制带版本号，问题基本消失。

第二步是查边的时间有效性。有些关系带时间戳，检索时如果没按当前时间过滤，会拿到已经失效的边。这类问题的表现是“答案在训练期成立、线上不成立”，离线评估完全测不出来。

第三步是查子图剪枝的稳定性。图谱新增大量节点后，Top-K 邻居的排序会变，原来在子图里的关键节点可能被挤出去。这个问题的排查方式是对比同一问题在不同时间点的子图快照，看关键节点是否还在。解决办法是把剪枝策略从纯度数排序改成度数加语义相关性混合排序，减少纯拓扑变化的影响。

5.4 几个不写在文档里的实操心得

第一个心得是关于元任务数量的。我一开始追求任务数量多，构造了几百个元任务，结果元训练反而慢且效果差。后来发现任务数量在五十到一百之间效果最好，太多会让每个任务分到的训练步数不足，学到的东西被稀释。质量比数量重要得多。

第二个心得是关于评估集构造的。评估集必须留出全新的图谱，不能只在训练用过的图谱上做留一验证。我早期吃过这个亏，在同一批图谱上交叉验证效果很好，一上新图谱就崩，因为元任务之间共享了太多结构信息。

第三个心得是关于冷启动的保守期。保守期不能太短，我一开始设成二十轮，结果有些图谱在保守期结束后策略还没适应好，直接开始激进回答，错误率飙升。后来改成基于轨迹量而不是轮数来退出保守期，攒够一百五十条有效轨迹再做评估，达标才退出，稳定很多。

最后一个心得是关于日志的。策略上线后一定要把完整的状态向量、动作分布、选择理由都记下来，不要只记最终动作。出问题时缺了这些数据，排查基本靠猜。存储成本确实会涨，但比起反复复盘找不到原因的代价，这点成本不值一提。

我在实际项目里最大的体会是，元学习在对话策略上的价值不在于把指标做高几个点，而在于把“上一个新领域”这件事从工程项目变成配置工作。以前接一张新图谱要排期、要标注、要重训，现在前端接入完，跑一遍指纹检索加内循环，当天就能出灰度结果。这个变化带来的组织效率提升，比离线指标上的那几个点有意义得多。