10万小时签约、月交付万小时、验收合格率超95%：真机数据开始有专门的供应商了，这才是具身智能最缺的那一环

Monday, November 02, 2026

10 万小时签约、月交付万小时、验收合格率超 95%：真机数据开始有专门的供应商了，这才是具身智能最缺的那一环

Part One：把"数据"从各家自研变成可采购的产能

2026 年 10 月 30 日，在 2026 物理 AI 与世界模型大会期间，睿尔曼智能披露了它真机数据业务的进展。数字不长，但每一个都值得停下来看：

自 2026 年 6 月进入规模化交付阶段；
累计签约订单近 10 万小时；
月交付能力达到万小时级别；
万小时以上交付量级的数据验收合格率超过 95%；
客户覆盖国内超过半数具备大规模数据采购能力的具身模型企业，覆盖第一梯队，已产生商业复购。

这几句话合起来，描述的不是一家公司接了多少单，而是一件结构性的事：具身智能的"数据"第一次出现了专门的供给层。

在此之前，真机数据的获取方式基本只有三种：

各家模型公司自建数采团队——自己买机器人、自己搭场地、自己雇遥操员。问题是重资产、慢、且每家的数据规格都不一样，无法复用。
买公开数据集——成本低，但质量参差、场景单一、缺乏闭环质控，而且通常不含力反馈、关节状态这类本体信息。
用仿真数据补充——便宜、可无限生成，但 sim-to-real gap 一直是硬伤（这也是为什么智元的 Genie Sim 那 96.7% 的一致性指标值得单独写一篇）。

而"可采购的、带质控闭环的、真实作业场景产生的、多模态对齐的真机数据"，此前几乎是空白。 睿尔曼做的事，本质上是把这件事工业化——把数据采集从"每家模型公司的成本中心"，变成"可以按月下单、按小时计价的产能"。

这个转变的意义，用一句话概括：具身智能的瓶颈正在从"模型不够强"转向"数据不够真"，而后者第一次有了市场化的解法。

Part Two：GLN 远程劳动力网络——为什么"遥操"比"示教"值钱

这套体系的核心，是一个叫 GLN（远程劳动力网络） 的东西。它让遥操人员可以跨地域调度分布在一线点位的机器人，在真实业务任务中同步采集多模态真机数据。

落地上，是在常州具身智能数据实验平台搭建了"集中遥控调度 + 分布式真机作业“的一体化数采架构。机器人在超过 1000 种真实作业任务中运行，场景横跨工厂产线、仓储物流、商业服务、家庭康养。

这里有一个关键区别，报道里点得很准：“不同于仅做标准化示教的采集方案，这里的数据不是为了录样而刻意编排，而是机器人完成真实作业时自然生成的原生记录。”

为什么这个区别这么重要？用代码算一下就能看出来：

# 标准化示教数据 vs 真实作业数据的"分布覆盖"差异
def coverage_analysis():
    """
    假设一个抓取任务有若干影响成功率的因素，
    每个因素有若干个取值。
    """
    factors = {
        "工件偏差": ["居中", "偏左", "偏右", "倾斜5°", "倾斜15°"],
        "物料摆放": ["整齐", "杂乱", "堆叠", "半遮挡"],
        "光照条件": ["标准", "强光", "弱光", "侧光", "频闪"],
        "环境干扰": ["无", "人员经过", "设备振动", "线缆缠绕"],
    }

    # 标准化示教：通常只覆盖"理想组合"
    demo_combos = 1 * 1 * 1 * 1  # 只录最规整的那一种

    # 真实作业：各因素随机组合
    total_combos = 1
    for k, v in factors.items():
        total_combos *= len(v)

    return {
        "因素数": len(factors),
        "组合总数": total_combos,
        "示教覆盖": demo_combos,
        "示教覆盖率": f"{demo_combos/total_combos:.2%}",
    }

for k, v in coverage_analysis().items():
    print(f"  {k:12s} {v}")

四类因素、组合空间上百种，而标准化示教只覆盖其中一种。 这就是为什么"在实验室锤炼上万次、到了货架前还是摔瓶子”——因为模型学到的是"理想世界"的分布，而真实世界是长尾的。

真实作业数据的价值，恰恰在于它天然覆盖了长尾。 遥操员在远程操作机器人干活时，机器人不可避免地要处理：工件偏差、物料杂乱、光照波动、环境干扰。这些"麻烦"不是数据采集的噪音，而是数据采集的目的。 一台机器人在真实产线上班 8 小时，产出的数据分布，比在实验室精心编排 8 小时要丰富得多。

而"集中遥控调度 + 分布式作业"这个架构，解决的是另一个现实问题：成本。

# 集中调度 vs 分散自建的成本对比（示意模型）
def cost_model(robots=100, hours_per_day=8, days=250,
               operator_ratio=0.25, operator_monthly=12000):
    """
    robots: 机器人数
    operator_ratio: 每个遥操员可同时照看的机器人数（分布式场景下可批量调度）
    """
    # 自建模式：一个遥操员盯一台
    self_built_operators = robots
    # 网络调度模式：一人可轮转照看多台（非全程 1:1）
    network_operators = int(robots * operator_ratio)

    annual_self = self_built_operators * operator_monthly * 12
    annual_net = network_operators * operator_monthly * 12
    hours = robots * hours_per_day * days

    return {
        "年采集小时": f"{hours:,}",
        "自建人力成本": f"{annual_self/1e4:.0f} 万元",
        "网络调度人力成本": f"{annual_net/1e4:.0f} 万元",
        "单小时人力成本（自建）": f"{annual_self/hours:.0f} 元",
        "单小时人力成本（网络）": f"{annual_net/hours:.0f} 元",
    }

for k, v in cost_model().items():
    print(f"  {k:22s} {v}")

这个模型是示意，但它揭示了 GLN 的经济逻辑：遥操是人力密集型工作，而"集中调度"让一个人不必绑定一台机器——机器人分布在多个城市的一线场景，调度端统一排班、轮转操作、按任务类型分派。这本质上是用"调度软件"把分散的、碎片化的机器人作业时间，聚合成一条连续的产能。

这也是为什么它敢说"月交付万小时"——万小时不是靠堆人堆出来的，是靠把已有的机器人作业时间组织起来。

Part Three：数据规格——多模态对齐到底对齐了什么

报道里有一句容易被跳过的话：采集内容包含"机器人关节状态、力反馈、视觉图像、时空时间戳等完整本体信息"。

这句话的技术含量，比"1000 种任务"更高。因为多模态对齐是具身数据里最容易出问题、也最难补救的一环。

# 多模态真机数据的典型规格与对齐要求
def data_spec():
    return {
        "关节状态": {
            "典型频率": "100-1000 Hz",
            "内容": "各关节角度/速度/力矩",
            "对齐难点": "高频，需与视觉帧严格插值对齐",
        },
        "力反馈": {
            "典型频率": "500-1000 Hz",
            "内容": "末端六维力/力矩",
            "对齐难点": "延迟敏感，接触瞬间的力峰必须精确落在对应帧",
        },
        "视觉图像": {
            "典型频率": "30-60 Hz",
            "内容": "多路相机（头部/腕部/第三人称）",
            "对齐难点": "多路相机之间需硬件同步，否则视差会污染策略",
        },
        "时空时间戳": {
            "典型频率": "每帧",
            "内容": "统一时基的采集时刻",
            "对齐难点": "时钟漂移、丢帧、跨设备时基不一致",
        },
    }

for modality, spec in data_spec().items():
    print(f"\n【{modality}】")
    for k, v in spec.items():
        print(f"  {k:8s} {v}")

为什么对齐这么要命？ 因为具身模型学的是"状态 → 动作"的映射。如果视觉帧和关节状态差了 30 毫秒，模型学到的就是"看到旧画面，做出新动作"——这个错误在训练 loss 上几乎看不出来（因为数值上仍然相关），但部署到真机上就是系统性偏移。

而力反馈的对齐要求更苛刻：接触瞬间的力峰往往只有几十毫秒，如果力信号和视觉帧错位，模型就学不会"什么时候该松手"。这类错误在仿真里几乎不可能被发现，因为仿真里一切都是完美同步的。

# 时间戳校验：丢帧与漂移的检测逻辑
def validate_timestamps(ts_list, expected_hz, tolerance_ms=2.0):
    """
    ts_list: 时间戳列表（毫秒）
    expected_hz: 期望采样频率
    tolerance_ms: 允许的间隔误差
    """
    nominal = 1000.0 / expected_hz
    dropped, drift, ok = 0, 0, 0

    for i in range(1, len(ts_list)):
        gap = ts_list[i] - ts_list[i - 1]
        if gap > nominal * 1.5:
            dropped += 1          # 丢帧
        elif abs(gap - nominal) > tolerance_ms:
            drift += 1            # 时钟漂移或抖动
        else:
            ok += 1

    total = len(ts_list) - 1
    return {
        "总间隔": total,
        "正常": f"{ok} ({ok/total:.1%})",
        "丢帧": f"{dropped} ({dropped/total:.1%})",
        "漂移/抖动": f"{drift} ({drift/total:.1%})",
        "判定": "通过" if dropped / total < 0.01 and drift / total < 0.05 else "隔离返工",
    }

# 模拟一段 100Hz、10 秒的数据，含 3 次丢帧和若干抖动
import random
random.seed(42)
ts = [0.0]
for _ in range(1000):
    gap = 10.0
    r = random.random()
    if r < 0.003:
        gap *= 2          # 丢一帧
    elif r < 0.08:
        gap += random.uniform(0.5, 3.5)  # 抖动
    ts.append(ts[-1] + gap)

for k, v in validate_timestamps(ts, 100).items():
    print(f"  {k:10s} {v}")

这段代码不是复现他们的实现，而是说明**“质量闭环"这件事在工程上到底长什么样**：它不是一句"我们做了质控”，而是一整套可执行的检查规则——采样频率校验、时间戳完整性校验、丢帧检测、多模态时空对齐。每一条都要写代码、设阈值、跑批处理，然后对不合格样本执行隔离、返工、重采，并完整留存处理记录。

Part Four：六环节闭环与"95% 合格率"到底怎么定义

睿尔曼的质控体系覆盖六个环节：采集准备、原始记录、格式转换、语义标注、数据集交付、模型验证。

# 六环节闭环：每个环节的失败模式与拦截手段
def six_stage_pipeline():
    stages = [
        ("采集准备", "场地/标定/设备状态不一致", "标定校验、设备自检"),
        ("原始记录", "丢帧、时钟漂移、多路相机不同步", "时间戳校验、硬件同步"),
        ("格式转换", "单位不统一、坐标系混乱", "schema 校验、单位归一"),
        ("语义标注", "标注与动作不对齐、类别错误", "抽检复核、一致性比对"),
        ("数据集交付", "版本混乱、缺元数据", "版本锁定、元数据清单"),
        ("模型验证", "数据能用但训不出效果", "下游训练回归、效果对比"),
    ]
    return stages

print(f"{'环节':<10} {'失败模式':<28} {'拦截手段'}")
print("-" * 72)
for stage, failure, guard in six_stage_pipeline():
    print(f"{stage:<10} {failure:<28} {guard}")

六个环节里，最后两个最容易被低估。

“数据集交付"看起来只是打包，但实际上决定了数据能不能被复用：版本是否锁定、元数据是否完整（任务类型、场景、机器人型号、采集参数、质控结果）、有没有变更记录。 一份没有元数据的 100 小时数据，对模型团队来说价值可能不到一半——因为你不知道它能用来干什么，也不知道它和已有数据是否重复。

“模型验证"则是唯一一个把"数据质量"和"模型效果"连起来的环节。前五个环节都是"数据自身是否合规”，只有这一个在问：“这批数据训进去，模型真的变好了吗？“这是最难、也最贵的一步——因为它需要跑完整训练回归。

而”万小时以上交付量级验收合格率超 95%“这个数字，恰恰是这套闭环的产出指标。但这里必须提醒一句：“合格率"的定义决定了这个数字的分量。

# "95% 合格率"的三种可能口径，含义差异巨大
def pass_rate_framings():
    return {
        "口径A：样本级合格率": {
            "定义": "单条数据（一段轨迹）通过全部检查的比例",
            "严苛度": "最高",
            "含义": "每一段轨迹都经得起检验",
        },
        "口径B：批次级合格率": {
            "定义": "整个交付批次一次性通过验收的比例",
            "严苛度": "中等",
            "含义": "少数坏样本不影响整批交付",
        },
        "口径C：小时级合格率": {
            "定义": "按小时计费中，被客户确认可用的小时占比",
            "严苛度": "偏低",
            "含义": "返工后重采的小时不计入分母",
        },
    }

for name, d in pass_rate_framings().items():
    print(f"\n{name}")
    for k, v in d.items():
        print(f"  {k}: {v}")

print("\n注：公开信息未披露采用哪种口径，95% 的实际含义需以官方口径为准。")

这不是挑刺，而是必要的谨慎。 在数据交付这种业务里，“合格率"是核心商务指标——它直接决定返工成本、客户信任和复购。同一个 95%，在三种口径下对应的实际质量可以差出一个数量级。任何引用这个数字的分析，都应该标注口径未知。

Part Five：为什么做数据业务的公司，必须先有硬件

有一个容易被忽略的细节：睿尔曼的硬件是自研 RealBOT 系列机器人，搭载车规级关节模组，通过 CR L3 级可靠性认证，平均无故障运行时间（MTBF）达到 5 万小时。

这三个数字，是数据业务能成立的前提，不是可选项：

# 为什么 MTBF 直接决定数据业务的可行性
def mtbf_impact(mtbf_hours=50000, robots=100, hours_per_day=8):
    """
    计算在给定 MTBF 下，每天预期的故障次数
    """
    daily_robot_hours = robots * hours_per_day
    failures_per_day = daily_robot_hours / mtbf_hours
    # 每次故障需要停机、排查、修复，假设平均 4 小时
    downtime_per_failure = 4
    downtime_hours = failures_per_day * downtime_per_failure

    return {
        "每日机器人总工时": f"{daily_robot_hours} h",
        "MTBF": f"{mtbf_hours:,} h",
        "每日预期故障次数": f"{failures_per_day:.2f}",
        "每日停机工时": f"{downtime_hours:.1f} h",
        "可用率": f"{1 - downtime_hours/daily_robot_hours:.2%}",
    }

for k, v in mtbf_impact().items():
    print(f"  {k:18s} {v}")

# 对照：如果 MTBF 只有 5000 小时（消费级水平）
print("\n对照 MTBF = 5,000 h（消费级）:")
for k, v in mtbf_impact(mtbf_hours=5000).items():
    print(f"  {k:18s} {v}")

这张表说明了一件事：数据业务的商业模式，本质上是"用机器人时长换数据小时”。 如果机器人天天坏，你交付的不是数据，是维修记录。MTBF 从 5000 小时提到 5 万小时，可用率从七成多提到九成七——这不是硬件指标的改善，这是商业模式的成立条件。

而"车规级关节模组"和"CR L3 级可靠性认证"这两个表述，指向的是同一件事：这套硬件不是实验室原型，是按工业设备的可靠性标准设计的。 这也解释了为什么睿尔曼起家于超轻量仿人机械臂（它的老本行），而不是从模型公司转型——数据生意的护城河，一半在软件（质控闭环），一半在硬件（能连续跑）。

Part Six：客户覆盖超半数——数据层的议价权与锁定

“服务国内超过半数具备大规模数据采购能力的具身模型企业，客户覆盖国内第一梯队，并已产生商业复购。”

这句话里有三个信息点，分开看：

第一，“超过半数"限定了分母——“具备大规模数据采购能力的"企业。 这个限定很聪明：它不是说"服务了国内一半的机器人公司”（那不可能，因为大部分公司还买不起数据），而是说"在真正会花钱买数据的客户群里，覆盖过半”。这个口径既诚实，又有说服力。

第二，“第一梯队"意味着客户质量。 具身模型的第一梯队公司，对数据规格、质控标准、交付周期的要求是最苛刻的。能进这个名单，本身就是一种能力背书。

第三，也是最关键的：“已产生商业复购”。 这是整个披露里最有含金量的一句。

# 数据业务的单位经济：为什么复购是生死线
def unit_economics(hours_per_batch=1000, price_per_hour=200,
                   cost_per_hour=140, rework_rate=0.05):
    """
    price_per_hour: 售价（元/小时）
    cost_per_hour: 采集+质控成本（元/小时）
    rework_rate: 返工率
    """
    revenue = hours_per_batch * price_per_hour
    effective_cost = hours_per_batch * cost_per_hour * (1 + rework_rate)
    gross = revenue - effective_cost
    margin = gross / revenue

    # 复购假设：同一客户第二年订单量增长 50%
    year2_hours = hours_per_batch * 1.5
    year2_gross = year2_hours * (price_per_hour - cost_per_hour * (1 + rework_rate))

    return {
        "首批收入": f"{revenue/1e4:.1f} 万元",
        "首批毛利": f"{gross/1e4:.1f} 万元",
        "毛利率": f"{margin:.1%}",
        "复购后毛利": f"{year2_gross/1e4:.1f} 万元",
        "复购增量": f"{(year2_gross-gross)/1e4:.1f} 万元",
    }

for k, v in unit_economics().items():
    print(f"  {k:12s} {v}")

这个模型是示意（真实价格与成本未公开），但它揭示了数据业务的核心特征：首单只是入场券，复购才是利润来源。

为什么？因为数据交付有一个隐性的"前期成本”——客户要花时间跟你对齐规格、建立信任、验证质量。 这个成本在首单最重，复购时几乎归零。所以：

没有复购的数据供应商，永远在付"客户获取成本”，毛利被吃掉；
有复购的供应商，边际成本递减，因为规格已对齐、流程已磨合、质控标准已成共识。

更重要的是，复购意味着"锁定”：一旦模型公司的训练管线建立在这套数据规格上（元数据格式、标注规范、时间对齐标准），换供应商的成本就很高——不是钱的问题，是管线要重写。这就是为什么"已产生商业复购"这句话，比"10 万小时签约"更能说明这门生意的质地。

Part Seven：判断与边界

第一，这件事的意义不在睿尔曼本身，而在"数据供给层"的出现。 任何一个产业走向成熟，都会经历"核心投入品从自给自足到专业化分工"的过程——就像云计算把服务器运维从每家公司自建变成按需购买。具身智能的真机数据，正在走这条路。 一旦数据可以按月采购，模型公司的竞争重心就会从"谁能搞到数据"转向"谁能用好数据”——这对整个行业是好事。

第二，“真实作业数据 > 实验室示教数据"这个判断，值得所有做具身的人重新审视自己的数据策略。 实验室数据的问题是分布太窄：精心编排的场景、理想的物料摆放、稳定的光照。而模型部署到真实环境，面对的恰恰是长尾。睿尔曼的 1000 种任务、四类场景，本质上是在用"真实世界的脏"来对冲"实验室的干净”。 这个思路不新，但把它做成可交付的产能，是新的。

第三，硬件的可靠性指标是这门生意的隐形地基。 MTBF 5 万小时、车规级关节、CR L3 认证——这些看起来是硬件公司的宣传语，实际上是数据业务的成本结构决定项。任何想做"数据即服务"的团队，如果机器人天天坏，商业模型直接不成立。 这也解释了为什么数据供应商往往从硬件公司长出来，而不是从模型公司长出来。

第四，95% 这个数字必须带口径读。 前面已经拆过三种可能的口径（样本级/批次级/小时级），含义差异巨大。在没有官方口径说明的情况下，把它当成"质量很高"的定性信号可以，当成"精确的良率"就过度了。 这不是苛责，而是数据交付这个行业的常识——合格率的定义，本身就是商务谈判的一部分。

第五，也是最重要的一条：数据供给层出现之后，具身智能的瓶颈会转移。 现在最缺的是"真、多、对齐好"的数据；一旦数据变得可采购，瓶颈就会转向**“怎么用有限的数据训出泛化能力”**——也就是数据效率、世界模型、仿真增强这些方向。换句话说，睿尔曼这类公司的成功，会加速"数据不再是瓶颈"那一天的到来，然后它们自己也要面对"客户不再需要那么多数据"的问题。 这是所有供给层生意的宿命，也是它们必须往"数据+工具+评测"综合服务走的原因。

最后给一个可跟踪的观察框架：判断这条线是否真的成立，别只看签约小时数，看四个数——① 复购客户的订单占比（新客 vs 老客的结构，比总量更能说明质地）；② 单小时价格的走势（降价说明供给过剩，涨价说明质控有溢价）；③ 交付周期（从下单到验收的天数，这是产能弹性的真实度量）；④ 客户拿这批数据训出来的模型，在下游 benchmark 上的提升幅度（这是数据价值的最终证明，也是最难拿到的数字）。

来源：科技日报《这家企业靶向物理 AI 高质量数据供给》（2026-10-30，记者罗云鹏）；网易智能/新浪财经《睿尔曼智能真机数据签约近 10 万小时，月交付能力达万小时级》（2026-10-30）；2026 物理 AI 与世界模型大会相关披露。文中数据量换算、成本模型、时间戳校验逻辑、合格率口径分析、单位经济模型、MTBF 影响测算均为基于公开信息的推演与示意，非官方数据；“95% 合格率"的具体统计口径未公开，引用时请注意口径未知这一前提。