研究提案

[WIP] 视频教程步骤标注：操作序列理解的多模态训练数据

一个面向大型多模态模型（LMM）的视频教程步骤标注数据集构建方案，聚焦编程/技术操作类视频的步骤依赖关系与操作意图标注。

2026年3月30日多模态学习视频理解数据构建操作序列 LMM

[WIP] 视频教程步骤标注：操作序列理解的多模态训练数据

动机

LMM 在操作视频理解上的短板

当前大型多模态模型（LMM）在图像描述、视觉问答、场景理解等任务上已经相当成熟。然而，当任务变成「观看一段操作视频并理解其中的步骤序列」时，模型表现往往令人失望。

问题不在于感知能力——LMM 能识别帧里的代码编辑器、终端窗口、鼠标点击位置——而在于序列推理：步骤之间的因果依赖、中间状态的变化、以及操作意图的抽象。一个典型例子：给模型看一段「配置 Python 虚拟环境并安装依赖」的录屏，它可以逐帧描述每一步在做什么，却很难回答「为什么第 3 步必须在第 2 步之后执行」，更难在步骤出错时定位原因。

这种能力的缺失，根源在于训练数据的结构性空缺：现有视频训练数据几乎没有对步骤依赖关系和操作意图进行系统性标注。

为什么这个能力很重要

工程 AI 场景：面向开发者的 AI 助手（如 Copilot、Cursor）目前主要依赖代码上下文，无法利用视频教程这一海量知识来源。如果模型能理解操作视频中的步骤序列，就可以直接从 YouTube/Bilibili 教程中学习「如何部署一个 K8s 集群」「如何调试 CUDA OOM」。

实验室 AI 场景：科研人员日常会录制实验操作视频用于存档和传承。理解这类视频中的步骤依赖关系，有助于构建自动化实验记录系统和实验可重复性验证工具。

操作助手场景：在工业、医疗等领域，操作手册日益以视频形式存在。能够理解「这一步的前提是上一步完成了哪些状态变化」的 AI，才能真正充当合格的操作指导助手，而不只是播放视频的遥控器。

现有视频训练数据的缺口

目前主流视频数据集面临以下共同问题：

动作标注，而非步骤标注：标注的是「正在敲键盘」而非「正在安装依赖包以为后续导入做准备」。
无依赖关系：缺乏对「步骤 B 为何必须在步骤 A 之后」的显式建模。
无操作意图：缺乏对每步操作目的的抽象标注（functional intent），只有表面动作描述。
领域偏差：大量数据集集中在烹饪、运动等场景，技术操作类内容占比极低。

与现有方法的对比

现有视频理解数据集

ActivityNet（约 20K 视频，203 个活动类别）和 Kinetics（约 650K 视频片段）是动作识别领域的标杆数据集。它们的标注粒度是「动作类别」，每个片段对应一个独立动作标签，完全没有跨片段的依赖关系建模。

HowTo100M 是迄今最大的操作类视频数据集（136M 个视频片段，来自 1.2M YouTube 教学视频），通过自动对齐字幕与视频生成弱监督标注。然而其字幕来自自动语音识别（ASR），质量参差不齐，且没有对步骤之间的逻辑依赖关系进行任何标注——本质上仍是「动作描述序列」而非「步骤依赖图」。

COIN（约 11K 视频，180 种任务）在 HowTo100M 的基础上增加了步骤边界标注，是离本方案最近的工作，但仍然缺乏操作意图和依赖关系的标注，且技术操作类视频占比极低。

现有多模态指令数据

以 LLaVA、InstructBLIP 为代表的多模态指令数据集，主要建立在静态图像上。即使有视频版本（如 Video-LLaVA），视频数量远少于图像，且操作类内容更是凤毛麟角。这类数据的问题在于：它训练的是「看图说话」，而非「看操作序列推理依赖」。

本方案的差异化

维度	ActivityNet/COIN	HowTo100M	LLaVA-Video	本方案
领域	通用/生活	通用教学	通用	编程/技术操作
步骤边界	部分有	弱	无	✅ 精确
操作意图	✗	✗	✗	✅
依赖关系	✗	✗	✗	✅
标注来源	人工/弱监督	自动ASR	自动/人工	LMM辅助+人工验证

本方案的核心差异化在于两点：技术操作领域的专注，以及步骤依赖关系的显式标注。

具体方案

数据来源

主要面向三类视频来源：

YouTube/Bilibili 编程教程：涵盖环境配置、框架使用、项目部署等，是最丰富的来源。
终端操作录屏：如 Linux 配置、Docker 操作、数据库管理，操作边界清晰，适合自动化处理。
数据处理演示视频：Jupyter Notebook 操作、Pandas/SQL 数据清洗演示，步骤结构规整。

筛选条件：视频时长 5–45 分钟、分辨率 ≥ 720p、有语音解说、操作对象为屏幕内容（录屏类优先）。

采集 Pipeline

a. 字幕提取（Whisper ASR）

使用 OpenAI Whisper（large-v3）对视频音频进行转录，输出带时间戳的字幕片段。对于已有自动字幕的视频（如 YouTube CC），优先使用并与 Whisper 结果交叉验证。

b. 关键帧提取

采用双重检测策略：

场景变化检测：基于帧间像素差和直方图差异，设定阈值提取场景切换帧。
操作事件检测：针对技术操作视频特点，检测以下事件：光标大幅移动、新窗口/标签页出现、终端输出刷新、代码文件切换。

目标是每个「操作步骤」至少覆盖 3 个代表性关键帧：步骤开始帧、核心操作帧、步骤结束帧。

c. 步骤边界识别

通过字幕与视觉变化的联合判断识别步骤边界：

字幕中出现明确的步骤信号词（“接下来”、“然后”、“第N步”、“now let’s”）
视觉上发生场景级切换（如从编辑器切换到终端）
两个信号同时出现时置信度最高

对于信号不明确的区域，记录为低置信度段，优先送人工审核。

d. LMM 辅助标注操作意图

将每个步骤的关键帧序列 + 对应字幕文本，构造结构化 prompt 送入 GPT-4V 或 Claude 3.5 Sonnet，要求模型输出：

action_description：本步骤的表面操作描述（做了什么）
functional_intent：本步骤的功能意图（为了什么目的）
state_change：执行前后系统/环境状态的变化
prerequisites：执行本步骤需要哪些前提条件已满足

e. 依赖关系提取

在单视频内，基于 prerequisites 和 state_change 进行步骤间依赖推断：若步骤 B 的某个 prerequisite 与步骤 A 的某个 state_change 匹配，则建立 B → A 的依赖边。依赖图以有向无环图（DAG）形式存储。

数据格式示例

{
  "video_id": "yt_dQw4w9WgXcQ",
  "video_title": "Python 虚拟环境配置完整教程",
  "source": "youtube",
  "duration_sec": 742,
  "steps": [
    {
      "step_id": "step_001",
      "start_time": 12.4,
      "end_time": 38.7,
      "keyframes": [
        "frames/yt_dQw4w9WgXcQ/step_001_start.jpg",
        "frames/yt_dQw4w9WgXcQ/step_001_core.jpg",
        "frames/yt_dQw4w9WgXcQ/step_001_end.jpg"
      ],
      "transcript": "首先我们来安装 Python，打开终端输入 python3 --version 检查是否已安装",
      "action_description": "在终端执行 python3 --version 命令检查 Python 版本",
      "functional_intent": "确认系统中 Python 3 已正确安装，为后续创建虚拟环境做前提验证",
      "state_change": {
        "before": "未知系统 Python 安装状态",
        "after": "已确认 Python 3.11.x 可用"
      },
      "prerequisites": [],
      "confidence": 0.92
    },
    {
      "step_id": "step_002",
      "start_time": 39.1,
      "end_time": 67.3,
      "keyframes": [
        "frames/yt_dQw4w9WgXcQ/step_002_start.jpg",
        "frames/yt_dQw4w9WgXcQ/step_002_core.jpg"
      ],
      "transcript": "好，Python 已经安装好了，现在执行 python3 -m venv myenv 创建虚拟环境",
      "action_description": "执行 python3 -m venv myenv 创建名为 myenv 的虚拟环境",
      "functional_intent": "创建隔离的 Python 环境，避免全局包污染",
      "state_change": {
        "before": "无 myenv 目录",
        "after": "当前目录下生成 myenv/ 虚拟环境目录"
      },
      "prerequisites": ["Python 3 已安装且可从终端调用"],
      "confidence": 0.95
    }
  ],
  "dependency_graph": {
    "edges": [
      {
        "from": "step_002",
        "to": "step_001",
        "type": "requires_output",
        "reason": "step_002 的执行前提为 Python 3 可用，由 step_001 确认"
      }
    ]
  },
  "metadata": {
    "annotator": "gpt-4v-2024-11",
    "annotation_date": "2026-03-30",
    "human_verified": false,
    "quality_score": 0.88
  }
}

数据规模估算

粗略估算目标数据规模：

YouTube 技术教程类视频存量约 500 万条（2024 年估计），其中符合筛选条件（时长/分辨率/有解说）的约 10%，即 50 万条。
每视频平均步骤数约 15 步，初始可提取步骤约 750 万步骤。
经过质量筛选（低置信度过滤、重复去除、领域相关性过滤）保留率约 30%，最终约 225 万步骤，涵盖约 15 万视频。

考虑到 Bilibili 中文教程的加入以及终端录屏类内容，总步骤量目标设定在 300 万步骤级别，视频量约 20 万条，形成一个中等规模、高质量的专域数据集。

质量验证方法

自动一致性检验：对同一视频的不同 LMM 标注版本（GPT-4V vs Claude）计算语义相似度，差异过大的条目标记为需要人工复核。
人工抽样审核：随机抽取 5% 的步骤标注，由领域专家评分（1–5 分），目标平均分 ≥ 3.8。
依赖关系合理性验证：对依赖图进行拓扑排序检验（确保无环），并人工验证随机抽样的依赖边是否合理。
下游任务验证：以构建好的数据微调小规模基线模型，在步骤预测和依赖推断任务上评估数据有效性。

客观评价

真正有价值的地方

步骤依赖关系是当前数据集的绝对空白。COIN 等数据集有步骤边界，但没有任何步骤之间的逻辑联系；HowTo100M 有规模，但标注几乎是噪声。本方案若能落地，将是第一个在技术操作领域系统性标注步骤依赖图的多模态数据集，直接填补这一空缺。

另一个被低估的价值在于操作意图（functional intent）的抽象层次。现有数据只标注「做什么（what）」，本方案额外标注「为什么做（why）」和「做完状态如何变化（state change）」，这对于训练模型具备因果推理能力至关重要。

主要挑战

版权问题：YouTube/Bilibili 视频受版权保护，直接分发原始视频帧存在法律风险。可行的规避路径是只发布标注元数据（时间戳、步骤描述、依赖关系等），不发布原始帧，用户自行下载视频并重建数据集——这与 HowTo100M 的做法一致，但会增加数据集使用门槛。

标注一致性：LMM 对同一步骤的 functional_intent 描述可能措辞差异很大，即使语义相近。这会在下游任务中引入噪声，需要建立标准化词汇表（尤其对常见操作类型）并进行后处理归一化。

视频质量差异大：YouTube 技术教程质量参差不齐——有高清录屏配专业解说，也有 360p 画质配口音浓重的音频。低质量视频的 ASR 错误率显著上升，关键帧提取也更困难。需要在筛选阶段严格把关，代价是可用视频数量减少。

计算成本：对 20 万视频调用 GPT-4V/Claude API 进行标注，按每视频平均发送 15 步 × 3 帧 = 45 张图片估算，API 成本约为每视频 $0.5–1.5 美元，总成本在 $10–30 万美元量级。这对大多数学术团队来说是不可承受的。实际上更可行的路径是：用开源视觉语言模型（如 InternVL2、Qwen-VL）进行初始标注，仅对低置信度样本使用商业 API，可将成本压缩至 1/10。

现实可行性评估

环节	自动化程度	人力需求	成本量级
视频爬取与筛选	高（90%+）	极少	服务器+带宽，$1–3K
Whisper 字幕	完全自动	无	GPU算力，$5–10K
关键帧提取	高（85%+）	低置信度人工复核	CPU算力，$1–2K
步骤边界识别	中（70%）	边界模糊处需人工	$3–5K（人工）
LMM 意图标注	中高（用开源模型）	抽样质检	GPU算力，$10–20K
依赖关系提取	中（60%）	复杂依赖需人工	$5–10K（人工）
质量验证	部分自动	专家抽审必须人工	$10–15K（人工）

总估算：以开源 LMM 替代商业 API 为前提，构建 20 万视频规模的数据集，总成本约在 $4–6 万美元，工期约 6–9 个月（含迭代和质检）。对于有 GPU 集群的研究机构，成本可进一步压缩。

这个量级是可行的，但不是小项目。最务实的起步策略是先构建 1 万视频的种子集，验证 pipeline 各环节的自动化效果和标注质量，再决定是否扩展规模。

本文为工作进展记录（WIP），方案细节将随实施过程持续更新。