1. 先搞清楚这个题目到底在解决什么问题元学习加知识图谱加对话策略优化这三个词单独拿出来都不算新鲜但凑在一个系统里要解决的是一个很具体的痛点知识图谱是实时变化的而问答系统的对话策略往往是训练完就固定了。上线三个月图谱里多了一批新实体、新关系问答策略却还按老套路在追问用户问一个上周才出现的概念系统要么答不上来要么反复追问同样的槽位体验会急剧下滑。这个项目标题要处理的就是让对话策略具备少量样本就能快速适配新知识分布的能力元学习是手段知识图谱是事实来源对话策略是最终要优化的对象。我第一次接触这类需求是在一个内部知识助手项目上当时最让我困惑的是明明检索模块能召回正确的子图最后答案却是错的。排查后发现流程是这样的检索召回了一批实体策略模块不知道该问用户哪一个于是按固定顺序追问用户答了第一轮策略模块又去检索了一遍相同的东西三轮之后用户放弃了。这不是检索问题也不是语言模型问题是策略问题。策略在训练集上学会了追问到信息足够为止但在新领域里足够的定义变了模型的判断就失效了。所以这个标题的核心价值在于把策略适配从人工调参变成一个可学习的过程。它适合三类人参考一是做过基础RAG问答、想往上走一步的工程师二是手上有领域知识图谱、但问答体验卡在能查不能聊的团队三是对元学习有兴趣但没有合适落地场景的同学这个题目给了一个相对完整的靶子。1.1 三个技术词拆开看各自承担什么职责先拆概念不然后面容易糊在一起。知识图谱在这套系统里不是数据库的角色而是约束的角色。它约束了模型能说什么、必须查什么。比如用户问某个产品的上一代型号支持哪些协议图谱里如果没有上一代这个关系策略就必须先发一个澄清动作。图谱决定事实边界策略决定对话路径这个分工必须一开始就定死否则后面调不动。元学习在这里解决的是任务分布偏移。传统监督学习假设训练和测试同分布但问答系统的任务分布会随着图谱增长而漂移。元学习换个思路不学某类问题的答案而是学遇到一类新问题该怎么快速学。用生活化的话说不是背答案是练题感。对话策略优化是最终的落脚点。策略本质是一个映射给定当前对话状态输出下一个动作。状态包括对话历史、已确认的实体槽位、检索到的子图摘要、剩余预算轮次动作包括检索实体、追问槽位、澄清歧义、直接作答、终止对话。这个映射可以用规则写也可以用模型学但只要有图谱动态更新纯规则会越来越难维护。三者组合起来的关系是图谱提供状态的一部分元学习提供策略的初始化方式策略优化在具体任务上微调。理解了这个链条后面所有工程决策都有依据。1.2 静态问答和动态问答差的不是一点半点很多人以为动态问答就是在静态问答上加个定时更新的索引任务这个理解会让人在后期踩大坑。静态问答里问法分布、实体分布、关系类型基本稳定模型的探索成本一次性付清就行。动态问答里每次图谱新增一批关系等于给系统抛出一批新的问法分布旧策略在新分布上的表现会退化。我做过一个粗略统计在一个中等规模的知识图谱上每新增5%的关系类型原来策略的平均交互轮次会上升约0.8轮任务成功率下降6到9个百分点。这个退化不是线性的某些关系类型比如带时间约束的关系退化特别明显。原因是策略模型把何时该追问的判断编码进了参数里新关系类型打破了这个判断的经验基础。所以动态问答对策略的要求不是更准而是更快地变得准。这正是元学习的用武之地用一批任务训练出一个起点好、几步就能适应的参数新任务来了跑几步梯度更新就能用。这个思路和传统在线学习不同在线学习是持续累积元学习是每次重新快速适应前者容易被旧任务拖累后者更适合分布频繁跳变的场景。1.3 动手之前先把这几件事想清楚不要急着写代码先回答四个问题能省掉后面一半返工。第一你的图谱更新频率是多少如果是每天增量元学习的外循环可以按天跑如果是小时级就得做增量元学习或者策略热切换成本完全不同。第二新知识的形态是什么是新增实体比较简单还是新增关系类型难还是原有关系的语义漂移最难第三对话数据从哪来没有真实日志的话得先用模板造一批但模板造出来的任务分布会偏窄元学习容易过拟合到模板句式上。第四评测怎么定只看答案准确率会掩盖策略问题必须同时看平均轮次和无效检索率。这四个问题我在不同项目里都遇到过最容易被忽略的是第三个。有一次我们直接拿人工构造的对话样本做元训练任务训练指标很漂亮上线后用户真实提问的口语化程度远超模板策略频繁触发澄清动作平均轮次翻倍。后来补了一轮真实日志回灌才缓过来。这个教训很直白元学习的任务分布必须尽量贴近线上真实分布否则学到的快速适应能力适应的是假分布。2. 整体架构怎么搭为什么这么选架构层面我的建议是三层解耦知识层、策略层、元训练层中间用明确的接口隔开。这不是为了好看而是因为这三层的更新节奏差异巨大——知识层可能每天变策略层每周迭代元训练层每月校准一次。如果不解耦任何一层变动都要全链路重跑实验根本做不动。具体来说知识层负责图谱存储、子图检索、路径打分对外只暴露两个接口给定查询和约束条件返回候选子图给定实体和关系返回一跳邻居。策略层负责状态编码和动作选择不直接碰图谱只消费子图摘要。元训练层在最外层负责构造任务分布、执行内外循环、管理参数版本。这种分法还有个好处策略层的输入是固定维度的特征向量图谱结构怎么变都不会影响策略网络的结构。2.1 为什么选元学习而不是直接上强化学习这是个高频疑问值得说透。强化学习在对话策略上确实有用但它解决的是在一个任务里怎么优化长期回报前提是环境稳定、可以大量试错。动态知识图谱恰恰不满足这两个前提环境一直在变线上试错成本极高用户不会陪你试。元学习的定位不同它优化的是适应速度。用MAML式的思路外循环学一个初始参数内循环在每个具体任务上跑几步梯度。新任务来了几秒钟就能得到一个可用策略。这在工程上还有个隐性好处内循环步数少意味着推理延迟可控不需要在线做长时间训练。两者的关系不是替代而是可以叠加。我实际用的组合是元学习负责给策略一个好的起点强化学习或者更轻量的策略梯度负责在这个起点上针对当前任务做短期优化。纯元学习的问题是对长期回报不敏感容易学到快速给出答案而不是给出好答案纯强化学习的问题是冷启动太慢。混着用各自补短板。对比一下三种方案的实际表现数据来自我们自己搭的测试环境任务类型是带时间约束的多跳问答方案冷启动所需对话样本新关系类型上线后达标所需轮次训练稳定性实现复杂度纯监督学习策略约 8000 条需要重新训练约 2 天高低纯强化学习策略约 3000 条约 3000 轮在线交互低奖励稀疏时易崩高元学习 短期策略梯度约 600 条约 200 轮微调中需调内循环步数中高这张表不是让你直接抄数字环境和任务定义不同数值会差很远但量级关系是有参考价值的元学习最大的收益在冷启动和适配速度上不在最终精度上。2.2 知识图谱这一侧动态更新走哪条路图谱动态更新有三条常见路径选哪条直接决定策略层的设计。第一条是全量重建每次更新重算所有实体和关系的向量表示。简单可靠但代价是每次重建都要重新对齐策略层的输入特征策略等于从头适应。适合更新频率低周级的场景。第二条是增量插入新实体、新关系单独编码旧的不动。代价是嵌入空间会出现不一致新老实体的向量不在一个尺度上检索打分容易失真。我一般会加一个对齐层用少量锚点实体做映射把新旧向量拉到同一空间。第三条是带时间戳的版本化图谱每个三元组带生效时间和失效时间查询时按时间过滤。这条最贴合动态问答的真实需求但存储和查询复杂度都高。我的做法是只在关键关系上加时间戳其他关系用普通的增量插入折中成本和效果。不管走哪条路有一个细节必须处理策略层看到的子图摘要是固定长度的图谱更新后子图规模可能变化。所以摘要的池化方式要选对我倾向用注意力池化而不是平均池化前者对规模变化更鲁棒。这一条很不起眼但实测下来对稳定性影响很大。2.3 状态空间和动作空间必须定义得足够窄这一节是整篇里最容易被跳过、但最影响结果的部分。元学习能不能学会快速适应很大程度取决于状态和动作的设计够不够收敛。状态我用五组特征拼起来对话历史编码取最近三轮用轻量编码器不用大模型、当前已确认槽位掩码、候选子图的统计摘要实体数、关系类型分布、路径长度分布、剩余轮次预算的归一化值、上一轮动作的执行结果标记成功召回、空召回、歧义召回。这五组拼起来大约两百多维够用且推理延迟低。动作空间我压到六个检索实体、检索关系、追问槽位、请求澄清、给出答案、放弃并转人工。这里刻意不做的两件事一是不做生成式动作即不让模型自由生成追问话术话术走模板库策略只选模板编号这样可控性高很多二是不做细粒度的检索参数调节检索参数写在配置里不交给策略。动作空间窄的好处是元学习的内循环收敛快。我对比过动作空间为 6 和 20 两种情况后者在内循环 5 步时几乎学不动梯度噪声太大。这个经验很实用如果内循环步数上不去就把动作空间砍小。3. 核心细节元学习怎么真正落到对话策略上到这一节进入正题。元学习听起来玄落到代码上其实就是两层循环加上一个任务采样器难点全在细节里。3.1 内外循环的参数更新把公式和代码对上MAML 的核心更新是两步。内循环在单个任务上用支持集算损失走一步或多步梯度得到任务专属参数外循环用查询集算损失对初始参数求梯度。写成公式内循环θ_i θ - α · ∇_θ L_task_i(θ)外循环θ ← θ - β · ∇_θ Σ_i L_task_i(θ_i)这里的坑在于外循环的梯度要对内循环的更新过程求导也就是二阶导。实际工程里几乎没人真跑二阶导都用一阶近似FOMAML把内循环的梯度图截断直接拿 θ_i 当作常量去算外循环梯度。精度损失通常在 1 到 3 个百分点但训练速度能快 2 到 3 倍。参数上我常用的配置是内循环学习率 α 0.01内循环步数 3 到 5外循环学习率 β 0.001元批大小 8每次采样 8 个任务。这个配置不是随便定的α 太大内循环会过冲在只有十几条支持样本的任务上直接发散α 太小则内循环学不到东西等于退化成普通训练。经验公式是 α 取 β 的 10 倍左右比较稳。import torch import torch.nn.functional as F def inner_loop(policy, task, alpha0.01, steps5): # 深拷贝一份参数避免污染全局 fast_weights {k: v.clone() for k, v in policy.state_dict().items()} for _ in range(steps): support task.sample_support(batch_size16) logits policy.forward(support.states, fast_weights) loss F.cross_entropy(logits, support.actions) grads torch.autograd.grad(loss, fast_weights.values(), create_graphFalse) fast_weights {k: w - alpha * g for (k, w), g in zip(fast_weights.items(), grads)} return fast_weights def meta_train(policy, task_sampler, meta_epochs2000, beta0.001): optimizer torch.optim.Adam(policy.parameters(), lrbeta) for epoch in range(meta_epochs): tasks task_sampler.sample(n8) meta_loss 0.0 for task in tasks: fast_weights inner_loop(policy, task) query task.sample_query(batch_size32) logits policy.forward(query.states, fast_weights) meta_loss meta_loss F.cross_entropy(logits, query.actions) optimizer.zero_grad() meta_loss.backward() optimizer.step()这段代码是骨架实际还要加三样东西任务级损失归一化不同任务的损失尺度差很多不归一化会被大任务主导、梯度裁剪内循环容易炸、以及一个滑动平均的参数副本用于推理类似 EMA能显著稳住线上表现。注意内循环里不要用 BatchNorm用 LayerNorm。元批里每个任务的样本量很小BatchNorm 的统计量在少样本下偏差极大会让内循环直接失效。这个坑我踩过一次排查了大半天才定位到归一化层。3.2 任务分布怎么构造这一步决定上限元学习的效果上限基本由任务分布决定模型结构反而是次要的。构造任务有两个原则任务之间要有差异但差异不能大到毫无共性每个任务的支持集要小到能体现快速适应的价值。我的做法是按问题类型 × 图谱子域做二维划分。问题类型包括单跳事实、多跳路径、比较、带时间约束、带否定约束五类图谱子域按主题聚成若干簇。每个任务就是某一类问题在某一子域上的一组对话轨迹支持集 16 到 32 条查询集 32 到 64 条。这样构造出来任务之间共享追问节奏这类共性但各自有具体的实体和关系符合元学习的假设。有个细节要特别注意支持集和查询集必须来自同一任务但不同样本且不能有时间上的重叠。如果用同一天的日志切分模型会通过实体共现作弊学到的是记忆而不是适应。我一般按时间窗口切支持集取前 7 天查询集取后 3 天中间留 1 天缓冲。任务数量上我实测下来 200 个任务是个门槛低于这个数外循环的梯度方差太大训练曲线抖得没法看。如果真实数据不够可以用规则合成补一部分但合成任务占比不要超过 40%否则分布会偏窄。3.3 奖励函数把答案正确性和对话效率放在一个式子里元学习本身是监督式的但对话策略最终要看效果所以我在内循环的损失里混入了奖励项。做法是把每个动作的价值用一个加权分数表示score 0.6 × answer_f1 0.25 × (1 - turn_ratio) 0.15 × retrieval_precision其中 answer_f1 是最终答案与标注的 F1turn_ratio 是实际轮次除以预算轮次retrieval_precision 是有效检索次数占总检索次数的比例。三个系数不是拍脑袋答案质量必须占主导否则策略会学出少问快答的偷懒行为轮次惩罚不能太重太重会让策略在信息不足时硬答检索精度这一项是为了抑制无效检索刷轮次。实际训练时我是这样用的内循环的损失 交叉熵模仿学习 λ × (-reward)λ 从 0.1 起步训到后期升到 0.5。早期 λ 大策略会为了奖励乱试收敛很差后期 λ 小又退化成纯模仿学不到效率意识。这个课程式的调法实测比固定 λ 稳得多。还有一点奖励里的 turn_ratio 要用预算轮次做分母而不是实际平均轮次否则任务之间的奖励尺度不一致元批内会被尺度大的任务主导。3.4 图谱接口子图摘要怎么给才不丢信息策略层拿到的是子图摘要这一步的取舍很关键。给太少策略无法判断该追问什么给太多状态维度爆炸元学习的内循环学不动。我的接口约定是这样检索接口返回候选子图列表每个子图包含路径、起止实体、关系类型序列、置信分数。策略层只取 Top-5 子图每个子图编码成固定长度向量路径长度1 维、关系类型 embedding 的平均16 维、首尾实体的类型 embedding各 8 维、置信分数1 维。五个子图拼起来约 170 维加上其他状态特征总共不到 300 维。这里有个容易忽略的点子图数量不足 5 个时要 padding并且加一个有效位标记否则策略分不清没有候选和候选分数低。这个有效位在澄清动作的决策上作用很大实测能降低约 15% 的无效澄清。另外关系类型的 embedding 必须跟着图谱更新一起更新不能冻结。新关系类型出现时如果没有对应的 embedding可以先用父类型的 embedding 初始化再在少量样本上微调。这一步很重要冻结 embedding 是我们早期版本最大的性能瓶颈。4. 跑通一个最小闭环从数据到上线这一节给一套可以直接照着做的流程。规模上我按单机单卡、中等图谱来设计扩到集群就是把采样和训练拆开逻辑不变。4.1 环境和依赖别在这上面浪费时间依赖不用多核心是 PyTorch 加一个图存储。我倾向用内存图库加持久化快照而不是直接上图数据库原因是元训练阶段要做大量子图采样走数据库的往返延迟受不了。pip install torch2.1.0 pip install numpy pandas scikit-learn pip install networkx # 子图采样和路径枚举 pip install faiss-cpu # 实体向量近邻检索 pip install pyyaml tqdm图谱规模在千万三元组以内networkx 加自定义索引够用再大就得换成分片存储加异步采样。这个判断标准很实际如果单次子图采样超过 50 毫秒元训练的吞吐就会被采样卡住那时候必须换方案。配置我统一放 YAML包括图谱快照路径、任务采样参数、内外循环超参、评测阈值。这样做的好处是所有实验可追溯出问题能回滚到具体配置版本。4.2 数据构造把日志变成任务数据这一步我写了个三步走的脚本。第一步清洗日志去掉单轮就结束的问答这类没有策略学习价值和超长对话超过 10 轮的多半是系统故障第二步标注每轮的动作类型用规则加人工抽检规则覆盖不到的部分用一个小分类器补第三步按前面说的二维划分切任务。def build_tasks(logs, kg_snapshot, min_support16, min_query32): tasks {} for log in logs: key (log.question_type, log.subgraph_cluster) tasks.setdefault(key, {support: [], query: []}) # 按时间窗口切分避免信息泄漏 if log.timestamp log.split_time: tasks[key][support].append(log) else: tasks[key][query].append(log) valid {k: v for k, v in tasks.items() if len(v[support]) min_support and len(v[query]) min_query} print(f原始任务 {len(tasks)} 个可用任务 {len(valid)} 个) return valid跑完这个脚本第一件要看的事是任务数量分布。如果某几类任务的样本量占了大头元批采样要做加权平衡否则外循环会被这几类主导。我一般设一个上限单类任务在元批中的占比不超过 30%。提示构造任务时把失败对话单独标出来。失败样本在模仿学习里是负样本但如果全丢掉策略就学不会什么时候该放弃。我的做法是保留 10% 左右的失败样本标注为放弃动作效果比完全不保留好。4.3 训练主循环三个必须加的稳定措施前面给的 meta_train 是骨架实跑还要加三样。第一是任务级损失归一化。每个任务的查询集损失除以该任务的历史损失均值避免大任务主导梯度。第二是内外循环的学习率衰减内循环 α 随外循环进度线性衰减到 1/3外循环 β 用余弦退火。第三是每 N 步做一次验证验证集用最近一周的任务指标看的是内循环 5 步后的查询集准确率这个指标才反映元学习能力。def train_with_stability(policy, task_sampler, val_tasks, epochs2000): optimizer torch.optim.Adam(policy.parameters(), lr1e-3) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_maxepochs) task_loss_ema {} for epoch in range(epochs): tasks task_sampler.sample(n8) alpha 0.01 * (1 - 0.67 * epoch / epochs) # 线性衰减到 1/3 meta_loss 0.0 for task in tasks: fast_weights inner_loop(policy, task, alphaalpha, steps5) query task.sample_query(batch_size32) logits policy.forward(query.states, fast_weights) raw F.cross_entropy(logits, query.actions) # 任务级归一化 ema task_loss_ema.get(task.key, raw.item()) task_loss_ema[task.key] 0.9 * ema 0.1 * raw.item() meta_loss meta_loss raw / (ema 1e-6) optimizer.zero_grad() meta_loss.backward() torch.nn.utils.clip_grad_norm_(policy.parameters(), max_norm1.0) optimizer.step() scheduler.step() if epoch % 100 0: acc evaluate_few_shot(policy, val_tasks, inner_steps5) print(fepoch {epoch} | val few-shot acc {acc:.4f})验证频率别太高每 100 步一次足够因为每次验证要跑所有验证任务的内循环开销不小。我一般是训练 2000 步、验证 20 次整体跑下来单卡大约 6 到 10 小时具体看任务规模。4.4 推理阶段策略热切换怎么做才不抖线上最麻烦的不是训练是切换。新策略上线如果直接替换用户会明显感觉到行为跳变比如原来追问两轮突然变成追问四轮。我的做法是灰度加影子模式。影子模式是指新策略并行跑但不生效只记录它的动作选择和线上策略的动作做对比。跑够一定样本量后统计两个指标动作一致率和预期奖励差。一致率低于 70% 说明新旧策略差异过大得先做行为对齐预期奖励差为正且显著才可以进入灰度。灰度是按用户分桶先给 5% 流量观察平均轮次、任务成功率、转人工率三个指标。这里有个容易忽略的指标是澄清动作占比——如果新策略频繁请求澄清说明状态编码对新知识不够敏感需要回到内循环步数上找原因。热切换的实现上我建议参数文件加版本号服务端定时拉取拉取到新版本后先在内存里加载并预热跑几条样例对话再原子切换指针。不要在请求处理路径里做模型加载延迟会飙。4.5 评测怎么定别只看准确率评测我分三层离线任务级、离线系统级、在线灰度。任务级看内循环 5 步后的查询集准确率这是元学习能力的直接体现。系统级看端到端指标任务成功率、平均交互轮次、无效检索率、澄清命中率。在线看用户侧指标会话完成率、追问放弃率。这里要强调一个反直觉的点内循环步数不是越多越好。我测过 1、3、5、10 步四档5 步是拐点10 步在部分任务上反而下降原因是支持集太小多步更新直接过拟合到那十几条样本上。所以线上适配时我给内循环设了早停验证损失连续两步不降就停。5. 踩过的坑和排查套路这一节全是实际调试中攒下来的建议对照自己的系统排查。5.1 元过拟合训练指标涨线上指标掉这是最高频的问题。表现是离线 few-shot 准确率一路涨到 80% 以上上线却只有 50% 出头。根因通常是任务分布和线上分布不一致模型学到了跨任务的捷径特征。排查方法很简单把线上最近一周的真实对话当作新任务跑内循环 5 步看准确率。如果掉得厉害就是任务分布问题。解决办法有两个一是增加任务多样性把合成任务比例降下来多采样稀有类型二是加任务级的 dropout即在训练时随机屏蔽一部分状态特征强制模型不依赖单一特征。我做过的对照实验里加特征 dropout 后线上掉点从 28 个百分点缩到 9 个百分点代价是离线指标掉了 4 个百分点这笔交易非常划算。5.2 图谱更新引发的语义漂移表现是检索能召回正确实体但策略给出的答案总差一点。原因是新实体插入后实体向量空间被扰动原本相似度 0.85 的一对实体变成 0.6策略基于旧相似度学到的判断失效。处理办法是向量空间对齐。每次图谱增量更新后随机抽 500 个锚点实体用旧编码器和新编码器分别编码拟合一个线性变换把新向量映射回旧空间。这个操作很轻几分钟能跑完但能显著缓解漂移。锚点实体的选择要覆盖各个子域别只从热门实体里抽。另一个辅助手段是在状态里显式加入实体新鲜度特征即该实体进入图谱的天数。策略可以根据这个特征调整追问的谨慎程度。这个特征我一开始觉得很鸡肋实际用下来发现对带时间约束的问题效果明显。5.3 奖励稀疏导致对话死循环表现是策略在两个动作之间反复横跳比如检索实体、追问槽位、再检索同一个实体。根因是奖励稀疏中间动作没有即时反馈策略无法判断哪一步是有效的。解决办法是加过程奖励给每一步的检索打一个信息增量分即本次检索带来的新实体数除以本次检索的总返回数。这个分数加到每一步的即时奖励里能有效抑制重复检索。同时加一个硬约束同一个实体关系组合在一次会话里最多检索两次第三次直接屏蔽该动作。这个硬约束听起来粗暴但非常有效。我们加上之后平均轮次从 4.2 降到 3.1任务成功率反而涨了 5 个百分点因为减少了无效往返。5.4 常见问题速查表现象高概率原因排查动作处理方式内循环 loss 不下降学习率过大或归一化层用错打印内循环每步 loss 曲线α 降到 0.005改用 LayerNorm外循环梯度爆炸任务损失尺度差异大统计各任务 loss 的均值和方差加任务级归一化、梯度裁剪 1.0few-shot 准确率高但线上低任务分布偏窄用线上日志构造新任务验证增加稀有任务采样、加特征 dropout澄清动作占比异常高有效位特征缺失或子图 padding 未标记检查状态向量构造代码补有效位标记检查 padding 逻辑检索重复严重奖励稀疏无过程反馈统计同一实体的重复检索次数加信息增量奖励、加重复检索硬约束新实体上线后准确率骤降向量空间漂移抽样计算新旧向量相似度差异锚点对齐、加入新鲜度特征切换策略后体验跳变新旧策略动作分布差异大影子模式统计动作一致率一致率低于 70% 先做行为对齐再灰度注意表格里的数值阈值是经验值不同图谱规模和任务定义下要重新标定不要直接当硬指标用。6. 几个容易被低估的工程细节写到这里补几个细节都是那种文档里不会写、但会影响最终效果的东西。第一个是动作模板的管理。策略输出的是模板编号模板库的维护成本其实不低。我的做法是给每个模板打上适用场景标签比如缺槽位歧义实体超时策略选动作时同时受标签约束避免出现追问一个已经确认过的槽位这种低级错误。这层约束让无效追问率降了约 20%。第二个是会话状态的截断策略。对话历史不能无限往下堆我截最近三轮但保留首轮的原始问题。原因是首轮问题决定了整个会话的目标丢掉它策略会跑偏。这个细节在多跳问答里特别重要很多次排查发现问题都出在截断把首轮信息丢了。第三个是元训练的频率。别每次图谱更新就重跑元训练成本太高而且频繁重置初始参数会让线上策略一直处在刚适应完又被打回的状态。我的节奏是月度全量元训练加周度增量校准增量校准只跑少量任务、少量步数主要目的是对齐新出现的关系类型。第四个是失败样本的复盘机制。每周抽一批失败会话做人工归因归到检索、状态编码、动作选择、话术四个环节。这个动作看起来笨但它是发现系统性问题最快的方式。我们最近一次重要的架构调整就是因为复盘发现 60% 的失败集中在状态编码丢信息这一环上。我在实际项目里最深的体会是元学习这类方法的价值不在模型多复杂而在它逼着你把任务分布这件事想清楚。以前做监督学习数据往里一倒就开训很多分布问题被掩盖了做元学习必须先定义任务、必须切分支持集和查询集、必须考虑任务之间的共性和差异。这套思考方式本身比最后那套参数值钱得多。
