把Deep Research这类深度研究能力从网页文本搬到视频里，是我最近扎进去折腾的一件事。做调研时，大家习惯用深度研究工具去查文字资料、拉证据、生成报告，可一旦输入变成几个小时的视频——课程回放、会议录像、发布会全程——事情就完全变了：视频没有现成的文本结构，直接让多模态大模型把全片从头读到尾，视觉token的消耗高得离谱，而且答案未必更准。

这个项目做到后面，核心思路浓缩成一句话：先浏览，再定位，后精读。先用极低的成本把整段视频扫一遍，建立时间轴索引；再根据研究问题，从索引里定位出真正相关的候选片段；最后只对候选片段做高密度精读。实测下来，回答的精度比上一版方案还高，token消耗反而降了58.3%。这篇文章把三层设计、成本模型、消融实验和踩过的坑完整拆开讲，适合正在做长视频理解、视频知识检索或者多模态RAG的开发者参考。

1. 为什么长视频研究任务这么难啃

1.1 视频研究任务的真实形态

很多人一想到“视频研究”，第一反应是“AI帮我看完一部电影然后写影评”。但实际工作中，这类需求要朴素得多，也更硬核：

• 从几十小时的培训录像里，找出所有提到某个操作规范的片段，并汇总成执行要点。
• 把半天会议的视频复盘成一份带时间戳的决议清单，每一句结论都能回溯到原话。
• 对着某产品发布会全程录像，逐条整理对方在哪些时间点、用什么原话描述了某个能力。
• 从产线监控视频里定位某个异常事件的前因后果，再截取关键证据片段。

这些任务的共同点是：答案只存在于整段视频中极少数几个时间区间里，但你需要先知道“在哪儿”，然后才能去“细看”。这就像在一本几百页的书里做文献综述，不可能每页都精读，得靠目录、索引和关键词先把相关章节捞出来，再逐段精读。

1.2 现有方案为什么撑不住

我最早那版实现特别粗暴：把视频均匀抽帧，全部塞进多模态大模型的上下文里，然后直接问问题。两小时的视频，如果按每秒1帧抽，就是7200帧，即便每帧压缩到128个视觉token，光输入就是92万token，实际跑起来还要加上记忆缓存和输出，一个任务轻松突破百万token。成本只是一方面，更致命的是模型在超长上下文里根本抓不住重点，中间段落的信息大量丢失，引证时间戳经常张冠李戴。

还有人会问：能不能只靠语音转写文本，不碰视觉？可以，但会丢掉太多信息。视频里大量的关键内容长在画面上——PPT上的图表、产品外观、屏幕操作步骤、肢体动作——这些语音转录文本完全覆盖不到。我测试过一批“画面对答案有决定性影响”的任务，纯文本方案的正确率比多模态方案低了将近两成。

所以这个项目要解决的核心矛盾是：视频信息密度极低，但全量精读的成本极高；研究型任务要求证据可追溯，但上下文一长，模型警惕性就下降。想要在成本和精度之间同时拿到好处，就必须换一种信息编排方式。

2. 三级流水线：先浏览、再定位、后精读的整体设计

2.1 浏览层到底在干什么

浏览层的目标不是“理解视频”，而是“给视频建索引”。它把非结构化的视频原材料，转成一张带时间戳的语义地图。

具体流程是：先用开源场景切分工具把视频切成镜头和场景段；然后对每一段做低密度视觉采样——比如每15到30秒取一帧，用轻量视觉编码器提取场景标签；同时把整段视频的音频做完整转写，拿到带时间戳的文本。最后每个场景段会得到这样一条记录：起止时间、场景类型、视觉标签列表、语音转写文本、一句话摘要。

这一层特别便宜。视觉采样帧很少，而且用的是轻量编码器，不走大模型的完整推理链路；ASR虽然要覆盖全片，但文本token数量级远小于视觉token，一次性花完也就一两万token的水平。我在设计的时候一直提醒自己：浏览层不追求理解深度，它只负责让系统“知道视频里大概有什么、大致在什么位置”。任何想在浏览层就把问题彻底想明白的做法，都会把成本推回暴力方案的水平。

2.2 定位层为什么可以这么便宜

定位层是三层里最不起眼、但价值最被低估的一环。它拿浏览层产出的语义地图，配合用户的研究问题，做一次“检索”，而不是“推理”。

具体操作分三步：第一，把用户问题编码成查询向量；第二，在浏览层的索引上做混合检索——向量检索负责语义召回，关键词检索负责精确命中专有名词和术语，两者用RRF分数融合；第三，按相关度排序后截取Top区间。

这个阶段完全不调用大模型做生成式推理，只有embedding计算和轻量打分，token消耗几乎可以忽略。但它的作用是决定性的：后面精读层的所有预算都花在定位层挑出来的候选区间上，定位的召回率，直接决定了整个系统精度的上限。所以我做这个模块的时候定了一条铁律：定位可以多召回，不能漏召回。阈值宁可放宽一点，让候选区间稍微多一点，也绝对不能因为阈值设高了把关键片段挡在门外。

2.3 精读层怎么把细节补回来

精读层是这套流水线真正的“重武器”。定位层给了候选区间之后，系统只对这些区间做高密度采样细读，而不是回到全片。

精读阶段会把区间内的视觉采样密度提上去，比如每秒1帧甚至更高，同时把区间内的ASR文本、浏览层摘要、用户问题一起组织成一个精读指令，送入多模态大模型。指令里明确要求输出结构化的观察记录，每条观察必须带原始时间戳和原文引用。多个区间的精读结果最后进入一个聚合阶段，按时间顺序合并、去重、消解冲突，生成最终的研究报告。

这样做有一个容易被忽略的好处：单次精读的上下文长度被控制住了。模型不需要在几万token的上下文里大海捞针，而是在几百到几千token的上下文里集中注意力，事实忠实度自然上去了。后面实测数据也印证了这一点，精度提升不是靠更大模型，而是靠更聚焦的输入。

3. 实现细节与关键参数：从时间轴索引到证据链聚合

3.1 时间轴索引的构建

浏览层产出的索引，是整个流水线的地基。我在项目里对索引做了一轮又一轮调整，最后保留了几个关键字段：

• segment_id：场景段唯一编号
• start/end：场景段的起止时间戳，单位是秒
• transcript：该场景段的ASR文本，按句带时间偏移
• visual_tags：轻量视觉编码器输出的场景标签，比如“会议室”“PPT”“室外”“多人”“移动镜头”
• text_embedding：对transcript按句切分后生成的向量数组

一个很重要的实现细节是：视觉和语音的时间轴要做联合校准。ASR模型自带的时间戳偶尔会有几百毫秒到一两秒的漂移，视觉场景边界又往往和语音段落边界对不齐。我在构建索引时，会先把场景边界和ASR句边界投影到同一条时间线上，然后以场景段为准重新分配文本片段，避免后续检索时出现“定位到画面，却配了上一段的文本”这种错位。

这块的代码并不复杂，核心就是处理时间戳的对齐和合并。项目初期我用了一个很土的办法：把每个ASR句子的起止时间和场景段的起止时间求交集，交叠超过50%就把句子归入该场景段。效果足够稳，后来也一直没有换成更花哨的方案。

3.2 候选区间筛选与合并规则

定位层从索引里捞出相关场景段之后，不能直接拿去做精读，中间还有两道必须做的处理：区间合并和缓冲扩展。

先说区间合并。相邻的几个场景段可能都命中了关键词，如果把它们当成独立区间拿去精读，每个区间都要重复读一遍边界附近的视频帧，非常浪费。我的做法是：只要两个连续命中区间之间的间隔小于20秒，就把它们合并成一个候选区间。这个阈值是我通过实验试出来的——太小了区间碎片化严重，切换开销大；太大了会把大量无关内容包进精读区，token消耗又涨回去。

再说缓冲扩展。定位层判定的是一个粗略区间，而视频内容的边界是模糊的，关键信息往往正好卡在区间的边缘，差几秒就会漏掉。所以我在每个候选区间的首尾各向外扩15秒。实测下来，这个15秒的缓冲能显著减少“证据被边界截断”的情况，而token成本只增加百分之十几，非常划算。

合并和缓冲之后，系统会得到一串不重叠的候选区间，按时间顺序排列。这些区间就是精读层的全部工作范围。到这一步为止，整个流程还没有调用过大模型做任何一次生成式推理。

3.3 精读指令与报告聚合

精读层的指令设计直接决定输出质量。我一开始用的指令非常简单，就是“请仔细分析以下视频片段并回答问题”，结果模型经常给出模棱两可的结论，还不带出处。后来把指令改成强制结构化输出，情况立刻好转。这里给出一个简化版模板，可以按自己的模型做调整：

你正在对一段长视频中的候选片段做深度分析。 研究问题：{question} 候选片段起止时间：{start} - {end} 片段语音转写：{transcript} 片段视觉采样帧：{frames} 请按以下结构输出： 1. 事实观察：列出你在片段中看到的、与问题直接相关的事实，每条以“【时间戳 mm:ss】事实描述”开头。 2. 原文引证：引用片段中支持该事实的原话或画面证据，注明对应时间戳。 3. 不确定项：列出片段中涉及但无法确认的信息，并说明原因。 4. 初步结论：基于以上观察，给出对研究问题的部分回答，标注置信度（高/中/低）。

聚合阶段则是把所有候选区间的结构化输出整理成一份完整报告。我这里没有选择把所有区间的原始帧和转写一次性塞进一个大prompt，而是只把每个区间已经整理好的结构化观察送进聚合模型，让它在时间轴上做合并与冲突消解。这样做既控制了上下文长度，又保留了每个区间证据的独立性，不会因为上下文过长导致前后矛盾。

4. 58.3%是怎么算出来的：token消耗模型拆解

4.1 上一版方案的成本基线

要说清楚58.3%这个数字，必须先把基线定义清楚。我的比较对象不是“暴力全量抽帧精读”，因为那种方案在两小时视频上根本跑不起任何一个真实任务，不具备工程可比性。我拿来对比的是项目里上一版已经能上线的方案：先浏览全片，然后对全片做中等密度精读。

还是以一部长约120分钟的视频为例。上一版方案的成本拆解如下：

• 全程每2秒抽1帧，共3600帧，每帧128个视觉token，合计约46.1万token。
• 完整ASR转写，约2.2万token。
• 浏览摘要、系统交互和输出占位，约1.3万token。
• 总计接近49.6万token。

请注意，这已经是优化过的“可运行方案”，不是最粗暴的版本。我最早那版把所有帧全塞进上下文，成本是这个数字的三到五倍，而且效果更差，这里就不放进对比了。

4.2 三级流水线的成本构成

当前方案处理同一段视频时，成本分布发生了根本性变化：

49.6万降到20.7万，降幅正好在58.3%附近。省下来的钱主要来源很清晰：浏览层用低分辨率、低采样率的视觉信号做索引，成本只有原来的零头；定位层几乎不花钱；精读层只把全片约11%的时长纳入高成本分析，把火力集中在刀刃上。

这里有个容易算错的地方：很多人会把ASR转写也算进新方案的“额外成本”，但上一版方案同样要做ASR，它并不是新增项。真正新增的是定位层那几千token，和浏览层的低密度视觉采样，这两项加起来也不到总成本的10%。所以新方案并没有在流程上做加法，而是把原本分摊在全片上的精读预算，集中到了更小范围。

4.3 精度反而提升的三个原因

只降成本还不能说明方案好，关键为什么精度也升了？我在项目复盘里总结了三条机制：

第一，上下文变短，注意力更集中。多模态大模型在超长上下文里会出现明显的“中间迷失”，视频帧序列尤其严重——中间的帧经常被模型忽略，只有开头和结尾被充分吸收。把上下文从几万token降到几千token，模型对每一帧的处理深度反而上去了。

第二，定位层起了检索增强的作用。精读阶段模型是带着明确问题去读片段的，相当于先有人划了重点，再从重点里找证据，而不是在一整部视频里漫无目的地找线索。检索过程把相关性先验注入了模型，回答完整度显著提升。

第三，预算再分配，而不是单纯省钱。省下的token并没有全部存起来，我把一部分投入了关键区间的更高密度采样。上一版因为受全片预算约束，整段视频只能用每2秒1帧的中等密度处理；新方案在候选区间里可以用每秒1帧甚至2帧，细节捕获能力强了一大截。比如PPT上停留时间很短的一行小字，低帧率下根本看不清，高密度采样就能抓到。

5. 消融实验与效果复盘

为了验证三个模块缺一不可，我在一个内部测试集上做了消融实验。测试集包含约40段视频，覆盖课程录像、会议视频、发布会实录和场景监控四类，任务类型统一为“给定问题，输出带时间戳的证据型报告”。评估指标用两个：引证准确率（模型引用的时间戳和原文是否真实对应）和任务完成度（报告是否覆盖了问题所有关键维度）。

方案C的结果是最惨烈的。没有浏览层，定位层就没有索引可查，退化成随机抽几个区间精读，相当于完全瞎猜，引证准确率掉到及格线以下。这印证了一个观点：浏览层看起来“最笨”，却承担了整个系统的召回上限。

方案B则恰好说明定位层的价值。它保留了浏览和精读，但精读范围铺满全片，上下文长度大幅上升，引证准确率直接跌破九成，成本却是完整方案的2.4倍。这个结果非常直观地展示了“全量精读的代价”并不只在token账面上，还会以精度损失的方式再收一次智商税。

方案D在含有大量口播内容的课程视频上表现尚可，但在发布会和监控场景里下降尤其明显，因为这类视频的关键信息大量存在于画面中，纯文本索引只能捞到“提到了什么”，捞不到“画面上发生了什么”。

方案E的教训是：区间碎片化会让模型反复读同一段边界内容，token浪费在重复阅读上，而且没有缓冲时证据经常被截断，完成度明显偏低。

6. 常见问题与排查技巧实录

定位层漏掉了关键片段怎么办。这是被问得最多的一个问题。我的建议是先从召回端下手：把向量检索和关键词检索的Top-K都往上调一档，把阈值门槛降低，宁多勿少。如果还漏，就要检查浏览层是不是丢了模态信息——比如一段视频只有画面在演示操作、语音从头到尾没提关键步骤，纯文本索引必然捞不到。这种情况下必须在浏览层补视觉标签索引，别无他法。

精读上下文还是太长怎么办。如果候选区间过大，或者若干个区间合并后总时长超限，我的做法是在区间内部做二次定位：把精读指令先在小范围跑一轮粗筛，把区间进一步切成更小的分析块，分多次推理后再聚合。这会增加几次模型调用，但单次上下文长度可控，综合成本反而更低。

时间戳引证对不上怎么办。时间戳错位通常不是大模型的问题，而是底层ASR时间戳本身有漂移。排查时先看浏览层的ASR句子时间戳是否和场景边界对齐，如果漂移明显，就需要做联合校准——以画面场景边界为基准，把文本时间戳整体平移对齐。这个方法虽然土，但我测下来最有效。

多说话人的会议视频效果差。浏览层的ASR文本混在一起，定位层很难区分“谁说的”。遇到这种场景，我会在浏览层增加说话人分离环节，把转写文本按说话人打标签，索引里额外存一个speaker字段。这样定位时可以按问题去匹配指定角色的发言，精读阶段也能输出“谁在什么时间说了什么”这种更细粒度的证据。

延迟没有降下来，反而感觉更慢了。token降了不代表耗时降了，因为流水线分三阶段，中间有检索和等待时间。如果对延迟敏感，可以并行化处理：浏览层的多个场景段可以同时做索引，精读层的多个候选区间也可以并行跑多路推理，最后统一进聚合。实测并行化之后，端到端耗时大约只有串行的三分之一。

成本优化不能只看输入token。输出token同样是真金白银。我在精读指令里强制结构化输出，一个直接好处就是控制输出长度——让模型只输出观察、证据、结论，而不是大段复述视频内容。聚合报告阶段也一样，限制每段结论不超过指定字数。如果放任模型自由发挥，输出token可能比输入还高，账面上就不好看了。

这个项目做下来，我最大的体会是：视频研究任务真正拼的不是模型有多强，而是信息流怎么编排。把视频当作一个待检索的语料库，而不是一段需要逐帧阅读的长文，思路一下子就打开了。先浏览、再定位、后精读这套逻辑，本质上做的事情是把不可穷举的视频搜索问题，强制转换成一个稀疏检索加聚焦精读的问题，然后把模态和时间两个维度的信息对齐好，剩下的交给模型去发挥。后续我打算把定位层的索引做得更细，加入屏幕文字识别、音频事件检测这类信号，让“浏览”这张地图的颗粒度再小一层。这活儿越做越有意思，有新的进展再来分享。