让视频模型学得更好、更快

# 生成式视频预训练的数据筛选 | Linum 实践手记 来源：https://www.linum.ai/field-notes/data-filtering-gen-video 图像和视频模型在过去几年里取得了显著进步，尽管自 Stable Diffusion 3 以来，这些模型的内部架构并未发生根本性变化。当然，也存在一些小的变体，例如由 GPT-Image 推广的自回归扩散模型（https://arxiv.org/pdf/2406.11838）。但从宏观层面看，主流架构基本仍是基于 Transformer 骨干网络、采用 v-prediction 目标函数的流匹配（https://arxiv.org/pdf/2210.02747）方法。根据我们的经验，大部分性能提升直接归因于以下三方面的数据改进： 强化学习（RL）带来了一些提升，但在图像和视频领域，它直到近几个月才真正开始发挥显著作用（https://arxiv.org/pdf/2603.12893）。 1. **数据筛选与再平衡**：移除噪声数据，并通过战略性重采样，让模型更高效地学习。 2. **数据标注**：收集更优质的标注，例如更丰富的描述文本、边界框和字体细节，使模型能更轻松地区分视觉概念。大型语言模型（LLM）在图像描述方面的能力在过去12个月里有了质的飞跃。视频描述方面稍逊一筹，但那将是另一个话题。 3. **合成数据生成**：微调一组现有的生成模型，为那些自然界中极少或几乎不存在的数据创建训练集（例如，为 Nano-Banana 风格模型进行图像编辑/参考条件生成）。这通常涉及一系列针对特定任务训练的脆弱 LoRA 模型，以及一个经过微调以过滤不良合成数据的 LLM。 几年前，所有生成模型（无论是文本、图像还是音频）领域的普遍共识是，预训练应尽可能多地聚合数据。幸运的是，这个领域在这方面已经变得更加明智。如果你在预训练中塞入大量低质量数据（例如，严重压缩的 JPEG 图像），模型会浪费大量容量去学习模仿这部分数据。如果你能很好地筛选数据集，模型将更容易学到你期望它学习的内容。 我们知道这听起来很显而易见，但在实践中却难得多。不过，所有好的建议事后回想起来都应该显得理所当然。 今天，我们将带您回顾自2024年以来，我们的数据筛选方法是如何演进的。并希望这能避免您未来在训练自己的生成模型时走一些弯路。 1. **2024年**：基于 CPU 的传统计算机视觉（CV）方法 2. **2025年初**：基于 GPU 的微调 LLM 方法 3. **2025年末**：基于 GPU 的强化学习（RL）方法 - 被保留 - 被丢弃 - 被误丢弃 - 被保留但应被丢弃 - RL 评判标准 ## [2024] 预算有限的筛选 —— 基于 CPU 的传统 CV 方法 最初，我们决定使用传统的计算机视觉算法处理原始数据集。这样我们就可以使用一簇廉价的 CPU 实例，而无需使用大量运行多模态 LLM 的 GPU，或者花费数百万美元的 GPT-4 token 费用。 ### 场景检测 我们需要将数百亿的图像和视频筛选以构建预训练数据集。图像通常不需要特殊预处理，但原始视频需要。当训练生成式视频模型时，首先需要在图像生成任务上进行预训练。如果模型先学习名词再学习动词，通常收敛会更好（也更快）。 下次看电视剧或电影时，留意镜头切换的频率（https://www.youtube.com/watch?v=kmvvA7wudKo）。如果是近二十年制作的内容，很可能每5秒就会出现一次切换。何时切换、如何切换是创作者的决定，不应由生成式视频模型随意决定。因此，我们需要在筛选前，根据镜头边界将视频分割成片段。 基于我们只用 CPU 的节俭策略，我们选择了 PySceneDetect（https://www.scenedetect.com/）。其基本原理是维护一个滚动窗口包含 K 帧，如果第 K+1 帧的图像统计特性与前 K 帧有显著差异，则将其归类为切换点。它没有底层的机器学习模型。运行速度很快，但在处理常见的过渡效果（如溶解、淡入淡出、抖动切换）时表现不佳（这其实是个大问题）。 ### 了解你的数据 每当获得新数据时，你应该花几天时间审查随机样本，列出你想保留和想丢弃的内容。理想情况下，花时间起草一个在“好”与“坏”类别下的分类本体，并跟踪这些类别的相对大小。 在数据筛选过程的某个阶段，你的工程师思维会占据主导，你会花费过多时间调整启发式规则（或 LLM）的参数，追求那个“完美”的决策边界。这些记录将在未来帮助你避免陷入这种执念。它们将提供事实依据，让你在答案明显是“不”的时候，说服自己放弃尝试“再多一个想法”。 此外，理解数据分布的形状对于数据集再平衡非常有帮助。某些类别在所有视频的自然分布中被过度代表。我们需要降采样并抑制这种信号，否则它会主导训练，导致模型难以学习我们需要的人、地点、事物、动作的长尾分布，从而无法生成多样化的内容。 ### 筛出“不可描述”的内容 生成式视频模型的主要限制在于我们能否用文字正确且一致地描述内容。或者更准确地说，LLM 能否廉价地为我们进行标注。文本提供了理解视觉世界相当好的脚手架，但它绝不是视频生成所有方面的正确条件机制。诸如时空中的摄像机轨迹、演员表演的细微差别等细节，在自然语言中根本无法描述。参考驱动的视频生成目前很流行。它是对这些视频难以言喻属性进行控制的首次明确表述，但我们认为这本身并不是一个很好的控制手段。它足以用于自动生成和混搭的内容，如 meme 和“脑腐”视频，但无法实现传达创作者意图所需的精细引导。它无法让我们创造这项技术本应开创的引人入胜的故事。 目前，我们需要过滤掉那些主要吸引点在于“不可描述”的片段。没有清晰明确的文字描述，对我们的文生视频模型而言就是噪声。 #### 文字密集型 例如，我们需要过滤文字密集型视频。LLM 仍然难以准确描述屏幕上不断变化的动态图形。阅读屏幕内容并非难点，难点在于清晰描述文字何时以及如何在屏幕上变化。我们不希望我们20亿参数的模型浪费容量去学习动态图形，而应该将其用于学习动作。从更宏观的角度看，我们的目标是打造动画创作工具（https://www.linum.ai/about）。文字和动态图形目前并非优先事项。 为此，我们从每个视频中抽取帧，运行一个轻量级的 EAST 检测器（https://docs.opencv.org/4.x/d8/ddc/classcv_1_1dnn_1_1TextDetectionModel__EAST.html）来提取文本的边界框。然后，根据包含文本的帧百分比以及每帧中被文本覆盖的百分比，过滤掉文字密集的视频。 使用 CNN 来完成这个任务是正确的想法，但具体模型选择有误。为了在 CPU 上处理数百亿帧，我们不得不大幅度缩放帧尺寸。因此，许多含有小字体的文字密集样本被遗漏了。 EAST 是 2017 年的一个相当古老的模型。它体积小，远非文本检测领域的最新水平。让它在 CPU 上高效运行，同时避免缓存失效和线程过载，是一个挑战。即使经过性能优化，它仍然是这个版本数据流水线的最大瓶颈。在庞大的 CPU 集群上，我们花了数周时间才在我们的数据集上运行完 EAST。 #### 不可描述的动作 当屏幕上没有太多内容发生时（例如，人脸特写），很难描述具体发生的动作。如果发生的事情太多（例如，镜头极度晃动、足球比赛中多人同时在场上移动），LLM 也难以正确描述片段。我们将这类视频归类为“不可描述动作”片段并丢弃。 视频通常以压缩格式序列化存储在磁盘上。像 H.264 这样的编解码器通过存储关键帧和描述关键帧随时间如何变化的运动向量，而不是每个像素随时间的 RGB 值，来减小文件大小。我们在此简化了许多细节。在 H.264 中，编码器计算两帧之间的残差（帧差），然后对残差应用 DCT（离散余弦变换）。这样我们得到了一个高度量化的运动向量，以较小的磁盘文件大小为代价，实现了有损的帧重建。 我们使用存储在 mp4 文件本身的运动向量来隔离并过滤“不可描述动作”视频。在 2024 年，我们也尝试在 CPU 上运行传统的光流算法，如 Lucas-Kanade。它们非常脆弱，在开放世界视频上表现不佳。 具体来说，我们使用了 mv-extractor（https://github.com/LukasBommes/mv-extractor）并为每个片段计算两个启发式指标： - `average_frame_energy`：视频中所有运动向量的 L2 范数的平均值。 - `min(sub_clip_average_frame_energy)`：将每个片段根据视频长度分割成可变数量的块，计算每个块的平均帧能量，然后取这些 L2 范数的最小值。 接着是决策树： - `average_frame_energy` < 0.1：丢弃该片段。这些本质上是静态视频（例如，幻灯片、静止画面、定格画面）。 - `average_frame_energy` > 25：丢弃该片段。画面极其混乱。 - `min(sub_clip_average_frame_energy)` < 0.03：丢弃该片段。片段的一部分没有内容发生（例如，纪录片中的淡入淡出，向静止图像的过渡）。 - 保留其他所有内容。 这作为廉价的第一道过滤器效果不错，但召回率一般（即，很多不可描述动作的片段仍被保留在数据集中）。 ### 对“说话头部”视频片段的降采样 从我们对原始数据分布的初步审查中，很明显，人们直视镜头的“说话头部”片段被过度代表。如果我们放任不管，数据集将严重偏向这类片段。我们的模型在生成此类片段时会变得异常擅长（可能以牺牲其他内容为代价），因此我们需要找到它们并进行降采样。还记得 2025 年初走红的 VEO-3 视频吗（https://www.youtube.com/watch?v=Tvz8an1znIo）？其中很多是“街头采访”视频。它能如此出色地生成这类视频，而其他风格的视频则不然，这表明底层训练数据存在显著的偏差。 在传统 CV 的思维模式下，我们自然而然地在工程隧道里钻研得更深，引入了*额外的启发式规则*。我们从每个视频片段中抽取帧，运行一个 Haar 级联人脸检测器（https://docs.opencv.org/4.x/db/d28/tutorial_cascade_classifier.html）来提取人脸的边界框，并计算两个数值： Haar-like 特征（https://en.wikipedia.org/wiki/Haar-like_feature）通常无法检测到相对于摄像头成角度的人脸。对我们来说，这是件好事。这样我们就能区分真正的“说话头部”视频和人们正在执行实际动作的视频。 - `average_face_frame_energy`：人脸边界框内运动向量的 L2 范数。 - `average_background_frame_energy`：仅取画面角落区域运动向量的 L2 范数（作为背景运动的代理指标）。 然后又是另一棵决策树： - 中等 `average_frame_energy` + `average_face_frame_energy` >= `average_background_frame_energy`：保留该片段。通常是很好的特写。 - 低/中等 `average_frame_energy`：对这些进行降采样。 ## [2025年初] `rm -rf` —— 用微调 LLM 替代手工设计的启发式规则 我们开始绘制一棵相当复杂的决策树。它充满了效果一般的有损代理方法，并且非常不完整。我们省略了我们尝试过滤的许多类别。例如，包含 Ken Burns 效应（https://en.wikipedia.org/wiki/Ken_Burns_effect）的片段。此外，我们还没触及基于质量的过滤（例如，识别并丢弃像素化内容）这个复杂问题。 这种方法根本无法扩展。每次你有一个新的过滤想法，都必须重新审视决策树中的新节点如何影响所有其他分支。所有东西都纠缠在一起，最终你会得到一个既不可解释又难以编辑的流水线。 2024年我们开始时，面对的是数百亿条样本。预算有限，我们本能地想构建尽可能廉价的过滤器。*这是根本性的错误*。我们的视频模型在2024年数据集上训练数周后，仍然难以学习吉他扫弦这样的基本动作，但在应用2025年的过滤器后，不到24小时的训练就能学会这些动作。你不应该寻找最便宜的过滤器，而应该尽可能优化你能负担得起的最好的过滤器。 ### 迁移到数千个 GPU 上 这引出了我们的第二个核心结论：*抛弃你那些“原理性”的计算机视觉技术，在可能的地方采用黑盒神经网络*。有些模式人类根本无法很好地描述，无论我们多么努力。传统 CV 方法是它们那个时代最好的手工设计近似方案。它们确实是工程上的壮举，但训练有素的神经网络将学习到一个非线性函数，在99%的情况下都能在精确率和召回率上胜出。 一旦你接受了这个现实，你的工作重点就应该从设计廉价启发式规则，转向优化模型的 GPU 吞吐量，以及构建健壮、可并行的工作负载，以便在多家供应商的 SPOT 实例上运行。Karpathy 在他 2025 年夏季的 YC 演讲（https://www.youtube.com/watch?v=LCEmiRjPEtQ）中，讨论了他在 Tesla AutoPilot 工作中的类似认知转变。他将其描述为从“软件 1.0”到“软件 2.0”的过渡。 具体来说，我们用 AutoShot（https://github.com/wentaozhu/AutoShot）和 TransNetV2（https://github.com/soCzech/TransNetV2）替换了 PySceneDetect 的启发式规则，并使用自定义 CUDA 内核加速推理。这些模型仍然难以捕捉 100% 的镜头切换。例如，它们仍然会漏掉帧抖动切换。目前这已经足够好了。但在未来，我们必须使用新数据训练这些模型以填补这些空白。 我们停止在 CPU 上运行古老的 EAST 检测器。相反，我们在数千个 Nvidia A10G 和 L4 GPU 上部署了 PaddleOCR 并配合 TensorRT。仅用了约36小时就在 GPU 上处理完了数百亿样本。花费不到10,000美元，却获得了更快、更好的结果。 此外，我们移除了错综复杂的计算机视觉算法网络（Haar 人脸检测器、Lucas-Kanade、单目深度估计器等），并用一组经过微调的 LLM 替换了它们。我们仍然使用 H.264 运动向量作为对极低和极高运动片段的廉价初始过滤器。 ### 迭代式数据集标注（aka 自一致性比你想象的更难） 微调过程相当直接，这要归功于 Unsloth（https://github.com/unsloth