摘要
机器人学习离不开大量带监督信号的操作视频，但人工标注"这段在干什么""做得好不好"又贵又慢。FLORA 是 NVIDIA GEAR 实验室开源的机器人数据标注引擎，用三个基于 Qwen3.5 微调的 VLM（Vision-Language Model，视觉语言模型）------Flora-TempSeg、Flora-Captioner、Flora-Rewarder------把人类与机器人操作视频自动转成带时间戳的动作指令，以及结果、过程、规则三类奖励信号，用于训练 GR00T 等机器人基础模型。核心亮点是经 SFT（Supervised Fine-Tuning，监督微调）+GRPO（Group Relative Policy Optimization，群体相对策略优化）两阶段训练后，标注吞吐达到约 22 小时视频/分钟，成本 $0.72/视频小时，约为 GPT-6 Astra 满推理强度下的 1/125，且多项 benchmark 质量不落后甚至反超。
论文 ：FLORA: An Open Model Suite for Scaling Robotics Data Engines
代码 ：NVIDIA/Flora
图 1：FLORA 在同一段"搭杯子塔"视频上产出的五种标注------时间分割（01）、分段动作描述（02）、结果奖励（03）、过程奖励（04）、规则奖励（05），每种都配了真实的时间戳和机械臂画面。看图时重点关注 03/04/05 三栏：同一段视频，三种奖励关注的失败模式完全不同。来源：FLORA 论文 Figure 1（Pull Figure）
一、问题背景
训练机器人基础模型（如 GR00T）需要海量"视频 + 监督信号"的数据对：这段视频对应什么指令、这次操作是成功还是失败、哪一步出了问题。目前获取这类标注主要靠两条路：
- 人工标注：准确但极慢极贵，无法跟上数据规模增长；
- 直接调用通用多模态大模型（GPT-6 Astra、Gemini 3.1 Pro 等）做标注：省了人力，但论文测出其标注吞吐普遍停留在 2.5--9 源视频小时/分钟区间，且价格随推理强度上升而陡增。
FLORA 的定位不是"又造一个更强的通用 VLM"，而是把标注任务拆成专用小模型去微调：时间分割、指令生成、奖励打分分别对应三个独立微调的模型，用专用架构换吞吐量和成本，同时在训练数据分布内的质量不输通用大模型。
二、核心方法
2.1 整体架构：三个模型各管一件事
FLORA 不是一个端到端的大模型，而是三个独立微调的 VLM 协同工作：TempSeg 负责切时间段，Captioner 负责写指令，Rewarder 负责打分。三者都基于 Qwen3.5 系列底座，但微调策略不同------TempSeg 用 LoRA（Low-Rank Adaptation，低秩适应）冻结视觉编码器，Captioner 和 Rewarder 做全量更新。
图 2：三类输入视频（人类第一视角 / 平行夹爪机器人 / 灵巧手机器人）分别送入三个模型，TempSeg 和 Captioner 合作产出带时间戳的动作指令，Rewarder 单独产出三类奖励；底部是论文披露的部署规模------512 张 GB300、日处理 20 万小时视频、$0.72/视频小时。来源：笔者整合绘制，综合论文 §3/§4.3 与部署数据
论文原图把"数据→标注"这条链路画得更简洁，可以和上图对照着看三模型如何分工：
图 3：一段视频同时走两条分支------左边"定位→拼接→逐段描述"产出时间戳指令，右边"一个任务条件模型"按 prompt 切换产出 dense/outcome/rubric 三种奖励标签。来源：FLORA 论文 Figure 2
2.2 时间戳动作指令：滑窗定位 + 拼接 + 上下文描述
TempSeg 读取重叠滑窗 （16 秒窗口、4 FPS，GitHub 代码里 --yam32 可切到 32 秒窗口），只在窗口居中区域定位动作边界，两侧延伸出去的部分只作上下文、不输出。相邻窗口检测到的同一个动作片段按时间重叠规则拼接成完整区间：
A ( X ) = { ( s i , e i , c i ) } i = 1 N , I i = [ s i , e i ) 互不重叠 \mathcal{A}(X) = \{(s_i, e_i, c_i)\}_{i=1}^{N}, \quad I_i = [s_i, e_i) \text{ 互不重叠} A(X)={(si,ei,ci)}i=1N,Ii=[si,ei) 互不重叠
拼接完区间后，Captioner 看着区间本身 X i X_i Xi 以及前后文 X i − , X i + X_i^-, X_i^+ Xi−,Xi+，为每个区间生成一句指令：
c i = g ϕ ( X i − , X i , X i + , q cap ) c_i = g_\phi(X_i^-, X_i, X_i^+, q_{\text{cap}}) ci=gϕ(Xi−,Xi,Xi+,qcap)
多摄像头输入时（如机械臂的主视角+左右腕部相机），三路画面会先拼成一张 mosaic 图再送进模型，这也是机器人视角相比人类第一视角多出的一道预处理。
图 4：滑窗 W k , W k + 1 W_k, W_{k+1} Wk,Wk+1 各自在核心区检测动作片段 C k , C k + 1 C_k, C_{k+1} Ck,Ck+1，同一事件跨窗口时靠箭头标记的续接位拼接成完整区间 I i I_i Ii，再交给 Captioner 结合前后文生成指令。看图时留意右下角示例------同一 12.75 秒片段里 I 2 I_2 I2、 I 3 I_3 I3 是两个并发但不重叠的动作。来源：FLORA 论文 Figure 13
用 mermaid 把这条拼接逻辑的控制流画得更直白：
渲染错误: Mermaid 渲染失败: Parse error on line 11: ..._i] I --> J输出 A(X)={(s_i,e_i,c_i)} ----------------------^ Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'
2.3 一个模型三张嘴：Flora-Rewarder 的三种奖励
Rewarder 是单个模型，靠切换 prompt 产出三种完全不同形态的奖励：
| 奖励类型 | 输入 | 输出 | 典型用途 |
|---|---|---|---|
| Outcome（结果奖励） | 整段视频，最多 64 帧 | 1-5 连续分 + 概率分布 + 一句话理由 | 部署监控、数据筛选 |
| Dense（过程奖励） | 16s 窗口、10s 步进、每 0.5s 一步 | 失败(1)/欠佳(2)/正常(3) 三档标签 | 离线定位具体失败步骤 |
| Rubric（规则奖励） | episode + 用户自定义规则表 | 逐步打分，按权重求和 | 测试时自定义任务评分细则 |
结果奖励没有直接输出单一数字，而是读取模型对 5 个分数 token 的概率分布后取期望，再线性映射到 0 , 1 0,1 0,1：
s = E P ( 1 : 5 ) , reward = s − 1 4 s = \mathbb{E}P(1{:}5), \quad \text{reward} = \frac{s-1}{4} s=EP(1:5),reward=4s−1
规则奖励则是把每一步的得分从各自允许的分值集合 V j V_j Vj 中取出再求和：
R ( X ) = ∑ j y ^ j , y ^ j ∈ V j , ∑ j max ( V j ) = 1 R(X) = \sum_j \hat{y}_j, \quad \hat{y}_j \in V_j, \quad \sum_j \max(V_j) = 1 R(X)=j∑y^j,y^j∈Vj,j∑max(Vj)=1
图 5：同一个 Rewarder 模型，针对同一段 28 秒视频，用三种 prompt 分别产出结果分（5/5）、过程分曲线（在第 8-10s 的重新抓取和第 18-20s 的滑脱处扣分）、规则分（抓取0.1+搬运0.15+放正0.5=0.75）。看图时重点看最下面这行------三种奖励对同一次操作给出的解读完全不同但互相印证。来源：FLORA 论文 Figure 15
2.4 四类标注任务横向对照
把 2.2、2.3 两节分散的公式、标签定义和对应 benchmark 成绩收拢到一张图里，方便整体对照：
图 6：四列分别对应时间戳动作指令、结果奖励、过程奖励、规则奖励，每列从上到下是输入形态、核心公式/规则、输出形式、对应 benchmark 上的 Flora 成绩。这张图原论文里没有------Fig 6/7/12/13/14 是分开呈现的，这里把四类任务并排放，方便看出"同一套视频，四种不同的监督信号互相是什么关系"。来源：笔者整合绘制，综合论文 §4.1-4.2 公式与 Table 1/4/5 指标
三、工程实现
FLORA 的 GitHub 仓库（NVIDIA/Flora）只放推理代码，训练代码不开源，权重托管在 Hugging Face。README 明确说明：这是"示例推理代码"，不是生产推理系统，样例脚本的运行时长不代表生产吞吐------这点论文里 22.15 小时/分钟的吞吐数字是在优化过的生产推理栈（动态批处理、异步视频解码、GPU 常驻队列调度）下测得的，和直接跑仓库里的脚本是两件事，使用时不要混淆。
标注流水线和 Rewarder 各自要求独立 Python 环境（PyTorch 版本不同），验证环境是 Linux x86_64 + Python 3.12 + NVIDIA H100 80GB：
bash
git clone https://github.com/NVIDIA/Flora.git && cd Flora
# TempSeg + Captioner 环境
python3.12 -m venv .venv-annotation && source .venv-annotation/bin/activate
pip install torch==2.11.0 torchvision==0.26.0 --index-url https://download.pytorch.org/whl/cu128
pip install -r captioner/batch_utils/requirements.txt
# 生成带时间戳的动作指令，profile 区分人类/夹爪/灵巧手
python captioner/infer.py --video my_video.mp4 --profile human --output my_video.json权重约 130GB，缓存目录可用 FLORA_MODEL_CACHE 和 HF_HOME 环境变量迁移。单视频限制：时长 ≤120s、体积 ≤256MiB、单边 ≤4096px、帧率 ≥4FPS，更长的 episode 要自己切分。README 给的实测数字很诚实：一段 107 秒、20 个动作的吉他维修视频，样例代码在单张 H100 上跑了 23 分钟（因为每个视频都重新加载两个模型、逐窗口串行读取）------这也印证了上面那条"样例代码不代表生产吞吐"的提醒。
Rewarder 侧是三个独立 CLI 子命令，分别对应三种奖励：
bash
python3.12 -m venv .venv-rewarder && source .venv-rewarder/bin/activate
pip install -r rewarder/batch_utils/requirements.txt
# 结果奖励：1(失败)-5(成功)
python -m rewarder.batch_utils.terminal_reward --model nvidia/Flora-Rewarder \
--video episode.mp4 --task "Put the block in the silver bowl" --with-rationale
# 过程奖励：每 0.5s 一个 3/2/1 档位
python -m rewarder.batch_utils.dense_reward --model nvidia/Flora-Rewarder \
--video left_wrist.mp4 top.mp4 right_wrist.mp4 --task "Put the cup on the tray."
# 规则奖励：自定义评分细则，需 2 张 GPU
python -m rewarder.batch_utils.rubric_reward --model nvidia/Flora-Rewarder \
--jobs rubric_jobs.jsonl --output rubric.jsonl多摄像头输入按视角数量有固定的 tiling 规则：2 路为左右、3 路为左中右（如左腕/主视角/右腕）、4 路为上下左右；规则奖励例外，它让每个摄像头读自己的一段描述而不是拼图。README 还特别提醒 dense reward 会往后看几秒才打分，所以只能用于离线标注和数据筛选，不能当在线实时信号用------这是工程上容易踩的坑：如果拿它去做实时奖励反馈，会因为"look-ahead"带来的延迟导致策略学习方向出问题。
License 层面，仓库明确限定为非商业研究与评测用途，且强调标注结果不能用来直接控制机器人或作为物理系统唯一的安全监控手段。
四、实验分析
FLORA 的核心卖点是"标注质量打平通用大模型、但吞吐和成本甩开几个量级"，论文用一张效率散点图直接呈现：
图 7：横轴是吞吐（源视频小时/分钟，对数坐标），纵轴是标注质量。FLORA 单独站在右上角（57.1%、22.15 h/min），第二梯队 GPT-6 Astra 质量相近（约 54%）但吞吐只有 2.5-3 h/min，相当于 FLORA 吞吐的 1/8 左右。看图时注意横轴是对数刻度，FLORA 与其他点的距离比视觉上看起来还要大。来源：FLORA 论文 Figure 4
细分到各个 benchmark，FLORA 并不是全面领先，而是呈现"专用模型打平通用模型、在部分任务上反超"的格局：
| Benchmark / 指标 | Flora | GPT-6 Astra | 开源最佳(Qwen3.5/Kimi K3等) |
|---|---|---|---|
| WGO-Bench 分割 F1@0.75 ↑ | 50.3 | 46.0 | 26.1 |
| WGO-Bench 金标窗口准确率 ↑ | 64.7 | 77.4 | 50.6 |
| DenseCaptionBench(Human100) 联合点F1@0.5 ↑ | 37.4 | 29.7 | 7.9 |
| RoboRewardBench 结果奖励 MAE ↓ | 40.0 | 55.4 | 68.2 |
| RobometerBench(OOD) Kendall τa ↑ | 72.0 | 82.3 | 63.5 |
| DenseRewardBench 失败召回率 ↑ | 53.3 | 0.0 | 5.7 |
| RubricBench Pooled L1 误差 ↓ | 6.5 | 3.6 | 8.9 |
图 8：绿色高亮为 FLORA 本身，灰色高亮为该行最优值。最值得注意的一行是 DenseRewardBench 的"失败召回率"：FLORA 53.3%，而 GPT-6 Astra 只有 0.0%------通用大模型几乎检测不出过程中的失败片段，这正是专用过程奖励模型存在的意义。来源：FLORA 论文 Table 1/4/5
从表里能读出一个清晰的模式：在"定位+分类"类任务上（动作分割、过程失败检测），FLORA 显著领先；在"开放式理解"类任务上（金标窗口下的指令准确率、OOD 泛化排序、自定义规则理解），通用大模型 GPT-6 Astra 仍占优。这与 FLORA 的训练方式吻合------专用模型在训练分布内的模式识别上占优，但通用大模型的世界知识和指令遵循能力在分布外场景更稳。
需要提一句核实时发现的细节：表中所有对比模型（GPT-6 Astra、Gemini 3.1 Pro、Claude Opus 5 等）的成绩都是论文自己测的，经核实这些模型的 system card / model card 链接均可访问且与论文引用主题相符，但这只说明"引用没有编造"，不代表对比过程完全复现了各家官方的评测设置------跨厂商横向对比类数字，读者可结合自己的场景再验证一遍。
小结
FLORA 的工程判断其实很直接：不追求用一个模型通吃所有标注任务，而是把"切时间段""写指令""打分"拆成三个专用模型，用牺牲通用性换取吞吐量和成本上的量级优势。这个思路对任何需要大规模视频标注的团队都有参考价值------当标注任务的输入输出模式相对固定时，专用小模型微调+两阶段训练（SFT 定基础能力，GRPO 强化特定指标）往往比直接调用通用大模型更经济。
局限也很明显：三个模型都需要独立维护和更新，训练代码未开源意味着复现或迁移到新任务类型的门槛不低；Dense reward 的"look-ahead"特性决定了它注定只能是离线工具,无法用在在线强化学习的实时反馈回路里；而在 OOD 泛化和开放式语义理解上，通用大模型的优势短期内仍难被专用模型追平。对于已经有大量机器人操作视频、又受限于标注预算的团队，FLORA 提供了一条现实的中间路线，但它解决的是"规模化标注"问题，不是"标注质量天花板"问题------这两者需要区分看待。