第一次跑 LIBERO 的时候我一度怀疑自己拿到了假数据。同样是一段夹取动作有的 demo 里 action 的数值范围在 ±0.05 附近有的任务里旋转分量能到 ±0.2夹爪分量又长期贴着 -1 和 1 两个值。更让我懵的是翻遍官方仓库和数据集说明文档它似乎并没有像图像那样有一套明确的前后处理流程。这个看不见、摸不着、却又确实存在的“动作归一化”就是 LIBERO 从“能跑通”到“跑得好”之间最大的一道坎。这篇文章想聊的就是这件事。我会从 LIBERO 官方数据集里 Action 的真实结构出发拆开“归一化”这个词背后混在一起的三层含义然后沿着代码把一条 action 从 HDF5 文件到 loss 的完整路径走一遍最后给出一套我实际验证过的排查和归一化方案。无论你是刚接触 LIBERO 的新手还是已经在做终身学习和机器人策略复现的老手这篇文章应该都能帮你省下好几个周末的调试时间。1. 先搞清楚 LIBERO 的动作到底长什么样1.1 LIBERO 是拿来干嘛的LIBEROLifelong Robot Learning Benchmark是一个面向机器人长期学习场景的仿真基准专门用来评估“学会新任务同时不忘旧任务”的能力。它由多个任务套件组成最常用的是 Spatial、Object、Goal、Long 四套合计 130 个左右的任务。任务内容都是桌面操作比如把碗推到目标位置、把方块放到特定的颜色区域、按顺序完成一串动作等。整个基准的数据收集和评估都在 robosuite 仿真环境中完成采集对象是 Franka 机械臂。每个任务提供约 50 条人类或脚本生成的演示轨迹每条轨迹包含视觉观测顶视图、前视图、关节状态、末端执行器位姿以及动作序列。训练时模型输入通常是“观测 语言指令”输出是一段动作序列或单个动作步。之所以 LIBERO 会被广泛使用是因为它把“终身学习”这件事做成了一个可重复的考试题。但既然是一套考试题题目数据里每个字段的语义就必须清清楚楚。Action 恰好是这里最容易含糊的字段。1.2 Action 的 7 维结构增量动作而不是绝对位姿LIBERO 官方数据集里每个时间步的 action 是 7 维向量顺序大致为前 3 维末端执行器在笛卡尔空间的位置增量 delta position单位是米中间 3 维末端执行器姿态的增量 delta rotation单位是弧度最后 1 维夹爪开合控制量。这套动作不是“末端执行器的下一帧绝对位姿”而是“相对于当前位姿应该怎么动”。也就是说策略网络输出的不是一个目标位置而是一个位移量由仿真器中的控制器把这个位移量叠加到当前状态上再通过逆运动学映射到关节力矩。这一点特别容易被忽略。很多人第一次拿到数据看到 action 数值很小以为官方做过了归一化。其实不是它只是“增量动作”的自然结果。控制周期短、步长小增量自然就小。换句话说这个动作空间的“小”是由机器人控制器特性决定的而不是后处理归一化造成的。理解这层区别是全文的关键。后续所有关于不透明性的争论基本都源于“增量动作的小范围”和“主动归一化的小范围”容易被混淆。1.3 官方数据集的存储格式与动作字段LIBERO 官方数据集以 HDF5 格式分发每个任务对应一个.hdf5文件。文件内部结构大致包含data/demo_0/actions演示轨迹的动作数组形状为(T, 7)data/demo_0/obs/agentview_rgb、eye_in_hand_rgb图像序列data/demo_0/obs/joint_states关节角度序列其他辅助字段如末端执行器位姿。这个存储结构本身没有任何归一化标识。图像是 0 到 255 的 uint8关节角度是弧度动作是浮点数没有专门的 scale 或 offset 字段写在属性里。这就有意思了。很多 CV 数据集会在打包时把图像归一化到 [0, 1]或者在元数据里写明 mean 和 std。但 LIBERO 数据集的动作字段没有这种待遇。为什么因为官方训练代码里对动作的处理根本不是“读数据时统一归一化”而是分散在环境配置、训练脚本甚至模型输出层里。这就为“不透明性”埋下了种子。2. 三种“归一化”被混为一谈2.1 环境层的动作缩放控制器替你完成了一半归一化robosuite 的 OSC操作空间控制控制器本身就限制了动作的输入范围。以常见的 OSC_POSE 控制器为例位置增量通常被限制在 ±0.05 米左右旋转增量在 ±0.25 弧度左右夹爪控制量在 [-1, 1] 之间。这个限制是在环境初始化时通过控制器参数设定的不写进数据集。也就是说模型动作如果超出这个范围仿真器会做截断或缩放。从效果上看控制器把动作输入“映射”到了一个有限区间内这本身就是一种隐式归一化只是它不是对数据的归一化而是对控制量的约束。论文和代码仓库通常不会显式强调这一点。于是出现了一个经典误区有人在分析数据集时发现 action 最小值大约是 -0.05最大值大约是 0.05就得出结论“官方数据集做了 min-max 归一化”。这个结论是错的那只是控制器截断后的分布结果。2.2 数据层的统计归一化官方并没有默认做在训练机器人策略时有些框架会对动作做统计归一化也就是计算每个维度的均值、标准差然后做标准化action (action - mean) / std或者做 min-max 缩放action (action - min) / (max - min) * 2 - 1这一类处理在 LIBERO 官方训练代码里默认是不做的。官方默认的做法是直接把 7 维 action 当作回归目标计算 MSE 或 L1 loss。你翻遍script_train系列脚本会看到对图像做/ 255.0但对动作基本不做额外变换。这带来一个很直接的结果如果你在某个社区项目里看到别人对 LIBERO 动作做了标准化那不是官方行为而是他为了训练稳定自己加的。两种做法在同一个数据集上训练出的模型性能差异可能非常大但论文里经常不说清楚自己到底用了哪种。2.3 训练层的动作处理复现项目里最乱的地方除了“数据层面归一化”和“环境层面动作缩放”还有第三层就是模型输出层的动作处理。最典型的一种做法是把动作先除以一个固定常数让数值落在较小的区间再用 MSE 回归。另一种做法是让模型输出经过 tanh 激活限制在 [-1, 1]然后反缩放为真实动作。OpenVLA 这类模型在适配 LIBERO 时会额外用数据集统计量做归一化再离散成动作 token。这些处理都在训练代码里不进数据集文件。也就是说同一份官方数据集到了不同项目里动作的处理路径完全不同。有些是“直接用原始动作”有些是“除以最大绝对值”有些是“按维度标准化”有些是“只看夹爪维度怎么处理”。这些都属于“训练层动作处理”。问题在于很多项目只把模型结构写清楚对动作归一化策略一笔带过。于是 BibTex 里换了三四个模板最终跑出来的分数对不上你都不知道是模型问题还是归一化问题。这一层才是“不透明性”最让人头痛的地方。2.4 为什么不透明版本、分支与文档的多重缺口LIBERO 官方仓库经历过多次更新数据集的版本、环境配置、控制器参数在不同 commit 之间有差异。有的版本里动作范围是 ±0.05 位置 / ±0.25 旋转有的分支因为改了控制频率动作的实际统计分布完全不同。更隐蔽的是HDF5 文件本身没有写入“动作生成时的控制器参数”。robosuite 环境脚本里虽然有参数但数据分析师通常不会去翻环境脚本。即使翻了还需要确认训练时用的 env_kwargs 和采数据集时是否一致。只要有一处不一致你对动作分布的判断就会出错。文档层面呢LIBERO 的 README 和论文里写清楚了任务划分和评估协议但对动作归一化几乎是零描述。这在机器人社区不算罕见但对于想要精确复现的研究者来说这就是一个黑箱。3. 代码追踪一条 Action 从 HDF5 到 loss 的真实路径3.1 从 HDF5 到 sample数据加载阶段发生什么在官方代码里数据加载通常走过get_dataset系列函数返回一个LiberoSequenceDataset或类似对象。__getitem__返回的样本里action 字段就是 HDF5 里的actions数组切片基本上原样输出。这段逻辑里没有归一化。你可能会在 obs 字典里看到图像被转换成 float 并缩放到 [0, 1]但 actions 只是被转换成 float 而已没有减均值、没有除标准差。这一点我们可以拿代码习惯佐证官方训练里图像归一化是写死在 obs 处理函数中的而 action 处理则分散在 trainer 或 policy 里。所以如果你只看了数据加载代码会误以为“官方没有归一化”。如果只看 trainer 代码又可能看到某个地方调用了 normalize_action 之类的函数。两段代码放到一起才会意识到action 的处理链路是分段的不是一步完成的。3.2 训练脚本里 action 是怎么被处理的官方训练脚本的主体流程并不复杂加载数据集初始化策略每步取 batch前向得到 action 预测和真实 action 算 loss反向传播。在常见的官方实现里loss 计算直接基于原始动作。动作预测的输出维度是 7真实动作也是 7直接算均方误差。这里没有对 action 做标准化处理也没有对 loss 项做分维度加权。夹爪那一维的 loss 和位置那一维的 loss 是一样权重的这导致后面很多训练问题。也有一些社区复现版本会加上normalize_action函数比如def normalize_action(action, low, high): return (action - low) / (high - low) * 2 - 1然后传--normalize参数默认开启或默认关闭完全看维护者心情。问题在于这类函数经常不在 README 里写明默认值也改来改去。你从一个旧 commit 切到新 commit性能变化 3 到 5 个点根本猜不到是网络结构改动还是归一化改动。3.3 在哪里埋下不确定性几处隐蔽分支根据我自己的排查经验动作归一化不确定性的主要埋点有三个。第一个是环境加载脚本里的控制器参数。如果你在评估时用的环境控制频率或动作缩放系数与训练时不一致模型输出的动作范围就会被“重新解释”效果等同于改变了归一化。第二个是动作回放时的 clip 行为。有些代码在控制真实环境时会对动作做 clip有些不做。如果训练时动作在 [-0.05, 0.05] 但评估时 clip 到 [-0.03, 0.03]模型表现自然会掉。第三个是模型输出层的激活函数。有的策略头直接输出 7 维向量有的套了一层 tanh 或 scale。这层信息往往藏在模型代码里不画数据流图根本发现不了。这三个埋点都很隐蔽但它们共同决定了一个模型的真实动作分布。你只盯数据集本身永远发现不了问题。4. 不透明性带来的实际影响4.1 训练尺度失衡一个被忽视的梯度问题如果直接拿原始 7 维 action 计算 MSE不同维度的数值尺度差异会直接影响梯度。位置增量的量级大约是 0.01 到 0.05旋转增量的量级大约是 0.05 到 0.25夹爪动作则大部分时间贴着 -1 或 1。三者放在同一个 loss 里梯度贡献天然不均衡。位置维度 loss 太小模型可能倾向于忽略位置误差只要把旋转和夹爪练好总 loss 就能降到很低。反过来如果旋转维度数值噪声大模型也可能在旋转上过拟合。这种问题在单任务训练里还不致命顶多多训练几万步。但在终身学习场景里就很麻烦新任务如果旋转分量变化剧烈模型会优先调整旋转相关表征挤压其他任务的知识空间导致灾难性遗忘更严重。我在实际训练中观察过把位置、旋转、夹爪三个维度分别计算 loss 并做加权比直接算整体 MSE 能稳定提升最终成功率。这个技巧不算复杂但因为官方代码没有提示很多人根本想不到去做。4.2 终身学习评估任务间的动作分布漂移LIBERO 的核心价值在于评估终身学习算法比如 EWC、PackNet、EWC 等。这些算法通常基于对参数重要性的估计而重要性估计依赖 loss 或梯度。如果不同任务的动作分布差异很大模型在不同任务上的梯度尺度也会差异很大。一个对动作尺度敏感的算法可能把“任务 A 的旋转动作特殊性”当成“模型遗忘的关键因素”导致正则化强度分配失误。举个例子某个任务需要频繁大角度旋转另一个任务主要是平移。直接混训时旋转维度的梯度主导模型更新参数重要性估计会被带偏。如果先做动作归一化让每个维度在任务间分布一致算法对任务差异的判断会更准确。这是一个非常实际的问题。我在跑 LIBERO-Long 套件时多次发现 EWC 的 Fisher 信息矩阵数值范围异常排查到最后都是因为动作分布在不同任务间漂移太大而不是算法写错了。4.3 复现与对比归一化策略成了隐形超参Benchmark 的意义在于不同论文之间的结果可对比。但如果每个团队对 LIBERO 动作的归一化处理不同那最终分数就没有可比性。假设论文 A 直接用原始动作训练论文 B 对动作按维度做了标准化论文 C 把动作除以固定最大值三者在相同任务上的成功率可能差好几个点。当这个差异大于算法本身带来的提升时实验对比就是失效的。更讽刺的是这种差异很难从论文文本中识别。因为大家通常都只写一句“we follow the official setting”但“official setting”在不同仓库里已经被改得面目全非。我在复现某篇论文时不得不去翻它的训练代码确认是否做了动作归一化结果发现作者用的是自己实现的NormalizeAction类而论文里只字未提。这提醒我们一件事如果你要在 LIBERO 上做实验对比必须先统一动作归一化协议否则所有结论都是空中楼阁。5. 实操避坑把不透明变成透明5.1 第一步翻环境代码确认动作边界拿到任何 LIBERO 数据集不要先急着训练。先找到生成数据时用的环境脚本确认控制器类型和参数。重点看两个地方控制器是不是 OSC_POSE位置动作边界是多少旋转动作边界是多少夹爪控制是不是二值。通常在环境定义的_get_action_limits或类似函数里都能找到。这一步的意义是明确“数据集的天然动作范围”而不是自己猜。我建议把确认结果写成一个常量文件后面所有归一化操作都以这个文件为准而不是再凭空设边界。5.2 第二步写脚本统计每个维度的真实分布就算环境里写了边界实际数据也未必均匀分布在整个边界内。直接统计每个维度的 min、max、mean、std是最快理解数据的方式。import h5py import numpy as np def inspect_actions(hdf5_path, n_demos50): actions [] with h5py.File(hdf5_path, r) as f: for i in range(min(n_demos, len(f[data]))): demo f[fdata/demo_{i}] actions.append(demo[actions][:]) actions np.concatenate(actions, axis0) print(shape:, actions.shape) print(min:, actions.min(axis0)) print(max:, actions.max(axis0)) print(mean:, actions.mean(axis0)) print(std:, actions.std(axis0)) print(percentiles:) for q in [1, 5, 50, 95, 99]: print(q, np.percentile(actions, q, axis0))这个脚本几乎适用于所有 LIBERO 套件。统计完你会很直观地看到位置维度集中在 ±0.05旋转维度通常更分散夹爪维度几乎只有两个尖峰。这些数字会直接指导你后续的归一化方案。5.3 第三步选择一个可解释的归一化方案在机器人动作归一化上我不推荐直接按整个数据集的 min/max 做缩放。因为夹爪维度的离群点极少但会极大拉宽 min-max 范围导致前 6 维被压扁。更稳的方案有两种。方案一按边界缩放。如果位置维度的物理边界是 ±0.05旋转是 ±0.25夹爪是 [-1, 1]那就直接用这些固定边界把每个维度映射到 [-1, 1]不做数据统计。action_scale np.array([0.05, 0.05, 0.05, 0.25, 0.25, 0.25, 1.0]) normalized_action action / action_scale这个方案的好处是逻辑透明、可逆、不会因为数据集中添了几条 demo 就改变归一化参数。方案二按分位数标准化。为每个维度计算 5% 和 95% 分位数用这两个数作为缩放边界。这种方式能抵抗离群点比 min/max 稳定但需要提前统计而且换数据集要重算。方案三按任务分别归一化。在终身学习场景里如果任务间动作分布差异实在太大可以按任务计算统计量各自归一化。但这样做要非常小心如果测试时不知道任务身份归一化参数就无法确定如果任务身份在训练时可知、在测试时不可知那模型输入标准就不一致了。我个人的默认选择是方案一也就是固定物理边界归一化。它把“归一化”从黑箱变成了一个可读懂的代码常量而且与 robosuite 控制器参数一致物理意义清晰。5.4 常见问题速查表现象可能原因排查与解决训练 loss 降到很低但 rollout 成功率不高夹爪维度主导 loss位置维度没学好分维度打印 loss尝试分维度加权或固定边界归一化相同模型相同 seed复现分数差 5 个点以上训练代码中动作归一化策略不一致检查有无 normalize_action、有无 tanh、有无 clip多任务训练时 loss 波动巨大任务间动作分布差异大统计各任务动作分布考虑固定边界归一化EWC 等终身学习算法失效不同任务梯度尺度不均衡对动作做标准化后再训练观察 Fisher 矩阵数值夹爪动作学成中间值夹爪维度被当作连续回归目标将夹爪 loss 改为二值交叉熵或单独加权某维度梯度为 nan数据里有极端值或异常 demo用分位数检查动作分布过滤掉异常轨迹每个问题我都实际踩过。尤其是“loss 好看但 rollout 拉垮”几乎成了 LIBERO 复现的经典陷阱。归根结底问题不总出在模型而常常出在动作数值分布不够透明。6. 关于 LIBERO 动作归一化我最后想说的把这个话题翻来覆去讲完我的结论其实很简单LIBERO 官方动作归一化的不透明不是你理解能力的问题而是项目本身把归一化分散到了多个层面、多个文件、多个版本里却从来没有统一说明。作为使用者最靠谱的做法不是去等官方补文档而是自己把这条链路梳理清楚。环境控制器参数看一下数据集动作分布统计一下训练代码里有没有隐藏的 normalize 查一下然后明明白白地写进自己的实验配置里。我后来在自己的项目里定了一条规则不管跑哪个机器人 benchmark都要在实验记录里单独写一行“Action normalization method: fixed-boundary / stats / none”。就这么一行字帮我避开了无数次复现灾难。如果你正准备跑 LIBERO希望这篇文章能帮你少走这段弯路。先不要急着训模型花半小时把 action 的来龙去脉搞清楚后面会顺很多。