OPAL：动作原语与数据增强提升离线RL稀疏奖励长程任务

1. 稀疏奖励的长程任务，在离线数据上几乎是跑不动的

第一次把离线强化学习算法搬到稀疏奖励的长程导航任务上，结果很难看：训练曲线平得像一条直线，评估时的成功率长期停在个位数。换成稠密奖励立刻就好了——同样的算法、同样的数据、同样的超参。这说明问题不在算法本身，而在奖励信号在时间轴上的分布方式：稀疏奖励意味着整条轨迹上只有一个非零的回报点，价值函数要把这个信号一步步往回调，中间隔了几百步，Q 网络的 bootstrap 过程在离线设定下会迅速退化成噪声。

OPAL（Offline Primitive Discovery for Accelerating Offline Reinforcement Learning）就是针对这个具体困境提出的。它的出发点很朴素：如果一步动作到回报的距离太远，那就别用"一步"作为时间单位。把动作重新定义成一段可变时长的动作序列，让智能体在"片段"这个粒度上做决策，长程问题就被压缩成了短程问题，信用分配的距离从几百步降到几十步。

这篇文章适合两类人看：一类是正在做离线 RL、被稀疏奖励和长 horizon 卡住的实践者；另一类是想理解"时间抽象"和"数据增强"在离线设定下如何组合生效的研究型读者。下面我会把 OPAL 的三段式结构拆开讲，给出可以直接跑的最小代码骨架，然后重点聊那些论文里一句话带过、但真正决定成败的参数与坑。

1.1 离线场景下稀疏奖励的两个死结

在线 RL 里遇到稀疏奖励，常规解法是探索——多试几次总能撞到奖励，撞到之后靠大量在线交互把价值传播开。离线设定把这条路堵死了：数据是固定的，你没法去"多试几次"，撞不到就是撞不到。

第一个死结是数据覆盖不足。稀疏奖励任务里，真正接近目标的轨迹在数据集中往往只占很小一部分，绝大多数片段是随机游走或者无目的的移动。这些数据里，状态空间覆盖可能还行，但"接近目标"这一块的状态-动作对极度稀缺。值函数在数据稀疏区域的外推完全靠函数逼近器的泛化能力，很容易高估。

第二个死结是信用分配的距离太长。假设一条轨迹 800 步，只有最后一步给了奖励。标准的 Q-learning 更新里，那个非零回报要经过 800 次 bootstrap 才能影响到第一步的决策。离线设定下每次更新都受限于固定数据集，误差累积非常明显。有实验经验的人都清楚，这种任务上你把网络加大、把训练轮数拉高，效果提升非常有限，因为瓶颈在信息传播路径，不在模型容量。

OPAL 的思路是把这两个死结一起松开：用片段级的抽象缩短信用分配距离（解第二个结），用生成式增强补足数据覆盖（解第一个结）。

1.2 "动作原语"这个词到底指什么

先把概念说清楚，后面才不会绕。所谓 primitive，在这篇工作里的定义非常具体：一段固定长度的、从数据中抽取出来的动作序列，由一个低维的连续隐变量所刻画。

注意三个限定词。第一，"固定长度"——实际实现里就是切成长度 H 的窗口，H 一般取 8 到 20 之间。第二，"从数据中抽取"——它不是手工设计的技能库，而是从离线轨迹里学出来的。第三，"由一个低维隐变量刻画"——这是关键，一段 16 步、每步 8 维的动作序列有 128 个自由度，但被压缩成一个 4 到 8 维的 z。压缩本身就是在丢弃细节、保留"这段动作大概在干什么"的语义信息。

这个设计的好处在于它同时满足两个需求：作为强化学习的动作空间使用时，维度必须低（否则分层的好处就没了）；作为数据增强的生成器使用时，解码出来的动作必须能落回原始动作空间并且物理上合理。低维隐变量 + 解码器重建，正好卡在中间。

注意：这里的 primitive 不是"宏动作"那种离散技能库，也不是"选项"框架里带终止条件的东西。它是固定时长、无条件终止的连续隐变量片段。这个简化看起来丢了灵活性，但换来的是实现上极其干净——你不需要学终止函数，也不需要处理 option 的边界信用分配问题。

2. OPAL 的三段式结构：把"动作"重新定义成"片段"

整个方法可以拆成三个独立训练的阶段，阶段之间只通过数据和模型参数传递，彼此不联合优化。这种松耦合设计是它实用的重要原因：每一段你都可以单独跑、单独调、单独验证，出问题的时候容易定位。

2.1 第一段：用条件变分自编码器从裸轨迹里抽出隐动作原语

第一段的任务是从无标注的离线轨迹中学一个"片段生成器"。具体做法是把数据集里的每条轨迹切成不重叠（或半重叠）的长度为 H 的窗口，每个窗口包含状态序列 s_0, s_1, ..., s_H 和动作序列 a_0, ..., a_{H-1}。

编码器吃进整个窗口的状态和动作，输出一个高斯分布的均值和对数方差，采样得到隐变量 z。解码器则吃进窗口内的每个状态 s_t 和同一个 z，输出对应的动作 a_t。用公式写就是：

编码器：q(z | s_0, s_1, ..., s_H, a_0, ..., a_{H-1}) = N(μ, σ²) 解码器：p(a_t | s_t, z)，对 t = 0 ... H-1 逐点输出 损失：重建误差（MSE）+ β · KL(q(z|·) ‖ N(0, I))

这里有一个容易被忽略但很重要的设计选择：解码器重建的是动作，不是状态。原因很实在——状态转移由环境决定，你重建状态等于在拟合环境动力学，那是另一个问题（世界模型），而且会把模型容量浪费在预测那些和决策无关的视觉细节上。重建动作则直接对应用户要控制的量，梯度信号也干净得多。条件里给了 s_t 而不是让解码器自己从 z 里推断状态，是为了把"当前在哪儿"和"这段动作要干什么"解耦开——同一个 z 在不同位置可以解码出不同的具体动作，这正是原语该有的语义。

KL 项的作用是把这个隐空间推向标准正态。这不只是个正则化技巧，它直接决定了后面怎么用：一旦训练完成，你可以直接从 N(0, I) 里采样 z 来生成原语，不需要额外的先验估计。整个第三阶段能跑起来，靠的就是这一条。

2.2 第二段：数据集增强，但增强的是"重播轨迹"而不是噪声

大部分离线 RL 的数据增强是在状态或动作上加噪声、做随机裁剪、做镜像。这些操作的共同问题是它们引入了数据分布之外的样本，却没有对应的可靠标签，容易让 Q 函数学到虚假的高值。

OPAL 的增强方式不同：它把数据集中已有的片段重新编码成 z，再用解码器重新生成一遍动作序列，然后把原始片段和重生成的片段都放进增强数据集。

这个操作的妙处得细品。重生成的动作序列不是随机扰动，而是被 z 约束在"这段动作的语义"附近。原始数据里的动作往往带有大量高频抖动（尤其是随机探索策略产生的数据），解码器由于隐变量维度低、容量有限，天然会把这些高频噪声过滤掉，输出更平滑、更有方向性的动作。结果是：同一个状态序列下面，你多了一条"更接近专家风格"的动作标注。

这就是为什么在稀疏奖励导航任务上它特别有效。数据集里那些随机游走的轨迹，状态序列本身是有价值的（覆盖了空间），但动作序列是没方向的。经过一次编解码，状态被保留，动作被"提纯"，相当于凭空造出了一批带方向性的训练样本。而且这些样本的状态转移是从真实数据来的，不存在世界模型误差累积的问题。

同时，增强数据集里还要额外记录片段级的转移：从 s_0 出发，执行 z，经过 H 步到达 s_H，这中间累积的折扣回报记为 r_primitive。这样就构造出了一个时间尺度被压缩了 H 倍的新 MDP。原来的 800 步轨迹，在这个新 MDP 里只有 50 步左右。

2.3 第三段：在原语空间上跑标准的离线 RL

有了片段级 MDP，第三段就变得极其常规：状态空间不变，动作空间变成隐变量 z 的连续空间（4 到 8 维），奖励是片段累积折扣回报，折扣因子要相应调整（这一点后面单独说，是个大坑）。然后随便上一个成熟的离线 RL 算法就行。

原论文用的是保守类方法（对 Q 值做保守正则），这个选择是有道理的：增强数据集虽然状态来自真实数据，但动作是生成出来的，分布和原始行为策略有偏差，保守正则能压住由此产生的外推高估。如果你换成纯 BCQ 或者纯 TD3+BC，也能跑，但对数据质量的敏感度会更高。

推理阶段的执行方式有两种，需要按场景选：

实践中第三种最常用，但要注意：策略输出的 z 必须和训练时编码器产生的 z 处于同一个分布。如果训练时 z 是从编码器后验采的、推理时是策略网络直接回归的，两者容易错位。缓解办法是在第三阶段的训练里，把"策略输出的 z"和"编码器给出的 z"做一个对齐约束，或者干脆在训练时就只用先验采样。

3. 手写一遍：最小可跑的 OPAL 骨架

下面这套代码是我自己复现时整理的最小版本，去掉了所有工程性的并行和缓存逻辑，只保留核心数据流。用 PyTorch 写，结构上分三个文件比较清晰：primitive_vae.py、build_dataset.py、train_offline.py。

3.1 数据切片与网络形状：几个必须提前定死的数

先定三个全局超参：H（片段长度）、z_dim（隐变量维度）、action_dim（原始动作维度）。这三个数一旦定了，后面的网络形状、数据集切法、折扣因子全跟着走，所以要提前想清楚。

切片的实现有个细节要注意：episode 的边界必须严格处理，不能让一个窗口跨过两条轨迹。我的做法是先把每条轨迹补齐到 H 的整数倍（用 mask 标记 padding 位），再切。mask 要一路传到损失函数里，padding 位不参与重建误差计算，否则解码器会去拟合那堆零填充，学出一堆莫名其妙的动作。

import torch import torch.nn as nn class PrimitiveEncoder(nn.Module): def __init__(self, state_dim, action_dim, H, z_dim, hidden=256): super().__init__() self.H = H # 输入是 H 个状态 + H 个动作拼接 in_dim = H * state_dim + H * action_dim self.net = nn.Sequential( nn.Linear(in_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), ) self.mu = nn.Linear(hidden, z_dim) self.logvar = nn.Linear(hidden, z_dim) def forward(self, s_seq, a_seq): # s_seq: (B, H, state_dim) a_seq: (B, H, action_dim) x = torch.cat([s_seq.reshape(s_seq.size(0), -1), a_seq.reshape(a_seq.size(0), -1)], dim=-1) h = self.net(x) return self.mu(h), self.logvar(h) class PrimitiveDecoder(nn.Module): def __init__(self, state_dim, z_dim, action_dim, hidden=256): super().__init__() self.net = nn.Sequential( nn.Linear(state_dim + z_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), nn.Linear(hidden, action_dim), ) def forward(self, s, z): # 同一个 z 应用到每个时刻的状态上 B, H, _ = s.shape z_rep = z.unsqueeze(1).expand(-1, H, -1) return self.net(torch.cat([s, z_rep], dim=-1))

网络宽度上，编码器不需要太深。两三层的 MLP 足够，参数量过大反而会让 VAE 更容易忽略 z（解码器直接记住动作的均值分布就能把重建损失降下去），这就是所谓的后验坍缩。我在一个动作维度为 8 的任务上试过，编码器 256 宽的两层 MLP 效果不比 512 宽的差，而且训练更快、更容易收敛。

3.2 训练循环里两个必须盯住的信号

VAE 的训练本身没什么稀奇，但在 OPAL 这个场景下有两个指标必须实时监控，否则你会在第三阶段才发现问题，回头排查成本很高。

第一个是重建误差的绝对量级。它不是越低越好。如果重建误差降到接近零，说明解码器完美记住了训练数据，z 基本没起作用（信息都从 s_t 里来了）。这时候生成出来的动作和原始动作一模一样，增强数据集等于原始数据集，整个方法白做。合理的状态是：重建误差稳定在一个非零水平，大约相当于原始动作方差的一个可观比例。

第二个是 KL 项的实际数值。它应该在第一阶段快速上升然后趋于平稳，而不是持续下降趋近于零。KL 趋零就是典型的后验坍缩，编码器退化成常数输出，z 不携带任何信息。这时候你去采样 z 生成原语，得到的所有片段几乎一样。

def vae_loss(recon_a, target_a, mu, logvar, mask, beta=0.5): # 逐样本、逐时刻的重建误差，mask 掉 padding 位 rec = ((recon_a - target_a) ** 2).mean(dim=-1) # (B, H) rec = (rec * mask).sum(dim=-1) / mask.sum(dim=-1).clamp(min=1.0) rec = rec.mean() # KL 到标准正态 kl = -0.5 * (1 + logvar - mu.pow(2) - logvar.exp()).sum(dim=-1).mean() return rec + beta * kl, rec.detach(), kl.detach() def reparam(mu, logvar): std = torch.exp(0.5 * logvar) eps = torch.randn_like(std) return mu + eps * std

beta这个权重是这一阶段最需要手调的参数，后面单独说。

3.3 增强数据集怎么建、策略怎么跑

第二阶段的核心循环是：读一批片段，编码得到 z，解码得到新动作，然后在真实环境里"重播"这个状态序列来验证新动作——但离线设定下你不能真的重播。所以实际做法是：保留原始状态序列，把动作换掉，用原始数据里下一时刻的状态作为结果的近似。

这里有个近似误差必须承认：原始数据里 s_{t+1} 是由原始动作 a_t 产生的，你换成新动作 a't 之后，真实的下一状态应该不一样。用原始的 s{t+1} 当标签，会引入偏差。这个偏差在片段长度短、动作幅度小的任务上可以接受，在动作幅度大、动力学敏感的任务上会明显拖累效果。所以第一阶段的 H 不能设得太长，这也是 H 通常取两位数以内而不是几十的原因之一。

@torch.no_grad() def build_augmented(dataset, encoder, decoder, H): aug = [] for s_seq, a_seq, r_seq, mask in dataset.iter_windows(H): mu, _ = encoder(s_seq, a_seq) z = mu # 推理时用均值，不加噪 a_new = decoder(s_seq, z) aug.append({ "s_seq": s_seq, # 状态沿用真实数据 "a_seq": a_new, # 动作是重生成的 "r_seq": r_seq, "z": z, # 片段级动作标签 "mask": mask, }) return aug

第三阶段，在片段级 MDP 上训练一个标准离线 RL 策略。状态用 s_0，动作用 z，奖励用片段内折扣累积和。这里常见的一个实现细节是：片段级转移的下一状态是 s_H 而不是 s_1，别搞错了。虽然看起来是显然的，但我在两个不同的开源实现里都见过把它写成 s_1 的 bug，效果会直接崩掉。

4. 参数与坑：复现时最容易翻车的几处

这一节是全文里我最想写的部分。论文正文给出的参数组合是经过大量搜索得到的，直接抄过来在别的任务上大概率不适用。下面这几个坑，是我在复现和迁移过程中实际踩到的。

4.1 片段长度 H：最容易被随手设错的一个数

很多人第一反应是"越长越好，越长抽象层级越高，信用分配距离越短"。这个直觉在离线设定下是错的。

H 太长会遇到三个问题。第一，重播近似误差急剧放大——你用一个早就过时的 s_{t+1} 去标注新动作，误差随 H 线性甚至超线性增长。第二，编码器的输入维度是 H 乘 (state_dim + action_dim)，H 翻倍输入维度就翻倍，样本效率下降明显。第三，增强后的动作序列容易在片段边界处出现明显的跳变，执行起来很别扭。

H 太短则失去了抽象的意义。如果 H 只有 2 到 3，片段级 MDP 的 horizon 只缩短了 2 到 3 倍，稀疏奖励的问题基本没解决，你只是多做了一次数据增强。

我的经验是：H 应该和"一个有意义的行为单元持续多少步"大致对得上。导航任务里，一次转向或者一段直行大概十几步，H 取 10 到 16 比较合适。操作任务里一个抓取动作可能只有 5 到 8 步，H 就要相应减小。测试的时候可以先跑一组扫参：H ∈ {4, 8, 16, 32}，看第二阶段增强后的数据在第三阶段上的成功率曲线，通常能看出一条明显的倒 U 形。

4.2 KL 权重 beta 与隐变量维度：坍缩和爆炸之间的窄缝

beta是第一阶段唯一真正需要仔细调的超参。它太小，隐空间不被约束，z 的分布偏离标准正态，第三阶段从先验采样得到的 z 会落在编码器从没见过的区域，解码出垃圾动作。它太大，KL 项主导损失，编码器倾向于直接输出先验（mu 趋零、logvar 趋零），后验坍缩，z 不带信息。

判断方法很直接：训练完成后，从 N(0, I) 采样 20 个 z，用同一个状态序列解码，看动作序列的差异。如果 20 条几乎一样，说明坍缩了，beta 要调小。如果差异大到完全不像同一个任务的动作，说明约束不够，beta 要调大。健康的状态是：不同 z 解码出的动作序列在"方向"或"节奏"上有系统性的区别，具体细节不同但都物理合理。

z_dim同理。4 维可能不够表达行为多样性，8 维通常够用，16 维就开始有多余自由度被浪费在噪声上。我在一个动作维度为 6 的移动任务上做过对比，z_dim从 4 提到 8 有明显提升，8 提到 16 反而略降，因为多余的维度被用来记住片段的具体细节，泛化变差。

提示：如果你想快速判断 VAE 阶段是否健康，做一个"插值测试"——取两个不同片段的 z，线性插值出中间点，解码看动作序列。如果中间点解码出的动作能平滑地介于两个原始行为之间，说明隐空间结构良好。如果中间点是乱的，说明隐空间没有被有效组织。

4.3 折扣因子在片段级 MDP 上必须重设

这个坑非常隐蔽，很多人不会注意到。原始 MDP 里折扣因子 γ = 0.99，片段长度 H = 16。如果片段级奖励直接取 γ 的累积折扣和，那么一个片段的效果相当于在原始时间尺度上折扣了 γ^16 ≈ 0.85，也就是片段级 MDP 的有效折扣其实是 γ^H 而不是 γ。

如果你在片段级 MDP 上继续用 γ = 0.99 作为 bootstrap 的折扣，实际的总折扣会是 (γ^H) × γ = 0.85 × 0.99 ≈ 0.84，等效于原始尺度上的 γ_eff^H = 0.84，反推 γ_eff ≈ 0.989。听上去差不多，但影响的是几十步之后的价值传播，累积起来误差很明显。

正确的做法是显式地按 γ_primitive = γ^H 来构造片段级回报和 bootstrap。实操上更简单的等效做法是：片段级回报用未折扣的累积和（或者小折扣），bootstrap 时用 γ^H 作为折扣因子。这两种写法在数学上等价，但实现上后者更不容易出错。

4.4 增强数据的混合比例与"只用增强数据"的风险

第二个阶段的增强数据可以和原始数据混合使用，也可以只用增强数据。我一开始的做法是只用增强数据，因为直觉上它更干净。结果发现效果反而不如混合。

原因在于，增强数据虽然动作更"平滑"，但它丢失了原始数据里的动作多样性。如果任务的解法恰好需要一些不那么平滑、但确实有效的动作模式，只用增强数据就把这部分信息抹掉了。比较稳妥的做法是按 1:1 的比例混合，并且在采样时给原始数据略高的权重（比如 6:4）。这样既享受了提纯带来的方向性，又保住了原始分布的尾部。

还有一个问题是增强数据的动作可能落在行为策略的支撑集之外。Q 函数在这些位置的外推是高估的重灾区，所以第三阶段的离线 RL 算法必须带保守约束。如果你用的是不带保守项的方法，建议在损失里显式加一个对增强样本的惩罚，或者干脆把增强样本的权重降下来。

5. 什么场景下值得用，什么场景下是纯粹的成本

这套方法不是万能的，它的收益高度依赖任务和数据的形态。搞清楚边界比学会怎么调参更重要，因为选错场景意味着你花了三倍的工程量却拿不到任何提升。

5.1 值得用的三类场景

第一类是长 horizon 加稀疏奖励。这是 OPAL 的主场。导航、长程操作、多阶段任务都属于这一类。判断标准很简单：如果你把奖励改成稠密版本之后，基线算法立刻就好起来了，那说明瓶颈就是信用分配距离，OPAL 大概率能帮上忙。反过来，如果稠密奖励下也跑不好，那问题在别处，别在这上面浪费时间。

第二类是动作序列存在大量冗余高频抖动。随机探索策略采出来的数据往往是这样：大方向可能对，但每步都在抖。这类数据拿来直接训练，策略会学到抖动本身。编解码一次相当于做了个低通滤波，效果提升非常直观。这个收益在数据质量差的时候尤其明显，甚至不需要长 horizon 也能看到。

第三类是动作维度不算太低、但行为模式种类不多。比如一个六足或者四足的移动任务，动作维度十几维，但实际有效的行为模式可能就那么几种（前进、转向、后退、蹲伏）。低维隐变量正好能把这种"少模式、高维度"的结构压出来。

5.2 用了反而不划算的三种情况

短 horizon 加稠密奖励。这是最常见的误用。任务本身就只有几十步、每步都有奖励信号，信用分配根本不是瓶颈。这时候上 OPAL，你付出的代价是：额外训练一个 VAE、额外一轮数据增强、额外一套片段级 MDP 的工程代码，收益基本为零甚至为负（因为重播近似误差）。我见过有人在这种任务上硬套，最后效果比直接跑基线差，还以为是调参没调好。

动作维度极低、行为连续的任务。如果动作只有两三维、而且随状态连续变化，那么"把多步动作压缩成一个低维向量"这个操作提供的信息增益很小。隐变量能表达的东西本来就不比原始动作空间多多少，压缩反而是有损的。

数据本身已经是高质量的专家演示。专家数据的动作平滑、有方向性，编解码的提纯作用就不存在了。这时候增强数据 ≈ 原始数据，白白多了一轮训练和一层近似误差。

我把这几条整理成一个快速判断表，实际项目里对着看一眼就能决定要不要上：

5.3 它和层次化 RL、序列建模类方法的边界在哪

顺带说清一个容易混淆的问题：OPAL 和经典的层次化 RL 有什么本质区别。

经典层次化方法（选项框架那一类）通常要学三样东西：高层策略、低层策略、终止函数。终止函数是最麻烦的，它决定了什么时候该换 option，而这个决策本身又需要在稀疏奖励下学习，形成套娃。OPAL 直接砍掉了终止函数——片段长度固定为 H，到点就换。这个简化牺牲了灵活性（有些行为确实该持续更久，有些该提前中断），但换来了实现的干净和训练的稳定。在离线设定下，这个交换通常是划算的，因为在线交互能帮你学到好的终止点，离线数据里学终止函数则非常困难。

另一个常被拿来比的是把离线 RL 转成序列建模的那一类方法。它们走的是完全不同的路子：不学价值函数，直接建模轨迹分布，用条件生成来做决策。这类方法在长 horizon 稀疏奖励上也有不错的报告，但它们的瓶颈在推理时的搜索成本和对数据质量的敏感性。OPAL 的优势是它能在现有离线 RL 算法上做增量改造——你不用换掉整个技术栈，只要在数据侧和动作空间侧动刀。对于已经在用成熟离线 RL 框架的团队，这个改造成本低得多。

我个人在实际操作中的体会是：如果你的团队已经有一套调好的离线 RL 训练管线，OPAL 是一次低风险的增量升级；如果你是从零开始，而且任务本身不算长程，那先老老实实把基线调好、把数据质量提上去，收益比上这套抽象更大。时间抽象是解决特定瓶颈的工具，不是通用加速器——把它当成后者用，往往会在工程复杂度上付出远超预期的代价，而在指标上什么也换不回来。