Robotic Embodied Intelligence - From Zero to Hero

11.2.1 阅读开源 VLA / 机器人基础模型仓库的方式

这一小节的目标，是教读者“拿到一个陌生的开源 VLA / 机器人基础模型仓库，如何从不会到能跑起来、看得懂、改得动”。可以结合前面章节对 VLA 架构与训练范式的理解，这里则更加工程化、落地化。

11.2.1.1 选取项目

并不是任何一个 GitHub 仓库都适合作为学习对象。选择起点时，可以遵循几个简单的原则。

（1）优先选择有论文 / 网站支撑的“标志性”项目 这类项目往往有较完整的文档、清晰的实验设定和稳定的代码实现，例如：

• OpenVLA：开源 7B 参数 VLA 模型，基于 Open X-Embodiment 约 97 万条机器人轨迹预训练，支持多机器人、多任务控制，并提供推理与 LoRA 微调脚本。(GitHub)
• RT-1（Robotics Transformer）：Google Robotics 提出的视觉-语言-动作 Transformer，官方及非官方仓库给出了训练与推理代码。(GitHub)
• Octo：开源的通用机器人策略（generalist robot policy），基于 Transformer + diffusion policy，在 80 万条 Open X-Embodiment 轨迹上训练，支持多机器人、多观测空间与多任务。(GitHub)
• robomimic：更偏“框架”的模仿学习平台，包含多种离线模仿 / offline RL 算法与标准数据集，适合作为训练/评测 pipeline 的参考。(GitHub)

另外，还可以参考“awesome / survey”类仓库（如 Generalist Robotic Foundation Models 列表），从中挑选代表性模型。(GitHub)

（2）优先选“功能可闭环”的项目

即：

• 至少包含：数据加载 → 模型构建 → 训练 / 微调 → 推理 / 评估 全流程代码；
• 最好提供：示例脚本（examples/、scripts/、tutorials/ 目录）、** 预训练权重下载方式以及 一键 demo**。

这类项目可以让你做到：

读几页 README → 配好环境 → 跑通一个 demo → 再回头看代码结构，印象会清晰很多。

（3）从“小而完整”到“大而复杂”的渐进路径

建议的学习顺序可以是：

1. 单任务、单机器人项目（比如基于 robomimic 的模仿学习基线）——先熟悉最简 pipeline。(robomimic)
2. 单机器人、多任务 VLA 模型（如某些 RT-1 实现、Octo 子集）。(GitHub)
3. 多机器人、多模态的大型基础模型（OpenVLA、Octo 全量等）。

（4）检查“可维护性信号”

打开 GitHub 后，可以快速扫描：

• Star / fork 数量是否过低（过少可能仓库尚不成熟）；
• 最近是否有 commit（过于久远可能与当前依赖版本不兼容）；(GitHub)
• README 是否有安装、数据准备、训练、评估等完整说明；
• 是否有 issue / discussion 在积极回复。

图片占位：

[图 11-2-1 占位：某开源 VLA 仓库的 GitHub 首页截图，标出 README、src/、configs/、scripts/ 等关键入口。]

11.2.1.2 入口与主流程

选定项目后，第一步不是“逐文件通读”，而是找到 程序的主干流程 。通常可以按下面的套路来。

（1）从 README / 教程脚本反推入口

大多数项目都会在 README 中给出类似命令：

python train.py --config configs/openvla_libero.yaml
# 或
python -m openvla.train experiment=openvla_libero

这条命令中的脚本（train.py）或模块（openvla.train）就是训练主入口。(GitHub)

推理同理，例如 Octo 中的 inference.py、demo_* 脚本通常是第一站。(GitHub)

（2）用“从外到内”的方式跟踪主流程

打开入口脚本后，可以标出几个关键函数：

• 参数 / 配置加载：parse_args、OmegaConf.load、hydra.main 等；
• 初始化：setup_logger、set_seed、build_model、build_dataset；
• 训练循环：for epoch in ...:、train_one_epoch、evaluate;
• 保存与日志：save_checkpoint、log_metrics。

建议画一个简单的流程图（哪怕是纸上手绘）：

“命令行参数 / 配置 → 构造 Dataset / DataLoader → 构造 Model → 配置 Optimizer / Scheduler → 训练循环（forward + loss + backward + step）→ 定期验证 + 保存权重”。

图片占位：

[图 11-2-2 占位：训练主流程框图，从命令行入口到训练循环、评估与保存。]

（3）用简化伪代码重构理解

可以尝试把入口脚本抽象成伪代码，加深对整体结构的理解，例如：

def main(config):
    # 1. 环境初始化
    setup_seed(config.seed)
    setup_distributed(config.dist)
    logger = setup_logger(config.log)

    # 2. 构建数据与模型
    train_loader, val_loader = build_dataloaders(config.data)
    model = build_model(config.model).to(device)
    optimizer, scheduler = build_optimizer(config.optim, model)

    # 3. 训练循环
    for epoch in range(config.optim.num_epochs):
        train_one_epoch(model, train_loader, optimizer, scheduler, logger, epoch, config)
        if (epoch + 1) % config.eval.freq == 0:
            evaluate(model, val_loader, logger, epoch, config)
        save_checkpoint_if_needed(model, optimizer, epoch, config, logger)

阅读仓库时，可以一边看原始代码，一边自己在笔记里写下类似伪代码，逐渐把陌生代码抽象成熟悉的结构。

（4）优先看“数据一帧的生命周期”

主流程的核心，是一条数据从磁盘到 loss 的路径 。在入口脚本中找到：

1. Dataset.__getitem__：从文件中读出图像、状态、语言指令、动作等；
2. collate_fn：将多条样本打包成 batch；
3. model.forward：如何对视觉 / 语言 / 状态 / 历史动作编码并融合；
4. loss_fn：如何对动作 token 或连续动作计算损失；
5. loss.backward() → optimizer.step()。

优先搞清楚这一条“完整 pipeline”，再去深挖细节，会更有方向感。

11.2.1.3 模块划分

当你知道“程序从哪里进、大概要干什么”之后，下一步是给仓库做一个 功能模块地图 。

（1）典型 VLA / 机器人基础模型仓库的目录结构

很多仓库会有类似的分层（以伪目录为例）：

openvla/
  configs/            # YAML / JSON 配置
  data/               # 数据相关（dataset 定义、预处理）
  models/             # VLA 模型、backbone、头部等
  train/ 或 engine/   # 训练 / 推理引擎（循环、分布式封装）
  eval/               # 评估脚本、指标实现
  envs/ 或 robots/    # 仿真环境或真实机器人接口
  utils/              # 通用工具（日志、分布式、检查点等）
  scripts/            # 命令行脚本、demo

Octo、RT-1 的公开实现以及 robomimic 等框架基本都采用类似的层次结构，只是在命名和粒度上略有差别。(GitHub)

图片占位：

[图 11-2-3 占位：一个典型 VLA 仓库目录树示意图，用颜色标出 config / data / models / train / eval 等模块。]

（2）按“重要性和依赖顺序”规划阅读顺序

推荐的阅读顺序：

1. configs/ 或 conf/：了解有哪些实验配置、使用了什么模型 / 数据集 / 优化器；
2. models/：搞清楚主干网络结构（Transformer / diffusion policy / CNN + Transformer）与输入输出定义；
3. data/：理解轨迹数据的组织形式，包括视觉帧、语言指令、动作序列、状态等；
4. 训练引擎 train/ / engine/：如何把 data / model / optimizer 拼接起来，如何做分布式、日志、保存；
5. eval/ 与 envs/ / robots/：评估指标、仿真或真实机器人接口是怎样集成进来的；
6. utils/：最后再看，里面通常是通用工具，对整体理解帮助较小。

（3）为每个模块写一行“功能注解”

在个人笔记中，可以给每个核心模块写一句话的总结，例如：

• openvla/models/transformer_vla.py：实现视觉-语言-动作统一 Transformer 的主体结构，定义输入 token 化与动作解码；
• octo/data/trajectory_dataset.py：负责从 Open X-Embodiment 之类数据集中读取轨迹，并打包成 transformer-friendly 的序列。(octo-models.github.io)
• robomimic/algos/bc.py：标准行为克隆算法实现，可作为所有模仿学习类算法的参照基线。(GitHub)

随着阅读深入，你会发现许多项目尽管细节不同，但在模块划分和数据流设计上高度相似，理解一个之后，再看新的 VLA 仓库就容易很多。

11.2.2 从配置文件与训练脚本理解整体 pipeline

前面强调了“从入口梳理主流程，本小节更系统地讲：如何仅凭配置文件和训练脚本，把一个大型项目的 训练 pipeline 在脑中“还原”为清晰的结构。

11.2.2.1 配置文件

现代 VLA / 机器人基础模型项目高度依赖配置系统（YAML + Hydra / OmegaConf，或 JSON / Python dict），这是理解 pipeline 的最好入口之一。

（1）典型配置文件结构

以一个假想的 configs/openvla_libero.yaml 为例，你通常会看到以下模块：(GitHub)

• experiment：实验名、输出目录、随机种子；
• data：
  • 数据集名称（如 libero、robomimic_kitchen）；
  • 数据路径、训练 / 验证拆分；
  • 图像分辨率、帧数（history length）；
  • 是否使用语言指令、状态信息；
• model：
  • 视觉 backbone 类型（ResNet / ViT / FiLM EfficientNet / patch tokenizer 等）；(GitHub)
  • Transformer 层数、hidden dim、注意力头数；
  • 动作 token 化方式（关节空间 / 末端空间 / diffusion policy 的 action embedding）；(GitHub)
• optim：
  • 优化器类型（AdamW 等）、学习率、权重衰减；
  • batch size、训练步数 / epoch 数；
  • 学习率调度器（cosine、linear、warmup 步数）；
• train / dist：
  • 使用的 GPU 数量、分布式后端；
  • 混合精度（fp16/bf16）、梯度累积步数；
• eval / logging：
  • 评估频率、保存模型的策略；
  • 日志后端（TensorBoard、W&B）。

阅读配置时的一个小技巧：统一标记“和你关心的科研问题直接相关的字段”，例如你要做“历史长度 ablation”，就重点关注 data.history_len。

（2）练习：从配置推测训练设定

拿到一个配置文件，可以尝试用文字复述一遍实验设定，例如：

“本实验使用 LIBERO 仿真数据，单目 RGB 图像，输入 3 帧历史，将语言指令作为文本 token 拼入序列，采用 12 层 Transformer，hidden dim=1024，以 1e-4 学习率在 8 GPU 上训练 200k 步。”

如果你能做到这一点，说明你已经基本“读懂”了配置文件。

图片占位：

[图 11-2-4 占位：标注注释后的 YAML 配置片段截图，用颜色高亮 data/model/optim/dist 等字段。]

11.2.2.2 训练脚本

配置文件给出了“实验的静态参数”，而训练脚本则描述“这些参数如何被用来真正跑起来”。

（1）训练脚本的典型结构

无论是 OpenVLA、Octo 还是 robomimic，训练脚本往往包含几个固定组成部分：(GitHub)

1. 解析配置
   • 从命令行 / Hydra 获取 config；
   • 设置随机种子、确定设备（CPU / GPU）。
2. 构建数据 pipeline
   • 调用 build_dataset(config.data)；
   • 构建 DataLoader，指定 batch size、num_workers、shuffle 等。
3. 构建模型与优化器
   • 调用 build_model(config.model) 返回一个 VLA 模型实例；
   • 将模型移动到设备；
   • 使用 build_optimizer(config.optim, model) 创建优化器和学习率调度器。
4. （可选）分布式 / 混合精度封装
   • 使用 DistributedDataParallel 或强封装（如 accelerate、Lightning）；
   • 开启 AMP（自动混合精度）上下文。
5. 训练 / 评估循环
   • for step in range(max_steps): 或 for epoch in range(num_epochs):；
   • 在循环中完成前向计算、loss 计算、反向传播、优化器更新；
   • 定期做验证、日志记录与 checkpoint。

（2）跟踪“一个 batch”在脚本中的路径

阅读训练脚本时，可以重点追踪以下几个函数调用：

for batch in train_loader:
    obs = batch["obs"]          # 视觉、状态等
    lang = batch["language"]    # 语言指令
    actions = batch["actions"]  # 轨迹中下一步动作

    outputs = model(obs, lang)
    loss = compute_loss(outputs, actions)
    loss.backward()
    optimizer.step()
    scheduler.step()

你可以在 IDE 中用“跳转定义”功能，从 model(...) 追到模型源码，再从 compute_loss 追到 loss 实现，再从 batch 的结构追到 Dataset 定义。

（3）注意训练脚本中“工程细节”的位置

比如：

• 日志与监控：通常集中在 log_metrics、logger.log 这一类函数里；
• 梯度裁剪：可能埋在单独的 optimizer_step 或 train_one_epoch 中；
• checkpoint 管理：保存 / 加载逻辑往往分散在 save_checkpoint、load_checkpoint、resume_if_needed 等函数。

这些地方虽然看上去“业务不性感”，但对可复现性和调试至关重要（与第 9.4 节的 MLOps 内容可以互相参照）。

11.2.2.3 Pipeline 连贯性

当你基本理解配置和训练脚本后，需要进一步做到：在脑中形成完整、连贯的“实验 pipeline 心智模型” 。

（1）画出三条主线：数据流、模型流、优化流

可以在笔记中画三条并行的线：

1. 数据流：
   • 磁盘 → Dataset → DataLoader → batch → 模型输入；
   • 其中包括：图像解码、归一化、数据增强、token 化（语言 / 动作）。
2. 模型流：
   • 视觉编码 → 语言编码 → 多模态融合（Cross-Attention、统一 Transformer）→ 动作解码（token / diffusion）→ loss。
3. 优化流：
   • loss → backward → 梯度规约（分布式）→ 梯度裁剪 → optimizer step → scheduler step → 更新后的模型参数。

图片占位：

[图 11-2-5 占位：三条主线（data/model/optim）的时序图，展示一次训练 step 内各模块的调用关系。]

（2）用“极简运行”检验你的理解

一种非常有效的练习是：

• 在配置中设置 非常小的 batch size / 步数（例如 run 10 step 就停）；
• 在关键位置打印 tensor shape、loss 数值；
• 在笔记里按顺序记录：
  • 输入图像 / token 的维度；
  • 模型内部每层输出的维度（可以用 hook 或简单 print）；
  • loss 是否随着 step 单调下降（至少在一小段上）。

如果你能解释“为何在这一层维度从 768 变成了 1024”“为何这里会多出一维表示时间步”，说明你对 pipeline 的连贯性已经比较清楚。

（3）避免“黑盒跑通”的幻觉

很多同学会陷入“脚本能跑 = 我理解了”的误区。一个简单的自测方法：

关闭代码，单凭配置和你刚画出的流程图，能否准确回答： – “训练时每步输入多少帧图像？” – “语言指令是如何被编码并融合到 Transformer 中的？” – “动作是 token 化还是直接回归？如果是 token 化，codebook 大小是多少？” – “优化器与学习率调度策略是什么样的？”

如果能回答、大致能写出伪代码，那就真正掌握了该仓库的整体 pipeline。

11.2.3 Debug 常见问题：NaN、梯度爆炸、收敛失败

在 VLA / 机器人基础模型的训练中，训练失败并不是例外，而是常态 。本节针对最常见的三类问题，给出系统的排查思路与建议，帮助读者建立“工程级”的 debug 能力。

11.2.3.1 遇到 NaN

（1）现象与第一反应

典型症状包括：

• loss 突然变为 NaN 或 inf；
• 指标为 nan；
• log 中出现 “gradient overflow” 或 “Detected NaN in …”；
• 参数 / 梯度中出现非有限值。

第一反应：先停下来保存现场（log、配置、最近 checkpoint），不要盲目继续训练。

（2）定位 NaN 来源的基本步骤

1. 检查输入数据
   • 在 Dataset.__getitem__ 和 collate_fn 中打印 / 断言：
     • torch.isfinite(img).all()，torch.isfinite(actions).all()；
   • 特别注意：
     • 深度图 / 点云中是否有 inf；
     • 关节角 / 速度是否有奇异值（非常大的数 / NaN）。
2. 检查预处理与归一化
   • 图像除以标准差时，是否有 std = 0 的情况；
   • 对数操作 log(x) 是否保证 x > 0；
   • 平方根 sqrt(x) 是否有负数输入；
   • 归一化时是否有 除以样本数 0 的情况。
3. 分拆 loss
   • 如果总 loss 是多个项之和（模仿 loss + 正则项 + 对比损失等），可以单独打印每一项：
     • 哪一项先变为 NaN？
   • 在 VLA 中要特别注意：
     • 动作 token 的 cross-entropy；
     • KL 散度 / log-likelihood 之类的项是否做了 clamp 防止 log(0)。
4. 开启框架的 NaN 调试工具
   • PyTorch 有 torch.autograd.set_detect_anomaly(True)，可以在出现 NaN 时给出对应的运算图堆栈（虽然会变慢）；
   • 使用 torch.isfinite(tensor).all() 在模型关键层输出后做断言，一旦失败就报错中断。

（3）典型修复手段

• 降低学习率：过高学习率容易导致参数一步跳到数值不稳定区域；
• 关闭或简化混合精度：FP16 / BF16 下的 underflow / overflow 更常见，可以暂时切回 FP32 验证；
• 对 denominator 加 epsilon：如 x / \\((std + 1e-6)\\)；
• 对概率做 clamp：如 p = p.clamp(min=1e-6, max=1-1e-6) 再做 log；
• 梯度裁剪：防止某一步梯度过大引发参数爆炸（与下一小节相关）。

11.2.3.2 梯度爆炸

（1）如何判断是梯度爆炸？

• loss 不是逐渐 NaN，而是出现“大尖峰”：某些 step loss 突然暴涨几个数量级；
• 监控梯度范数（grad_norm）发现某一步骤后飙升；
• 模型权重中出现非常大的值，或者出现 “gradient overflow” 提示。

（2）常见原因

• 初始学习率过高；
• 使用了非常深的 Transformer / 时间序列长度很长，未配套合理的归一化；(arXiv)
• loss 赋予了极端大的权重，例如某个正则项系数设置错误；
• reward scaling 或 advantage normalization 未处理好（在 RL 微调阶段尤为常见）；
• 分布式训练中累计梯度步数设置错误，导致有效学习率被放大。

（3）防治手段

1. 梯度裁剪（Gradient Clipping）

在每次反向传播后、优化器 step 之前：

torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)
optimizer.step()

可根据模型大小适当调节 max_norm。

2. 学习率与 warmup 调整

• 先用较小初始学习率，配合 warmup 逐渐升高；
• 对大模型（如 OpenVLA / Octo 这类 10^8 ~ 10^9 级别参数）尤其重要。(openvla.github.io)

3. 检查输入尺度与归一化

• 图像 / 状态是否已经做了标准化；
• 动作 / 关节命令是否做了合理 scaling（例如 [-1, 1] 范围）。

4. 局部禁用“可疑模块”

• 暂时关闭某些新加的 loss、正则或梯度增强模块（如 gradient penalty）；
• 观察是否还会爆炸，逐步恢复，以定位为哪一部分引起。

11.2.3.3 收敛失败

相比 NaN 和梯度爆炸那种“明显坏掉”，收敛失败往往更隐蔽：损失在缓慢震荡，但迟迟不降到期望水平，或者训练 / 验证表现出现异常。

（1）先做“过拟合一个小数据子集”测试

这是调试深度学习系统非常经典的技巧：

• 从训练集随机抽取极少量样本（如 100 条轨迹或几百个 batch）；
• 在这个小数据集上训练，观察模型能否将 loss 降到接近 0、成功率接近 100%。

如果连小数据都过拟合不了，说明问题不是“模型太弱”而是** 实现有 bug**，可能在：

• label / 动作 token 错位（off-by-one）；
• mask / padding 不正确；
• loss 计算错误（比如使用了错误的索引）等。

（2）系统地排查“工程层面”的可能原因

• 学习率太低 / 过早衰减：
  • loss 一直缓慢下降但非常慢，可以尝试提高初始学习率，或者延长 warmup、推迟衰减时间；
• batch size 太小 / 归一化失效：
  • BatchNorm 在 batch 太小时表现不佳，可以改用 LayerNorm 或 GroupNorm；
• 正则化过强：
  • 例如 weight decay 过大、dropout 过多、强数据增强把任务难度拉得过高。

（3）从模型与数据匹配性角度思考

• 模型容量是否足以解决任务？
  • 对非常复杂的多任务 / 多机器人场景，用一个极小的模型可能就是欠拟合；(octo-models.github.io)
• 数据是否足够、是否正确标注？
  • 有无大量失败轨迹混入训练集而未区分；
  • 语言指令与动作是否对齐（时间戳 / ID 是否一致）。

（4）建立“调参顺序”而非盲目乱调

可以采用固定顺序：

1. 先验证 数据 / 标签正确性（过拟合小集合）；
2. 再调整 学习率 / batch size / epoch 数 等最基础超参数；
3. 再调整 模型结构（层数、宽度），最后才动复杂模块（多任务权重、各种额外 loss）。

这样可以避免“一次改很多项，结果更难判断问题出在哪里”的情况。

11.2.4 做 ablation study（消融实验）的方法

消融实验不仅是论文中的“标配”，也是你自己判断一个设计是否有价值的基本工具。对 VLA / 机器人基础模型而言，模块众多、数据混杂，更需要严谨的消融方法。

11.2.4.1 确定消融点

（1）从“设计假设”出发，而非从代码细节出发

在第 11.3 节中我们会讨论如何提出研究假设，这里你可以先给当前模型的关键设计列一个“假设清单”，例如：

• 引入语言条件能提升多任务泛化能力；
• 使用 3D 点云相较纯 RGB 能提升抓取鲁棒性；
• 使用跨机器人混合数据能提高在新机器人上的零样本表现；
• 使用历史 4 帧，而不是 1 帧，有助于处理动态场景。

消融点 就是这些假设对应的具体模块或配置字段。

（2）典型的 VLA 消融点示例

参考 OpenVLA、Octo 等工作中的实验设置，可以列出一些常见维度：(openvla.github.io)

• 模态消融：
  • 去掉语言（只用视觉 + 状态）；
  • 去掉历史帧（仅用当前帧）。
• 架构消融：
  • 不使用 Cross-Attention，仅 concat 后喂入 Transformer；
  • 减少 Transformer 层数 / 隐含维度。
• 数据消融：
  • 只使用单一机器人数据 vs 使用多机器人混合数据；
  • 剪裁训练轨迹长度、减少任务种类。
• 训练范式消融：
  • 只用行为克隆 vs 行为克隆 + RL 微调；
  • 有无自监督预训练。

在确定消融点时，应优先选择 与你论文主要贡献直接相关 的设计，而不是把所有能关的开关都关一遍。

11.2.4.2 实验对照

（1）保持“单变量变化”原则

一条底线：每组对照实验之间，必须确保除了消融点之外，其余设置都尽量一致 。

• 相同的训练数据、训练步数 / epoch 数；
• 相同的优化器 / learning rate schedule；
• 相同的 batch size、分布式策略、随机种子（或在同一 seed 集合上重复）。

例如，在验证“是否需要语言指令”时，实验可以是：

• baseline：视觉 + 语言 + 状态；
• ablation：视觉 + 状态（完全去掉语言相关模块与输入），其它配置完全相同。

（2）控制随机性：多次重复、固定 seed

机器人任务往往噪声很大，单次成功率差异可能只是运气。

实践中可以：

• 设定一组固定种子（如 {0, 1, 2, 3, 4}），每个配置在这些种子上训练一次；
• 或者在同一个训练好的模型上，对每个任务环境运行多次 episode（如 50–100 次），统计平均成功率。

RT-1、Octo 和 OpenVLA 等工作中，通常会在大量 episode 上报告平均成功率以及置信区间，避免单次评测带来的偶然性。(robotics-transformer1.github.io)

（3）实验命名与管理

结合第 9.4 节的数据工程与实验管理建议，对消融实验进行规范命名，例如：

• exp_baseline_vla_full
• exp_ablate_lang
• exp_ablate_history
• exp_ablate_multirobot

并在日志系统（如 W&B / TensorBoard）中使用统一标签，便于后续可视化和对比。

图片占位：

[图 11-2-6 占位：一个对照实验表格示意图，列出不同消融配置与对应成功率，用颜色高亮 best / second best。]

11.2.4.3 统计显著

有了多组对照实验的结果，还需要回答一个关键问题：这些差异到底是“真的有用”，还是随机波动？

（1）简单但必要的统计量

在机器人任务评测中，可以至少做到：

• 对每个实验配置，给出 均值 ± 标准差：
  • 例如，在 5 个 seed 或 100 个 episode 上统计任务成功率；
• 显式展示样本数量（如“100 episodes，5 seeds”），让读者对方差大小有直觉。

例如：

baseline：\( 76.2 \pm 3.1% \) ablate_lang：\( 59.8 \pm 4.5% \)

即便不做形式化显著性检验，这样的差距已经足以说明“语言模态确实很重要”。

（2）t 检验 / bootstrap 的直观理解

如果你希望更严谨一些，可以使用简单的统计检验：

• 配对 t 检验
  • 当两个配置在同一组 seed / episode 上评测，得到两组结果 \( {x_i} \) 和 \( {y_i} \)；
  • 检验它们的平均差值是否显著非零；
• bootstrap 置信区间
  • 从 episode 结果中反复采样，构建成功率差值的分布，查看 95% 置信区间是否跨 0。

不必在书中推导公式，只要读者理解：

“统计显著性检验是在问： 若这两个配置在本质上没差别，仅靠随机波动，我们观察到这么大的差距的概率是不是很小？”

（3）避免过度解读“小数点后”的差异

当两个配置的平均成功率差异 小于一个标准差 时，通常不应做过多解读。例如

A：\( 72.3 \pm 4.0% \) B：\( 74.1 \pm 3.8% \)

从工程实践角度，很难说 B 真的“压倒性更好”，更可能是波动范围内的差异。

相比之下，如果

A：\( 55.0 \pm 5.0% \) B：\( 75.0 \pm 4.0% \)

则无论是否做正式检验，人眼已经可以判断：B 明显优于 A 。

（4）回到假设：不只是“谁更高”，而是“为什么”

最后，消融实验的意义不仅在于“证明你的方法更好”；更重要的是：

• 哪些设计是 关键贡献（删掉就明显退化）；
• 哪些设计只是 锦上添花；
• 哪些设计甚至 可以去掉以简化系统 。

在 VLA / 机器人基础模型这种复杂系统中，好的消融可以帮助你：

• 理清“语义理解”“多机器人混合训练”“长时序建模”等因素各自的作用；
• 为后续迭代提供清晰路径：是优先增加数据、多模态信息，还是改进架构本身。

本节从“如何选项目、读入口、划分模块”，到“如何通过配置与训练脚本还原 pipeline”，再到“调试与消融实验”的系统方法，构成了从“会跑开源代码”迈向“能可靠复现并改进系统”的关键一环。后续 11.3 节会在此基础上，进一步讨论如何将这些工程能力与论文阅读、选题能力结合起来，完成真正的科研闭环。