你有没有想过，当你在视频网站搜索"一个人打开冰箱拿出牛奶"的时候，系统到底是怎么从几百万段视频里，又快又准地找到那一段的？
这事儿听起来简单，做起来却挺拧巴。快和准,这两件事天生就是矛盾的。要快,系统得提前把视频处理好,存成一个简单的"指纹",搜索的时候直接拿指纹比对,根本不看视频内容本身。要准,系统就得真正把你的问题和视频内容拉到一起,逐帧逐句去核对,但这样一来,每来一个新搜索请求,就得把视频重新看一遍,慢得要命。
这篇论文要解决的,正是这个两难。
一、当下最好的方法,好在哪里,又卡在哪里
目前视频搜索的主流做法叫双编码器检索。
双编码器*：把视频和文字搜索词分别转换成一组数字(向量),然后比较这两组数字的相似程度,数字越接近,说明内容越匹配。
这套做法的好处是快,因为视频的数字表示提前算好存着,搜索时直接拿来比对就行。CLIP4Clip、X-CLIP这些比较知名的系统都是这个路子。但问题也很明显:视频的数字表示是在"没见过搜索词"的情况下算出来的,文字和画面从头到尾没有真正"打过交道"。打个比方,这就像你去相亲角,提前把自己写成一张固定的卡片,"25岁,会做饭,喜欢安静",然后别人拿着自己的择偶条件去匹配卡片上的关键词。可现实中很多匹配靠的是聊起来才知道的默契,一张死卡片是捕捉不到的。
于是业内又搞出了联合编码器,也叫重排序器(reranker)。
联合编码器*：让搜索词和视频内容真正放在一起,经过模型的注意力机制互相"对话"一遍,再给出匹配分数,这样能发现仅凭各自特征看不出来的细节关联。
这个在静态图片搜索领域已经很成熟了,BLIP系列模型就是典范。但视频不一样,视频是一串帧,你要联合编码,就得把这一串帧的所有细节都存起来,存储量跟着帧数疯涨;而且如果每次搜索都要把候选视频重新塞进一个大模型里跑一遍,那延迟会大到没法忍受。还有一类更狂野的做法,直接上多模态大语言模型(MLLM)做重排序,比如LamRA和CaRe-DPO这些系统,效果确实好,但代价是把一个几十亿参数的解码器直接摆在了每次搜索的路径上。CaRe-DPO用的模型有76亿参数,这是什么概念?相当于你问个路,系统得先叫醒一整个专家团队开会讨论才给你答案。
这就是VEDJE出场前,整个领域卡住的地方:要联合匹配的精度,就得接受视频特征现场重新处理的巨大代价;要省掉现场处理的代价,就只能退回到死板的向量比对。
那有没有办法两头都要?
VEDJE*：全称Video-Efficient Discriminative Joint Encoder,是本文提出的一套视频文本检索重排序方案,核心思路是把视频特征提前压缩好,存成一个紧凑的缓存,搜索时只用一个很小的模型去读这个缓存,不用再碰原始视频。
二、把缓存按时间切片存起来,而不是揉成一团
VEDJE的第一个关键设计,是怎么把视频压缩进缓存里。
一个最简单的想法是,把整段视频揉成一个向量,存储量极小,但代价是把时间信息全部抹掉了。如果有人问"先打开冰箱还是先拿牛奶",这种被揉烂的表示根本答不上来,因为前后顺序的信息已经被平均没了。另一个极端是,把每一帧的每一个局部位置的特征全部原样存下来,信息最全,但存储量爆炸,VideoPrism这种骨干网络产生的完整帧和局部块(patch)特征,一段视频要占6.02MB。
VEDJE选择了一个折中方案:在每一帧内部做压缩,但帧与帧之间的时间顺序保留下来,不互相混合。
具体来说,系统用一个共享的两层transformer解码器,针对每一帧单独算出少量几个"学习出来的查询token"去对该帧的局部特征做注意力汇总,把一帧压缩成M个token(默认是4个),然后把16帧的token按时间顺序拼接起来,存成一个有序的缓存。
这就好比你去参加一个连续三天的会议,想做笔记。你完全可以把三天的内容全部混在一起写成一段话,省纸但事后根本分不清哪句话是哪天说的;你也可以把每句话都原样抄下来,信息最全但笔记本写得密密麻麻根本没法快速翻阅。VEDJE的做法相当于每天结束时提炼出几条关键笔记,按日期分开记录。如果不这样分开记,那"第一天说了要降价,第三天又说不降了"这种随时间变化的事实,你翻遍笔记本也理不清楚先后顺序,而这恰恰是很多视频搜索问题最需要的那种时间线索。
Table 4的实验直接验证了这个设计的价值。在存储预算完全相同的情况下,把帧特征直接做平均池化(mean pooling)或者注意力池化(attention pooling),T2V(文字搜索视频)召回率只有51.7到52.0,而VEDJE按时间分组存储能做到54.0。换句话说,存储量一分不多花,仅仅是组织方式的改变,就带来了2个百分点的提升。
这里出现了两个专业名词需要解释清楚。
T2V(text-to-video)*：用一段文字去搜索最匹配的视频,这是最常见的搜索方向。
V2T(video-to-text)*：反过来,给一段视频,从一堆候选文字描述里找出最匹配的那句话。
R@1*：召回率的一种衡量方式,表示系统给出的第一个结果就命中正确答案的比例,数值越高越好。
三、让模型自己去猜"接下来会变成什么样",顺便学会压缩
VEDJE的第二个关键设计更有意思,叫特征变化预测(feature-change supervision)。
这个设计解决的问题是:缓存一旦写好,就要服务所有未来还没出现的搜索词,系统压根不知道以后有人会问什么。那怎么保证压缩出来的那几个token真的抓住了视频里"有用"的信息,而不是随便抓了几个无关紧要的细节?
论文的做法是,额外训练一个"预测头",让它根据某一帧压缩后的token,去预测几帧之后视觉特征会发生什么变化,具体是预测第t+h帧的特征减去第t帧特征的差值。注意,这个预测头只在训练阶段存在,一旦训练结束就被扔掉,不会增加搜索时的任何计算负担。
为什么要预测"变化量"而不是直接预测"未来那一帧长什么样"?论文给出了明确的对比数据。在Table 18里,直接重建当前帧特征,T2V R@1是54.2;预测未来帧的绝对特征,反而降到52.8;而预测"变化量"(delta),达到54.6,是三者里最好的。
这背后的道理其实很直白。两帧之间有大量内容是完全不变的,比如背景墙、桌子、光线角度。如果非要去重建或预测这些压根没变的东西,模型大部分精力都耗在了"记住那些不重要的不变量"上。而只盯着变化量去学,相当于直接把注意力聚焦在"发生了什么事"这件事本身上,这正是动作识别和事件理解最核心的信息。
这让我想起侦探破案的方式。好的侦探不会把房间里的每一件物品都仔仔细细记录一遍,他们会特别留意"哪里跟上次不一样了",烟灰缸挪动了位置,窗户本来是关的现在开了。如果侦探非要把房间里所有静止不变的东西都一视同仁地记下来,他反而会在信息过载里错过真正的线索。VEDJE的预测头干的就是这个侦探的活,专注抓变化,而不是无差别记录全部。
这个设计在压缩预算特别紧张的时候效果尤其明显。Table 3显示,当缓存从64个token(48KiB)压缩到16个token(12KiB,相当于每帧只留1个token)时,有没有这个特征变化监督,T2V的提升幅度从0.6个百分点跳到了1.9个百分点。这说明压缩越狠,这种"抓重点"的训练信号就越重要,因为留给模型犯错的空间已经很小了。
四、给联合打分器加一个"参考意见"
VEDJE的第三个设计是怎么在线打分。
系统用一个只有33M参数的小型联合编码器(MiniLM-L12),把搜索文字和缓存里的视频token拼在一起送进去,让它们互相做注意力计算,产出一个融合后的表示。但这还不是终点,论文还把第一阶段检索给出的粗略相关性分数,也嵌入进来,以残差的方式加到联合表示上,再过一个打分头给出最终分数。
为什么要保留第一阶段的分数?Table 11给出了理由。只用第一阶段分数(没有联合特征),T2V R@1是50.1;只用联合特征(没有第一阶段分数),反而掉到43.8;两者结合,达到54.6。
这组数字挺有意思的,因为它说明联合特征单独拿出来用,表现居然比什么都不做更差。原因可能是联合编码器只看到了压缩后的缓存,信息已经有损耗,如果完全抛弃第一阶段那个基于完整特征算出来的分数,反而是把一部分有效信息主动扔掉了。两边各有各的信息来源,合在一起才是互补的。
这就像请两个专家一起判案。一个专家只看过案件卷宗摘要(第一阶段分数),另一个专家只看过现场照片的几张关键截图(压缩后的联合特征)。单独听任何一个专家的意见都不够全面,但把两人的判断综合起来权衡,反而能得出更靠谱的结论。如果强行只听现场照片专家的,会丢掉卷宗摘要里那些照片拍不到的背景信息;反过来也一样。
Table 5进一步验证了这套联合编码器本身的价值。同样是读取同一份缓存,用传统的MaxSim打分方式(一种常见的多向量匹配算法),只能做到51.9,换成这个联合编码器,直接提升到54.6。这说明不仅是"存什么"重要,"怎么读"同样重要。
五、实验结果:到底有多大提升,代价有多小
论文在MSR-VTT、MSVD、DiDeMo、ActivityNet四个标准数据集上做了测试,覆盖T2V和V2T两个方向。
最亮眼的结果出现在MSR-VTT上搭配微调过的VideoCLIP-XL第一阶段:T2V R@1从56.2提升到59.8,V2T R@1从55.1提升到58.8。这个结果的重要性在于,它证明即便第一阶段已经经过专门微调、表现已经很强了,VEDJE的重排序依然能挤出额外的提升,而不是只能在弱基线上捡便宜。
跨数据集的结果同样一致。无论用VideoPrism还是零样本VideoCLIP-XL做第一阶段,VEDJE在全部四个数据集的两个方向上都带来了正向提升,T2V提升幅度从1.1到8.9个百分点不等,V2T提升幅度从0.2到7.2个百分点不等。
在和EERCF这个同样做轻量级重排序的系统对比时,用同样的CLIP ViT-B/16骨干网络,EERCF达到49.9/47.8(T2V/V2T),VEDJE达到49.8/49.6,T2V基本持平,V2T高出1.8个百分点,而且VEDJE的视觉骨干网络是完全冻结不动的,没有做任何微调。
存储方面的结果也值得细说。默认配置下,一段视频的缓存只占48KiB,比起同样特征的完整帧和局部块表示(6.02MiB),缩小了128.5倍。如果继续压缩到每帧只留1个token,缓存进一步缩到12KiB,T2V R@1仅从54.6降到54.4,几乎没有损失。
延迟方面,论文在一张NVIDIA L40S显卡上做了完整的端到端测试。处理20个候选视频,64-token缓存配置的完整查询耗时5.79毫秒,其中第一阶段检索本身大约占4.3毫秒,也就是说VEDJE重排序增加的额外延迟只有1.5毫秒左右。随着候选数量增加到100,16-token的小缓存开始显出速度优势,把延迟从7.83毫秒压到6.33毫秒。
这些数字放在一起说明一件事:存储和速度上的代价,相比精度收益,是相当划算的。
六、模型大小对比:小模型打出了大模型的效果
论文在Figure 1里画了一张图,横轴是在线模型的参数量,纵轴是T2V R@1。这张图最直观地体现了VEDJE的定位。
VEDJE的在线总参数量大约是143M到157M之间(取决于用哪个第一阶段骨干),包含第一阶段文本编码器和33M的联合重排序器。相比之下,LamRA和CaRe-DPO这类基于多模态大语言模型的重排序系统,在线部分用的解码器就有7.6B参数,是VEDJE的近50倍。而VEDJE搭配微调过的VideoCLIP-XL达到的59.8分,已经和LamRA的复现结果59.7非常接近。
这组对比挺值得琢磨的。花50倍的参数量,换来的提升幅度居然和一个轻量方案打平手。当然CaRe-DPO最终做到了64.1,确实更高,说明大模型路线在精度天花板上还是有优势的,但这个优势的边际成本已经相当昂贵了。
七、论文自己承认的局限
论文在结尾部分很诚实地指出了几个还没解决的问题。
缓存是"对搜索词盲视"的,一旦写好就固定了,服务所有未来的查询,没法针对具体某个搜索词去动态调整或者补充缓存内容。
缓存依赖固定的视觉骨干网络和压缩器,如果想换一个更强的骨干网络,就得把整个视频库重新编码一遍,这个重建成本在实际部署里是不能忽视的。
第一阶段检索和第二阶段重排序目前是分开训练的,没有打通联合优化,这意味着两边各自最优未必等于整体最优。
四个测试数据集全部是英文字幕、网络来源的视频,论文自己也说了,这些结果没法说明方法在多语言场景下表现如何。
写在后面
读完这篇论文,最让我意外的其实是Table 11那组对比数据,只用联合特征(43.8)反而比只用第一阶段粗分数(50.1)表现更差。这完全反直觉,因为直觉上"更精细的联合匹配"应该天然比"粗糙的向量匹配"强。但事实是,压缩带来的信息损耗一旦叠加上单独使用,反而会把原本能用的信息也搭进去。这提醒我一件事:很多时候"更精细的方法"不是无条件更好,它的优势必须建立在和粗糙方法互补的前提下,单独拿出来可能还不如老办法。
另一个让我多想了一会儿的细节,是特征变化预测这个训练技巧。它本质上是在教模型"去关注差异而不是全部",这个思路其实在很多领域都能看到影子,比如视频压缩编码里的帧间差分,比如版本控制系统git只存储diff而不是每次全量快照。这篇论文把这个古老的"只存变化"的智慧,用一种全新的方式嫁接到了神经网络的监督信号设计里,这个嫁接本身比技术细节更有启发性。
论文还有一个没细说但值得追问的地方:当视频库规模从几万段扩展到几千万段甚至更大的时候,这套缓存方案的检索延迟会不会出现新的瓶颈?论文给出的payload外推数字是一千万段视频大约需要0.123到0.492TB存储,这个数字听起来还可以接受,但真正的生产环境里,磁盘I/O的随机读写性能、缓存命中率这些工程细节,恐怕才是决定这套方案能不能真正落地的关键,而这部分论文只是浅浅地碰了一下。
Q&A
Q1：VEDJE是什么？
A：VEDJE是一种视频文本检索的重排序方案，核心做法是提前把视频特征压缩成一个紧凑的缓存文件，搜索时只用一个33M参数的小模型读取这个缓存，不用再重新处理原始视频，兼顾了检索精度和搜索速度。
Q2：VEDJE相比其他方法提升了多少效果？
A：在MSR-VTT数据集上，搭配微调过的VideoCLIP-XL第一阶段，VEDJE把文字搜视频的R@1从56.2提升到59.8，视频搜文字的R@1从55.1提升到58.8，在四个主流数据集的两个检索方向上都有稳定提升。
Q3：VEDJE的视频缓存能压缩到多小？
A：默认缓存每段视频只占48KiB，比完整的帧和局部特征表示小128.5倍。如果进一步压缩到每帧只存1个token，缓存能缩到12KiB，而文字搜视频的召回率几乎没有下降。
