把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 三级流水线的成本构成当前方案处理同一段视频时成本分布发生了根本性变化环节明细Token消耗约浏览层每30秒1帧240帧×48 token约1.2万1.2万浏览层ASR转写约2.2万 摘要输出约0.8万3.0万定位层查询向量化、索引检索、排序打分0.5万精读层候选区间视频帧约820帧×128 token10.5万精读层各区间精读指令与最终聚合4.8万其他接口缓存、上下文窗口填充等杂项0.7万总计约20.7万49.6万降到20.7万降幅正好在58.3%附近。省下来的钱主要来源很清晰浏览层用低分辨率、低采样率的视觉信号做索引成本只有原来的零头定位层几乎不花钱精读层只把全片约11%的时长纳入高成本分析把火力集中在刀刃上。这里有个容易算错的地方很多人会把ASR转写也算进新方案的“额外成本”但上一版方案同样要做ASR它并不是新增项。真正新增的是定位层那几千token和浏览层的低密度视觉采样这两项加起来也不到总成本的10%。所以新方案并没有在流程上做加法而是把原本分摊在全片上的精读预算集中到了更小范围。4.3 精度反而提升的三个原因只降成本还不能说明方案好关键为什么精度也升了我在项目复盘里总结了三条机制第一上下文变短注意力更集中。多模态大模型在超长上下文里会出现明显的“中间迷失”视频帧序列尤其严重——中间的帧经常被模型忽略只有开头和结尾被充分吸收。把上下文从几万token降到几千token模型对每一帧的处理深度反而上去了。第二定位层起了检索增强的作用。精读阶段模型是带着明确问题去读片段的相当于先有人划了重点再从重点里找证据而不是在一整部视频里漫无目的地找线索。检索过程把相关性先验注入了模型回答完整度显著提升。第三预算再分配而不是单纯省钱。省下的token并没有全部存起来我把一部分投入了关键区间的更高密度采样。上一版因为受全片预算约束整段视频只能用每2秒1帧的中等密度处理新方案在候选区间里可以用每秒1帧甚至2帧细节捕获能力强了一大截。比如PPT上停留时间很短的一行小字低帧率下根本看不清高密度采样就能抓到。5. 消融实验与效果复盘为了验证三个模块缺一不可我在一个内部测试集上做了消融实验。测试集包含约40段视频覆盖课程录像、会议视频、发布会实录和场景监控四类任务类型统一为“给定问题输出带时间戳的证据型报告”。评估指标用两个引证准确率模型引用的时间戳和原文是否真实对应和任务完成度报告是否覆盖了问题所有关键维度。方案引证准确率任务完成度Token消耗A 完整三级流水线94.6%88.2%基准B 去掉定位层浏览后全量中等密度精读87.3%79.5%约2.4倍C 去掉浏览层随机抽区间精读61.8%54.1%约0.9倍D 定位只用ASR文本不索引视觉标签89.2%81.7%约0.95倍E 不合并相邻区间不扩展缓冲92.5%83.6%约1.3倍方案C的结果是最惨烈的。没有浏览层定位层就没有索引可查退化成随机抽几个区间精读相当于完全瞎猜引证准确率掉到及格线以下。这印证了一个观点浏览层看起来“最笨”却承担了整个系统的召回上限。方案B则恰好说明定位层的价值。它保留了浏览和精读但精读范围铺满全片上下文长度大幅上升引证准确率直接跌破九成成本却是完整方案的2.4倍。这个结果非常直观地展示了“全量精读的代价”并不只在token账面上还会以精度损失的方式再收一次智商税。方案D在含有大量口播内容的课程视频上表现尚可但在发布会和监控场景里下降尤其明显因为这类视频的关键信息大量存在于画面中纯文本索引只能捞到“提到了什么”捞不到“画面上发生了什么”。方案E的教训是区间碎片化会让模型反复读同一段边界内容token浪费在重复阅读上而且没有缓冲时证据经常被截断完成度明显偏低。6. 常见问题与排查技巧实录定位层漏掉了关键片段怎么办。这是被问得最多的一个问题。我的建议是先从召回端下手把向量检索和关键词检索的Top-K都往上调一档把阈值门槛降低宁多勿少。如果还漏就要检查浏览层是不是丢了模态信息——比如一段视频只有画面在演示操作、语音从头到尾没提关键步骤纯文本索引必然捞不到。这种情况下必须在浏览层补视觉标签索引别无他法。精读上下文还是太长怎么办。如果候选区间过大或者若干个区间合并后总时长超限我的做法是在区间内部做二次定位把精读指令先在小范围跑一轮粗筛把区间进一步切成更小的分析块分多次推理后再聚合。这会增加几次模型调用但单次上下文长度可控综合成本反而更低。时间戳引证对不上怎么办。时间戳错位通常不是大模型的问题而是底层ASR时间戳本身有漂移。排查时先看浏览层的ASR句子时间戳是否和场景边界对齐如果漂移明显就需要做联合校准——以画面场景边界为基准把文本时间戳整体平移对齐。这个方法虽然土但我测下来最有效。多说话人的会议视频效果差。浏览层的ASR文本混在一起定位层很难区分“谁说的”。遇到这种场景我会在浏览层增加说话人分离环节把转写文本按说话人打标签索引里额外存一个speaker字段。这样定位时可以按问题去匹配指定角色的发言精读阶段也能输出“谁在什么时间说了什么”这种更细粒度的证据。延迟没有降下来反而感觉更慢了。token降了不代表耗时降了因为流水线分三阶段中间有检索和等待时间。如果对延迟敏感可以并行化处理浏览层的多个场景段可以同时做索引精读层的多个候选区间也可以并行跑多路推理最后统一进聚合。实测并行化之后端到端耗时大约只有串行的三分之一。成本优化不能只看输入token。输出token同样是真金白银。我在精读指令里强制结构化输出一个直接好处就是控制输出长度——让模型只输出观察、证据、结论而不是大段复述视频内容。聚合报告阶段也一样限制每段结论不超过指定字数。如果放任模型自由发挥输出token可能比输入还高账面上就不好看了。这个项目做下来我最大的体会是视频研究任务真正拼的不是模型有多强而是信息流怎么编排。把视频当作一个待检索的语料库而不是一段需要逐帧阅读的长文思路一下子就打开了。先浏览、再定位、后精读这套逻辑本质上做的事情是把不可穷举的视频搜索问题强制转换成一个稀疏检索加聚焦精读的问题然后把模态和时间两个维度的信息对齐好剩下的交给模型去发挥。后续我打算把定位层的索引做得更细加入屏幕文字识别、音频事件检测这类信号让“浏览”这张地图的颗粒度再小一层。这活儿越做越有意思有新的进展再来分享。
