长视频理解：让模型学会在时序中“划重点”

一、问题背景：当视频长度撞上上下文窗口

全模态模型的出现，让“同时理解文字、图像与音频”从愿景变成了工程现实。这类模型能够接收多路输入，在统一表征空间内完成跨模态推理，堪称多面手。然而，它们普遍面临一个硬性约束：上下文窗口有限。

所谓上下文窗口，通俗讲就是模型一次能“记住”或“看到”的信息总量，通常用 token（词元）数量衡量。超出这个限度的内容，模型根本处理不了——不是效果变差，而是直接截断或报错。

论文中曾给出一个具体数字：某类 30B 量级的全模态模型，上下文上限为 65536 个 token。按照常规的视频编码方式，一小时的视频大约要消耗 47000 个 token。这意味着，一段 81 分钟左右的录像，就能把这类型号的“脑容量”直接撑爆。

问题不止于“装不下”。视频信息密度远低于文本：一帧画面可能包含数百个 token 的视觉特征，但其中真正与当前任务相关的，可能只有几帧、几个区域。如果模型逐帧硬看，绝大部分算力都花在了冗余信息上。

二、三条既有路线的得与失

面对这一限制，业界此前大致试过三条路。

第一条：选择性保留。 提前筛出一些可能相关的片段，扔掉其他内容。但问题是，如果筛选的时候看得太粗糙，很容易把真正重要的那几分钟漏掉。比如一段产品评测视频，关键结论可能只出现在最后 30 秒；一段监控录像，异常事件可能只持续几帧。粗粒度筛选一旦漏掉，后续再强的推理能力也无法弥补。

第二条：均匀降采样。 按固定间隔抽帧，比如每秒一帧或每几秒一帧。这种做法实现简单，但假设了“信息在时间上均匀分布”，而现实恰恰相反——视频中的关键信息往往是稀疏、突发的。

第三条：分段独立处理。 把长视频切成若干短片段，分别送入模型，再在后期做融合。这种做法绕开了上下文限制，但代价是丢失了跨片段的时序依赖。片段之间的因果关系、前后指代、事件演化，在切分的一刻就被割裂了。

三条路线各有取舍，但都没有真正解决核心矛盾：如何在有限 token 预算下，最大化保留视频中的有效信息。

三、核心思路：让模型自己学会“划重点”

与其在外围做启发式筛选，不如把“看哪里”这件事交给模型自己学。这就是 LEAP 类方法的基本出发点：将关键帧/关键片段的选取建模为可学习的决策过程，让模型在训练中自适应地学会在长视频里划重点。

具体来说，这一思路包含三个层面：

3.1 可学习的 token 压缩

传统做法是对视频帧做固定编码，每帧产生固定数量的 token。更优的做法是：让模型在编码阶段就学会“哪些 token 可以丢”。这可以通过轻量的选择网络实现——它接收帧级特征，输出一个重要性分数，按分数保留 top-k 个 token。选择网络与主模型联合训练，梯度会告诉它：丢掉哪些 token 会导致最终任务性能下降。

用伪代码表示大致如下：

# 伪代码：可学习 token 选择
def forward(video_frames, question):
    frame_features = encode(video_frames)          # [T, D]
    importance = selector(frame_features)           # [T]
    topk_idx = topk(importance, k=budget)
    selected = frame_features[topk_idx]             # [k, D]
    answer = llm(selected, question)
    return answer

关键在于 selector 不是独立训练的，而是与下游任务损失端到端联合优化。

3.2 时序上的粗到细定位

只在帧级别做选择，粒度仍然偏粗。更精细的做法是两阶段：先让模型在低分辨率、低帧率下“扫一遍”，定位出可能相关的若干时间段；再对这些时间段做高分辨率、高帧率的精细编码。这样，token 预算被集中分配给真正重要的区域。

3.3 注意力引导的预算分配

不同视频、不同问题，所需的信息量差异巨大。简单问“视频里有没有猫”和复杂问“主角在第三幕为什么改变了决定”，需要的上下文长度完全不同。因此，预算分配也应当是动态的：模型根据问题复杂度与视频内容，自适应决定保留多少 token、保留哪些。

四、工程落地中的关键权衡

4.1 训练信号从哪来

选择网络需要监督信号。最直接的是任务损失反向传播，但这种方式信号稀疏、训练不稳定。实践中常引入辅助损失：比如用人工标注的关键帧做监督，或用对比学习让重要片段的表征与问题表征更接近。

4.2 推理效率与精度的平衡

token 选择本身也有计算开销。如果选择网络太重，省下的 token 预算又被选择过程吃掉了。因此选择网络通常设计得极轻——几层 MLP 或轻量注意力即可，参数量控制在主模型的 1% 以下。

4.3 与现有基础设施的兼容

长视频理解往往不是单机任务。视频解码、特征提取、模型推理可能分布在不同节点上。token 选择模块应尽量靠近特征提取端，减少不必要的数据传输。在云上部署时，可结合对象存储做视频分片缓存，用消息队列解耦解码与推理阶段，用日志与监控服务追踪每段视频的实际 token 消耗与选择命中率。

五、效果评估：不只是准确率

评估长视频理解方案，不能只看最终答案准确率。还需关注：

• token 效率：单位 token 预算下的任务性能；
• 关键帧召回率：被选中的片段是否覆盖了人工标注的关键区间；
• 时序鲁棒性：当关键信息出现在视频末尾或中间某处时，性能是否稳定；
• 跨长度泛化：在短训练、长推理的场景下是否仍能工作。

这些指标共同刻画了方案是否真正“学会了划重点”，而非记住了训练集中的位置偏置。

六、小结

长视频理解的瓶颈，表面上是上下文窗口不够大，本质上是信息密度与注意力分配的问题。逐帧硬看是最笨的办法，均匀降采样是偷懒的办法，分段独立处理是回避问题的办法。让模型自己学会在时序中划重点——可学习 token 压缩、粗到细定位、动态预算分配——才是更接近问题本质的路径。

对于开发者而言，这意味着在架构设计时要把“选择”作为一等公民：选择网络与主模型联合训练，选择粒度可粗可细，选择预算动态可调。对于企业用户而言，这意味着在同等算力下，能够处理更长的视频、更复杂的时序推理任务，而不必为每一分钟录像支付全量 token 成本。