2026 年百万小时具身智能数据建设，这个目标一出来，很多做机器人的团队都会心里一紧。百万小时是什么概念？如果按单台机器人每天采集 8 小时有效数据来算，粗算需要 340 多台设备跑满一整年，这还没算清洗、筛选、标注、质检和重新采集的损耗。所以这个消息真正的看点不是三家合作本身，而是具身智能行业开始认真对待数据供给侧的问题。
这次合作的一方是黎曼动力，另外两家是光轮智能和诺亦腾机器人。前者在具身智能数据领域有积累，后两者在仿真数据、动捕数据采集和机器人硬件上有各自的底子。三方合作瞄准的是 2026 年建成百万小时级别的具身智能数据资产。如果你做机器人算法、数据平台、仿真训练或者机器人产品落地，这篇文章重点拆一下这条数据建设路线的技术结构、工程难点和可以复用的验证方案。
先给一个整体判断：百万小时数据建设，真正的技术难点不在“采”，而在“数据怎么采得可用、怎么洗得干净、怎么存得高效、怎么喂给模型时不把模型带偏”。数据质量决定模型上限，这已经是行业共识。下面把这条链路拆开讲。
1. 核心能力速览
先看这次合作涉及的核心能力分布。以下内容基于公开信息做归纳，具体参数需要按各家实际产品和后续官方披露为准。
| 能力项 | 说明 |
|---|---|
| 项目方向 | 具身智能数据建设，面向机器人基础模型训练 |
| 主力参与方 | 黎曼动力、光轮智能、诺亦腾机器人 |
| 目标规模 | 2026 年达成百万小时级具身智能数据 |
| 覆盖环节 | 数据采集、仿真生成、数据处理、质量评估、训练集构建 |
| 涉及硬件 | 机械臂、人形机器人、数据采集装备、动捕设备、传感器 |
| 关键技术点 | 遥操作采集、动捕数据、仿真数据合成、数据清洗、数据仓管理 |
| 适合读者 | 机器人算法工程师、数据平台开发、具身智能创业者、仿真训练团队 |
从这张表能看出来，这次合作不是单一工具或模型的发布，而是数据基础设施级别的布局。对普通开发者而言，短期内能直接获取的价值可能有限，但它代表的方向值得关注：具身智能的数据建设正在从“攒数据”走向“建数据工业线”。
2. 为什么百万小时数据是具身智能的硬门槛
先看一个基础问题：大语言模型能通过互联网文本获得海量训练数据，具身智能模型为什么不行？因为机器人需要的是多模态的、时序的、因果关联的交互数据——不仅要看到桌子上的杯子，还要知道手伸过去抓握的角度、力度、失败后的调整策略。这类数据互联网上没有现成的，必须靠真机采集、仿真生成或动捕迁移。
这里的“小时数”和视频时长不是一回事。一小时有效的具身智能数据，通常包含：多视角视频流、本体状态流、关节角度流、力矩流、触觉信号流、指令和任务标签，以及失败轨迹记录。单纯一小时多传感器同步采集，未压缩前可能产生数百 GB 的原始数据，清洗筛选后能进入训练集的可能只有几分钟到几十分钟。所以百万小时听上去是采集量，实际上对应的是庞大的原始数据池和数据治理体系。
进一步看，数据规模不是线性扩大就能解决能力问题的。如果模型在小规模数据上已经出现过拟合或行为退化，直接加数据反而可能放大噪声。具身智能数据的质量评估体系必须前置进来：哪些轨迹是有效的、哪些行为是任务完成的、哪些是环境偶然因素导致的“假阳性”。没有这套体系，百万小时数据最后只能变成存储成本。
3. 三方合作的技术链路拆解
3.1 数据采集端：真机遥操作与动捕方案
黎曼动力、光轮智能与诺亦腾的合作，核心逻辑大概率是“真机数据 + 仿真数据 + 动捕数据”三条腿走路。诺亦腾在动捕和姿态追踪上有成熟的产品线，可以把人的动作映射到机器人本体上，这是一种高效的“示教数据”生产方式。相比纯手动示教，动捕方案能大幅提升采集效率，因为操作员可以用更自然的方式完成复杂动作。
这条链路的关键点有几个：
- 动作映射的标定精度。人体骨骼和机械臂关节的运动学结构不一致，需要做坐标系变换和关节限位保护。
- 多传感器同步。视觉、关节角、力矩、触觉的时间戳必须对齐，否则模型学到的是错位关联。
- 采集状态监控。操作员的疲劳、误操作、环境干扰都会被记录进去，需要实时或近实时的质量提示。
3.2 仿真数据：降低成本放大器
光轮智能在仿真数据上的积累，可以为这条数据线提供规模化合成数据。仿真数据能解决真机数据覆盖不足的问题——危险动作、极端场景、小样本物体交互，都可以通过仿真批量生成。
但仿真数据有两个老问题：仿真到现实的迁移（Sim-to-Real）和域随机化。单纯仿真数据训练出来的模型，在真实环境里往往要打折扣。所以百万小时数据建设大概率需要仿真数据和真机数据的混合比例设计，以及一套跨域评估机制。
比较务实的做法是：仿真数据负责广度，真机数据负责精度，动捕数据负责复杂操作行为。每一类数据都要有独立的统计口径和质检规则，不能在数据集层面简单拼接。
3.3 数据处理：从原始数据到训练集
数据采集之后是清洗、筛选、标注、增强、版本化。这个环节是百万小时数据建设里最容易被低估的部分。
数据清洗要解决的是传感器丢帧、同步错位、异常跳变、任务失败轨迹混入等问题。一条轨迹采集完成，不代表它能进入训练集。必须有自动化检查脚本结合人工抽检，给每条轨迹打上“可用/需修补/废弃”的标签。
数据标注则更复杂。具身智能数据不是简单给一张图打标签，而是要标注任务语义、物体状态、动作意图、成功与否。密集标注的成本往往不低，所以需要自动标注辅助工具，再配合人工校验，控制整体成本。
4. 百万小时数据建设的工程化架构参考
围绕这次合作的新闻，可以抽象出一套通用的具身智能数据建设架构，适合团队内部做数据平台设计时参考。
采集端（真机/动捕/仿真） ↓ 多模态原始数据回传（断点续传 + 流式同步） ↓ 数据预处理（时间戳对齐、丢帧修复、传感器校准） ↓ 数据清洗（异常检测、轨迹有效性评估、噪声剔除） ↓ 数据标注（语义标签、任务标签、质量标签） ↓ 数据仓（分区存储、版本管理、血缘追踪） ↓ 训练集构建（混合比例、抽样策略、跨域验证）4.1 原始数据回传与服务端接收
真机采集现场往往网络不稳定，数据回传通道需要考虑断点续传、校验重传和本地缓存。服务端接收模块需要支持多终端并发上传，并按照“项目/任务/时间/设备ID”分目录落盘。
这里可以做一个小型数据接收服务的配置示例，实际部署时按团队基建调整：
ingest: mode: local-first # 本地优先，支持先存后传 upload_protocol: http max_concurrent_uploads: 16 chunk_size_mb: 64 retry_count: 5 storage: root_path: /data/raw layout: "{project}/{task}/{device_id}/{date}/" checksum: sha256 validation: require_manifest: true time_sync_tolerance_ms: 104.2 数据清洗流水线
数据清洗是数据质量的第一道闸门。建议用 DAG 工作流管理，每一个采集样本都跑一遍检查项。
def validate_episode(episode: dict) -> dict: issues = [] # 检查传感器时间戳是否对齐 if not check_time_sync(episode["sensors"]): issues.append("time_sync_error") # 检查关节角是否出现跳变 if detect_joint_jump(episode["joint_states"]): issues.append("joint_state_jump") # 检查任务执行是否成功 if not episode["task_success"]: issues.append("task_failed") # 检查轨迹长度是否达标 if len(episode["steps"]) < min_steps: issues.append("too_short") episode["quality_issues"] = issues episode["quality_score"] = compute_quality_score(issues) return episode建议为每一条轨迹维护一张质量卡片，字段包括：任务 ID、设备 ID、操作员 ID、环境描述、成功标志、轨迹长度、传感器完整性、异常列表、质检结果。
4.3 数据仓建设
热搜词里有“数据仓4层建设”，这个思路同样适配具身智能数据。可以把数据仓分为四层：原始数据层、清洗数据层、标注数据层、训练集层。每一层之间用版本控制和血缘关系串起来，保证任何一条训练数据都能回溯到原始采集文件。
| 层级 | 内容 | 示例 |
|---|---|---|
| ODS 原始数据层 | 采集端原始文件 | 视频流、关节日志、触觉流 |
| CDL 清洗数据层 | 通过质检的轨迹 | 对齐修复后的多模态片段 |
| ADL 标注数据层 | 带语义标签的样本 | 任务标签 + 对象标签 + 失败标签 |
| TDL 训练集层 | 按比例发布的训练集 | 训练/验证/测试集 |
这套分层的好处是：当模型效果出现问题时，可以快速定位是哪个环节的数据有问题，而不是整个数据集推倒重来。
5. 数据质量评估体系怎么搭
百万小时数据，量级本身会掩盖很多问题。如果没有质量评估体系，最后训练出来的模型一旦出现问题，根本无从排查。
5.1 自动化质量指标
每一小时数据都应该能够自动产出质量统计。建议关注五个维度：
- 完整度：传感器流是否存在长时间缺失。
- 同步度：多模态数据时间戳最大偏差。
- 成功率：任务级成功轨迹占比。
- 多样性：场景、物体、动作类型的覆盖分布。
- 稳定性：关节力矩和末端轨迹是否存在异常抖动。
这五个维度不是评估单条轨迹，而是评估一个数据集批次。
5.2 一致性抽检
自动化指标难以覆盖语义层面的错误，所以需要人工抽检。有效方式是按批次抽检，并让抽检结果与自动化指标做相关分析。如果自动化指标显示数据完整度高，但人工抽检发现大量语义错误，说明采集协议和标注规范需要调整。
5.3 模型侧反馈闭环
数据建设的终点不是数据仓，而是模型能力的提升。所以要建立一个数据版本和模型指标的对账机制：每发布一版训练集，跑一组固定的能力评测任务，把数据版本的变化和模型指标的变化绑定起来。哪一版数据让模型退步了，要能追溯到具体的数据分区。
6. 数据规模估算与资源配置建议
百万小时数据建设，前期的资源规划就很重要。这里给一个基于公开案例的估算方法，实际规模需要根据传感器数量和数据格式调整。
假设单台设备采集一小时数据，多传感器原始数据约 150GB（多视角 RGB 视频 + 深度流 + 关节状态 + 力矩 + 触觉），经过预处理压缩清洗后有效数据约 5GB。采集 100 万小时原始数据，则对应约 15 万 TB 的原始存储，清洗后约 5 万 TB 有效数据。这还没有算中间产物、备份和多版本副本。
这个规模对任何团队来说都不小，所以数据建设不能只靠真机采集，需要仿真数据承担一部分混合比例。另一个思路是优先做高价值场景的密集数据，而不是均匀撒网采集。
资源层面建议：
- 存储：分层存储，热数据用高性能存储，冷数据用低成本归档存储。
- 算力：数据清洗和自动标注需要 GPU 集群，可以和模型训练集群共用但要做好资源隔离。
- 网络：采集端到数据中心的回传要考虑带宽限制，尽量做边缘预处理。
- 人力：数据标注管理和质检团队需要单独配置，不能从算法团队临时抽人。
7. 实际测试与验证流程参考
对于想验证自己数据建设链路的团队，可以参考下面这一套最小验证流程。这里的重点是“先跑通小规模闭环，再扩量”，避免一上来就追求数据规模。
7.1 验证环境准备
准备一台数据接收服务器、一台带 GPU 的数据清洗服务器、一台机器人或动捕设备。先不追求仿真数据和生产环境，用一小批真实数据跑通全流程。
# 数据接收服务启动示例 python data_ingest_server.py \ --host 0.0.0.0 \ --port 18080 \ --storage /data/raw \ --project test_project # 数据清洗任务示例 python data_clean_task.py \ --input /data/raw/test_project \ --output /data/clean/test_project \ --min_steps 50 \ --time_sync_tolerance_ms 107.2 小规模数据闭环测试
采集 10 到 20 条轨迹，覆盖 3 类以上任务。跑完清洗流水线，确认轨迹质检结果符合预期。重点观察清洗前后数据量的衰减比例。如果 20 条真实轨迹清洗后只剩 5 条可用，就说明采集协议或任务设计需要调整，而不是继续扩量采集。
标注环节先跑自动标注，再人工抽检，比对一致率。最后把这批数据组装成一个小训练集，跑一遍下游任务模型，观察指标能否有可测量的提升。
7.3 规模化前需要确认的指标
在决定扩量到百小时、千小时之前，先确认这几个指标是否合理：
- 采集命中率：有效轨迹数 / 总采集轨迹数。
- 清洗通过率：清洗后通过质检的数据量 / 原始数据量。
- 标注一致率：人工抽检与自动标注的标签一致比例。
- 数据版本回退率：因为质量差而需要回退的数据集版本比例。
这四个指标如果有一个不达标，扩量只会放大问题。
8. 常见问题与排查方法
结合具身智能数据建设的常见问题，整理一份排查清单。这里的问题模型同样适用于团队自建数据平台。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 采集到大量不可用轨迹 | 任务设计不明确，采集人员操作不规范 | 查看任务指令和操作日志 | 增加任务引导和采集前验证 |
| 多传感器时间戳严重错位 | 采集端时钟同步失败 | 检查时间同步服务和传感器日志 | 加入硬件同步或定期校时 |
| 清洗后数据量过少 | 质检标准过于严格或采集协议不合理 | 分析各检查项失败分布 | 调整检查阈值，优先修复采集端问题 |
| 自动标注准确率低 | 训练数据不足或任务语义定义不一致 | 抽检标注结果并做一致性统计 | 完善标注规范，增加模型训练数据 |
| 模型训练效果与数据版本不符 | 训练集混入脏数据或数据分布漂移 | 对比数据版本差异和模型指标曲线 | 回退数据版本，重新验证 |
| 数据回传带宽吃紧 | 采集端并发上传过多 | 查看网络监控和上传队列 | 增加断点续传和边缘压缩 |
| 存储成本失控 | 副本过多或没有冷热分层 | 检查存储策略和文件访问频率 | 配置生命周期管理，归档冷数据 |
9. 数据合规与安全边界
百万小时数据采集，特别是包含真实场景、操作员操作数据、可能涉及个人或环境信息的数据，必须考虑合规问题。这里单独强调，不是套话，而是这类项目最容易踩坑的部分。
真机采集数据时，如果摄像头拍到人脸、车牌、室内环境标识、敏感物品，都需要做脱敏处理。动捕数据如果来自人体动作捕捉，原则上属于生物特征相关数据，采集前必须获得明确授权，并限制使用范围。仿真数据相对风险较低，但如果仿真场景复刻了真实特定环境，也需要做审查。
数据存储和访问权限要分角色控制。训练集发布前要做内容安全扫描，确认没有包含敏感画面、个人信息和版权素材。数据建设和模型训练的日志需要留存，方便事后审计。
10. 团队如何从这次合作中拆解出可落地的方向
黎曼动力、光轮智能和诺亦腾的合作是行业头部玩家的资源组合，对中小团队和独立开发者来说，更实际的是从这次合作中提取可复用的方法论。
如果团队自建具身智能数据线，优先级建议是：先搭清洗质检，再建数据仓，最后上规模采集。很多团队把大量预算花在采集设备和算力上，却忽视了数据治理。但具身智能数据的特点是采集成本高、质量方差大、下游模型敏感，没有质量闸门，数据越多反而越难用。
对于已经在做机器人算法和模型训练的团队，可以从今天开始给每次数据采集增加三个字段：任务成功率、环境描述、操作者编号。这三个字段能在后续数据回溯时提供极大的排查效率。同时建立数据血缘关系，训练集每一批都要记录它来自哪些采集任务、清洗版本和标注版本。
下一步值得关注的方向包括：数据合成与真机数据的混合比例优化、基于具身智能数据训练的评测基准、以及面向机器人的数据版本管理工具。2026 年百万小时目标达成后，行业更需要的不是“更多数据”，而是“能解释和能复现的数据”。
