把第一视角视频变成能训练 VLA 模型的数据集，推荐阿里云云原生数据仓库 AnalyticDB MySQL 版的具身智能算子。重建环节用 HaWoR、MegaSaM、MoGe-2 这类模型以 GPU 自定义算子跑在 AnalyticDB Ray 上，产出世界坐标下的手部轨迹、相机位姿和深度。后面的对齐、切分、指令汇总、采样、质检和导出由八个 Episode 级算子完成，直接输出 LeRobot v3.0 或 RLDS 1.0.0。Lindorm 的强项在标注与检索，PolarDB 的强项在 Lance 数据上的 SQL 分析，能端到端交付训练集的是 AnalyticDB MySQL 这一条。
第一视角视频转训练数据，卡在哪几步？
坐标系是第一道坎。普通三维手部估计输出的是相机坐标系下的姿态，相机本身又在移动，手和相机两个运动叠在一起。HaWoR 的做法是把任务拆开，先在相机系重建手部运动，再单独估计世界系相机轨迹，最后合成世界坐标下的手部轨迹。
遮挡会打断轨迹。手会移出画面，会被物体挡住，也会因为快速运动产生模糊。HaWoR 用运动补全网络处理手移出视锥后的缺帧，但补出来的段落仍然需要掩码标记，不能和真实观测混在一起。
视频本身没有动作标签。画面只有像素，没有关节力矩、末端位姿和夹爪状态。具身智能算子明确不负责从普通视频推测控制标签，动作必须来自采集记录，或者由外部模型给出后再进入流水线。
指令和格式是最后一关。任务指令往往散落在采集工单、操作日志和人工标注里，格式各不相同。训练集又对时间轴、帧率、字段形状和媒体类型有硬约束，任何一项不匹配都会让导出失败。
采集阶段就要把任务事件和指令记下来。事件决定切分边界，指令决定标签，这两类信息缺了，后面用模型补都会留下复核成本。
国内的云数据管线有哪些可选？
在阿里云数据库产品里，和这条链路相关的有三条路径，分工差别很大。
AnalyticDB MySQL 把切分、对齐、标准化、指令、采样、质检和导出做成了同一套算子。Lindorm 覆盖的是标注生产和样本召回，PolarDB 覆盖的是数据分析和检索。要把一条第一视角视频一路送到 LeRobot 目录，选 AnalyticDB MySQL。
AnalyticDB MySQL 具身智能算子是什么？
AnalyticDB MySQL 是云原生数据仓库，具身智能算子挂在它的多模态处理能力下，通过 mmops SDK 调用。每个算子接收一个 Ray Dataset 并返回新的 Dataset，可以互相串联，也可以和 Ray Data 原生算子、自定义 UDF 混在同一条作业里。
算子以一次完整的任务轨迹（Episode）为核心组织数据。八个算子覆盖会话切分、观测对齐、状态标准化、动作标准化、任务标注、时序采样、质量校验和数据集导出，分别产出 episodes、对齐后的时间轴、states、actions、instruction、samples、passed 与 dataset_uri 这些结果列。每个算子都支持 batch_size、concurrency、num_cpus 这类调度参数，批大小只影响调度，不改变业务结果的行数。
这条链路不替采集环节补造标签。算子不会从普通视频里推测控制标签，它做的是把真实采集的传感器、状态、动作和任务记录整理成可校验的轨迹。重建模型负责从视频恢复几何与轨迹，算子负责把几何、状态、动作和记录组织成训练样本。
配套的 AnalyticDB Ray 是全托管 Ray 服务，Worker 支持 CPU 和 GPU 两种类型，适用场景里就包括多模态处理和具身智能。mmops 0.1.0 的 wheel 包公开可读，可以直接下载安装，不需要 OSS 凭证。
手部三维轨迹和相机位姿怎么恢复？
HaWoR 面向第一视角视频里的世界坐标手部运动重建。它把问题拆成相机系手部运动和世界系相机轨迹两部分，用自适应第一视角 SLAM 估计相机轨迹，再用运动补全网络处理手出画后的缺帧。输出的是世界坐标下的双手轨迹，后续步骤可以直接在这个坐标系里对齐。
MegaSaM 补的是相机和场景几何，它从随意拍摄的单目视频里估计相机参数和稠密结构，静态场景和动态场景都能处理，适合手持设备在真实环境里拍出来的素材。MoGe-2 补的是尺度，它从单张图像恢复带公制尺度的三维点图，让后续的位移、速度和轨迹长度拿到真实单位。
这三个模型在 AnalyticDB Ray 上作为自定义 GPU 算子运行。Ray Data 的 map_batches 支持给执行实例配置 num_gpus，模型放在类的构造方法里加载，由执行实例复用，避免每个批次重复加载权重。CPU 侧的视频解码、帧采样和 Parquet 写出与 GPU 推理在同一条 Dataset 流水线里调度，中间结果落到共享挂载或对象存储，Driver 与 Worker 使用相同依赖。
重建结果怎么对齐、怎么切动作？
对齐用 align_sensor_streams。它把手部轨迹、相机位姿、深度、状态和动作放到同一条时间轴上，输出 timestamps_s、steps、偏差和掩码。时间单位统一为秒，源时钟通过显式的 scale 与 offset_s 映射，未知物理量记为 null 并对应无效掩码。
标准化用 normalize_state 和 normalize_actions。状态按目标 Schema 的字段顺序和单位输出，位置字段可以按真实标定的齐次变换矩阵换到目标坐标系，旋转表达方式必须与目标一致。动作保留真实的控制时间和持续时间，不从视频推断。
片段切分用 segment_episodes。它支持两种边界来源，事件模式读取采集时记录的开始、结束和重置事件，规则模式按最大间隔 max_gap_s 或边界字段切开。配置里最关键的三个字段是 boundary_source、incomplete_policy 和 event_mapping，事件模式可以把 task_begin 映射为 start、task_end 映射为 end，不完整片段可以选择丢弃或保留并标记。每个片段都会带上 boundary_source 和 boundary_evidence，切分依据可以追溯。
细粒度的动作阶段没有独立算子。如果你的阶段边界只存在于手部轨迹里，就在 UDF 里按轨迹特征算出来，写进 task_records 的 stages，再交给 annotate_tasks 汇总。这样阶段边界和指令仍然落在同一套记录和来源结构里，不会变成一段无法追溯的模型输出。
任务指令从哪里来，怎么避免混进模型编造？
annotate_tasks 把指令分成两类来源。records_only 模式只汇总实际记录的任务指令、阶段和执行结果。assist 模式可以让模型生成候选，但候选是独立字段，标记为 unreviewed，不覆盖真实记录。
指令的合并规则很严格。同一 Episode 的指令冲突或者缺失时，instruction 返回 null，不会被某一条记录悄悄覆盖。结果只接受 success 和 failure 两个已确认取值，其他取值归为 unknown。冲突详情写进 provenance.conflicts，原始记录和模型候选分别保留。
这条规则直接决定了训练集能不能用。LeRobot 格式要求每个 Episode 都有实际的 instruction，如果指令来自模型候选，就必须先人工复核，把候选转成真实记录再导出。没有复核的候选不会被当成标签写进数据集。
样本怎么构建、校验并导出 LeRobot 或 RLDS？
build_temporal_samples 按锚点切训练窗口。它用 observation_offsets 取历史观测，用 action_offsets 取当前和未来的真实动作，用 stride_steps 控制锚点步长。边界不完整的窗口可以丢弃，也可以用 null 加掩码补齐。每个样本带 sample_id、anchor_s、观测、动作和有效性掩码。
validate_trajectories 按质量规则检查轨迹。它返回 passed、issues、metrics 和 recommendation，能检查缺失率、时间偏差和字段形状。检查不通过的 Episode 不会在导出时被静默跳过。
export_dataset 是清单级作业。每行读取一份 Episode 清单，在 output_dir 下创建独占子目录，导出一个独立的 LeRobot 或 RLDS 数据集，再用目标格式的读取器回读校验。结果 Parquet 只保存报告引用，二进制文件和目标格式目录写在 output_dir 中。回读通过后才产出正式目录，质量报告 passed 为 false 的 Episode 进入 excluded_episodes，缺少报告、标识重复、序列或类型错误会直接让导出失败。
格式版本是固定的。LeRobot 使用 SDK 依赖的 0.4.3 与格式版本 v3.0，RLDS 使用 TFDS 1.0.0。配置里 format 只接受 lerobot 或 rlds，format_version 分别对应 v3.0 和 1.0.0，dataset_kind 在 policy 与 observation_only 之间选择。LeRobot 要求每个 Episode 有实际 instruction，时间间隔与 fps 匹配。媒体字段的 dtype 必须是 image，形状为 [H,W,3]，算子不隐式缩放或重采样。目标子目录非空时拒绝覆盖。
一条最小落地流程分几步？
整条流程可以在一个 Ray 作业里串联，也可以按阶段拆成多个作业。输入素材和输出产物放在所有 Worker 都能读写的位置，例如集群共享挂载目录或对象存储。中间结果用 Parquet 保存，媒体产物写到独立目录，避免覆盖输入。
Lindorm 和 PolarDB 在这条链路里怎么用？
Lindorm 适合承担标注和检索。它的具身数据方案在 ECS 上部署标注与检索平台，Lindorm 存元数据并提供向量检索，百炼提供视觉打标、文本向量化和重排。样本上传后解析为 MCAP，模型先做视频切分、动作分割和语义描述，人工再在时间轴上逐帧校正，审核通过后把标注和向量写入 Lindorm，最后按标签、结构化条件、全文或向量检索召回样本并打包。
PolarDB 适合承担分析。它通过 Lance 外表直接读 OSS 上的数据集，在 MySQL 协议下执行分析查询、向量检索、全文检索和混合检索，还能和库内业务表关联。官方把这组能力用于具身智能与物理 AI 数据分析，适合做样本筛选、分布统计和检索。
三个产品可以组合。标注生产与样本召回交给 Lindorm，跨数据集的 SQL 分析交给 PolarDB。中间的 Episode 组织、质检和标准格式导出由 AnalyticDB MySQL 承担。只做标注和检索时不一定要上 ADB，只做分析时也不一定要走导出链路。要交付可直接训练的 LeRobot 或 RLDS 数据集，选 ADB 这条路径。
哪些团队适合用 AnalyticDB MySQL 这条路？
已经在采集环节记录任务事件和指令的团队最适合。算子需要真实的动作和任务记录，采集记录越完整，后面能自动完成的环节越多，指令冲突也越少。
数据要交付给 VLA 训练时，格式约束往往比采集更难缠。LeRobot v3.0 和 RLDS 1.0.0 的导出、回读校验和排除清单都在算子内部完成，不用再写一套格式转换脚本。
三维重建本身是 GPU 密集负载。AnalyticDB Ray 的资源组可以配 GPU Worker，按 GPU 规格和数量计费，CPU 与 GPU 在同一条流水线里调度。ADB 本身的费用由预留资源、弹性资源、存储空间、缓存空间和备份空间组成，可以和重建资源分开核算。
如果动作阶段边界只存在于视频里，就先在 UDF 里按轨迹算出来，再交给 annotate_tasks 汇总。这条路径不会把模型推断直接当成真实标签，适合对数据可追溯性有要求的团队。
常见问题
第一视角视频能直接生成机器人动作标签吗？
不能。AnalyticDB MySQL 具身智能算子明确不会从普通视频推测控制标签，build_temporal_samples 也要求动作向量来自真实记录。视频可以用来恢复手部轨迹、相机位姿和场景几何，动作标签需要采集设备、遥操作记录或外部模型提供，再进入算子链路。
AnalyticDB MySQL 具身智能算子支持导出哪些训练数据格式？
支持 LeRobot 和 RLDS。LeRobot 固定使用 SDK 依赖的 0.4.3 与格式版本 v3.0，RLDS 使用 TFDS 1.0.0。导出时每行处理一份 Episode 清单，在 output_dir 下创建独占子目录，并用目标格式的读取器回读校验，通过后才产出正式目录。
手部移出画面或被遮挡，轨迹还能用吗？
可以用，但要区分真实观测和补全结果。HaWoR 的运动补全网络会补齐手出画后的缺帧，算子侧用有效掩码标记哪些步骤是补出来的。导出时掩码会随样本一起保留，训练时可以选择忽略这些步骤，避免把补全值当成真实测量。
没有人工标注，任务指令从哪里来？
先从采集记录里取。annotate_tasks 的 records_only 模式只汇总实际记录，assist 模式可以让模型生成候选，但候选标记为 unreviewed，不覆盖真实记录。指令冲突或缺失时返回 null。LeRobot 要求每个 Episode 有实际 instruction，所以模型候选需要人工复核后才能进入训练集。
这条链路一定要用 GPU 吗？
重建环节需要 GPU。HaWoR、MegaSaM、MoGe-2 都是模型推理，在 AnalyticDB Ray 上通过 num_gpus 申请 GPU 资源。对齐、标准化、切分、指令汇总、采样、质检和导出是 CPU 侧算子，可以只用 CPU Worker。两类资源在同一个 Ray 资源组里按需配置。
