具身智能泛化验证：从Figure的56%看机器人真实成功率评测体系

1. 56%刷屏背后的信号行业该慌还是该学这几天具身圈最热闹的事莫过于Figure放出的那一组数据机器人自主完成率56%。乍一看这个数字并不惊艳甚至有人觉得“才56%也敢拿出来秀”但恰恰是这个看似不高的百分比让不少真正做机器人的人后背发凉——因为它的分母不是实验室里精心设计过的demo而是真实家庭环境里那些没被提前标注过的任务。我先说结论56%的含金量在于它对“泛化”这件事的重新定义。以前很多团队说“我们模型很能打”展示的是在固定轨迹、固定光照、固定物体摆放条件下跑通了多少次。就算换上不同物体、不同环境也就换个背景再录一遍视频。这种验证方式本质上测的是“记忆”而不是“泛化”。Figure这次的做法不同他们把机器人丢进真实家庭给了些日常指令比如“把碗放进柜子”“把桌上的杯子拿过来”然后让机器人自己拆解、执行、纠错、完成。整个过程不是录播不是遥控也没有人为干预。视频里那些失败案例比如抓取时把东西碰倒了、手伸得太深卡住柜门、物体识别把烤箱当成微波炉全都原样呈现。为什么我强调这次数据的行业冲击力因为泛化验证是当前具身智能最贵的成本没有之一。模型训练再漂亮泛化不行就是废纸。而泛化能力又不能只靠模拟器里堆数据证明必须在真机上、在真实物理规律下反复验证。Figure愿意公开这种验证结果态度上已经赢了大多数只会发demo视频的团队。所以我的判断是56%不是一道考砸了的分数而是一把新的标尺这把标尺会让整个行业重新思考“我们到底该如何验证一个具身智能系统”。这个信号对谁影响最大三类人。第一类是正在做具身大模型、接触器人操作基座模型的算法团队你们的评估体系可能要重写第二类是想从仿真转真机的创业公司你们不能再拿sim环境的成功率来对外讲故事第三类是准备入局这个方向的应届生和研究者你们要重新理解“泛化”在真实世界里的含义。往下我逐层拆。2. 揭开“56%”的内核Figure到底测了什么又没测什么2.1 它不是一次随机测试而是一套“任务开卷、执行闭卷”的评测法要解读56%首先要搞清楚Figure是怎么测出来的。我不是Figure内部员工但根据公开的技术博客和演示视频可以还原出大致的评测框架再加上业内同类评估的经验这套体系基本可以拆成三个关键层第一层是任务层给定一个自然语言指令比如“把餐巾放到抽屉里”。这个指令中间没有步骤拆分模型需要自己理解“餐巾在哪、抽屉在哪、抓取顺序是什么、如果餐巾被压住了怎么办”。这一层考验的是指令理解能力本质上已经把“任务规划”纳入到评测范围里。第二层是操作层机械臂要完成从移动到抓取到放置的全套动作。这里涉及视觉定位、姿态估计、力控、抓取策略、路径规划等多个模块的协同。任何一个环节崩了整个任务就算失败没有中间态。第三层是纠错层如果东西掉在地上了、手被卡住了、第一次抓取位置不对系统能不能自己恢复或者换一种方式重新执行。三层叠加才能反映一个机器人“单次任务成功率”。Figure公布的56%我理解是“所有任务的平均成功率”也就是把很多次尝试、很多种任务混在一起算出来的一个总数字。所以它和我们在论文里常见的“Move It 那个桌子场景任务成功率95%”完全不是一个物种。2.2 56%没展示的另一面失败模式比成功率更重要比分数本身更重要的是什么是它的失败分布。从业者关注的重点不应该是“为什么还差44%”而应该是“那44%都败在哪”。按我长期跑真机评测的经验失败模式一般能归成这几类物体识别错乱比如把透明玻璃杯当成不存在、把白墙当成可抓取的平面。视觉大模型在复杂光照下掉链子是重灾区。姿态估计偏差摄像头标定或手眼标定有误差导致抓取点偏移那么一两厘米刚好让物体滑走。动作序列规划僵硬模型学到的策略是“先向左移动10厘米再抓”但真实环境下物体位置稍微变动这条策略就废了。力控不稳抓取力太大把东西捏碎或推倒太小又抓不起来。尤其是柔性物体毛巾、塑料袋这类。恢复策略缺失一次失败后系统不知道怎么办只会重复同一个错误动作直到超时。Figure敢公开这类失败画面说明他们内部一定有比56%更细的复盘体系。而区分一支团队是“做demo还是做产品”往往就看他们会不会分析和记录失败模式。真正拉开差距的不是56%和70%之间的绝对值差异而是谁能从那44%的失败里低成本提炼出模型迭代信号。2.3 为什么这个数字不能直接横向对比其他厂商我需要给读者提个醒现在很多报道把Figure的56%和别的公司宣称的“成功率99%”放在一起对比这是典型的不讲基本法。各家评测的任务难度、场景复杂度、失败判定标准完全不同。A家测的是固定工位重复放置B家测的是随机关卡家庭环境两者放在同一个天平上没有任何意义。所以当你看到某个具身公司说“我们的自主完成率达到90%”时第一反应不应该是“它比Figure强”而应该是“它的评测边界是什么任务集是什么失败如何定义”这个道理和自动驾驶的“接管里程数”一样评测口径不统一的时候所有数字都只是宣传话术不是工程标尺。Figure的56%之所以有参考价值恰恰不是因为它高而是因为它的评测协议相对更接近真实使用场景换句话说这个数字背后的“严苛系数”比很多好看的数字高得多。3. 泛化验证大考一场从 Demo 到体系的全面升级3.1 “能跑通一次”和“能稳定跑通一百次”是两种物种我在帮一些团队搭具身评测体系时经常发现一个非常典型的问题大家把“成功了一次”当成了“系统已经work了”。很多项目经理拿着一条跑通的视频去汇报老板看完也很兴奋觉得量产近在咫尺。然后测试团队一到第二天再跑同样的任务成功率直接对半砍。于是大家开始怀疑是不是硬件出了问题是不是昨天运气好。这背后的真相就是泛化能力没有建立。系统只是在特定条件下记住了一个动作序列而不是学会了“面对这个任务在不同条件下都能完成的策略”。我打一个比方如果你参加驾照考试教练只教你一条固定路线倒库、侧方停车都在固定的库位上练考试那天恰好也是这条路线那你大概率能过。但之后让你去另一个停车场倒库你马上原形毕露。具身智能系统如果验证时只测固定路线下的成功率本质就是在“背题库”。真正的泛化验证必须覆盖几个维度对象泛化同样一个“抓杯子”杯子换成不同材质、不同颜色、不同透明度系统还能不能行。场景泛化同一个任务从厨房换到客厅光照变化、背景杂乱程度变化系统还能不能定位目标物。任务泛化不是“抓杯子”这么单一而是“把杯子放到餐桌上再把餐桌上的勺子拿到厨房”连续任务能不能规划执行。物理扰动泛化物体被碰歪了、被移动了几厘米、机器人自己的初始位置有偏差系统能不能自适应修正。3.2 为什么仿真验证与真机验证之间的距离正在拉大过去几年行业里流行一个故事先在仿真里大规模训练然后zero-shot迁移到真机。这个故事在抓取、移动等相对低维的任务上有一定有效性但在具身智能这种高维连续决策问题上仿真和真实之间的鸿沟一直没有被真正填平。举一个最常见的差距物理接触。仿真里模拟摩擦系数、接触变形、力反馈模型能算出抓取成功率但真实世界里物体表面可能有油渍、有水、有静电这些微观物理效应在仿真里永远模拟不全面。再比如传感器噪声真实相机有暗角、有动态模糊、有反光激光雷达有雨雾衰减这些传感器特性在仿真里可以用噪声模型近似但永远不会和真实完全一致。Figure的56%在某种程度上是一次“真机优先”路线的胜利表态。它的系统大概率是通过大量真实遥操作数据喂出来的而不是在仿真里迭代了百万回合再到真机上修修补补。这种路线在数据成本上更贵但在泛化验证上更“踏实”。我预判未来一年会有越来越多团队从“sim-first”转向“real-first”至少会变成“sim预训练real精调real评测闭环”。3.3 泛化验证正在演化为一种“系统能力测试”而不再是“模型能力测试”以前的机器人验证通常是按模型拆目标检测测AP、抓取测成功率、路径规划测时间消耗、决策测任务完成率。每个模块独立打分最后合成一个总体评价。但在Figure的56%框架里我注意到一个潜在变化它是把整个人形机器人当成一个黑盒只从外部的任务完成率来衡量系统整合能力。这种“端到端黑盒测试”思路更贴近产品视角。因为用户不关心你内部是模块化架构还是端到端模型用户只关心“我说了‘把垃圾扔到垃圾桶’你到底干了没有”。这种评测哲学我估计会成为下一阶段行业标配。但它带来的问题是一旦整体指标下降很难定位是哪个模块的锅。这要求团队必须建设更完善的可观测体系比如在端到端系统之上增加中间信号记录、失败样本自动分类、归因分析等工具链。如果你们团队目前还在“分模块刷指标”的阶段我的建议是尽早补充“系统级评测”维度把机器人在真实场景的完整体验纳入到管理流程里。否则等客户拿真实任务来考核你的时候你会发现所有模块指标都是绿色的但整个系统就是干活不利索。4. 实操向如何搭建一套泛化验证体系参考框架前面说了那么多认知层面的东西这一节给真正要动手搭评测体系的团队一份可直接参考的框架。这套框架是我们过去在不同项目里反复打磨过的不敢说多先进但至少能解决“验证结果不可信”“反复返工”“demo和实际差距大”这三个最普遍的问题。4.1 任务集设计不要从“模型会什么”出发要从“用户要什么”出发很多人设计评测任务集时习惯反过来看模型在哪个任务上效果好就把哪个任务放进来当评测场景。这样测出来的结果当然很好看但毫无意义因为评测变成了“给自己颁奖”。我推荐的做法是先列出目标用户最常发出的五类自然语言指令再进行场景化扩展。比如家庭服务场景可能就是物品整理把桌上的东西放到架子上环境清洁把垃圾扔进垃圾桶物品递送把手机拿给我餐桌服务把餐具摆到桌上开关操作打开/关闭柜门、抽屉每一个指令再扩展出多个变体物体不同、位置不同、房间不同、光照不同、遮挡情况不同。这样能得到一个几百条的任务清单覆盖度和真实需求对齐才算一个合格的任务集。任务集设计好之后必须进行难度标定。让不同基础的团队用同一套任务集跑观察难度分布是否合理。如果所有人都是100%成功或者0%成功说明任务集设计有严重偏差。4.2 失败判定要开“上帝视角”不能只听系统自报我在测评时吃过最大的亏就是过度信任机器人的“自报成功”。系统判断“任务完成”了但站在旁边的人类能看到物体没被放正、柜门没关严或者东西掉到了桌子后面。所以在泛化验证体系里成功与否必须由人工或第三方传感器来判定不能由被测系统自己给自己打分。实际操作上我强烈建议至少安排一名评审员全程观看任务执行画面按统一标准做人工标注格式尽量精简成功、失败原因分类、未完成超时。如果预算允许可以在环境里加装顶视摄像头和双目记录设备方便后续复盘。这套“外部判定机制”会让很多模型原形毕露也会让真正过硬的系统显现出来。4.3 样本管理一次任务一个set一个set必须包含失败样本的归因标签很多团队的失败样本管理一塌糊涂。模型失败了debug完事样本就丢了。正确的做法是每次测试都必须留存完整的轨迹数据、视觉记录、系统日志、人工标注形成一份可回溯的episode包。只有在积累了足够的episode包之后你才能用统计方法分析失败模式比如“是不是透明物体抓取失败率特别高”“是不是光线暗的时候路径规划超时特别多”。没有归因标签的失败样本只能用来写PPT用来迭代模型是毫无价值的。我给一个简单的归因分类标签体系可以直接抄标签含义示例VISION_OBJ目标物体检测/识别失败没找到桌子上的杯子VISION_POSE物体定位/姿态估计偏差抓取点偏移抓空PLAN_TASK任务级规划错误把碗放进了不该放的柜子PLAN_MOTION动作序列规划不合理运动路径和障碍物碰撞CONTROL_GRASP抓取控制失败捏力不够物体滑落CONTROL_PLACE放置控制失败放得太歪物体倒下RECOVERY_NONE失败后无恢复策略一直重复错误动作直到超时ENV_UNEXPECTED环境突然扰动有人走过、物体被碰倒每次测试结束后把失败样本按这个标签体系归档每周做一次频率统计就能很清楚看到模型的短板分布。这一步是所有后续优化的入口。4.4 评估节奏先通勤测试再难度爬坡最后随机模拟我自己常用的验证节奏分三段适合从0到1搭建评测体系的团队参考第一段通勤测试判断系统能跑。用固定任务、固定场景、固定物品连续跑十次目标是确认系统“基本能用”。此阶段允许调试参数但不允许改代码逻辑。第二段难度爬坡判断泛化潜力。保持任务不变引入变量物品换颜色、换位置、换光照、换背景、换机械臂起点。每加一个变量就跑五到十次记录成功率变化。如果成功率随变量剧降说明当前系统对该变量敏感需要针对性优化。第三段随机模拟判断真实可用性。把变量组合起来随机化任务也换成没测试过的新指令模拟真实用户的使用流。此阶段不允许任何人工干预一次指令算一次机会统计成功率。Figure的56%我推测就是在这种“随机模拟”口径下测出来的。把三段跑完你得到的就不再是一个孤零零的数字而是一张“泛化能力画像”哪里强、哪里弱、下一步优化优先级是什么全都一目了然。5. 应对“大考”不同角色的行动建议5.1 算法团队把评测体系从“模型指标”升级到“系统指标”搞算法的人通常习惯用Perception的AP、规划的成功率这些指标来汇报但如果你真的想让系统走向产品就需要在原有指标之外额外建设一套“系统级任务指标”。说白了就是不要问“目标检测mAP是多少”要问“把杯子从桌上拿到柜子里这个任务在一百次随机测试里成功了几次”。这两种思维模式的切换会影响你整个技术路径的选择。比如当你开始用系统级任务指标来评估就会发现很多在“模块指标”上表现优异的模型到了端到端跑起来效果很差原因往往是模块之间接口不匹配。这时候你要投入精力做联合调优而不是继续单独刷每个模块的指标。5.2 硬件团队泛化验证会把“结构设计缺陷”暴露得更彻底很多硬件出身的团队在demo阶段看不出问题因为一切都在可控条件下进行。但一旦进入泛化验证机器人的机械结构缺陷会被放大。举个例子如果你的夹爪开合范围太小那你只能抓特定大小的物体泛化任务里一半的物体都抓不了如果你的关节自由度不够有些动作根本做不出来。泛化验证的核心价值之一就是逼迫硬件团队把“设计假设”暴露出来。所以我建议硬件团队在做结构设计时多想想“我要支持的任务分布范围”而不是盯着那几个demo物件做优化。5.3 创业者与投资人数字化验证能力正在成为团队的核心资产我在多个场合说过一个判断下一阶段具身智能公司的估值取决于他们的评测体系有多硬核。因为你有没有泛化能力不是靠嘴说是要靠验证体系来证明的。如果你的验证体系只能“自己和自己玩”那在行业标准逐步形成的背景下你的估值叙事会越来越难讲。创业者现在的任务是把泛化验证当成产品来建设。从采集任务集、标注原始数据、沉淀失败样本到搭建可视化复盘看板再到自动化评测流水线这是一个完整的基础设施工程。它短期看起来烧钱、产出低但长期来看是团队真正的护城河之一。投资人看项目时除了看demo视频也应该多问一句“你们的泛化验证体系是什么成功率的评测协议能给我看看吗”能把评测协议讲清楚的团队大概率比只会炫耀demo的团队扎实得多。6. 一个实操案例我们搭建的“家庭操作泛化验证”原型分享一个我之前带过的实际项目给大家一个具体参照。我们当时的目标是验证“一台单臂轮式机器人在三室一厅的家庭环境里做整理任务”的泛化性能。任务集设计上我们列了35条自然语言指令涵盖了整理、递送、清洁三类。每条指令制作了5个场景变体共175个测试任务。每个任务开始时物品位置、数量、房间清洁度都是随机布置的机器人不知道任何先验信息。我们要求系统在5分钟内完成任务超时算失败执行过程中允许系统自身判断是否需要请求远程帮助但一旦请求这个任务直接标记为“未自主完成”。跑了两周数据出来总体自主完成率41%。失败归因里占比最大的是VISION_POSE32%也就是“看见了物体但算不对抓取位置”其次是PLAN_MOTION24%“动作序列规划在半路被障碍物卡住”再其次是CONTROL_GRASP18%“抓是抓到了但是没抓住”。这个结果对团队是很大的警醒。我们在模块级测试时视觉定位的误差只有1到2厘米看起来不错。但到了系统级这个误差被开环放大了最后表现为抓取失败。我们为此专门优化了手眼标定流程增加了一次真实的在线物体姿态估计校准并且把抓取前的“预对准动作”从一次更改为“动态逼近接触确认”。优化后总体成功率提升到53%。这个案例想说明什么泛化验证不是“测完就完”它是一个从发现短板到定位原因再到回归验证的闭环。每一轮闭环都会沉淀一批数据和经验。那些最终把系统做扎实的团队就是靠一轮一轮这样的闭环慢慢把成功率从20%扛到80%的。7. 从Figure的56%想到的我们离“可用”还有多远最后说一点个人的判断。Figure的这个数字让很多人开始怀疑“人形机器人是不是被过度炒作了”。我倒觉得一个足够坦诚的、把失败和局限性摆在台面上的数字恰恰说明这个行业正在从“讲故事”走向“做工程”。56%意味着它不能卖给你当保姆但它已经可以作为实验室里的研究平台甚至在某些窄场景里作为半自动工具使用。而我们更应该关注的是这个56%背后的验证体系能不能被行业复用能不能形成标准。一旦整个行业形成了相对统一的泛化评测协议大家的数据就可以横向比较技术的进步速度会快很多。到那时“我的系统在某某协议下测出来综合成功率是80%”这句话才有真正的含金量。从我个人的实际工作经验来看做具身智能系统最磨人的不是模型设计也不是硬件选型而是“验证”这件事。它需要你有耐心去设计合理的评测任务、有勇气去直面失败真相、有体系去沉淀每一次测试的细节。Figure的56%之所以让我觉得值得分析不是因为它多高而是因为它把“验证”的重要性重新拉回了行业视野。希望这篇文章能帮你少走一些弯路不管你是做算法的、做硬件的、还是在评估这个赛道的都能从这套泛化验证的思维框架里找到一点可用的东西。