Lecture 03 学习讲义
正文
工具
按问题查找
Lecture 035 · 查询依赖的交互:一个可运行的区域加权对照

5 · 查询依赖的交互:一个可运行的区域加权对照

独立阅读

并入相关学习路径

同一CLIP缓存、exact/IVF搜索、延迟/扫描量、区域交互基线

5 · 查询依赖的交互:一个可运行的区域加权对照

“每对都调用模型”不等于“有图文交互”。我们再定义一个小而完整的 query-dependent 后期交互:先缓存左右两个照片区域的 CLIP 向量 r1,r2r_1,r_2;对每一个查询 qq,计算 uj=q⊤rju_j=q^\top r_j,然后用 wj=softmax(uj/0.05)w_j=\mathrm{softmax}(u_j/0.05) 加权,得到分数 s=∑jwjujs=\sum_jw_ju_j。查询不同,区域权重和汇总表示不同,所以它确实在比较时使用了图和文的共同信息;但它是本册定义的加权规则,没有训练新的联合编码器,也不是 CLIP 官方的全图匹配分数。

在“猫左、宇航员右”拼贴上,cat 查询给左猫区94.15%的权重;astronaut 查询给右宇航员区80.08%。这是一项可观察的查询依赖变化。它的代价是每对查询与图要计算多个区域点积,缓存也从一向量变成区域集合;由于区域特征独立生成,它仍可部分预计算。

接着使用两条“谁在左/右”的关系句。交换区域顺序后,下述加权分数完全相同,因为这个公式对区域排列不敏感;它没有使用坐标。这不是代码 bug,而是设计本身丢失了顺序。如果需要真正的区域关系,需要显式位置、关系模块或经训练的联合模型。一个一般的 cross-encoder 会在内部让图文 token 相互条件化,通常不能将整次交互压成一个与查询无关的图片向量;本册只给其结构和成本解释,没有假装运行或比较某个未加载的 cross-encoder。