微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 机器人把积木从左边搬到右边,又搬了回去。你问它:现在做到哪一步了?它说不出来

机器人把积木从左边搬到右边,又搬了回去。你问它:现在做到哪一步了?它说不出来

2026-11-03 12:47
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-11-03 12:47 • 科技行者

你有没有想过这样一个场景:一个机器人正在执行一个很长的任务,比如把桌上五块红色积木依次挪到绿色垫子上再搬回原位。你拍下这个过程的某一帧画面,问旁边的AI:现在进度到哪了?

如果这一帧刚好拍到积木"半搭在垫子边缘",AI大概率能答对,看起来快完成了。但如果这一帧拍到的是机器人正抱着一块积木往回走,AI该怎么判断这是第几块积木、它原本是从哪个垫子拿的?画面里根本没有这些信息。

这正是这篇论文要解决的问题。研究者给它起了个名字,叫"情境依赖的进度估计"。

**进度奖励模型**

*Progress Reward Model,简称PRM,是一类专门给任务执行过程打分的AI模型,输入一段视频或一帧画面,输出当前任务完成了百分之多少*

这类模型在机器人学习里用处很大。它可以当作"密集奖励",告诉机器人每一步做得好不好,而不是等到任务全部结束才给一个成功或失败的反馈;它也可以当作"验证器",判断某个动作是不是真的做完了;还可以当"监控器",发现机器人卡住了没有进展。

问题是,现在这些PRM几乎都是只看"当前这一帧画面"来打分的。研究者在论文里举了个特别形象的例子:倒水倒到一半,杯子看起来半满,这种进度从画面上能直接看出来。但很多真实任务根本不是这样。

论文开头那个积木任务就是个典型。整个指令是:把每块红色积木依次移到绿色垫子上,再搬回它原来的位置,从左到右一块一块来。这个任务里有三个瞬间,单看当前这一帧,无论如何也判断不出进度。

第一个瞬间,积木正被搬回去的路上,画面里能看到积木,但看不出它原本是从哪块蓝垫子拿出来的。研究者管这叫"状态回忆"问题,要知道进度,得记得更早发生过什么事,但这件事已经不在眼前的画面里了。

第二个瞬间,中间那块积木正在移动,画面没法告诉你左边那块积木是不是已经完成了一整趟来回。这是"顺序追踪"问题,任务按固定顺序推进,要判断当前到了第几步,必须知道前面的步骤有没有做完。

第三个瞬间更微妙。积木刚被放到垫子上的前一秒和后一秒,两帧画面几乎长得一模一样,但进度其实完全不同,一个是"即将完成",一个是"已经完成"。这叫"重复消歧"问题,相似的画面可能对应完全不同的进度,区分它们得靠历史。

这三种情况有个共同点:进度这个数值是明确存在的,客观上就是那么多,但当前这一帧画面本身并不包含足够的信息去确定它。

研究者把解决这个问题所需要的那个"缺失的信息"叫做情境。

*情境:当前这一帧画面本身无法确定进度时,还需要额外补充的那部分关键信息,比如积木原本放在哪个垫子、前面几步有没有做完*

这里有个容易想岔的地方。你可能会想,那干脆把整段历史视频都塞给模型不就行了?论文专门花了篇幅说明,这个想法行不通,或者说,没那么简单。

历史视频记录的是"发生过什么",但情境需要的是"这段历史对现在这一刻意味着什么"。这两者不是一回事。一段很长的历史里,哪个信息跟当前这一步相关,取决于任务指令是什么、当前画面已经显示了什么。换句话说,情境不是从历史里"查"出来的,而是结合任务和当下,对历史"解读"出来的。

这就像你问一个刚进办公室的同事"项目做到哪了",如果你把过去三个月所有的会议记录、邮件、聊天记录原封不动甩给他,他未必能立刻说出答案。他需要的不是全部原始记录,而是有人帮他提炼出"现在卡在哪个环节、前面谁做完了什么"这样一句话。给他原始记录和给他这句提炼,效果天差地别,如果没有人帮他做这个提炼,他翻遍记录也可能漏掉关键的那一条。

**现有的PRM到底有多迷茫**

光讲道理还不够,研究者得拿出证据证明现有的PRM确实在这个问题上翻车了。

他们先构建了一个专门的测试集,叫CONTEXTPROGRESS-BENCH,覆盖24个机器人操作任务,120段执行视频,手工标注了552个子任务区间。这些任务是精心挑出来的,每一个都得满足"必须依赖情境才能判断进度"这个条件,不是随便找来凑数的。

有了测试集,研究者设计了一个很巧妙的对照实验,叫"配对诊断"。思路很简单:拿同一个PRM模型,输入格式完全不变,只改一件事,就是给不给它正确的情境信息。一组实验里模型只拿到任务指令本身,不给额外情境;另一组实验里,指令里直接嵌入了手工标注好的正确情境。两组实验除了这一点,别的全都一样。

结果相当惊人。没有情境的时候,五个主流PRM模型(包括ProgressLM、Robo-Dopamine、RoboMeter、TOPReward、VLAC)的平均绝对误差都在15.6到31.0之间,满分是100分,这个误差相当大。一旦给了正确情境,误差直接降到3.4到6.7,降幅在77%到82%之间。

更有说服力的是,这个提升不是靠少数几个"运气好"的样本撑起来的。研究者把552个配对区间逐一比较,93.3%的区间都是"给了情境之后误差明显变小",这说明这是一个普遍规律,不是侥幸。

研究者还做了个对照实验很有意思:如果情境不是来自标准答案,而是模型根据自己上一步的判断"接着往下走",效果虽然也有提升,但远不如用真实情境来得干净利落。这说明一旦模型自己判断错了一次,错误会一路带下去。

论文还细看了这三种情境依赖问题各自是怎么翻车的,分别起了名字:状态失忆、阶段漂移、重复混淆。

状态失忆发生在积木任务里。一旦某块积木离开绿垫子返回,画面上根本没有线索说明它该回到哪个位置,于是进度曲线不是持续上升,反而在某些时刻掉了回去,就像记忆被擦掉了一样。

阶段漂移发生在一个"把三根试管依次插入架子"的任务里。顺序信息画面里看不出来,模型会把第一步还没完全做完的状态,误判成第二步已经在进行了,进度曲线提前冲到了不该有的高度。

重复混淆则发生在"按同一个按钮八次"的任务里。八次按压产生的画面几乎长得一样,模型给出的进度值也几乎一样,本该是阶梯状上升的曲线,被模型画成了一条近乎水平的直线。

这三个案例合在一起说明一件事:模型不是看不见画面里发生的事情,而是不知道该把它放到进度曲线的哪个位置上。眼睛没瞎,但失去了方向。

**给PRM配一个指南针**

既然问题找到了,接下来就是怎么解决。

研究者的思路挺有意思。他们没有去重新训练一个更强的PRM,而是换了个角度思考:PRM这类模型,一旦知道"现在在做哪一步",打分其实是准的,前面的实验已经证明了这点,给了情境误差就能降八成左右。所以PRM本身的打分能力不是问题所在,问题是它自己没法从历史里推理出"现在是哪一步"。

那谁擅长干这件事?研究者注意到,通用的视觉语言模型(VLM)恰好相反:它们打分打得不准,但理解任务、拆解步骤、梳理上下文的能力很强。

*VLM:Vision-Language Model的缩写,泛指能同时处理图像和文字的通用人工智能模型,比如能看懂图片并用语言描述和推理的那类模型*

一个擅长打分不擅长定位,一个擅长定位不擅长打分,这两种能力刚好互补。于是研究者设计了一套系统,叫ProgressCompass,把PRM原封不动地冻结保留下来,专门雇几个VLM围着它转,负责把它需要的情境找出来并喂给它。

这套系统里有四个角色分工明确。

定向者负责看画面,判断任务当前进行到哪个具体步骤,把这个步骤转述成一句自包含的指令。它还要预测"这一步完成后画面应该变成什么样子",这个预测被称为预期转变,相当于提前写好一个可以核对的答案。

冻结的PRM负责打分,只拿定向者给的这句具体步骤指令和从该步骤开始的画面去打分,这正是前面实验证明PRM擅长的那种输入方式。

验证者负责核对,它看三张画面:步骤开始时、进行中、以及候选完成点,结合定向者预测的"预期转变",判断这一步是不是真的做完了。只有验证者点头,系统才承认这一步完成,进度才往前推进。

导航员是个纯文字角色,不看画面,负责调度整个流程,记住已经确认完成的内容,决定接下来该叫谁出场。

这四个角色循环配合,形成一个闭环:定向、打分、验证、再定向,一步步往前推进。

这个设计让我想起一个场景。你交代一个新来的实习生去跟踪一个复杂项目的进度,你不会指望他一个人又懂业务细节又能精准打分,更现实的做法是,配一个熟悉业务的人帮他梳理"现在该看哪个环节",再配一个审核的人帮他确认"这个环节真的结束了没有",实习生本人只需要专注打分这一件事。如果没有梳理环节这个角色,实习生拿到的永远是一堆没有标注重点的原始资料,他自己也摸不清方向,打出来的分自然不准;如果没有审核这个角色,他可能提前几步就以为某个环节结束了,一步错步步错。ProgressCompass本质上就是把这种协作结构搬到了AI系统里。

论文还给出了一个理论支撑,证明了这套设计的误差上限。简单说,只依赖当前画面的任何模型,误差底线取决于三种情境缺失带来的"情境地板",这是没法绕开的硬限制;而ProgressCompass把这个地板基本清零了,剩下的误差只来自"验证者判断错误的概率"和"PRM在单步内部打分的误差",这两项都比原来的情境地板小得多。这不是空口承诺,论文附录里给出了完整的数学证明。

实际效果上,同一个冻结不动的RoboMeter模型,套上ProgressCompass这套流程之后,进度误差从25.4直接砍到9.3,排序一致性(也就是进度曲线跟时间走向是否吻合)从0.53提升到0.93。这个提升幅度覆盖了所有三种情境依赖类型,而且全程没有改动模型的任何一个参数,所有提升都来自于"喂给它更合适的信息"这一件事。

更值得一提的是,研究者还专门测试了这套系统在"指令和实际执行对不上"情况下的表现,分三种场景:提前结束(任务还没做完视频就停了)、多做了(执行的步骤比指令要求的还多)、完全跑题(执行的是另一个无关任务)。

在提前结束的场景里,正确答案应该是"已经完成的那部分进度",不该把没做的部分也算进去。TOPReward在这种情况下偏差达到50.3,RoboMeter偏差32.7,而ProgressCompass只有7.3。

在多做了的场景里,正确答案应该是100,因为该做的都做了,还多做了些。ProgressCompass的偏差是15.8,是唯一能准确到达100的方法,其它方法偏差在24到40之间。

最极端的是跑题场景,正确答案应该全程为0,因为视频内容跟指令压根不是一回事。ProgressCompass在这种情况下从不超过0,而VLAC虽然碰巧也给出了0,但那是因为它根本没能正确理解指令本身,换成正确指令后它反而会给出负63.8这种离谱的数值。

研究者还单独验证了"预期转变"这个设计到底值不值得。他们把这一项从系统里拿掉,重新测了一遍,结果子任务结束点的判断误差直接翻倍,从8.6升到17.2,如果把"预期转变"从定向者和验证者两端都拿掉,误差进一步升到18.8。这说明让定向者提前写下一句"完成后应该是什么样",再让验证者拿这句话去核对画面,确实是让系统判断更精准的关键一环。

最后还有个挺实用的工程细节。整套流程在一次任务内部是严格顺序执行的,因为定向者必须等验证者确认上一步完成才能给出下一步。但不同任务之间没有这种依赖关系,研究者于是设计了一个调度器,让系统同时处理最多五个任务,一个模型闲下来的时候立刻去服务另一个任务,整体耗时从114.7秒降到39.5秒,准确率几乎没有损失。

写在后面

读完这篇论文,有一个点让我反复琢磨:问题的解法不是"训练一个更聪明的模型",而是"重新分配任务"。

这其实是个挺值得停下来想一想的设计哲学。很多时候我们遇到AI表现不好,第一反应是"模型不够强,再堆参数、再训练"。但这篇论文给出的答案完全是另一条路:模型本身没问题,是你问它的问题方式有问题。PRM打分能力是在的,只是你一直在问它一个它回答不了的问题,当前这一帧到底进度多少,而它手里压根没有回答这个问题所需要的信息。

另一个让我觉得有意思的细节是那个"重复消歧"的案例,按钮按了八次,模型给出一条近乎水平的曲线。这揭示了一件很本质的事:视觉模型对"视觉相似"的敏感度,远远超过对"语义差异"的敏感度。两帧画面长得像,模型就倾向于给出相近的判断,哪怕这两帧背后代表的事情完全不同。这种偏差不只出现在机器人进度估计里,大概率也是很多视觉AI系统共有的盲区。

这篇论文留下的一个开放问题是,情境的定位和理解现在完全交给了通用VLM去做,那如果任务复杂到连VLM自己都理解不了,比如那种步骤之间有隐藏的因果依赖、或者需要物理常识推理的任务,这套协作机制还能撑住吗?这个问题论文没有展开,但挺值得继续追问下去。

Q&A

Q1:ProgressCompass是什么?

A:ProgressCompass是论文提出的一套自主运行的协作系统,它让冻结不动的进度奖励模型(PRM)配合通用视觉语言模型,自动补全判断进度所需要的情境信息,从而大幅降低进度估计的误差。

Q2:为什么现有的进度奖励模型在长任务上会判断失误?

A:因为这些模型通常只看当前这一帧画面打分,而很多长任务的进度无法仅凭当前画面确定,还需要知道之前发生过什么、现在是第几步、这是第几次重复,这些信息画面里本身没有,模型因此会迷失方向。

Q3:CONTEXTPROGRESS-BENCH是用来做什么的?

A:它是论文构建的一个专门测试集,包含24个机器人操作任务、120段执行视频和552个标注子任务区间,专门用来检验进度奖励模型在需要依赖历史情境的任务上到底表现如何。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-