作者:hsj
https://zhuanlan.zhihu.com/p/2023447662066762473
机器人不缺数据,缺的是把数据变成能力的结构

一、一个显而易见的问题,做了几年还是没解
Joe Harris 前阵子发了条推文,说机器人行业根本不缺数据,每家部署超过半年的公司都有 TB 级传感器日志躺在 S3 里,真正缺的是把这些数据变得可用的基础设施。
他倒也没说错:基础模型团队花几百万美元从头造仿真数据,隔壁部署团队的硬盘里却全是真实世界录下来的日志,最后两边像活在两个平行宇宙里,谁也没有真正把对方手里的东西用起来。
不过这个方向其实早就有人在做了。Foxglove 拿了 4000 万美元 B 轮,Rerun 拿了 1700 万美元 seed,Scale AI 也专门开了 embodied AI 产品线。钱砸下去了,人也不算少,行业却还是在喊缺数据。一个看上去这么显而易见的工程问题,在资本和人才都不缺的前提下做了几年还是没解,比较合理的怀疑只能是:问题本身就搞错了。
今天我们聊聊数据问题,大家都在说缺数据,但是真的只是缺数据吗?能不能再精准一点呢?
这有点像你拍了几万小时的飞行录像,然后困惑为什么看了这么多录像还是造不出飞机。也许问题从一开始就不在录像不够多。
二、第一层:「我们缺数据」
行业最表层的叙事一直都很稳定。每次 robotics 的进展不及预期,第一反应几乎都是数据不够。基础模型团队花大钱搞仿真和遥操作采集,部署中的机器人每天产生 IMU、相机、激光雷达、关节状态日志,全躺在存储桶里发霉。表面上看,这当然像是一个典型的供需错配。
先说在前面:熟悉我的朋友都知道,我不是 scaling law 的信徒。我不认为它能在任何场景下都无条件生效。但我也承认,数据量和模型规模的增长确实在很多领域兑现了真实效果,这一点没什么好否认的。所以更值得追问的是:robotics 里的 scaling,到底在沿着哪个变量扩展,又在哪里开始失灵。这才是我们需要关心的问题。
如果带着这个问题去看那些真正推着机器人基础模型往前的结果,答案其实已经开始浮现:驱动进步的,并不像「只是缺数据」那么简单。
RT-2 是一个很好的例子。它的动作数据只来自 13 台机器人、17 个月、一间 office kitchen,听起来并不算多。真正让它上了一个台阶的,恰恰是接入了互联网规模的视觉语言预训练,跟机器人动作数据的增量关系不大。
DeepMind 官方博客写得很清楚:RT-2 用的是 web 预训练的视觉语言模型,再结合 RT-1 的机器人示范数据。换句话说,RT-2 的成功更像是「互联网语义先验加有限机器人动作数据」的联合产物,很难被简单归结为「只要继续多收机器人数据,能力就会持续上升」的案例。
Open X-Embodiment 把这件事又往前推了一步。22 种机器人、500 多种技能、超过 100 万个 episode 被汇到一起训练,结果当然是好的:RT-1-X 比各家原始模型平均高了 50%,RT-2-X 在全新技能上的成功率是 RT-2 的三倍。
但你仔细看它给出的证据,依然会发现关键不在于「总量继续变大」本身,而在于跨 embodiment、跨任务、跨环境的数据多样性终于开始产生迁移效应。这里出现的不是 LLM 那种 token 翻倍、loss 平滑下降的 scaling,更像是训练分布跨过某个门槛之后,模型突然拿到了一种以前没有的泛化能力。
Re-Mix 则进一步印证了这个直觉。斯坦福的 Dorsa Sadigh 团队在 2024 年的 Re-Mix 论文里用 Open X-Embodiment 检验数据混合策略,最后发现学出来的 domain weight 比均匀混合高 38%,比人工挑的权重还高 32%。
如果问题真的只是「数据还不够多」,这种差异不应该这么大。它之所以这么大,正好印证了一件事:决定结果的,更多是这些数据以什么比例进入模型、落在什么训练结构里、最终让模型学到了什么。
如果借用我之前写 Epiplexity 时用过的视角,这里的关键其实在于「数据里到底有多少结构,能被当前这个学习系统提取、重用、迁移」。同样是一堆日志,随机噪声再多,也未必比一个组织良好的失败案例更有价值;
同样是一段轨迹,能不能被模型吸收,不只取决于它是不是真实世界采来的,还取决于它有没有把任务结构、环境差异和动作约束以一种可学习的方式呈现出来。这样回头看,所谓数据的语义结构,说到底就是数据里那些对当前学习者来说真正可学的部分。
仿真更像一个反向证据。因为不少人每次听到「缺数据」,第一个条件反射几乎都是:那就用 Isaac Sim 无限生成。Figure 确实在用仿真训人形步态,NVIDIA 也在用 Isaac Sim 和 Cosmos 做稀有场景和数据增强,但所有顶级团队最后回到的表述都是 real-to-real workflow:先有真实数据,再由世界模型去扩展。如果堆量这件事本身就够,无限仿真早该把通用机器人往前推一大截了。但很显然,它没有。
所以回头看,迄今为止最成功的几个机器人基础模型,关键变量都落在**「这些数据到底是什么结构」上,远比「有多少数据」重要得多**。
「缺数据」这三个字,把一个结构性问题简化成了一个数量问题。
三、第二层:「数据够了,只是不可用」
Joe Harris 给出的修正比第一层聪明。格式不统一、没标注、不可检索、schema 不兼容,所以没人能用。这听起来像个 data engineering 问题,理论上应该能解。
也确实有人在解。但只要把这个领域稍微拆开看一下,你就会发现 Joe Harris 其实也只看到了最外面的几层。
最外层是观测和调试。Foxglove、Rerun 做的事,就是让工程师能看见机器人到底在干嘛。Foxglove 给 Slip Robotics 做的案例很典型:过去工程师要从 AWS 下载 ROS bag、写脚本抽数据、手动拼日志,拿到正确数据十分钟起步,跨工具 debug 动辄几小时。
接了 Foxglove 之后,原来几小时的事情,几分钟就能做完。Rerun 也已经开始从可视化工具向数据平台延伸,LeRobot、Meta 的 Project Aria 都在用。让数据可见,让调试不再像考古,这层需求是真的,客户也愿意付钱。但它解决的,归根结底只是最外层的问题:你终于看见了。
再往里一层是数据目录和检索。很多时候你不是看不见数据,而是在几百 TB 的日志里根本找不到最有价值的那一段:到底什么时候出错了,出错前后传感器状态怎么变,哪一次 intervention 跟过去那次最像。
没有目录,没有索引,没有统一 schema,所谓「数据存在」,很多时候只是物理意义上的存在,而不是工程意义上的存在。但这一层解决的,也无非是你终于把东西找出来了。
再往里是标注和供给。Scale AI 的 embodied AI 产品线做的就是这件事:bespoke datasets、跨 embodiment 标注、petabyte-scale deliveries。本质上是把自动驾驶时代那套数据 foundry 能力迁移到 robotics。
它处理的是另一类问题:不是数据在哪里,而是哪些数据能进训练,进训练之前又要怎么被切分、被标注、被组织。但这一层再完整,也还只是把杂乱的数据整理成能被训练体系消化的原料。
真正卡脖子的,是最里面那层:评测与训练闭环。定义什么算失败,怎么把长尾 case 筛出来重放,怎么拿历史 intervention 做 counterfactual evaluation,怎么根据评测结果调整下一轮训练配方。这一层一旦缺了,前面三层做得再漂亮,也只是把数据从「看不见」变成了「看得见但改不动模型」。
所以 Joe Harris 看到的当然不是假问题,Foxglove 和 Rerun 解的也当然是真需求,只是它们共同碰到的都还是入口。Covariant、1X、PI 这些头部公司之所以都在自己建系统、不买现成的,原因也在这里:第四层嵌入在模型训练最核心的位置,没法外包。越往里越值钱,也越不可能被通用平台吃掉。
Joe Harris 说对了一半。他看到的是问题的入口,不是问题最深的那一层。
四、数据可用了,然后呢?
说到这里,很多人会自然反问一句:好,就算 Joe Harris 只看到了入口,那些真实部署数据本身总归是值钱的吧。答案是,是,而且有时候非常值钱。问题不在于真实部署数据有没有价值,问题在于它在什么条件下才能转化成模型能力,又在什么地方会突然失效。
Covariant 是最像「部署数据飞轮」正面教材的公司。它几乎把这件事写在自己脸上:RFM-1 训练自最大的真实世界 robotics dataset,系统通过 fleet learning 持续从所有已连接机器人身上学习。
它给客户讲的故事也非常完整。机器人上线,持续运行,失败案例被回灌,模型越用越好。这套逻辑之所以站得住,恰恰因为它服务的是仓储拣选这种高重复、强反馈、评价标准极其清晰的任务。一个箱子抓到了没有,一个包裹分对了没有,一小时处理了多少件,人工介入率是多少,这些东西都能被直接测量。
Capacity 的 putwall 案例里,最高 515 PPH、人工介入低于 0.1% 这种指标之所以有说服力,恰恰是因为这个场景天生允许你把成败切割得很清楚。
Figure 在 BMW Spartanburg 的项目也说明了同一件事。11 个月、9 万多次零件装载、1250 多小时运行、120 多万步机器人步数,这些数字当然很重要,但真正重要的是它背后的组织方式。Figure 明确说每一次 intervention log 都进入了后续设计和验证流程。
注意这里的关键词是「进入流程」,光有记录远远不够。很多公司也能记录海量数据,但记录和可用之间差的恰恰就是这一整套把失败样本摘出来、回放、对照、再训练的机制。Figure 强的不是它有日志,而是它已经开始把日志变成资产。
1X 更进一步,甚至把这件事说得相当直白。Redwood 页面写 NEO 会从 real-world experience 中学习,世界模型页面则更明确:production 里出现的长尾场景和失败模式可以被专门整理进评测流程;world model 的准确率会随着 autonomous policy rollouts 的增加而提升。
很多人一看到这里就容易得出一个很顺手的结论:你看,最后还是谁部署得多谁赢,谁拿到真实数据谁赢。问题是,1X 自己给出的技术细节恰好在反对这种简化理解。它的系统并不是把家庭部署数据一股脑灌进模型里就起效了,而是要经过 14B 视频生成基础模型、900 小时第一人称人类视频的 mid-training、70 小时机器人数据的 embodiment fine-tuning、再加上 400 小时未过滤数据训练 inverse dynamics model 这一整套复杂 recipe。
也就是说,真实部署数据当然重要,但它从来不是裸奔进入模型的。它要先被转换,被切分,被加权,被纳入一个更大的训练结构里,最后才有可能转化成能力。
这也是为什么 Tesla 反而是一个特别有意思的反例。外界最容易想象成「数据优势最大」的公司就是 Tesla,因为它有海量车端视频、有成熟的 AI infra,也有非常强的自动驾驶叙事惯性。按很多人的直觉,这家公司理应最能证明「谁有真实数据谁赢」。
但截至目前,公开材料能支持的结论依然相当有限。Tesla 当然拥有潜在的数据优势和基础设施优势,但「潜在优势」和「已经兑现为 Optimus 的可量化模型能力」不是一回事。至少到今天,你还看不到类似 Covariant 在仓储里那样清晰、可复验、可比较的闭环证据。
这恰好说明了一件事:真实世界数据可以是强资产,但它不是自动生效的资产。数据多,不等于能力会按比例产生。
把这些案例放在一起看,会看到一个非常稳定的规律。部署数据飞轮并不是假的,它只是比想象中苛刻得多。它通常只在几种条件同时满足时才会真正转起来:任务边界足够窄,成功与失败有清晰标签,失败样本能被及时筛出来,评测基础设施能把新模型和旧失败案例做稳定对照,训练体系又允许这些信息被持续纳入下一轮更新。少了任何一个环节,所谓「数据飞轮」都很容易退化成「日志越攒越多,团队越看越累」。
Re-Mix 和 π0.5 这样的结果之所以特别关键,也在于此。它们把一个很多工程师靠经验才能感觉到的事实,第一次比较系统地摆到了台面上:决定结果的,并不只是你有多少数据,而是这些数据以什么比例混合、落在什么训练分布里、通过什么 recipe 被吸收。
Re-Mix 发现学出来的 domain weight 比均匀混合高 38%,比人工挑选还高 32%,这已经不是边角优化了,这是在直接告诉你,错误地混数据,本身就可能比缺数据更糟。
π0.5 也指向同一个方向。训练环境从 3 个扩到 104 个,性能会涨;但一旦你把完整 co-training recipe 拆开,只留下某一个局部,效果就会明显下降。驱动结果的从来不是某一个孤立变量,而是异构数据源、语义子任务、视觉语言先验、低层动作学习共同组成的结构。
所以问题到了这里,已经和 Joe Harris 原来那条推文不在同一个平面上了。他说的是「数据在那里,只是不可用」。真正更接近现实的说法是**:数据在那里,即便你把它变得可访问、可检索、可调试,它也依然未必是有效训练信号**。因为从原始传感器流到可泛化控制能力,中间隔着 recipe,隔着评测,隔着任务结构,隔着一整套尚未标准化的抽象过程。
这也就是我用「飞行录像」这个类比的原因。你拍一万小时的鸟在飞、飞机在飞、纸飞机在飞,当然不是完全没用。你可以从中看出姿态变化,看出风对轨迹的影响,看出一些失败模式。
但这些录像本身并不包含升力公式,不包含翼型设计的取舍逻辑,也不包含遇到湍流时该怎么调整控制策略。录像忠实记录了「发生过什么」,却不自动告诉你「为什么发生」以及「怎样让它在另一个环境里依然发生」。机器人今天面对的,就是这个问题。
数据可用只是起点,从可用到可学、从可学到可迁移、从可迁移到可执行,中间每一步都有自己的门槛。
五、哪怕 recipe 对了,物理世界还有自己的墙
但问题还没完。就算你把数据找到了,整理好了,也用一套像样的 recipe 喂进模型,物理世界依然还有几堵语言模型从来没有真正撞过的墙。这些墙不是今天才被看见的。它们在学术界已经隐约出现了好几年,而最能说明这一点的,恰恰是 Physical Intelligence 这家公司本身的存在。
PI 的两位联合创始人 Sergey Levine 和 Chelsea Finn,一个在 Berkeley,一个在 Stanford,都是机器人学习领域比较早系统性撞上这些墙的人。他们在 2024 年创办 PI,本身就是带着多年学术积累下场。
换句话说,你今天在 PI 看到的很多工程判断,这些线索的生产者自己把认知带进了工业实践。在那之后,他们仍然在学术和工业两条线上同时输出,这也是为什么下面提到的几项工作,虽然发表时间在 PI 成立之后,但反映的其实是同一批人对同一类瓶颈持续逼近的过程。
Levine 的研究路线最早把问题推向了评测。他参与的 AutoEval(2025)为什么重要,在于它直指了一个很少被行业正面承认的尴尬现实:generalist robot policy 越来越广,你需要覆盖的环境就越来越多,结果是你连「模型到底有没有进步」都越来越难判断。LLM 至少还有相对稳定的 benchmark,有 offline evaluation,可以在大规模基准上先跑一遍再说。
机器人不是。你得把它扔回真实环境里,让它真的去抓、去放、去开抽屉、去避障,你才知道它到底行不行。而一旦评测本身不稳定,训练就很容易滑向一种非常危险的状态:大家不断收更多数据、堆更大模型、加更多后训练技巧,但没有谁能非常确信这些改动究竟是在提升能力,还是只是在碰巧适配了某一小块环境。
这里其实还藏着一个比评测更底层的差异。语言模型预测错一个 token,后面的世界并不会因此改变;机器人动作错一次,下一秒面对的已经不是原来的世界了。姿态偏了,接触关系变了,夹爪打滑了,玻璃甚至可能已经碎了,后面的每一步都只能在这个被自己改写过的新现实里继续做决定。
换句话说,录像提供给你的只是已经发生过的开环轨迹,而控制真正要解决的却是一个会被自己动作不断改写的闭环世界。为什么 robotics 比 LLM 更依赖在线评测、在线修正和真实部署,底色就在这里。
Finn 的研究路线则把问题推向了世界变异性。她在 2025 年 9 月的 Stanford Report 采访里说过一句很直白的话,「we can’t yet cook shrimp in any kitchen」,我觉得比很多长篇论文都更准确。它一针见血地点破了 embodied intelligence 和 digital intelligence 的根本差异。
语言模型之所以能 scale,很大程度上是因为语言虽然复杂,但它的统计规律在不同语境之间是相通的。你在一个语料库里学到的语法和语义结构,拿到另一个语料库里通常仍然成立。
物理世界不一样。你家厨房和我家厨房,台面高度可能不一样,抽屉阻尼不一样,锅铲摆放位置不一样,摩擦系数不一样,光照不一样,甚至虾本身的大小和湿度都不一样。你在一个厨房里学会的东西,不会自动迁移到另一个厨房。
Finn 做 DROID,就是为了尽可能把这种世界变异性系统地纳入训练分布,跟日志数量本身无关。她真正焦虑的从来不是录像不够多,而是变化性远超覆盖。
而且变的还不只是环境。很多时候,连执行这个任务的“身体”本身都不稳定。不同机器人的形态不同,同一类机器人在执行器刚度、减速器背隙、传感器噪声分布上也会有差异,甚至同一台机器在长时间运行之后,状态都会逐渐偏移。
你以为自己在学「一个动作」,其实常常是在学「某一种身体在某一种环境里做出这个动作」的方法。很多录像之所以会制造一种错觉,让人觉得自己已经看懂了任务结构,可一旦换了机体、换了场景、换了接触条件,能力立刻就失效。
PI 把这两类学术问题进一步工程化之后,问题就又进了一步。它不再停留在「泛化」这种大词上,而是直接把配方之后的难点拆成记忆、精度、在线适应这些更具体、更残酷的局部瓶颈。Memory 项目说得很明白,当单个 motor skill 逐渐变稳之后,真正卡住系统的往往不再是这个 skill 本身,而是机器人怎么把多个 skill 衔接起来,维持一个长时程任务的执行连贯性,在中途失败之后改变策略而不是傻傻重试。
RLT 关注的则是另一个特别典型的现实:很多 VLA 在任务前半段都还像样,能走过去,能拿起来,能对准,但一到真正需要精细控制的最后一步就失手。为了修这一步,PI 强调的是用几分钟到几小时的真实世界经验做在线改进。
注意这里隐含的判断非常重要。它不是继续往总数据集里多追加一些日志,也不是再扩大一点 web pretraining,而是直接承认某些能力瓶颈必须靠在线闭环、靠实时修正、靠非常紧扣执行本身的训练机制才能解决。
所以如果把这条线索完整串起来,你会发现一轮非常清晰的 paradigm shift。最开始大家以为是数据不够,后来发现是数据分布不对,再后来发现是 recipe 不对,最后走到 PI 这里,问题已经被拆成了评测、环境变异性、记忆、精度、在线适应这些高度物理化的瓶颈。重心一步一步地从「收集更多观测」移向「如何在真实世界里稳定地形成可执行的能力」。这时候再回头看「机器人缺数据」这句话,就会觉得它几乎有点过于轻飘了。
更麻烦的是,连「数据越多越好」这件事本身都在被慢慢打问号。2025 年关于 generalist robot policy 的 shortcut learning 论文指出,大规模机器人数据集的子集往往同时有两个毛病:内部多样性不足,子集之间分布差异又太大。
模型在这种数据上学到的,很容易是 shortcut,而不是稳健泛化。也就是说,数据一旦被放进了错误的结构,它不但不会帮你,反而可能系统性地把你往错误方向推。
六、为什么所有人都「选择」了最省力的答案
如果最聪明的研究者早就把瓶颈重新定义了,为什么整个行业还是在反复说「缺数据」?为什么明明大家都知道问题没那么简单,融资 deck、媒体报道、行业访谈里出现频率最高的,依然是数据、数据、还是数据。
说到底,是因为「缺数据」这套说法太好用了。它未必最准确,却最容易被组织、被传播、用来融资、用来估值。
你说「我们需要更多数据」,这句话后面可以立刻接一整套熟悉的资本语言。可以有 TAM,可以有 data moat,可以有 flywheel,可以有「先发部署带来独家数据,独家数据带来模型领先,模型领先带来更多部署」的闭环故事。你甚至可以把它画成一张特别漂亮的图,横轴是数据量,纵轴是能力,曲线一路向上,投资人、媒体、合作伙伴都听得懂。
但如果你说「我们真正缺的是对开放世界泛化、评测、在线适应的理解,而且目前没人有成熟答案」,这句话是没法放进融资 deck 的。它太诚实了,也太吓人了。因为它意味着这个行业面对的一个认知问题,靠堆钱堆人可能根本无法逼近答案。量的问题靠加钱加人似乎总能解,认知问题则可能几年都没有清晰进展。
更微妙的一层在于,数据护城河叙事本身支撑着很多公司的估值逻辑。Tesla Optimus 的想象力里,有很大一块来自外界对车端数据优势的自然外推。1X、Figure、Covariant 这类公司的故事,也都不同程度建立在「部署越多,数据越多,模型越强」这条直觉链条上。
注意,我不是说这些公司在故意骗人。问题没有这么简单。更接近现实的说法是,整个行业都更愿意使用一种自己也能接受的语言来描述不确定性,而「缺数据」恰好就是这样一种语言。它既保留了希望,也保留了行动路径,还保留了足够强的融资想象力。
媒体也天然偏爱这种叙事。因为「机器人行业缺数据」是一个一句话就能讲明白、还能让外行快速进入的标题;而「机器人行业真正缺的是稳定评测、有效 recipe、跨环境泛化和在线适应能力」就很难被压缩成一个传播效率很高的口号。
研究者也未必完全能逃开这套逻辑,因为 grant、合作、公开表达都需要一个足够简单、足够可传播的问题定义。于是所有人都在不同程度上维护同一句话,哪怕他们私下里知道事情远没有这么简单。
更现实的一层是,在文本世界里,错误的判断可以靠便宜的 benchmark 很快被纠正;在机器人世界里,很多判断要靠真实硬件、真实环境、真实操作流程去验证,而这件事本身就是重资产工程。新的共识一旦建立成本太高,旧叙事就会活得特别久。
所以我更愿意把这件事理解成一种集体性的舒适归因。说「缺数据」,至少还能让人觉得方向是明确的,钱和时间砸下去,总会逼近答案。说「缺理解」,就意味着要承认这个领域也许还远没到可以靠堆资源线性推进的阶段。前者让人安心,后者让人不安。行业最后选择了更容易被接受的那种说法,这几乎是必然的。
所以回头看 Joe Harris 那条推文,它当然比「缺数据」高明一层,但它依然没有碰到最深的那层东西。
七、录像拍得再多,也推导不出空气动力学
回到文章开头那个矛盾。部署团队硬盘里全是数据,模型团队天天说没有数据可用。数据确实存在,也有人在做基础设施,真实部署数据也确实有价值。真实的情况要复杂得多,也苛刻得多。
一方面,真实部署数据当然重要。Covariant、Figure、1X 的案例已经足够说明,在任务边界清晰、反馈闭环稳定、评测基础设施完善的场景里,它确实可以构成能力优势,甚至构成护城河。
另一方面,这个优势并不是原始传感器流自动产生的。它要经过筛选、切分、标注、加权、评测、重放、后训练,最后还要越过环境变异性、执行精度、长时程记忆和在线适应这些真正属于物理世界的墙,才有可能变成稳定能力。
说了这么多,回头看「缺数据」这三个字,我真正在意的其实不是它准不准确。一句话不够精确,在技术讨论里太正常了。
我在意的是,一句不够精确的话被重复了太多次之后,会开始反过来塑造整个行业的行为模式。当所有人都相信瓶颈是数据,资本就会涌向数据基础设施,团队就会把编制砸在采集和标注上,技术路线就会默认「先把量堆起来再说」。
这些选择不是错的——Foxglove、Rerun、Scale 做的事情确实有价值——但它们加在一起,会让整个行业系统性地低配那些真正卡脖子的环节:评测体系的构建,训练配方的研究,跨环境泛化的机制,以及在线适应能力的突破。
这才是一句话被重复太多次之后真正危险的地方。它不会让你做错事,它会让你做对的事做得太多,而把最难的事一直往后排。等你终于意识到排在后面的那些才是决定性因素的时候,前面花掉的时间和资源已经回不来了。
自动驾驶花了十年和上千亿美元学这个教训。Robotics 最好不要再学一遍。