搜索相关性测量放在视觉语言模型Vision-Language ModelVLM这个新语境下重新做一遍是目前 Web-Scale Search 方向里一个很容易出效果、但也很容易被低估的切入点。核心问题可以用一句话描述当一个用户 query 和一张网页页面出现在模型面前模型需要判断这段文本和页面里的视觉内容到底是不是在说同一件事以及匹配到什么程度。传统做法只依赖文本字段VLM 把页面里的图像、布局信息也纳入判断适合做搜索排序里的相关性信号也适合做召回后的精排特征。这篇文章适合搜索算法工程师、相关性评测负责人以及想给图文搜索场景增加视觉理解能力的团队看。最值得你关注的不是模型本身而是怎么在 web-scale 的数据量、延迟和成本约束下把 VLM 变成一条稳定可评测的相关性流水线。下面按我对这个方向的理解和实际落地习惯拆开讲。1. 先理解相关性测量在搜索系统里到底卡在哪个环节1.1 文本相关性为什么够用又不完全够用传统搜索相关性测量基本围绕文本展开。query 进来之后系统拿它和标题、摘要、正文、锚文本、类目路径做词项匹配再叠加深度文本模型比如双塔召回、交叉编码精排最后输出一个相关分。这套体系经过很多年验证在纯文本场景里非常稳定。但它有一个天然盲区网页本身是图文混合的。很多页面的核心信息其实藏在图片里文本反而很稀疏或者因为 SEO 写法变得很绕。举个典型例子用户搜“红色轻便跑步鞋适合女生”一个商品页的标题写的是“Women’s Lightweight Knit Sneakers”正文里大量出现运动和折扣词但首图就是一双红色跑鞋。纯文本模型只能靠那点英文词和 query 碰出弱相关可人眼一看页面就知道强相关。反过来还有一种情况页面文本堆满了关键词图片却是无关的横幅广告图。这时候文本模型会给高分但用户点进去体验很差。所以文本相关性不是不够用而是单独使用时对图文混合页面的判别上限有限。VLM 要做的事情就是把这部分缺失的视觉信号补回来。1.2 VLM 能补上的不是“看图说话”而是“跨模态对齐”这里要先纠正一个常见误解。把 VLM 用在相关性测量里不是让它输出一段图片描述再把描述拿去做文本匹配。那是“图像转文本”的间接路径信息经过两次压缩误差会累积。更常见的做法是直接做跨模态对齐。一种思路是用对比式双塔结构把 query 文本编码成一个向量把页面图片编码成另一个向量让两者在同一个语义空间里能算相似度。典型代表就是 CLIP 这类模型。另一种思路是交叉式结构把 query 文本和图片的 patch 一起喂给同一个 Transformer让模型端到端输出一个相关分。这两种思路各有适用位置后面会展开。之所以说 VLM 补的是“对齐”而不是“理解”是因为搜索相关性本质上不是让模型看懂图片内容而是让模型判断“用户说的东西”和“页面展示的东西”是否匹配。这种匹配能力恰好是预训练 VLM 在大量图文对上学到的核心技能。1.3 哪些场景优先上哪些场景先缓一缓不是所有搜索都需要视觉相关性。按我的判断最有价值的是这几类电商搜索query 常常带颜色、风格、材质、场景等视觉属性。图文攻略和测评站文章配图承载大量真实信息。新闻搜索结果图片对新闻事件相关性有明显提示作用。UGC 内容用户发布的内容往往文字少、图片多。视频封面和短内容场景封面图决定了用户在不在意的第一印象。优先级低的是纯文本页面比如技术文档、论文、代码问答。这些页面即使有图图也是示意图视觉信号对相关性的增量非常有限。另一个低优先级场景是 query 本身没有视觉意图比如人名、产品型号、学术术语。如果用户搜“BERT 论文”配图是什么根本不影响相关性判断这时候上 VLM 就是纯增加成本和计算延迟。2. 技术路线双塔、交叉和融合怎么选2.1 双塔式图片向量离线算好线上只跑 query双塔式是落地成本最低的一条路。文本侧一个塔图像侧一个塔训练时让匹配的图文对在向量空间里靠近不匹配的拉远。线上使用时query 编码成 query embedding页面图片编码成 image embedding两者算余弦相似度或者点积。它的最大优点是图片 embedding 可以离线算。web-scale 场景里页面图片动辄几十亿张但绝大多数是静态的不需要实时更新。每天增量跑一批新图把向量写进向量库线上查询时只需要实时计算 query embedding然后到向量库里做 ANN 检索。这条链路的在线算力消耗非常低一个 query 一次文本编码就够了。缺点是双塔各自压缩信息细粒度匹配能力有限。两个塔交互不足遇到“红色但不适合女生”“轻便但不要那种网面”这种带条件限定的 query双塔往往区分不出来。所以在我的项目里双塔视觉分更适合放在粗排阶段或者作为一个召回通道不适合直接当精排绝对依据。2.2 交叉式把 query 和图片拼在一起打分交叉式结构不分离编码而是把 query 文本 token 和图片视觉 token 拼在一起喂给同一个 Transformer模型输出一个相关分数。因为模型能看到 query 和图片之间的细粒度交互所以准确率通常比双塔高尤其是条件限定多、语义细节多的 query。代价也很明确图片没法离线计算。每次 query 进来系统要对每一个候选页面都跑一遍完整模型在线算力需求是候选数量的倍数。web-scale 场景很难在精排阶段对全量候选跑交叉式 VLM一般只对点选后的前几十条跑或者离线预计算一部分热门 query 的结果缓存。所以我的建议是交叉式 VLM 放在精排末端做“守门员”用它的分数纠正文本双塔和视觉双塔都给出中高分但实际不匹配的样本。如果线上延迟预算很紧就先不要碰交叉式先把双塔的视觉特征落地。2.3 和现有排序特征怎么融合VLM 视觉分不是一个孤立的新排序方式而是要作为特征进入到现有的相关性融合框架里。常见的融合方式有三种加权求和final_score alpha * text_score beta * vision_scorealpha 和 beta 在验证集上调。分档修正先按文本相关性归入档位再在档位内用视觉分微调。规则兜底当视觉分极低且文本分中等时直接降档用来拦截“文本堆词但图片无关”的页面。我一般不建议上来就做复杂融合模型。先把视觉分作为一个单特征加到现有 GBDT 或线性融合里看验证集 NDCG 是否提升。如果提升不明显先排查视觉特征本身的质量而不是急着换模型结构。2.4 选型判断准确率、延迟和成本三角三类方案的本质差异可以看这张表方案离线计算量在线计算量相关性精度适合位置双塔视觉分高很低中等粗排、召回交叉式视觉分无法离线很高较高精排末端融合模型中中取决于特征质量全链路选择标准其实很朴素如果你的场景是慢查询、高客单价、用户愿意等交叉式值得做如果是一般搜索一秒几千次请求那就老老实实走双塔加分。不要为了一个视觉信号把整体延迟拉高一个数量级线上工程会因为超时把效果全部吃回去。3. Web-Scale 落地图片抽取、向量索引和在线链路3.1 页面图片抽取与清洗是第一道坎很多人把注意力放在模型选型上最后发现真正卡住的是图片根本抽不出来或者抽出来的图片是广告图。做 VLM 相关性第一步不是训练模型而是把页面主图稳定、干净地抽出来。这里有几个常见问题需要处理懒加载很多页面图片不会出现在最开始的 HTML 里要执行到滚动位置才会加载src 属性可能藏在> 用视觉语言模型增强搜索相关性：跨模态对齐与Web-Scale落地实践
搜索相关性测量放在视觉语言模型Vision-Language ModelVLM这个新语境下重新做一遍是目前 Web-Scale Search 方向里一个很容易出效果、但也很容易被低估的切入点。核心问题可以用一句话描述当一个用户 query 和一张网页页面出现在模型面前模型需要判断这段文本和页面里的视觉内容到底是不是在说同一件事以及匹配到什么程度。传统做法只依赖文本字段VLM 把页面里的图像、布局信息也纳入判断适合做搜索排序里的相关性信号也适合做召回后的精排特征。这篇文章适合搜索算法工程师、相关性评测负责人以及想给图文搜索场景增加视觉理解能力的团队看。最值得你关注的不是模型本身而是怎么在 web-scale 的数据量、延迟和成本约束下把 VLM 变成一条稳定可评测的相关性流水线。下面按我对这个方向的理解和实际落地习惯拆开讲。1. 先理解相关性测量在搜索系统里到底卡在哪个环节1.1 文本相关性为什么够用又不完全够用传统搜索相关性测量基本围绕文本展开。query 进来之后系统拿它和标题、摘要、正文、锚文本、类目路径做词项匹配再叠加深度文本模型比如双塔召回、交叉编码精排最后输出一个相关分。这套体系经过很多年验证在纯文本场景里非常稳定。但它有一个天然盲区网页本身是图文混合的。很多页面的核心信息其实藏在图片里文本反而很稀疏或者因为 SEO 写法变得很绕。举个典型例子用户搜“红色轻便跑步鞋适合女生”一个商品页的标题写的是“Women’s Lightweight Knit Sneakers”正文里大量出现运动和折扣词但首图就是一双红色跑鞋。纯文本模型只能靠那点英文词和 query 碰出弱相关可人眼一看页面就知道强相关。反过来还有一种情况页面文本堆满了关键词图片却是无关的横幅广告图。这时候文本模型会给高分但用户点进去体验很差。所以文本相关性不是不够用而是单独使用时对图文混合页面的判别上限有限。VLM 要做的事情就是把这部分缺失的视觉信号补回来。1.2 VLM 能补上的不是“看图说话”而是“跨模态对齐”这里要先纠正一个常见误解。把 VLM 用在相关性测量里不是让它输出一段图片描述再把描述拿去做文本匹配。那是“图像转文本”的间接路径信息经过两次压缩误差会累积。更常见的做法是直接做跨模态对齐。一种思路是用对比式双塔结构把 query 文本编码成一个向量把页面图片编码成另一个向量让两者在同一个语义空间里能算相似度。典型代表就是 CLIP 这类模型。另一种思路是交叉式结构把 query 文本和图片的 patch 一起喂给同一个 Transformer让模型端到端输出一个相关分。这两种思路各有适用位置后面会展开。之所以说 VLM 补的是“对齐”而不是“理解”是因为搜索相关性本质上不是让模型看懂图片内容而是让模型判断“用户说的东西”和“页面展示的东西”是否匹配。这种匹配能力恰好是预训练 VLM 在大量图文对上学到的核心技能。1.3 哪些场景优先上哪些场景先缓一缓不是所有搜索都需要视觉相关性。按我的判断最有价值的是这几类电商搜索query 常常带颜色、风格、材质、场景等视觉属性。图文攻略和测评站文章配图承载大量真实信息。新闻搜索结果图片对新闻事件相关性有明显提示作用。UGC 内容用户发布的内容往往文字少、图片多。视频封面和短内容场景封面图决定了用户在不在意的第一印象。优先级低的是纯文本页面比如技术文档、论文、代码问答。这些页面即使有图图也是示意图视觉信号对相关性的增量非常有限。另一个低优先级场景是 query 本身没有视觉意图比如人名、产品型号、学术术语。如果用户搜“BERT 论文”配图是什么根本不影响相关性判断这时候上 VLM 就是纯增加成本和计算延迟。2. 技术路线双塔、交叉和融合怎么选2.1 双塔式图片向量离线算好线上只跑 query双塔式是落地成本最低的一条路。文本侧一个塔图像侧一个塔训练时让匹配的图文对在向量空间里靠近不匹配的拉远。线上使用时query 编码成 query embedding页面图片编码成 image embedding两者算余弦相似度或者点积。它的最大优点是图片 embedding 可以离线算。web-scale 场景里页面图片动辄几十亿张但绝大多数是静态的不需要实时更新。每天增量跑一批新图把向量写进向量库线上查询时只需要实时计算 query embedding然后到向量库里做 ANN 检索。这条链路的在线算力消耗非常低一个 query 一次文本编码就够了。缺点是双塔各自压缩信息细粒度匹配能力有限。两个塔交互不足遇到“红色但不适合女生”“轻便但不要那种网面”这种带条件限定的 query双塔往往区分不出来。所以在我的项目里双塔视觉分更适合放在粗排阶段或者作为一个召回通道不适合直接当精排绝对依据。2.2 交叉式把 query 和图片拼在一起打分交叉式结构不分离编码而是把 query 文本 token 和图片视觉 token 拼在一起喂给同一个 Transformer模型输出一个相关分数。因为模型能看到 query 和图片之间的细粒度交互所以准确率通常比双塔高尤其是条件限定多、语义细节多的 query。代价也很明确图片没法离线计算。每次 query 进来系统要对每一个候选页面都跑一遍完整模型在线算力需求是候选数量的倍数。web-scale 场景很难在精排阶段对全量候选跑交叉式 VLM一般只对点选后的前几十条跑或者离线预计算一部分热门 query 的结果缓存。所以我的建议是交叉式 VLM 放在精排末端做“守门员”用它的分数纠正文本双塔和视觉双塔都给出中高分但实际不匹配的样本。如果线上延迟预算很紧就先不要碰交叉式先把双塔的视觉特征落地。2.3 和现有排序特征怎么融合VLM 视觉分不是一个孤立的新排序方式而是要作为特征进入到现有的相关性融合框架里。常见的融合方式有三种加权求和final_score alpha * text_score beta * vision_scorealpha 和 beta 在验证集上调。分档修正先按文本相关性归入档位再在档位内用视觉分微调。规则兜底当视觉分极低且文本分中等时直接降档用来拦截“文本堆词但图片无关”的页面。我一般不建议上来就做复杂融合模型。先把视觉分作为一个单特征加到现有 GBDT 或线性融合里看验证集 NDCG 是否提升。如果提升不明显先排查视觉特征本身的质量而不是急着换模型结构。2.4 选型判断准确率、延迟和成本三角三类方案的本质差异可以看这张表方案离线计算量在线计算量相关性精度适合位置双塔视觉分高很低中等粗排、召回交叉式视觉分无法离线很高较高精排末端融合模型中中取决于特征质量全链路选择标准其实很朴素如果你的场景是慢查询、高客单价、用户愿意等交叉式值得做如果是一般搜索一秒几千次请求那就老老实实走双塔加分。不要为了一个视觉信号把整体延迟拉高一个数量级线上工程会因为超时把效果全部吃回去。3. Web-Scale 落地图片抽取、向量索引和在线链路3.1 页面图片抽取与清洗是第一道坎很多人把注意力放在模型选型上最后发现真正卡住的是图片根本抽不出来或者抽出来的图片是广告图。做 VLM 相关性第一步不是训练模型而是把页面主图稳定、干净地抽出来。这里有几个常见问题需要处理懒加载很多页面图片不会出现在最开始的 HTML 里要执行到滚动位置才会加载src 属性可能藏在>