这阵子我一直在折腾视频长内容的深度理解。这里说的深度理解不是随便剪一段视频丢给模型让它出个总结而是像Deep Research那样针对一个具体的问题从视频里挖出答案、收集证据、整理成结论。网页文本上的Deep Research已经跑得很顺一到视频就卡壳语音转出来动辄几万字画面抽帧更是海量全量塞进模型先不说成本效果都容易因为上下文太长而崩掉。后来我把一套“先浏览、再定位、后精读”的三阶段方案跑通之后情况完全反过来了回答精度比全量粗暴处理还高一截token消耗反而降了58.3%。这篇文章就把这套思路从头拆开讲清楚——三个阶段分别做什么、为什么能同时做到降本和提精、实测数据是怎么测出来的以及落地时会踩的坑。如果你正在做视频问答、视频知识库、长视频内容分析这类场景这篇应该能帮你省下不少试错时间。1. 当Deep Research遇到视频核心设计思路1.1 视频深度研究的三个典型痛点做视频版的Deep Research第一个绕不开的坎是token爆炸。以一段60分钟的教学视频为例只算语音部分转写出来大概2到3万字换算下来接近4万token如果再把画面也算上按照常规的每秒1帧抽样那就是3600帧多模态模型处理一帧图像往往要消耗大几百个token光画面就是两三百万token的级别。全量塞进上下文一次问答烧掉的成本非常可观更别说多轮追问和多个视频交叉分析。第二个痛点是注意力稀释。模型的注意力是有限的资源几千帧画面和几万字文稿挤在一起关键信息往往淹没在噪声里。我做过对比测试把整段视频全量切成小块塞进上下文问它“视频里提到的某个工具参数在开头处的说明是否和结尾处的结论一致”模型经常会给出前后矛盾的答案因为它根本没有能力同时盯住相距很远的两处细节。第三个痛点是检索困难。网页可以用全文搜索、链接跳转的方式去定位信息视频没有天然的检索结构。你不能让模型自己去“翻目录”只能靠抽帧和转写文本硬啃。这个痛点不解决视频Deep Research就永远停留在“能跑”而不是“好用”的阶段。1.2 为什么“先浏览再定位后精读”符合直觉答案其实很朴素人在研究一段视频材料的时候本来就不会从头到尾一带而过。正常人拿到一段教学录像第一件事是快进浏览看个大概然后根据要回答的问题拖到相关的片段细看确认之后可能还会倒退回去反复核对关键帧。这套流程天然就是“先浏览、再定位、后精读”。所以这套方案的核心是把人做研究的习惯翻译成机器可执行的pipeline先用很低的成本把整段视频粗扫一遍生成带时间戳的结构化索引收到具体问题之后只在索引上做语义检索召回最相关的候选片段最后只对召回片段做高分辨率精读。全量处理是被迫把所有注意力摊到每一帧上而三阶段方案是把注意力集中到真正重要的区域所以同样的信息密度下模型容易抓住重点精度自然上去了。同时浏览阶段和精读阶段只接触整个视频的一小部分token消耗自然大幅下降。注意这里说的“降低58.3%”不是某个理论推导而是我在自己评测集上用固定口径跑出来的实测结果。后面的章节会给出具体评测方式和数据表。1.3 这套方案和普通长上下文方案的本质区别市面上很多视频理解工具都在拼“上下文窗口更大”把窗口从128K扩到1M仿佛能装下更多帧就能解决所有问题。实际上窗口扩容只会延缓症状不会治愈病灶。视频信息和网页文本不一样网页里每个段落都是独立语义块可以按块检索视频里连续数秒甚至数分钟的帧都在讲同一件事信息高度冗余如果全量塞入大量重复内容会白白占据注意力配额。三阶段方案本质上是把“大水漫灌”改成了“精准滴灌”。它不在上下文窗口里硬塞整个视频而是把视频先压缩成索引再按需膨胀回细节。这样的好处是无论视频多长最终进入精读阶段的输入长度只和候选片段相关和视频总时长解耦。这就是为什么它能在窗口不变的情况下反而比超大窗口方案做得更好。2. 三阶段架构拆解浏览、定位、精读各做了什么2.1 阶段一全局浏览——用最少token构建视频索引浏览阶段的目标很明确用尽可能少的token把一段长视频压缩成一份“可检索的目录”。这个阶段不追求理解细节只追求“知道哪里有值得细看的内容”。我的实现方式是三条线并行。第一条线是音频转写用ASR模型把视频语音转成带时间戳的文本这里不做任何摘要先保留全文但转写本身不会直接拿去喂给大模型而是存储起来备用。第二条线是视觉粗扫每隔5到10秒抽一帧用视觉模型给每一帧打个标签比如“讲解PPT”“实验演示”“代码界面”同时提取画面的关键文字信息做成粗粒度场景标签。第三条线是把音频文本按固定时间窗切块比如每30秒一段再把该时间窗内的转写文本和场景标签一起交给一个轻量模型生成一段一到两句的中等粒度摘要。这三条线的产物汇合起来就是一个结构化的视频索引每一行是时间戳区间、场景类型、文本摘要、关键实体。整个视频可能生成几千行索引但token消耗往往只有全量画面的百分之十几。这个索引就是后续所有检索和定位的基础所以阶段一不追求精但一定要全宁可错存不能漏存。这里有个容易被忽视的细节索引里的摘要我会要求模型把“专有名词”和“数字”原样保留不能改写。因为后续的语义检索非常依赖实体匹配一旦摘要阶段把“带宽25Gbps”改写成“网络速度很高”那就彻底检索不到了。这个习惯让我避掉了很多次召回失败的坑。2.2 阶段二语义定位——问题驱动的候选片段召回定位阶段是整套方案的核心。它的输入是用户的问题输出是一批“值得精读”的视频时间段候选。整个过程可以拆成三个并行的召回通道。第一个通道是向量语义召回。把索引中的每一条摘要文本做embedding入库同时把用户问题也做embedding然后做向量相似度检索取Top-K个时间段。这一层解决的是“问题表达和视频内容用词不同但意思相近”的情况比如问题问“网络瓶颈”但视频里说的是“带宽不足”语义向量能把它们拉到一起。第二个通道是实体匹配召回。解析用户问题中的实体关键词和数字条件比如“带宽”“25Gbps”“第三章”然后去索引里做精确匹配。这一层解决的是向量召回容易忽略的精确数字和专有名词问题通常和向量召回形成互补。第三个通道是视觉语义召回。如果问题涉及到画面上的信息比如“图中标注的按钮在哪里”我会把问题向量和浏览阶段保存的关键帧特征做对比找出相关性最高的帧所在的片段。这个通道独立于文本专门兜住纯视觉类问题。三个通道的结果做并集再按相关度排序取前几个时间片段作为精读候选。我通常保留1到3个候选片段每个片段长度控制在2到5分钟之间这样后续精读的token预算就非常可控。提示定位阶段的召回策略宁可“宽”一点。如果Top-K只取一个片段一旦漏掉真正答案所在的位置后续精读做得再细也无济于事。我会适当扩大候选区间把因为摘要太粗而丢失的边界帧重新拉回来。2.3 阶段三定点精读——高分辨率分析只发生在刀刃上经过定位阶段真正需要大模型认真读的内容已经收缩到很窄的范围了。精读阶段在这个小范围内做高分辨率分析然后把答案组织出来。精读的第一步是提高采样密度。浏览阶段可能每10秒抽一帧精读阶段我会对这个区间提升到每秒1到2帧保证不遗漏任何关键画面。第二步是重新调取对应的完整ASR文本不再使用摘要让模型读到原始的表述。第三步是按需做OCR如果问题上涉及屏幕上的文字、代码、表单就把关键帧送去OCR识别把识别出的文字并入上下文。第四步才是让大模型基于这些高密度材料做推理。这里有个关键设计精读不只是“读”和“答”而是要完成“证据链闭环”。我会要求模型在回答时给出所依据的时间戳和画面描述这样最终答案不仅正确还能溯源到视频的具体位置。对于那种需要跨多个片段综合的问题我还会让模型先分别精读每个候选片段生成子结论再汇总成最终答案避免长上下文把信息搅浑。整个精读阶段的token消耗只和候选片段的长度相关和视频总长度无关。一个60分钟的视频如果只召回3个3分钟的片段精读阶段的输入大概只有全量的九分之一。这就是成本能压下去的根本原因。3. 精度提升与token消耗下降58.3%的数据复盘3.1 评测口径与对照方案为了让“精度提升”和“token下降58.3%”这两个说法经得起推敲我专门搭了一套固定的评测集。评测集用的是某技术课程库中的10个视频时长从20分钟到90分钟不等每个视频配有8个问题涵盖概念解释、数值提取、步骤复述、跨段对比、画面信息识别等常见类型总共80个问答对。对照方案有三组。第一组是全量基线整个视频抽帧加语音转写全部塞进上下文让模型直接回答。第二组是只转文字基线只用ASR文本、不用画面全量文本直接进模型。第三组是本文介绍的三阶段方案。三个方案都使用同一个底层大模型避免模型本身差异干扰对比结果。精度指标采用人工打分从“答案正确”“证据准确”“信息完整”三个维度各打0到3分满分9分最后归一化成百分制。这里要特别说明一点在长视频场景上一张画面可能包含PPT文字、实验操作、人物动作等多重信息纯文本方案天然劣势明显所以只转文字基线更多是作为参照值不是竞对方案。即便如此三阶段方案在数值提取、步骤复述这类偏向文本语义的问题上也稳定优于纯文本基线说明它的提升不是单纯靠“加了画面信息”赢来的。3.2 token成本对比的实测数据先看token。下表是我在10个视频上的平均数据单位是千token四舍五入到整数方案输入token均值相对全量基线说明全量基线帧文本约2860K100%每1秒1帧全部进上下文只转文字基线约52K不适用仅全量文本三阶段方案约1194K41.7%浏览定位精读全流程从这张表能直观看到三阶段方案相对全量基线的平均降幅恰好是58.3%也就是输入token量只有原来的四成出头。其中定位阶段本身几乎不消耗大模型token主要靠向量检索和实体匹配真正的token大头集中在浏览阶段的索引构建和精读阶段的高分辨率分析上而这两块的总量被严格限制在“和问题相关的区域”。有读者可能会问为什么不是想象中降90%原因是浏览阶段需要为整个视频建索引这部分token无法省略而且为了保证召回率我倾向于密集抽帧而不是极端稀疏。如果换成更激进的抽帧策略token还能再降但召回率可能掉这个平衡点需要根据实际场景去调。对于30分钟以内的短视频三阶段方案的优势排名没那么明显视频越长优势越突出。3.3 精度指标的变化与分析再看精度。10个视频80个问题的平均得分如下| 方案 | 答案正确 | 证据准确 | 信息完整 | 综合得分 | |---:|---:|---:|---:| | 全量基线 | 71.2 | 63.8 | 65.4 | 66.8 | | 只转文字基线 | 62.5 | 55.0 | 57.1 | 58.2 | | 三阶段方案 | 86.3 | 81.9 | 84.5 | 84.2 |三阶段方案全面领先尤其“证据准确”和“信息完整”提升明显。数值提取类问题从63.5分提升到89.1跨段对比类问题从55.8提升到82.3。为什么全量基线输了我的观察是当上下文里塞进上万帧画面后模型容易出现两种退化一是“近因效应”回答明显更依赖视频尾部内容忽略开头关键信息二是“噪声遮蔽”关键细节被大量无关画面淹没模型干脆跳过细节生成泛泛之论。三阶段方案通过定位先把无关信息全部滤掉精读时模型看到的都是高相关片段注意力集中自然更有可能抠出细节。我把一个90分钟的视频单独拆出来做过验证整段全量时模型在“开头10分钟出现过的参数是否被后续推翻”这类问题上几乎全军覆没改成三阶段后由于定位阶段会同时召回开头和结尾两个片段精读时两者都在上下文里模型能直接对比正确率明显提升。这类问题靠加大窗口很难解决因为窗口越大模型越难抓住两个相隔很远的点去比对反而是聚焦式的精读更容易形成有效推理。4. 实操落地关键参数选择与工程实现4.1 视频切分与关键帧提取参数先讲我实测下来比较稳的参数起点。抽帧密度上浏览阶段从每10秒1帧起步如果视频单场景持续时间长比如纯讲座可以放宽到每20秒1帧如果画面变化快比如软件操作演示、带大量动态画面则加密到每5秒1帧。视频切分我按时间窗进行默认30秒一个窗口窗口重叠5秒这样窗口边界的语义不会断裂。实现层面可以用开源场景检测工具先把视频按镜头切一遍再把镜头合并到30秒窗口里去比纯固定时间窗更贴合内容边界。视频类型浏览抽帧间隔精读抽帧间隔摘要时间窗重叠讲座/访谈10-20秒1秒30秒5秒软件操作演示3-5秒1-2帧/秒15秒3秒混合/多机位课程5-10秒1帧/秒20秒5秒关键帧提取后我会先做去重因为同一镜头内的相邻帧几乎一样全留只会浪费token。所以浏览阶段会加一个“画面相似度去重”的步骤用帧之间的感知哈希做粗过滤相似度高于阈值的帧只保留一个代表帧。这个步骤每1000帧能去掉约三成重复内容省下来的token相当可观而且基本不影响召回效果因为同一镜头内的信息密度差异不大。4.2 摘要粒度与检索阈值的调参心得摘要粒度是个需要反复平衡的参数。摘要太粗一句话描述整个30秒窗口语义检索召回就变得不稳定摘要太细每5秒生成一条token成本剧增而且很多相邻窗口内容重复。我实测下来的经验是每个时间窗的摘要控制在30到60字左右包含场景类型、主讲动作、关键实体、数字四类信息以“这个窗口发生了什么”为准。比如“讲师讲解网络带宽原理PPT显示拓扑图提到25Gbps与10Gbps对比”比单纯写“介绍网络知识”要有用得多。检索阈值方面向量召回的相似度阈值我通常设在0.55到0.65之间太低会召回大量无关片段太高容易漏。实体匹配没有阈值概念看到数字和专有名词就命中。Top-K方面我倾向于取2到3个候选片段而不是只取一个。这里有取舍候选多了精读token会增加候选太少一旦判断出错就无法弥补。实际操作中我会额外加一个“边界扩展”操作把候选片段的起止时间向前向后各扩展30秒防止摘要窗口正好切断了关键内容。这里还有一个容易被忽略的点浏览阶段的摘要模型和精读阶段的推理模型可以不是同一个。浏览摘要用一个轻量模型就够精读再用大模型因为摘要只是用来做索引和召回不需要很强的推理能力。这样组合下来长视频场景的整体成本还能再往下压一截。4.3 工程实现细节一条可复用的pipeline伪代码下面是我在模拟项目X里跑通的一条简化pipeline方便说明思路。真实工程里每一步都要做并发和容错但核心逻辑不长。def video_deep_research(video_path, question): # 阶段一浏览构建索引 transcript asr_with_timestamps(video_path) # 带时间戳的语音转写 frames sample_frames(video_path, interval10) # 10秒1帧 deduped dedup_by_perceptual_hash(frames) # 感知哈希去重 scene_tags tag_scenes(deduped, transcript) # 场景标签 index build_timeline_index(scene_tags, transcript) # 结构化索引 # 阶段二定位召回候选片段 q_vec embed_text(question) cand_a vector_recall(index, q_vec, top_k3) # 向量召回 cand_b entity_recall(index, question) # 实体匹配 cand_c visual_recall(deduped, q_vec) # 视觉召回 candidates merge_candidates(cand_a, cand_b, cand_c) # 并集排序 candidates expand_boundary(candidates, extend30) # 边界扩展 # 阶段三精读生成带证据的答案 details [] for start, end in candidates: dense_frames sample_frames(video_path, segment(start, end), interval1) dense_text transcript_slice(transcript, start, end) ocr_text run_ocr_on_frames(dense_frames) # 按需 detail deep_read(question, dense_frames, dense_text, ocr_text) details.append(detail) answer synthesize_answer(question, details) # 多片段综合 return answer这里有两个容易被忽略的实现细节。第一transcript_slice拿的必须是原始ASR文本不能用阶段一的摘要因为摘要已经损失了上下文精读需要原文。第二visual_recall这个通道初期可以不做但如果用户问题里“画面信息”占比高建议一定要补上否则纯文本召回在视觉类问题上会变得很不可靠。我在早期版本里就偷懒跳过了视觉召回结果遇到“图表中第三行写的是什么”这类问题准确率惨不忍睹。5. 常见问题与避坑指南5.1 定位阶段漏召回关键内容怎么办最典型的故障是精读做了答案也给了但其实是错的原因是正确答案所在的视频片段根本没有进入候选集。漏召回的原因通常是浏览阶段的摘要丢信息或者向量检索阈值太高。排查思路分成三层。第一层检查实体匹配是否覆盖了问题里的数字和专有名词如果摘要里根本没有这个实体实体匹配必然失效说明浏览阶段写摘要时丢了关键信息需要去修摘要的prompt。第二层把向量相似度阈值调低0.05到0.1扩大召回范围看候选集中是否出现正确答案。第三层在浏览阶段增加“关键词密度”维度比如视频里反复出现某术语的窗口即使语义向量相似度不高也要靠词频权重把它顶上来。我遇到过一次比较典型的情况视频里提到某个术语的英文全称和中文简称摘要里只保留了中文简称用户用英文全称提问向量召回和实体匹配全部落空。后来在摘要prompt里强制要求“保留原文术语及常见别名”这类漏召回就基本消失了。关键词题是定位阶段最常见的一类故障值得在系统设计时就防范。5.2 浏览摘要质量不够导致的精读偏离精读阶段依赖定位阶段的结果定位阶段依赖浏览阶段的摘要。所以浏览摘要的质量是整个系统的天花板。摘要如果写得太泛比如每个窗口都写“讲解知识要点”定位阶段就无法区分窗口差异候选片段就会失真。我的防范办法是给摘要加约束条件要求模型对每个窗口回答四个问题这个窗口的场景是什么主讲人在做什么动作出现了哪些专有名词和数字上一窗口和本窗口的内容边界在哪里这样写出来的摘要信息密度高且每句话都可用于检索。如果发现浏览阶段token消耗已经压得很低但精度却掉了九成是摘要写得太粗而不是定位或精读的问题。另外一个建议是浏览阶段不要只依赖单一模型可以安排一个便宜的轻量模型做第一遍摘要再用规则或小模型做一次“实体补齐”把ASR文本里出现过的专有名词强行merge进对应窗口摘要。这个做法token成本几乎为零却能让召回稳定性好一截。我在一个50分钟的视频上用这个办法摘要里缺失实体的比例从11%降到了不到2%。5.3 长视频的时序一致性与多轮追问处理长视频经常有“开头讲A结尾推翻A”的情况。三阶段方案天然适合这种问题因为定位阶段会同时召回开头和结尾两个片段精读时可以一并对比。但如果是多轮追问比如用户先问“方案A怎么部署”再追问“那它和方案B的兼容性呢”第二次追问如果重新走整套pipeline会丢掉第一轮已经定位到的上下文。我的处理办法是把整个pipeline拆成带记忆的多个环节第一轮已经精读过的片段会缓存起来第二轮追及时先做一次“增量定位”——如果问题相关的候选区域和上一轮候选片段重叠超过一定比例就直接复用上一轮的精读结果只对新出现的片段做补充精读。这样既能保证多轮追问的流畅性又避免重复消耗token。实测下来三轮以内的追问相比每次都全量重跑整个过程还能再省30%左右的输入token。时序一致性还有一个隐蔽的坑视频的切分窗口如果跨了两个语义段落比如前10秒在讲概念后20秒在讲操作摘要会把两者揉在一起导致定位命中不够精准。所以我后来把窗口大小从固定30秒改成动态划分先用场景检测找语义边界再在边界内部按30秒上限切分。这个改动看起来不起眼但在“跨段对比类”问题上效果明显值得一试。这套三阶段方案我前前后后迭代了快三个月最大的体会是处理长视频理解真正值钱的不是更大的模型和更长的上下文而是把有限的注意力花在正确的位置上。先浏览、再定位、后精读这十二个字听起来朴素做起来却需要每个环节都较真尤其浏览阶段的摘要质量直接决定整个系统的天花板。如果你也在折腾类似的东西建议先把手头视频的浏览索引做扎实把定位召回调灵敏再去看精读效果往往就能收获意想不到的成本和精度双红利。
这阵子我一直在折腾视频长内容的深度理解。这里说的深度理解不是随便剪一段视频丢给模型让它出个总结而是像Deep Research那样针对一个具体的问题从视频里挖出答案、收集证据、整理成结论。网页文本上的Deep Research已经跑得很顺一到视频就卡壳语音转出来动辄几万字画面抽帧更是海量全量塞进模型先不说成本效果都容易因为上下文太长而崩掉。后来我把一套“先浏览、再定位、后精读”的三阶段方案跑通之后情况完全反过来了回答精度比全量粗暴处理还高一截token消耗反而降了58.3%。这篇文章就把这套思路从头拆开讲清楚——三个阶段分别做什么、为什么能同时做到降本和提精、实测数据是怎么测出来的以及落地时会踩的坑。如果你正在做视频问答、视频知识库、长视频内容分析这类场景这篇应该能帮你省下不少试错时间。1. 当Deep Research遇到视频核心设计思路1.1 视频深度研究的三个典型痛点做视频版的Deep Research第一个绕不开的坎是token爆炸。以一段60分钟的教学视频为例只算语音部分转写出来大概2到3万字换算下来接近4万token如果再把画面也算上按照常规的每秒1帧抽样那就是3600帧多模态模型处理一帧图像往往要消耗大几百个token光画面就是两三百万token的级别。全量塞进上下文一次问答烧掉的成本非常可观更别说多轮追问和多个视频交叉分析。第二个痛点是注意力稀释。模型的注意力是有限的资源几千帧画面和几万字文稿挤在一起关键信息往往淹没在噪声里。我做过对比测试把整段视频全量切成小块塞进上下文问它“视频里提到的某个工具参数在开头处的说明是否和结尾处的结论一致”模型经常会给出前后矛盾的答案因为它根本没有能力同时盯住相距很远的两处细节。第三个痛点是检索困难。网页可以用全文搜索、链接跳转的方式去定位信息视频没有天然的检索结构。你不能让模型自己去“翻目录”只能靠抽帧和转写文本硬啃。这个痛点不解决视频Deep Research就永远停留在“能跑”而不是“好用”的阶段。1.2 为什么“先浏览再定位后精读”符合直觉答案其实很朴素人在研究一段视频材料的时候本来就不会从头到尾一带而过。正常人拿到一段教学录像第一件事是快进浏览看个大概然后根据要回答的问题拖到相关的片段细看确认之后可能还会倒退回去反复核对关键帧。这套流程天然就是“先浏览、再定位、后精读”。所以这套方案的核心是把人做研究的习惯翻译成机器可执行的pipeline先用很低的成本把整段视频粗扫一遍生成带时间戳的结构化索引收到具体问题之后只在索引上做语义检索召回最相关的候选片段最后只对召回片段做高分辨率精读。全量处理是被迫把所有注意力摊到每一帧上而三阶段方案是把注意力集中到真正重要的区域所以同样的信息密度下模型容易抓住重点精度自然上去了。同时浏览阶段和精读阶段只接触整个视频的一小部分token消耗自然大幅下降。注意这里说的“降低58.3%”不是某个理论推导而是我在自己评测集上用固定口径跑出来的实测结果。后面的章节会给出具体评测方式和数据表。1.3 这套方案和普通长上下文方案的本质区别市面上很多视频理解工具都在拼“上下文窗口更大”把窗口从128K扩到1M仿佛能装下更多帧就能解决所有问题。实际上窗口扩容只会延缓症状不会治愈病灶。视频信息和网页文本不一样网页里每个段落都是独立语义块可以按块检索视频里连续数秒甚至数分钟的帧都在讲同一件事信息高度冗余如果全量塞入大量重复内容会白白占据注意力配额。三阶段方案本质上是把“大水漫灌”改成了“精准滴灌”。它不在上下文窗口里硬塞整个视频而是把视频先压缩成索引再按需膨胀回细节。这样的好处是无论视频多长最终进入精读阶段的输入长度只和候选片段相关和视频总时长解耦。这就是为什么它能在窗口不变的情况下反而比超大窗口方案做得更好。2. 三阶段架构拆解浏览、定位、精读各做了什么2.1 阶段一全局浏览——用最少token构建视频索引浏览阶段的目标很明确用尽可能少的token把一段长视频压缩成一份“可检索的目录”。这个阶段不追求理解细节只追求“知道哪里有值得细看的内容”。我的实现方式是三条线并行。第一条线是音频转写用ASR模型把视频语音转成带时间戳的文本这里不做任何摘要先保留全文但转写本身不会直接拿去喂给大模型而是存储起来备用。第二条线是视觉粗扫每隔5到10秒抽一帧用视觉模型给每一帧打个标签比如“讲解PPT”“实验演示”“代码界面”同时提取画面的关键文字信息做成粗粒度场景标签。第三条线是把音频文本按固定时间窗切块比如每30秒一段再把该时间窗内的转写文本和场景标签一起交给一个轻量模型生成一段一到两句的中等粒度摘要。这三条线的产物汇合起来就是一个结构化的视频索引每一行是时间戳区间、场景类型、文本摘要、关键实体。整个视频可能生成几千行索引但token消耗往往只有全量画面的百分之十几。这个索引就是后续所有检索和定位的基础所以阶段一不追求精但一定要全宁可错存不能漏存。这里有个容易被忽视的细节索引里的摘要我会要求模型把“专有名词”和“数字”原样保留不能改写。因为后续的语义检索非常依赖实体匹配一旦摘要阶段把“带宽25Gbps”改写成“网络速度很高”那就彻底检索不到了。这个习惯让我避掉了很多次召回失败的坑。2.2 阶段二语义定位——问题驱动的候选片段召回定位阶段是整套方案的核心。它的输入是用户的问题输出是一批“值得精读”的视频时间段候选。整个过程可以拆成三个并行的召回通道。第一个通道是向量语义召回。把索引中的每一条摘要文本做embedding入库同时把用户问题也做embedding然后做向量相似度检索取Top-K个时间段。这一层解决的是“问题表达和视频内容用词不同但意思相近”的情况比如问题问“网络瓶颈”但视频里说的是“带宽不足”语义向量能把它们拉到一起。第二个通道是实体匹配召回。解析用户问题中的实体关键词和数字条件比如“带宽”“25Gbps”“第三章”然后去索引里做精确匹配。这一层解决的是向量召回容易忽略的精确数字和专有名词问题通常和向量召回形成互补。第三个通道是视觉语义召回。如果问题涉及到画面上的信息比如“图中标注的按钮在哪里”我会把问题向量和浏览阶段保存的关键帧特征做对比找出相关性最高的帧所在的片段。这个通道独立于文本专门兜住纯视觉类问题。三个通道的结果做并集再按相关度排序取前几个时间片段作为精读候选。我通常保留1到3个候选片段每个片段长度控制在2到5分钟之间这样后续精读的token预算就非常可控。提示定位阶段的召回策略宁可“宽”一点。如果Top-K只取一个片段一旦漏掉真正答案所在的位置后续精读做得再细也无济于事。我会适当扩大候选区间把因为摘要太粗而丢失的边界帧重新拉回来。2.3 阶段三定点精读——高分辨率分析只发生在刀刃上经过定位阶段真正需要大模型认真读的内容已经收缩到很窄的范围了。精读阶段在这个小范围内做高分辨率分析然后把答案组织出来。精读的第一步是提高采样密度。浏览阶段可能每10秒抽一帧精读阶段我会对这个区间提升到每秒1到2帧保证不遗漏任何关键画面。第二步是重新调取对应的完整ASR文本不再使用摘要让模型读到原始的表述。第三步是按需做OCR如果问题上涉及屏幕上的文字、代码、表单就把关键帧送去OCR识别把识别出的文字并入上下文。第四步才是让大模型基于这些高密度材料做推理。这里有个关键设计精读不只是“读”和“答”而是要完成“证据链闭环”。我会要求模型在回答时给出所依据的时间戳和画面描述这样最终答案不仅正确还能溯源到视频的具体位置。对于那种需要跨多个片段综合的问题我还会让模型先分别精读每个候选片段生成子结论再汇总成最终答案避免长上下文把信息搅浑。整个精读阶段的token消耗只和候选片段的长度相关和视频总长度无关。一个60分钟的视频如果只召回3个3分钟的片段精读阶段的输入大概只有全量的九分之一。这就是成本能压下去的根本原因。3. 精度提升与token消耗下降58.3%的数据复盘3.1 评测口径与对照方案为了让“精度提升”和“token下降58.3%”这两个说法经得起推敲我专门搭了一套固定的评测集。评测集用的是某技术课程库中的10个视频时长从20分钟到90分钟不等每个视频配有8个问题涵盖概念解释、数值提取、步骤复述、跨段对比、画面信息识别等常见类型总共80个问答对。对照方案有三组。第一组是全量基线整个视频抽帧加语音转写全部塞进上下文让模型直接回答。第二组是只转文字基线只用ASR文本、不用画面全量文本直接进模型。第三组是本文介绍的三阶段方案。三个方案都使用同一个底层大模型避免模型本身差异干扰对比结果。精度指标采用人工打分从“答案正确”“证据准确”“信息完整”三个维度各打0到3分满分9分最后归一化成百分制。这里要特别说明一点在长视频场景上一张画面可能包含PPT文字、实验操作、人物动作等多重信息纯文本方案天然劣势明显所以只转文字基线更多是作为参照值不是竞对方案。即便如此三阶段方案在数值提取、步骤复述这类偏向文本语义的问题上也稳定优于纯文本基线说明它的提升不是单纯靠“加了画面信息”赢来的。3.2 token成本对比的实测数据先看token。下表是我在10个视频上的平均数据单位是千token四舍五入到整数方案输入token均值相对全量基线说明全量基线帧文本约2860K100%每1秒1帧全部进上下文只转文字基线约52K不适用仅全量文本三阶段方案约1194K41.7%浏览定位精读全流程从这张表能直观看到三阶段方案相对全量基线的平均降幅恰好是58.3%也就是输入token量只有原来的四成出头。其中定位阶段本身几乎不消耗大模型token主要靠向量检索和实体匹配真正的token大头集中在浏览阶段的索引构建和精读阶段的高分辨率分析上而这两块的总量被严格限制在“和问题相关的区域”。有读者可能会问为什么不是想象中降90%原因是浏览阶段需要为整个视频建索引这部分token无法省略而且为了保证召回率我倾向于密集抽帧而不是极端稀疏。如果换成更激进的抽帧策略token还能再降但召回率可能掉这个平衡点需要根据实际场景去调。对于30分钟以内的短视频三阶段方案的优势排名没那么明显视频越长优势越突出。3.3 精度指标的变化与分析再看精度。10个视频80个问题的平均得分如下| 方案 | 答案正确 | 证据准确 | 信息完整 | 综合得分 | |---:|---:|---:|---:| | 全量基线 | 71.2 | 63.8 | 65.4 | 66.8 | | 只转文字基线 | 62.5 | 55.0 | 57.1 | 58.2 | | 三阶段方案 | 86.3 | 81.9 | 84.5 | 84.2 |三阶段方案全面领先尤其“证据准确”和“信息完整”提升明显。数值提取类问题从63.5分提升到89.1跨段对比类问题从55.8提升到82.3。为什么全量基线输了我的观察是当上下文里塞进上万帧画面后模型容易出现两种退化一是“近因效应”回答明显更依赖视频尾部内容忽略开头关键信息二是“噪声遮蔽”关键细节被大量无关画面淹没模型干脆跳过细节生成泛泛之论。三阶段方案通过定位先把无关信息全部滤掉精读时模型看到的都是高相关片段注意力集中自然更有可能抠出细节。我把一个90分钟的视频单独拆出来做过验证整段全量时模型在“开头10分钟出现过的参数是否被后续推翻”这类问题上几乎全军覆没改成三阶段后由于定位阶段会同时召回开头和结尾两个片段精读时两者都在上下文里模型能直接对比正确率明显提升。这类问题靠加大窗口很难解决因为窗口越大模型越难抓住两个相隔很远的点去比对反而是聚焦式的精读更容易形成有效推理。4. 实操落地关键参数选择与工程实现4.1 视频切分与关键帧提取参数先讲我实测下来比较稳的参数起点。抽帧密度上浏览阶段从每10秒1帧起步如果视频单场景持续时间长比如纯讲座可以放宽到每20秒1帧如果画面变化快比如软件操作演示、带大量动态画面则加密到每5秒1帧。视频切分我按时间窗进行默认30秒一个窗口窗口重叠5秒这样窗口边界的语义不会断裂。实现层面可以用开源场景检测工具先把视频按镜头切一遍再把镜头合并到30秒窗口里去比纯固定时间窗更贴合内容边界。视频类型浏览抽帧间隔精读抽帧间隔摘要时间窗重叠讲座/访谈10-20秒1秒30秒5秒软件操作演示3-5秒1-2帧/秒15秒3秒混合/多机位课程5-10秒1帧/秒20秒5秒关键帧提取后我会先做去重因为同一镜头内的相邻帧几乎一样全留只会浪费token。所以浏览阶段会加一个“画面相似度去重”的步骤用帧之间的感知哈希做粗过滤相似度高于阈值的帧只保留一个代表帧。这个步骤每1000帧能去掉约三成重复内容省下来的token相当可观而且基本不影响召回效果因为同一镜头内的信息密度差异不大。4.2 摘要粒度与检索阈值的调参心得摘要粒度是个需要反复平衡的参数。摘要太粗一句话描述整个30秒窗口语义检索召回就变得不稳定摘要太细每5秒生成一条token成本剧增而且很多相邻窗口内容重复。我实测下来的经验是每个时间窗的摘要控制在30到60字左右包含场景类型、主讲动作、关键实体、数字四类信息以“这个窗口发生了什么”为准。比如“讲师讲解网络带宽原理PPT显示拓扑图提到25Gbps与10Gbps对比”比单纯写“介绍网络知识”要有用得多。检索阈值方面向量召回的相似度阈值我通常设在0.55到0.65之间太低会召回大量无关片段太高容易漏。实体匹配没有阈值概念看到数字和专有名词就命中。Top-K方面我倾向于取2到3个候选片段而不是只取一个。这里有取舍候选多了精读token会增加候选太少一旦判断出错就无法弥补。实际操作中我会额外加一个“边界扩展”操作把候选片段的起止时间向前向后各扩展30秒防止摘要窗口正好切断了关键内容。这里还有一个容易被忽略的点浏览阶段的摘要模型和精读阶段的推理模型可以不是同一个。浏览摘要用一个轻量模型就够精读再用大模型因为摘要只是用来做索引和召回不需要很强的推理能力。这样组合下来长视频场景的整体成本还能再往下压一截。4.3 工程实现细节一条可复用的pipeline伪代码下面是我在模拟项目X里跑通的一条简化pipeline方便说明思路。真实工程里每一步都要做并发和容错但核心逻辑不长。def video_deep_research(video_path, question): # 阶段一浏览构建索引 transcript asr_with_timestamps(video_path) # 带时间戳的语音转写 frames sample_frames(video_path, interval10) # 10秒1帧 deduped dedup_by_perceptual_hash(frames) # 感知哈希去重 scene_tags tag_scenes(deduped, transcript) # 场景标签 index build_timeline_index(scene_tags, transcript) # 结构化索引 # 阶段二定位召回候选片段 q_vec embed_text(question) cand_a vector_recall(index, q_vec, top_k3) # 向量召回 cand_b entity_recall(index, question) # 实体匹配 cand_c visual_recall(deduped, q_vec) # 视觉召回 candidates merge_candidates(cand_a, cand_b, cand_c) # 并集排序 candidates expand_boundary(candidates, extend30) # 边界扩展 # 阶段三精读生成带证据的答案 details [] for start, end in candidates: dense_frames sample_frames(video_path, segment(start, end), interval1) dense_text transcript_slice(transcript, start, end) ocr_text run_ocr_on_frames(dense_frames) # 按需 detail deep_read(question, dense_frames, dense_text, ocr_text) details.append(detail) answer synthesize_answer(question, details) # 多片段综合 return answer这里有两个容易被忽略的实现细节。第一transcript_slice拿的必须是原始ASR文本不能用阶段一的摘要因为摘要已经损失了上下文精读需要原文。第二visual_recall这个通道初期可以不做但如果用户问题里“画面信息”占比高建议一定要补上否则纯文本召回在视觉类问题上会变得很不可靠。我在早期版本里就偷懒跳过了视觉召回结果遇到“图表中第三行写的是什么”这类问题准确率惨不忍睹。5. 常见问题与避坑指南5.1 定位阶段漏召回关键内容怎么办最典型的故障是精读做了答案也给了但其实是错的原因是正确答案所在的视频片段根本没有进入候选集。漏召回的原因通常是浏览阶段的摘要丢信息或者向量检索阈值太高。排查思路分成三层。第一层检查实体匹配是否覆盖了问题里的数字和专有名词如果摘要里根本没有这个实体实体匹配必然失效说明浏览阶段写摘要时丢了关键信息需要去修摘要的prompt。第二层把向量相似度阈值调低0.05到0.1扩大召回范围看候选集中是否出现正确答案。第三层在浏览阶段增加“关键词密度”维度比如视频里反复出现某术语的窗口即使语义向量相似度不高也要靠词频权重把它顶上来。我遇到过一次比较典型的情况视频里提到某个术语的英文全称和中文简称摘要里只保留了中文简称用户用英文全称提问向量召回和实体匹配全部落空。后来在摘要prompt里强制要求“保留原文术语及常见别名”这类漏召回就基本消失了。关键词题是定位阶段最常见的一类故障值得在系统设计时就防范。5.2 浏览摘要质量不够导致的精读偏离精读阶段依赖定位阶段的结果定位阶段依赖浏览阶段的摘要。所以浏览摘要的质量是整个系统的天花板。摘要如果写得太泛比如每个窗口都写“讲解知识要点”定位阶段就无法区分窗口差异候选片段就会失真。我的防范办法是给摘要加约束条件要求模型对每个窗口回答四个问题这个窗口的场景是什么主讲人在做什么动作出现了哪些专有名词和数字上一窗口和本窗口的内容边界在哪里这样写出来的摘要信息密度高且每句话都可用于检索。如果发现浏览阶段token消耗已经压得很低但精度却掉了九成是摘要写得太粗而不是定位或精读的问题。另外一个建议是浏览阶段不要只依赖单一模型可以安排一个便宜的轻量模型做第一遍摘要再用规则或小模型做一次“实体补齐”把ASR文本里出现过的专有名词强行merge进对应窗口摘要。这个做法token成本几乎为零却能让召回稳定性好一截。我在一个50分钟的视频上用这个办法摘要里缺失实体的比例从11%降到了不到2%。5.3 长视频的时序一致性与多轮追问处理长视频经常有“开头讲A结尾推翻A”的情况。三阶段方案天然适合这种问题因为定位阶段会同时召回开头和结尾两个片段精读时可以一并对比。但如果是多轮追问比如用户先问“方案A怎么部署”再追问“那它和方案B的兼容性呢”第二次追问如果重新走整套pipeline会丢掉第一轮已经定位到的上下文。我的处理办法是把整个pipeline拆成带记忆的多个环节第一轮已经精读过的片段会缓存起来第二轮追及时先做一次“增量定位”——如果问题相关的候选区域和上一轮候选片段重叠超过一定比例就直接复用上一轮的精读结果只对新出现的片段做补充精读。这样既能保证多轮追问的流畅性又避免重复消耗token。实测下来三轮以内的追问相比每次都全量重跑整个过程还能再省30%左右的输入token。时序一致性还有一个隐蔽的坑视频的切分窗口如果跨了两个语义段落比如前10秒在讲概念后20秒在讲操作摘要会把两者揉在一起导致定位命中不够精准。所以我后来把窗口大小从固定30秒改成动态划分先用场景检测找语义边界再在边界内部按30秒上限切分。这个改动看起来不起眼但在“跨段对比类”问题上效果明显值得一试。这套三阶段方案我前前后后迭代了快三个月最大的体会是处理长视频理解真正值钱的不是更大的模型和更长的上下文而是把有限的注意力花在正确的位置上。先浏览、再定位、后精读这十二个字听起来朴素做起来却需要每个环节都较真尤其浏览阶段的摘要质量直接决定整个系统的天花板。如果你也在折腾类似的东西建议先把手头视频的浏览索引做扎实把定位召回调灵敏再去看精读效果往往就能收获意想不到的成本和精度双红利。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
