“开物元启” 具身大模型平台 技术支持
前两篇讲了格式选型和八维质检，这篇往回退一步，讲流水线中段最脏的活：清洗。

先说结论：清洗的难点不在于会不会用高斯滤波，在于算子的执行顺序。同样一组算子，排列不同，结果可以从"数据变干净"变成"数据被毁掉且看不出来"。

一、先讲一个能把整个数据集毁掉的操作

图像数据增强，几乎所有人第一个想到的都是水平翻转。免费的两倍数据量，CV 领域用了十几年，没人怀疑。

在具身智能场景，这个操作会静默地毁掉你的数据集。

原因很简单：具身智能的样本不是"图像"，是"图像 → 动作"的配对。

你把腕部相机的画面水平翻转，物体从画面右侧移到了左侧。但配对的动作标签还写着"末端向右移动 3 厘米"。模型学到的是：看到物体在左边，就往右边动。

# ✗ 灾难：只翻图像，不翻动作
image = cv2.flip(image, 1)
# action 原封不动 —— 现在这条样本在教模型做反方向的运动

# √ 正确：图像与动作必须同步镜像
image = cv2.flip(image, 1)
action[0] = -action[0]        # 末端 x 方向位移取反
action[4] = -action[4]        # 绕 y 轴旋转取反
# 而且：相机外参、抓取点坐标、所有带方向的量，全都要一起处理

更麻烦的是，双臂机器人做水平翻转，左右臂的动作要整体互换。做不到这一点，就别对具身智能数据做水平翻转。

这个坑的本质：CV 领域的算子经验，不能原样搬到具身智能。因为标签的性质变了——从"与几何无关的类别"变成了"与几何强耦合的动作"。

二、清洗算子有多少种？按模态拆开看

先建立全景。具身智能是多模态数据，每种模态的清洗算子完全不同。

基础类（7 条）—— 与模态无关，所有数据都要过

算子	干什么
数据去重	删除完全重复的记录
缺失值处理	填充或丢弃缺失字段
异常值检测	识别超出合理范围的数值
数据归一化	缩放到统一区间
Z-Score 标准化	按均值方差标准化
数据排序	按时间戳或指定字段排序
数据类型转换	统一 dtype，避免精度问题

图像类（13 条）

去噪三件套：高斯去噪 / 中值滤波 / 双边滤波——分别对付高斯噪声、椒盐噪声、需要保边的场景。

亮度与色彩：亮度调整 / 对比度调整 / 直方图均衡化 / 伽马校正 / 白平衡 / 色彩空间转换。

结构与尺寸：双三次插值缩放 / 锐化 / 边缘增强 / 格式转换。

具身智能场景最常用的是白平衡和伽马校正——实验室灯光和真实场景的色温差异，是模型从实验室出不去的常见原因之一。

音频类（6 条）

音频降噪 / 重采样 / 分割 / 裁剪 / 音量标准化 / 音源分离。

语音指令类数据主要用降噪和音量标准化；多说话人场景需要音源分离。

点云类（10 条）

算子	什么时候用
下采样 / 均匀下采样	点数太多，训练吃不消
离群点移除	深度相机的飞点
体素过滤	规整化点密度
统计滤波 / 半径滤波	两种不同思路的离群点判据
RANSAC 离群点检测	拟合平面（桌面）后剔除偏离点
法向量估计	抓取姿态规划要用
分割	分离前景物体与背景
配准	多视角点云拼接

轨迹类（10 条）

这是具身智能最特殊的一类，CV 领域完全没有对应物：

平滑 / 插值 / 重采样 / 移动平均 / Savitzky-Golay 滤波 / 分割 / 坐标转换 / 时间对齐 / 时间戳同步 / 速度过滤。

其中 时间对齐 和 时间戳同步 是整条流水线里最容易被忽略、后果最严重的两个。多传感器采样率不同（相机 30Hz、编码器 1000Hz、力传感器 500Hz），不对齐就谈不上任何后续处理。

Savitzky-Golay 滤波值得单独提一句：它在平滑的同时能保住导数信息，对需要从位置轨迹反推速度、加速度的场景，比移动平均好用得多。

增强算子（另外一套）

清洗是"去掉不该有的"，增强是"造出更多的"。两者性质完全不同，必须分开管理。

• 图像增强（12 条）：水平翻转 / 垂直翻转 / 旋转 / 平移 / 随机裁剪缩放 / 颜色抖动 / 噪声注入 / 模糊 / 锐化 / Cutout / Mixup / CutMix
• 音频增强（9 条）：音频噪声 / 高斯噪声 / 音调偏移 / 速度变化 / 时间偏移 / 时间遮蔽 / 频率遮蔽 / SpecAugment / 脉冲噪声
• 点云增强（6 条）：随机翻转 / 随机旋转 / 全局缩放 / 随机丢弃 / Cutout / 均匀下采样

注意：图像增强里的翻转、旋转、平移，点云增强里的翻转、旋转，全部属于第一节讲的"几何变换"，在具身智能场景下都必须同步处理动作标签。颜色抖动、噪声注入、模糊这类不改变几何的增强，才是可以无脑用的。

至于视频和轨迹的增强，目前主流做法还是走自定义扩展——这两类的增强语义高度依赖具体任务，很难有通用算子。好的做法是把算子体系设计成插件化的，按统一接口规范注册自己的实现，而不是等平台内置。

三、六条编排铁律

有了算子清单，真正的工程问题来了：按什么顺序执行。

铁律 1：去重和时间对齐必须在最前面

所有后续算子的正确性都建立在"数据条目是唯一的、时间轴是对齐的"这个前提上。

顺序错了会怎样：先做了插值，再做去重——插值出来的点被当成真实数据保留下来，去重反而删掉了原始点。

铁律 2：归一化和标准化必须在最后面

归一化的参数（min/max 或 mean/std）是从数据统计出来的。如果归一化之后又做了滤波、缩放、裁剪，统计量就失效了。

而且：归一化的参数必须只从训练集统计，然后应用到验证集和测试集。用全量数据统计归一化参数，本身就是一种数据泄漏。

# √ 正确：统计量只来自训练集
stats = compute_stats(train_set)
train_set = normalize(train_set, stats)
val_set   = normalize(val_set, stats)     # 用训练集的统计量
test_set  = normalize(test_set, stats)

铁律 3：清洗和增强不能混在一条流水线里跑

清洗作用于全量数据，增强只能作用于训练集。

如果你在同一条流水线里先清洗再增强，然后才切分数据集，那么增强出来的样本会同时出现在训练集和验证集里——这是最隐蔽的一种数据泄漏。

正确的顺序：

全量数据 → 清洗 → 质检 → 切分（episode 级）→ 只对训练集做增强

铁律 4：滤波在缩放之前

先缩放再去噪，噪声会被插值算法"抹开"，变成低频的、更难去除的伪影。先去噪再缩放，结果干净得多。

点云同理：先离群点移除，再下采样。反过来做，离群点会被保留下来并且权重变大。

铁律 5：几何变换类算子必须成组执行

图像的旋转、翻转、平移，点云的旋转、翻转、缩放——这些算子改变的是空间关系。只要用了其中任何一个，配套的动作标签、相机外参、抓取点坐标都必须同步变换。

工程上的做法是把它们封装成一个不可拆分的复合算子，输入输出都是「观测 + 动作」的配对，而不是单独的图像。

铁律 6：每一步都要能回溯

清洗是有损操作。一旦发现某个算子的参数配错了，你需要能回到上一步重来，而不是从原始数据重跑整条链。

这要求：原始数据、清洗数据、增强数据必须分开存放并保留血缘关系，而不是原地覆盖。

四、一个可用的默认顺序

把六条铁律落成一个具体的执行顺序，多模态场景下可以这样排：

① 时间戳同步 · 时间对齐          ← 多传感器必做，最前
② 数据去重                        ← 在任何生成性算子之前
③ 缺失值处理 · 异常值检测         ← 决定丢弃还是填充
④ 各模态专用清洗
   图像：去噪 → 白平衡/伽马 → 缩放
   点云：离群点移除 → 体素/下采样 → 法向量估计
   轨迹：速度过滤 → Savitzky-Golay 平滑 → 重采样
⑤ 数据类型转换 · 排序
─────────── 质检门禁 ───────────
⑥ episode 级切分
─────────── 分界线 ───────────
⑦ 仅训练集：非几何类增强（颜色抖动 / 噪声 / 模糊）
⑧ 仅训练集：几何类增强（必须同步变换动作标签）
⑨ 归一化 / 标准化（统计量只来自训练集）

这个顺序不是唯一正确的，但它满足全部六条铁律。你的场景如果要调整，先确认调整之后哪条铁律被打破了，以及能不能接受。

五、工程化实现长什么样

上面这套顺序，如果靠每个人写脚本各自实现，结果一定是每个人的顺序都不一样，而且没人说得清自己那版为什么这么排。

我们在「开物元启」平台里的做法是把它变成可视化编排：算子按模态分类列出，勾选需要的，配置各自的参数（比如增强算子的执行概率），然后拖拽调整执行顺序——顺序是显式的、可见的、可复用的，而不是埋在某个人的脚本里。

三个设计上的考虑：

1. 清洗算子和增强算子分两栏，从界面上就强制区分这两类东西的性质，避免铁律 3 被违反。
2. 算子体系插件化：内置算子按 com.algorithm.plugin.impl.{basic|image|audio|pointcloud|trajectory}.*Processor 的规范组织，自定义算子按同一接口注册。视频、轨迹这类增强语义高度任务相关的模态，走自定义扩展比硬塞通用算子更实际。
3. 数据分层不覆盖：原始数据 / 清洗数据 / 增强数据分开存，每一份都能往回追溯来源，对应铁律 6。

清洗完的数据直接进下一环节的质检（就是上一篇讲的八个维度），过了才允许导出。

写在最后

清洗这件事，最大的认知偏差是以为它是个技术问题。

技术上，每个算子都有成熟实现，调 API 就行。真正难的是：知道什么时候用哪个、按什么顺序用、以及哪些算子在具身智能场景下根本不能用。

这些东西不写下来，就只存在于做过的那个人脑子里。人一走，团队从零开始踩一遍。

---

下一篇写《12 个模型 × 6 种模态：具身智能的标注该让 AI 做到哪一步》。

在做具身智能数据这一块的，欢迎评论区聊；做高校实验室方案的可以私信我。

---

---