0. 摘要

LARYBench 是一套面向潜动作表征的标准化评测基准，目标不是直接比较某个机器人系统的任务成功率，而是先回答一个更基础的问题：从视频中抽取出来的潜动作，是否真的包含了足够稳定、足够可泛化、足够可用于控制的动作信息。围绕这个问题，LARYBench 把评测拆成两个维度，一是高层语义理解，也就是模型能否区分不同动作类别；二是低层物理控制，也就是模型能否从潜空间中恢复出末端执行器轨迹。对于具身智能研究而言，这种拆分非常重要，因为它第一次把“动作表征质量”从“下游策略效果”里独立出来，变成了可以直接测量、直接比较、直接分析的对象。

本文会按照公众号更适合阅读的结构，对 LARYBench 的问题背景、评测框架、数据构建、实验结果和实现流程进行完整说明。文中会穿插论文配图、仓库中的正式框架图以及若干关键代码片段，重点解释这些代码在流程中各自扮演什么角色，而不是只罗列命令本身。读者即使此前没有接触过 LARYBench，也可以通过本文理解它究竟在评什么、为什么这样评，以及如何用仓库代码把完整流程跑通。

图 1：LARYBench 项目页中的总览图，强调该基准面向潜动作表征评测，而不是单一模型训练。

1. 问题背景

具身智能当前面临的核心约束之一，是高质量动作数据远少于文本和图像数据。对视觉语言动作模型而言，文本可以来自互联网，图像可以来自网页和公开视频，但动作监督通常需要真实机器人、遥操作采集系统、动作同步记录和严格标注，这使得数据成本高、规模扩展慢、硬件之间也很难统一。不同机器人拥有不同自由度定义、不同抓手形态和不同控制接口，因此即便采集到了大量数据，也未必能直接迁移到另一类平台上。正因为如此，研究者才会转向一个更通用的思路：不直接学习“某台机器人怎么动”，而是先学习“视觉变化里隐含的动作结构”。

潜动作表征的基本设想，是把视频中的帧间变化编码成一种与具体 embodiment 无关的中间表示。这个表示不要求完全等同于某一台机械臂的关节命令，而是希望抓住“物体被拿起”“手臂向前移动”“夹爪闭合”“容器发生倾倒”这类更本质的交互变化。这样一来，人类视频、机器人视频乃至不同相机视角下的观测，就有可能被映射到一个共享的动作空间中。问题在于，这种潜空间是否真的可靠，过去一直缺少统一的检验标准。很多工作只能靠下游任务成败、聚类图或可视化样例来间接判断，这种做法很难区分表示问题、策略问题和控制器问题。

LARYBench 的贡献正在这里。它不直接回答“哪一个系统抓得更准”，而是先问“你抽出来的潜动作，到底有没有把动作学明白”。这个问题一旦被单独拿出来，就会立刻变得有研究价值，因为它是视觉到动作这条链路中最容易被忽略、却又最基础的一环。论文将这一点表述为对 latent action representation 的统一评估框架，而不是对某个特定策略网络的胜负比较。这个定位决定了 LARYBench 更像是一个诊断标准，而不是单纯的排行榜。

2. 评测对象与核心问题

LARYBench 要评估的不是完整机器人系统，而是“潜动作表征”本身。为了让问题足够清楚，论文把评测对象拆成两个彼此互补的维度。第一类问题是高层语义层面的“做什么”，即模型能否区分抓取、放置、旋转、压缩、倒水、推拉等动作类别。第二类问题是低层执行层面的“怎么做”，即模型是否保留了足够多的几何和动态细节，使得末端执行器轨迹可以从潜空间中被回归出来。这样的拆分非常关键，因为一个表示可能在分类上表现很好，却并不一定包含足够精细的控制信息；反过来，一个表示就算能勉强拟合位移，也不代表它真正理解了动作语义。

从形式化角度看，LARYBench 的流程可以概括为：给定视频帧序列或图像对，潜动作编码器先输出一个连续潜变量 z，然后分别进入分类探针和轨迹回归器。分类探针评估语义可分性，轨迹回归器评估物理可解码性。这种设计的意义在于，它统一比较的是“表征的可用程度”，而不是比较各家模型在不同策略头、不同训练技巧和不同控制器上的 engineering 结果。只要一个模型能输出潜动作表征，它就可以被放到同一套标准里进行测试。

# LARYBench 的核心评测逻辑可以抽象为两条分支
obs = load_video_or_image_pair(...)
z = latent_action_encoder(obs)

# 分支一：高层语义
action_logits = attentive_probe(z)
acc = top1_accuracy(action_logits, action_label)

# 分支二：低层控制
trajectory = action_expert(z)
mse = mean_squared_error(trajectory, ground_truth_action_chunk)

这段伪代码的重要性，不在于语法，而在于它揭示了 LARYBench 的设计立场。latent_action_encoder 负责把观测压缩成动作相关的中间表示；attentive_probe 检查这个中间表示是否已经形成可分的动作语义结构；action_expert 则检查它是否还能被解码成物理轨迹。也就是说，LARYBench 不是问“模型输出对不对”，而是问“这个潜空间是否足够好，以至于一个相对轻量的下游头就能把它用起来”。如果轻量探针已经无法把信息读出来，那么通常说明问题出在表示本身，而不是出在下游头的复杂度不够。

图 2：仓库中的框架图，把数据构建、潜动作提取和分类/回归评测三部分串成了完整流程。

三、数据构建与标注流程

LARYBench 的价值不仅来自指标设计，更来自数据构建方式。论文和项目页给出的总体规模是 1.2M 级别视频、超过 1000 小时时长、620K 图像对和 595K 运动轨迹，统一覆盖 151 个动作类别、11 种机器人 embodiment，以及人类与机器人、第一视角与第三视角、真实环境与仿真环境的组合变化。对一个评测基准而言，这种覆盖范围很重要，因为潜动作如果只对单一机械臂、单一视角或单一场景有效，那么它就不能被称为可泛化的动作表示。

在数据任务上，LARYBench 分成两大部分。第一部分是原子动作，用于检测机器人末端执行器的细粒度运动学变化，例如向上、向下、前进、后退、夹爪打开和夹爪闭合。第二部分是复合动作，用于覆盖更高层的语义行为，例如 pick、place、twist、pour、compress 等。这种组织方式非常合理，因为原子动作更接近低层控制结构，复合动作更接近高层交互语义。只有同时覆盖这两种层次，才能判断一个潜空间到底是在记忆局部位移，还是已经具备了跨场景、跨对象的动作理解能力。

图 3：论文中给出的数据构建流程图，重点展示了视觉语言模型参与时间分段和语义对齐的过程。

这套数据不是简单把公开数据集下载下来拼在一起，而是经过统一重切分、重对齐和重过滤之后才进入 benchmark。根据论文附录和仓库说明，LARYBench 使用一条自动化数据引擎处理来自 Ego4D、EPIC-KITCHENS、Something-Something V2、TACO、HoloAssist、EgoDex、AgiBotWorld-Beta 等多个来源的数据。这个引擎先做动作时间分割，再判断视频与描述是否严格匹配，随后抽取核心动词并校验其是否能够单独代表该视频动作，最后再做人类抽样复核。通过这个过程，原本标注口径不同、片段边界松散、动词粒度混杂的数据，才被整理成统一 taxonomy 下的评测样本。

这一点也解释了为什么 LARYBench 的“评测标准”并不只是一张结果表。标准的第一层，是数据是否被统一定义；第二层，才是模型在统一定义上的表现。以仓库 README 为例，作者明确指出 Something-Something V2 和 EgoDex 由于许可证限制，不能直接重新分发切片后的数据，因此用户需要下载原始视频，并用 utils/prepare_ssv2_egodex.py 重新裁剪出与 benchmark 相同的片段。对真正做复现的人来说，这是非常重要的信息，因为它表明 LARYBench 的数据构造流程本身就是评测协议的一部分，而不是附属脚本。

4. 评测协议与指标定义

LARYBench 的评测协议设计得比较克制，它刻意使用轻量下游头来避免“头太强，掩盖了表示不足”的问题。在语义分类任务中，论文使用 4 层 attentive probe 作为分类器，并在输入前加一个 projector，将不同模型输出的 latent 先映射到统一维度空间，再进行分类。这里的关键指标是 Top-1 Accuracy，衡量的是潜动作表征在动作类别上的可分性。这个任务表面上看是分类，但它真正测的是潜空间中是否已经形成稳定的动作结构边界。

在低层控制任务中，LARYBench 使用一个相对直接的 MLP 结构作为 Action Expert，把潜动作映射成动作 chunk，输出 7-DoF、12-DoF 或 16-DoF 的末端执行器轨迹。这里使用的核心指标是均方误差 MSE。论文与代码都强调，回归阶段使用的是连续 latent embedding，而不是离散 codebook index，这一设计是有明确考虑的：如果评测目标是比较不同表示的真实承载能力，那么不应让量化误差过早成为瓶颈。换句话说，LARYBench 希望先比较“这个潜空间本身好不好”，再讨论量化部署时可能出现的额外损耗。

# regression/main.py 中的分组误差计算逻辑
def compute_group_mse(pred, target, chunk_size, dataset_name):
    group_indices = get_group_indices(dataset_name)
    pred_reshaped = pred.view(-1, chunk_size, action_dim)
    target_reshaped = target.view(-1, chunk_size, action_dim)
    squared_diff = (pred_reshaped - target_reshaped) ** 2
    result = {}
    for group_name, indices in group_indices.items():
        result[f"mse_{group_name}"] = squared_diff[:, :, indices].mean().item()
    return result

这段代码说明，LARYBench 在回归评测时并不满足于只给出一个总 MSE，还会按语义组拆解误差，例如 position、orientation、gripper 等。这样的好处很直接：如果某个模型总体误差接近，但在姿态维度或夹爪状态维度上明显更差，那么研究者可以更清楚地知道表示到底在哪里失真。对于动作表征研究而言，这种分组误差比单一总分更有诊断意义，因为它能帮助识别模型是几何信息保留不足，还是交互状态保留不足。

另外，论文还专门处理了视频采样问题。由于不同数据集的 FPS、动作持续时间和动作速度差异很大，如果简单做均匀采样，很可能得到的是一组变化极小的帧，从而让模型更多地编码背景而不是动作。因此，LARYBench 在复合动作任务中引入了 Motion-Guided Sampler 来挑选更有动态差异的帧，再从相邻采样帧中提取潜动作特征。这个设计并不是工程小技巧，而是潜动作评测的必要前提，因为潜动作本质上来自帧间变化，如果采样本身不能保留变化，那么任何后续结论都会受到污染。

6. 代码结构与实现流程

从工程实现角度看，LARYBench 当前已经把完整流程收敛成三条主命令：extract、classify 和 regress。理解这三个命令各自输入什么、输出什么，是读懂仓库的关键。对公众号读者来说，可以把它们理解成三步流水线：第一步先把原始视频或图像对变成潜动作文件；第二步用这些潜动作文件做语义分类；第三步再用这些潜动作文件做动作回归。这样一来，潜空间就成为整个 benchmark 的公共中间层。

6.1 环境变量与目录约定

仓库在 env.sh 中定义了一组关键环境变量，其中最重要的是 LARY_ROOT、DATA_DIR、LARY_LA_DIR、MODEL_DIR 和 LARY_LOG_DIR。LARY_ROOT 指向代码仓库根目录，DATA_DIR 指向数据集根目录，LARY_LA_DIR 用来保存提取后的潜动作 .npz 文件，MODEL_DIR 保存预训练模型权重，LARY_LOG_DIR 则保存分类与回归阶段的日志和实验输出。理解这些变量很重要，因为后续命令大多不会显式给出所有路径，而是依赖这些环境变量进行解析。

cd LARYBench
source env.sh
conda activate laq

这三行命令看起来简单，但它们分别完成了三个动作。第一行进入仓库根目录，使相对路径解析到正确位置；第二行加载环境变量和辅助函数；第三行切换到 README 推荐的基础环境 laq。如果缺少这一步，后面的提取阶段很容易因为找不到配置、模型权重或数据根目录而失败。也正因为此，文章里不应只贴命令，更要告诉读者这些命令在整个流程中承担的是“把运行时上下文准备好”的作用。

6.2 第一步：提取潜动作

在仓库实现中，extract 是整个 benchmark 的入口。它的任务是读取原始样本元数据，加载指定模型，把视频或图像对转换为潜动作表征，并把结果写回到标准命名的 CSV 和 .npz 文件中。这一步完成之后，后续分类和回归阶段就不再直接碰原始视频，而是统一消费提取好的潜动作结果。这种设计有两个好处：一是不同评测阶段共享同一批 latent，避免重复提取；二是潜空间真正成为 benchmark 中可复用、可替换的中间表示。

# lary/cli.py 中 extract 命令的关键参数
extract_parser.add_argument("--model", type=str, required=True)
extract_parser.add_argument("--dataset", type=str, required=True)
extract_parser.add_argument("--split", type=str, default="all")
extract_parser.add_argument("--mode", type=str, choices=["video", "image"], default="video")
extract_parser.add_argument("--stride", type=int, default=5)

这段参数定义直接对应 extract 阶段最核心的五个问题。--model 决定你用哪种编码器或潜动作模型来提取表征；--dataset 决定读取哪一套数据；--split 决定处理训练集还是验证集；--mode 决定输入是视频还是图像对；--stride 则只在图像对模式下生效，用来控制前后帧间隔。特别要注意的是，video 模式通常对应分类任务中的复合动作，image 模式通常对应回归任务中的图像对和轨迹片段，这一点关系到后续输出文件命名。

python -m lary.cli extract \
    --model dinov2 \
    --dataset calvin \
    --split train \
    --mode image \
    --stride 5

python -m lary.cli extract \
    --model dinov2 \
    --dataset calvin \
    --split val \
    --mode image \
    --stride 5

…详情请参照古月居