搜索团队在迭代相关性时最容易踩的坑是离线指标涨了线上体验却没变好字面完全匹配的文档排到了前面用户却点都不点双塔向量召回把“语义相近”的图文捞回来精排又不知道该拿图像信息怎么办。这些问题背后其实是同一个矛盾——当前搜索相关性度量体系仍然默认“相关性”主要靠文本表达而 Web 级搜索里越来越多的内容本质上是图文混合体。Advancing Relevance Measurement with Vision-Language Models for Web-Scale Search这个题目指向的正是下一步用视觉语言模型VLM把相关性判断从“文本语义匹配”推进到“多模态联合理解”。这篇文章不会只停留在论文概念解读而是围绕技术原理、评测集构建、离在线流程、代码实现和工程上线五个层面展开。读完你会得到一条可落地的路线也会知道哪些场景适合上 VLM哪些场景现在上 VLM 反而是浪费。1. 为什么 Web-Scale 搜索的相关性度量越来越难做相关性度量本质上是判断“用户的一个 query 和候选文档Document是否匹配、匹配到什么程度”。在 Web-Scale 场景下这个问题的难度被三个因素放大第一是内容形态碎片化。一条结果可能是纯文本页面可能是一个商品主图加详情页可能是一段视频的封面图和标题也可能是社交媒体里的一张梗图。传统文本相关性工具只能“看到”文本当文本信息和视觉信息不一致、互补甚至矛盾时判断就会出现偏差。第二是用户意图表达高度模糊。用户搜“春天穿什么”他可能想要穿搭图文、商品链接、短视频教程也可能想要一张街拍图。这些结果的文本字段可能差别很大但视觉内容才是用户判断“是否相关”的第一信号。没有视觉理解能力的模型很难建立这种匹配关系。第三是相关性评估本身的主观性和长尾性。一个 query 对应的相关文档可能有成千上万条标注人员往往只能看到一部分标注口径也很难统一加上 Web 内容更新快静态评估集很快会失真。传统技术栈里相关性判断通常是三层结构。第一层是词法匹配代表是 BM25速度快、可解释但解决不了同义改写和语义匹配。第二层是语义向量匹配代表是双塔模型把 query 和 doc 分别编码成向量用余弦相似度计算相关性能解决“语义相近但字面不同”的问题但双塔模型对细粒度交互不敏感而且在图文混合场景下doc 向量如果只用文本编码图像信息就完全丢失。第三层是交互式精排比如基于 Transformer 的文本交叉编码器这类模型精度更高却仍然只能处理文本输入。这套体系最大的盲区是它假设“文档相关性”可以仅从文本中推断出来。一旦页面里的核心信息藏在图片、视频帧、截图中相关性判断就会退化成猜测。这也就是 VLM 进入相关性度量领域的核心逻辑它让系统第一次可以把“看到了什么”纳入相关性计算。接下来我们从原理上拆解它是怎么做到的。2. 视觉语言模型的核心原理与相关概念视觉语言模型简单说就是能同时理解图像和文本并能建立两者联系的模型。它并不是把 OCR 文本拼到文档里那么简单而是直接在视觉和语言两个模态之间学习对齐关系。从技术演进上看VLM 大致有三个阶段。早期是类似 CLIP 的对比学习范式用海量图文对训练把图像编码器和文本编码器映射到同一个向量空间后来发展为类似 BLIP、Flamingo 的生成式范式模型不仅能算相似度还能根据图像和文本生成描述或回答问题再到现在的统一多模态大模型能够在超大参数量下做复杂的视觉推理。在相关性度量这个任务里VLM 提供的能力可以拆成四层图文匹配给定 query 和图片判断它们在语义上是否匹配。视觉要素抽取从图片中识别商品、场景、动作、文字、风格等关键信号。多模态推理结合图片中的视觉信息和文本信息判断是否满足用户的多重条件。相关性打分输出一个连续分数供排序使用。这里要澄清一个常见误解图文检索不等于相关性度量。图文检索解决的是“给你一个 query从库里召回相关图片”相关性度量要解决的是“给你 query 和一批候选文档判断哪些更相关、哪些不相关”前者关注召回后者关注精排和评估。VLM 在这两种任务中都能用但方法不同。这也是很多团队上线 VLM 后效果不佳的原因——把相关性度量直接当成向量检索任务来做只取相似度忽视了相关性判断中的条件约束和语义细粒度。另一个容易混淆的概念是“相关性”的多层定义。我们可以把相关性拆成四个层级层级含义传统模型能否解决VLM 的优势字面相关性query 关键词是否出现在文档中能BM25 就够了能但不是重点语义相关性文本层面是否表达同一意思双塔/交叉编码器可以能但文本模型可能更划算意图相关性文档是否满足 query 背后的真实需求通常较弱能结合视觉内容判断多模态相关性图像、视频、排版、截图等视觉信息是否参与匹配基本不能强项从这层对比可以看出VLM 的价值并不在于替换掉所有旧模型而在于解决传统模型“看不见图像”的结构性缺陷。理解了这一点才能设计出合理的落地路径。3. VLM 相关性度量的适用场景与边界不是所有搜索场景都需要立刻上 VLM。从工程经济性出发下面这几类场景是最优先的候选。第一类是商品搜索。用户搜索“白色连衣裙 收腰”商品主图的颜色、版型、风格是决定是否购买的核心因素。文本字段可能包含“白色”“连衣裙”但“收腰”的视觉表现只能靠 VLM 判断。传统文本模型无法回答“这张图到底是不是收腰”的问题。第二类是内容社区和短视频搜索。搜索结果往往是一张封面图加一个标题相关性判断高度依赖封面视觉信息和标题语义的配合。一个标题为“教你做红烧肉”的视频如果封面是一盘成品红烧肉文本和视觉是强相关的如果封面是一张风景图文本与视觉矛盾传统模型很难识别这种错位。第三类是广告素材和 UGC 内容审核。广告主上传的图片、链接、标题是否与落地页内容一致截图信息是否与宣传文案匹配这类问题本质上就是多模态相关性判断。VLM 可以用于审核、灰度和风控环节。第四类是 Web 页面预览和富摘要。搜索结果页需要从页面中抽取图片、生成摘要、判断图片是否能代表页面主题。VLM 可以帮助选择更符合 query 意图的展示图提升点击率。但 VLM 也有明确的适用边界。如果你的搜索对象是长文本、论文、代码文档、法律条文视觉信息占比很低用纯文本交叉编码器通常更划算如果业务要求首轮阶段在几十毫秒内返回结果VLM 也不适合直接放在召回层更适合放到候选集已经缩小后的精排或重排阶段如果团队没有 GPU 推理资源和数据标注能力直接上大规模 VLM 会带来严重的成本压力需要更谨慎。所以更稳妥的判断是VLM 相关性度量不是万能的银弹而是对现有文本相关性体系的一个重要补层。它解决的是“文本模型看不见图”的问题而不是“相关性度量从此一步到位”的问题。4. 相关性度量总体方案设计把 VLM 引入 web-scale 搜索的相关性度量不能只做一个模型接口而是要设计一套从评测到排序的闭环方案。推荐用下面这个四层架构思路来组织先建“评估层”。人工标注一批多模态相关性样本区分相关、部分相关、不相关。这批样本是判断模型好坏的标准也是后续迭代的数据基础。再做“基线层”。保留原有文本相关性模型的结果作为对比基线例如文本双塔或者文本精排模型。这能让你知道 VLM 带来的增量到底有多少。然后是“VLM 重排层”。在候选集到达一定规模后用 VLM 做二次打分。打分结果可以与文本相关性分数做融合也可以在特定场景直接替换文本精排。最后是“监控与回流层”。把线上 bad case 回流到评估集持续扩充困难样本再进入下一轮模型迭代。这套架构设计的核心是把“离线的相关性评估”和“在线的相关性排序”统一到同一个 VLM 打分能力上。这样做的最大好处是离线指标涨了在线效果大概率也会涨因为两者用的是同一套理解能力而不是各玩各的。在工程实现上有几个关键设计点需要想清楚。一是候选集规模控制。VLM 推理成本远高于文本模型所以不建议对全量候选打分。一个可落地的策略是先用 BM25 或文本向量召回 100 到 200 条候选再用文本模型快速粗排留下 20 到 50 条最后对这部分跑 VLM。这样既保证了效果又把计算成本控制在一个可接受范围内。二是分数校准。VLM 输出的相关分数分布往往不稳定尤其在不同类型 query 之间可能存在明显偏差。上线前需要做分数校准让不同领域的分数可比否则会出现某些领域的相关结果被系统性压低的情况。三是多信号融合。不要把 VLM 分数当作唯一排序信号。更推荐的做法是把 VLM 相关分数和文本相关分数、点击反馈特征、时效性特征一起输入到一个融合模型里做最终排序。这样既利用了多模态理解能力又保留了传统排序特征的稳定性。5. 数据准备与评测集构建现在进入实操阶段。先说数据因为数据质量直接决定 VLM 相关性度量的上限。评测集数据一般来自三个渠道搜索日志抽样、人工标注、线上 bad case 回流。最理想的是三者结合。从搜索日志中抽取真实 query 和曝光文档能让评估集贴近线上分布人工标注提供 ground truthbad case 回流帮助模型发现盲区。在构建相关性评测集时建议每条样本包含以下字段{ query_id: q_000123, query: 白色收腰连衣裙 夏季, doc_id: d_004567, doc_url: https://example.com/item/004567, doc_title: 夏季新款白色系带连衣裙, doc_image: https://example.com/img/004567.jpg, doc_text: 收腰设计显瘦版型适合日常通勤, label: 2 }label 可以使用三分类2 表示相关1 表示部分相关或弱相关0 表示不相关。这里需要特别注意“部分相关”的口径定义。建议只在出现“query 的某些条件被满足、某些条件明显不满足”时才给 1否则很容易出现标注人员全给 2、模型评价失去区分度的情况。数据构建过程中最容易犯的错误有两个。第一个错误是评测集太简单。如果抽样方式是随机曝光样本那么大量不相关样本会稀释评估集难度造成“模型什么都好”的假象。更好的做法是分层抽样并在评测集中刻意加入很多“看起来相关但实际不相关”的困难样本比如标题包含关键词但图片完全无关的样本。这类样本正是 VLM 相对文本模型最有优势的地方不加入困难样本VLM 的价值就无法体现。第二个错误是数据泄漏。如果评测集里的 query 或文档和训练语料高度重叠模型指标会虚高。尤其是从线上日志抽取数据时要注意训练集时间窗口和评估集时间窗口的切分避免用“已知答案”做评估。Web-Scale 场景推荐按时间切分比如用前 90 天的数据训练后 7 天作为验证。标注环节建议配合双人标注加仲裁机制。可以让标注人员面对“query 文本 文档标题 文档图片 文档正文片段”四要素打分这样能最接近真实用户看到的搜索结果形态。标注完成后至少计算一次标注一致率Kappa 值低于 0.6 的样本需要回到规则讨论阶段。6. 核心代码实现VLM 相关度打分流程完成数据集构建后我们用一个最小示例跑通 VLM 相关度打分流程。下面以常见的开源视觉语言模型和 transformers 接口为例模型路径请按实际项目替换。6.1 环境准备建议使用 Python 3.9 以上版本安装以下依赖pip install torch transformers accelerate pillow faiss-cpu其中 torch 和 transformers 为核心推理依赖pillow 负责图像读取faiss 用于示例中的向量检索环节。生产环境建议使用 GPU 推理并优先使用 ONNX Runtime 或 TensorRT 加速。6.2 加载模型并实现单条相关度打分# 文件路径src/vlm_relevance_scorer.py from transformers import AutoModel, AutoProcessor import torch MODEL_PATH your-vlm-model-path # 替换为实际模型路径或模型名 class VLMRelevanceScorer: def __init__(self, model_pathMODEL_PATH, devicecuda): self.device device self.processor AutoProcessor.from_pretrained(model_path) self.model AutoModel.from_pretrained(model_path).to(device) self.model.eval() def score(self, query_text: str, image_path: str) - float: image self.processor.image_loader(image_path) inputs self.processor(textquery_text, imagesimage, return_tensorspt, paddingTrue).to(self.device) with torch.no_grad(): outputs self.model(**inputs) # 这里的分数计算方式由实际模型决定 # 对比学习模型通常取 text_embeds 与 image_embeds 的余弦相似度 logits outputs.logits_per_image score torch.sigmoid(logits).item() return score if __name__ __main__: scorer VLMRelevanceScorer() s scorer.score(白色收腰连衣裙 夏季, test_item.jpg) print(frelevance score: {s:.4f})这段代码的注释说明了关键点不同 VLM 的输出字段不一致logits_per_image是常见对比学习模型的输出如果你的模型是生成式 VLM可能需要用 prompt 让模型输出分数或用生成 token 概率计算。所以实际项目里第一件事是确定模型输出层结构。6.3 使用 Prompt 模板做生成式相关度判断如果使用生成式多模态大模型更通用的做法是用 prompt 引导模型输出判断结果。# 文件路径src/prompt_relevance.py prompt_template 你是一个搜索相关性评测专家。 请判断用户搜索词和图片及文本描述之间的相关性只输出一个数字 2 表示相关1 表示部分相关0 表示不相关。 用户搜索词{query} 图片内容请结合图片进行判断。 文档标题{doc_title} 文档摘要{doc_summary} 输出 def build_prompt(query: str, doc_title: str, doc_summary: str) - str: return prompt_template.format( queryquery, doc_titledoc_title, doc_summarydoc_summary )这种方式的优点是判断过程可解释能知道模型为什么给这个分数缺点是推理延迟更高、成本更大。实际工程中生成式 VLM 更适合做离线评测集的打分和 bad case 分析在线重排阶段一般优先使用判别式或对比式的轻量 VLM。6.4 在线重排VLM 对候选集二次排序在候选集小规模重排时可以用 VLM 分数对文本召回结果进行重排。# 文件路径src/rerank_with_vlm.py from vlm_relevance_scorer import VLMRelevanceScorer scorer VLMRelevanceScorer() def rerank_candidates(query: str, candidates: list, top_k: int 20): scored [] for cand in candidates: # cand 是 dict包含 doc_id、image_path、title 等字段 score scorer.score(query, cand[image_path]) # 可以结合文本分数做加权融合 final_score 0.7 * score 0.3 * cand.get(text_score, 0.0) scored.append((cand[doc_id], final_score)) scored.sort(keylambda x: x[1], reverseTrue) return scored[:top_k]这里做了一个简单加权融合。实际项目中权重不能拍脑袋设需要用验证集做参数搜索避免 VLM 分数和文本分数量纲差异过大导致排序失效。6.5 离线评估脚本计算 NDCG有了打分结果后要立刻用离线指标检验。相关性评测最常见的指标是 NDCGK。# 文件路径src/evaluate_ndcg.py import math def dcg_at_k(labels, k): dcg 0.0 for i in range(min(k, len(labels))): dcg (2 ** labels[i] - 1) / math.log2(i 2) return dcg def ndcg_at_k(labels, predicted_order, k10): labels [labels[i] for i in predicted_order[:k]] ideal sorted([labels[i] for i in range(len(labels))], reverseTrue) dcg dcg_at_k(labels, k) idcg dcg_at_k(ideal, k) return dcg / idcg if idcg 0 else 0.0 # labels 是每个 doc 的人工标注predicted_order 是模型排序后的文档索引 labels [2, 1, 0, 2, 1] predicted_order [0, 1, 2, 3, 4] print(fNDCG5: {ndcg_at_k(labels, predicted_order, 5):.4f})这套代码只展示了评测最核心的部分。线上评估时还需要把多个 query 的 NDCG 做平均并根据 query 类型做分层分析比如图片类 query、文本类 query、歧义 query 分别计算。只看整体平均指标往往会掩盖模型在某个细分场景上的退步。7. 运行验证与效果评估完成代码实现后第一步不是直接跑全量评测集而是先做小样本人工目检。跑 20 到 30 个 query把 VLM 每个分数的排序结果打印出来由人快速判断“这个排序是否符合直觉”。这一步能发现很多隐藏问题比如图片加载失败、模型对中文适配差、prompt 描述和实际输入不一致。如果小样本目检通过再跑全量评测集。重点关注以下三类指标第一类是排序质量指标。NDCG10、MAP、MRR 是衡量排序整体质量的基础指标。VLM 相对文本模型提升多少通常看这些指标的变化。第二类是分类质量指标。如果评测集是二分类或三分类可以计算 Accuracy、Precision、Recall也可以分“相关/不相关”两个方向分别计算。重点要关注不相关内容的拦截率也就是“把不相关结果排到后面”的能力这往往比提升相关结果排到前面更难。第三类是人工一致性指标。抽取 200 到 300 条 VLM 打分结果与人工标注做一致性对比计算 Cohens Kappa。如果 Kappa 低于 0.6说明模型判分标准还不够稳定需要检查数据标注口径或 prompt 设计。运行失败时的排查顺序也很固定先看依赖和模型是否能正常加载再看图像路径是否能读取再看模型输入尺寸和处理器是否正确最后看输出字段是否匹配。多模态任务出现“模型能跑、结果全 0.5”的情况通常不是代码问题而是输入没有正确喂入图像或者处理器把图像缩得太小导致信息丢失。8. 常见问题与排查思路下面这张表来自多模态相关性项目中的常见经验按影响程度排序。问题现象可能原因排查方式解决方案模型全部输出 0.5 左右图像没有正确输入模型只看到空图或默认图打印输入图像尺寸抽样保存预处理后图像修正图像读取逻辑增加加载失败日志对中文 query 的效果明显偏差模型训练语料中文图文对不足在细分中文评测集上单独计算指标增加中文图文数据微调或选择中文能力更强的模型底座离线 NDCG 提升线上 CTR 下降评估集和线上分布不一致或分数未做校准对比线上 query 与评估集 query 的主题分布从线上日志重新抽样构建评估集并做分数校准VLM 分数梯度不明显输入图像分辨率过低或图文信息被截断检查图像预处理和文本截断长度提升输入分辨率增加图像切片编码GPU 推理延迟过高全量候选都过 VLM缺乏级联过滤分析各环节耗时占比引入轻量过滤限制 VLM 只处理前 50 条候选长尾 query 相关分波动大长尾 query 在训练数据中占比少按 query 频次分层分析指标针对长尾 query 定向补充数据并微调模型把“含关键词但图不符”判为相关文本信号权重过高视觉信号被忽视单看纯图像输入时的得分调整多模态融合权重增加图文矛盾样本训练其中“图文矛盾样本”是 VLM 相关性项目中最容易忽视的部分。很多团队直接用图文匹配数据集微调数据集里文本和图像通常是一致的但在真实搜索里标题包含关键词但封面图无关的情况非常常见。这类样本需要在评测集和训练集中刻意加入否则模型永远学不会“图不对文”应该如何判分。9. 最佳实践与工程上线建议上线 VLM 相关性度量不能只是替换一个模型接口。以下几个工程原则项目越早遵循后续返工越少。第一用小成本评估集先验证增量。不要一上来就构建百万级数据集。先标 1000 到 2000 条困难样本跑通 VLM 打分、评估、bad case 分析整个流程确认效果增量大于成本再扩大投入。相关性工作的投入产出比几乎完全取决于评估集是否精准。第二采用级联架构而不是全量替换。文本模型负责粗召回和快速过滤VLM 负责困难候选的精排。体验上用户感知到的是排在前面的结果更准了成本上只对少量候选跑 VLM整体算力可控。第三为 VLM 相关分数建立监控体系。重点监控分数的整体分布、不同类型 query 下的分位值、图文加载失败率、超时率。分数分布突然变宽或变窄往往意味着图片源质量变化或模型输入格式被改动。相关分数不能上线后就不管它和点击率一样需要日常监控。第四做分场景灰度上线。不要一次性全量切换排序策略。可以按 query 类型或者按流量比例灰度比如先在“商品类 query”上开放 10% 流量观察 CTR、长点击、无点击率等指标再逐步扩大。灰度期间要保留旧排序输出的备份方便快速回滚。第五考虑模型蒸馏。VLM 推理成本高不适合所有流量都跑。实践中可以先用 VLM 在大量样本上打分再把打分结果作为监督信号蒸馏到一个轻量级图文模型。这样线上用轻量模型仍能保留大部分 VLM 的相关性理解能力。第六注意图片资源和隐私合规。搜索系统涉及的图片来自第三方网页或用户上传上线前要确认图片抓取、存储、传输的合规性。尤其是涉及用户头像、UGC 图片、广告素材时要谨慎处理避免把敏感图片送入外部模型服务。自建模型部署时也要做好访问控制和日志脱敏。10. 总结与后续学习方向本文围绕“Advancing Relevance Measurement with Vision-Language Models for Web-Scale Search”展开核心观点是VLM 不会替代整套文本相关性体系而是补上传统模型在视觉理解上的结构性缺口。落地路径从评测集构建开始经历小样本目检、离线指标验证、级联架构上线、监控回流每一步都有明确的可执行动作。如果你所在的团队正计划尝试 VLM 相关性度量更稳妥的第一步不是直接买 GPU 集群或训练大模型而是先构建一份包含 1000 到 2000 条困难样本的小型多模态评测集找一个人工标注团队把相关性口径对齐然后用现有开源 VLM 在这份评测集上跑出分数看看相对于文本模型的增量到底有多大。这一步结果会直接告诉你这个方向在当前业务里值不值得继续投入。后续可以继续探索的方向包括多图对比与视频帧级别的相关性判断、VLM 打分结果蒸馏到轻量线上模型、VLM 与 LLM 联合做复杂意图相关性推理以及如何让评测集随线上内容变化保持持续更新。多模态相关性度量这个方向才刚刚开始离成熟标准还有不小距离也正因为如此早期投入的团队更容易建立真正的技术壁垒。 视觉语言模型如何重构搜索相关性度量：从文本匹配到多模态理解
搜索团队在迭代相关性时最容易踩的坑是离线指标涨了线上体验却没变好字面完全匹配的文档排到了前面用户却点都不点双塔向量召回把“语义相近”的图文捞回来精排又不知道该拿图像信息怎么办。这些问题背后其实是同一个矛盾——当前搜索相关性度量体系仍然默认“相关性”主要靠文本表达而 Web 级搜索里越来越多的内容本质上是图文混合体。Advancing Relevance Measurement with Vision-Language Models for Web-Scale Search这个题目指向的正是下一步用视觉语言模型VLM把相关性判断从“文本语义匹配”推进到“多模态联合理解”。这篇文章不会只停留在论文概念解读而是围绕技术原理、评测集构建、离在线流程、代码实现和工程上线五个层面展开。读完你会得到一条可落地的路线也会知道哪些场景适合上 VLM哪些场景现在上 VLM 反而是浪费。1. 为什么 Web-Scale 搜索的相关性度量越来越难做相关性度量本质上是判断“用户的一个 query 和候选文档Document是否匹配、匹配到什么程度”。在 Web-Scale 场景下这个问题的难度被三个因素放大第一是内容形态碎片化。一条结果可能是纯文本页面可能是一个商品主图加详情页可能是一段视频的封面图和标题也可能是社交媒体里的一张梗图。传统文本相关性工具只能“看到”文本当文本信息和视觉信息不一致、互补甚至矛盾时判断就会出现偏差。第二是用户意图表达高度模糊。用户搜“春天穿什么”他可能想要穿搭图文、商品链接、短视频教程也可能想要一张街拍图。这些结果的文本字段可能差别很大但视觉内容才是用户判断“是否相关”的第一信号。没有视觉理解能力的模型很难建立这种匹配关系。第三是相关性评估本身的主观性和长尾性。一个 query 对应的相关文档可能有成千上万条标注人员往往只能看到一部分标注口径也很难统一加上 Web 内容更新快静态评估集很快会失真。传统技术栈里相关性判断通常是三层结构。第一层是词法匹配代表是 BM25速度快、可解释但解决不了同义改写和语义匹配。第二层是语义向量匹配代表是双塔模型把 query 和 doc 分别编码成向量用余弦相似度计算相关性能解决“语义相近但字面不同”的问题但双塔模型对细粒度交互不敏感而且在图文混合场景下doc 向量如果只用文本编码图像信息就完全丢失。第三层是交互式精排比如基于 Transformer 的文本交叉编码器这类模型精度更高却仍然只能处理文本输入。这套体系最大的盲区是它假设“文档相关性”可以仅从文本中推断出来。一旦页面里的核心信息藏在图片、视频帧、截图中相关性判断就会退化成猜测。这也就是 VLM 进入相关性度量领域的核心逻辑它让系统第一次可以把“看到了什么”纳入相关性计算。接下来我们从原理上拆解它是怎么做到的。2. 视觉语言模型的核心原理与相关概念视觉语言模型简单说就是能同时理解图像和文本并能建立两者联系的模型。它并不是把 OCR 文本拼到文档里那么简单而是直接在视觉和语言两个模态之间学习对齐关系。从技术演进上看VLM 大致有三个阶段。早期是类似 CLIP 的对比学习范式用海量图文对训练把图像编码器和文本编码器映射到同一个向量空间后来发展为类似 BLIP、Flamingo 的生成式范式模型不仅能算相似度还能根据图像和文本生成描述或回答问题再到现在的统一多模态大模型能够在超大参数量下做复杂的视觉推理。在相关性度量这个任务里VLM 提供的能力可以拆成四层图文匹配给定 query 和图片判断它们在语义上是否匹配。视觉要素抽取从图片中识别商品、场景、动作、文字、风格等关键信号。多模态推理结合图片中的视觉信息和文本信息判断是否满足用户的多重条件。相关性打分输出一个连续分数供排序使用。这里要澄清一个常见误解图文检索不等于相关性度量。图文检索解决的是“给你一个 query从库里召回相关图片”相关性度量要解决的是“给你 query 和一批候选文档判断哪些更相关、哪些不相关”前者关注召回后者关注精排和评估。VLM 在这两种任务中都能用但方法不同。这也是很多团队上线 VLM 后效果不佳的原因——把相关性度量直接当成向量检索任务来做只取相似度忽视了相关性判断中的条件约束和语义细粒度。另一个容易混淆的概念是“相关性”的多层定义。我们可以把相关性拆成四个层级层级含义传统模型能否解决VLM 的优势字面相关性query 关键词是否出现在文档中能BM25 就够了能但不是重点语义相关性文本层面是否表达同一意思双塔/交叉编码器可以能但文本模型可能更划算意图相关性文档是否满足 query 背后的真实需求通常较弱能结合视觉内容判断多模态相关性图像、视频、排版、截图等视觉信息是否参与匹配基本不能强项从这层对比可以看出VLM 的价值并不在于替换掉所有旧模型而在于解决传统模型“看不见图像”的结构性缺陷。理解了这一点才能设计出合理的落地路径。3. VLM 相关性度量的适用场景与边界不是所有搜索场景都需要立刻上 VLM。从工程经济性出发下面这几类场景是最优先的候选。第一类是商品搜索。用户搜索“白色连衣裙 收腰”商品主图的颜色、版型、风格是决定是否购买的核心因素。文本字段可能包含“白色”“连衣裙”但“收腰”的视觉表现只能靠 VLM 判断。传统文本模型无法回答“这张图到底是不是收腰”的问题。第二类是内容社区和短视频搜索。搜索结果往往是一张封面图加一个标题相关性判断高度依赖封面视觉信息和标题语义的配合。一个标题为“教你做红烧肉”的视频如果封面是一盘成品红烧肉文本和视觉是强相关的如果封面是一张风景图文本与视觉矛盾传统模型很难识别这种错位。第三类是广告素材和 UGC 内容审核。广告主上传的图片、链接、标题是否与落地页内容一致截图信息是否与宣传文案匹配这类问题本质上就是多模态相关性判断。VLM 可以用于审核、灰度和风控环节。第四类是 Web 页面预览和富摘要。搜索结果页需要从页面中抽取图片、生成摘要、判断图片是否能代表页面主题。VLM 可以帮助选择更符合 query 意图的展示图提升点击率。但 VLM 也有明确的适用边界。如果你的搜索对象是长文本、论文、代码文档、法律条文视觉信息占比很低用纯文本交叉编码器通常更划算如果业务要求首轮阶段在几十毫秒内返回结果VLM 也不适合直接放在召回层更适合放到候选集已经缩小后的精排或重排阶段如果团队没有 GPU 推理资源和数据标注能力直接上大规模 VLM 会带来严重的成本压力需要更谨慎。所以更稳妥的判断是VLM 相关性度量不是万能的银弹而是对现有文本相关性体系的一个重要补层。它解决的是“文本模型看不见图”的问题而不是“相关性度量从此一步到位”的问题。4. 相关性度量总体方案设计把 VLM 引入 web-scale 搜索的相关性度量不能只做一个模型接口而是要设计一套从评测到排序的闭环方案。推荐用下面这个四层架构思路来组织先建“评估层”。人工标注一批多模态相关性样本区分相关、部分相关、不相关。这批样本是判断模型好坏的标准也是后续迭代的数据基础。再做“基线层”。保留原有文本相关性模型的结果作为对比基线例如文本双塔或者文本精排模型。这能让你知道 VLM 带来的增量到底有多少。然后是“VLM 重排层”。在候选集到达一定规模后用 VLM 做二次打分。打分结果可以与文本相关性分数做融合也可以在特定场景直接替换文本精排。最后是“监控与回流层”。把线上 bad case 回流到评估集持续扩充困难样本再进入下一轮模型迭代。这套架构设计的核心是把“离线的相关性评估”和“在线的相关性排序”统一到同一个 VLM 打分能力上。这样做的最大好处是离线指标涨了在线效果大概率也会涨因为两者用的是同一套理解能力而不是各玩各的。在工程实现上有几个关键设计点需要想清楚。一是候选集规模控制。VLM 推理成本远高于文本模型所以不建议对全量候选打分。一个可落地的策略是先用 BM25 或文本向量召回 100 到 200 条候选再用文本模型快速粗排留下 20 到 50 条最后对这部分跑 VLM。这样既保证了效果又把计算成本控制在一个可接受范围内。二是分数校准。VLM 输出的相关分数分布往往不稳定尤其在不同类型 query 之间可能存在明显偏差。上线前需要做分数校准让不同领域的分数可比否则会出现某些领域的相关结果被系统性压低的情况。三是多信号融合。不要把 VLM 分数当作唯一排序信号。更推荐的做法是把 VLM 相关分数和文本相关分数、点击反馈特征、时效性特征一起输入到一个融合模型里做最终排序。这样既利用了多模态理解能力又保留了传统排序特征的稳定性。5. 数据准备与评测集构建现在进入实操阶段。先说数据因为数据质量直接决定 VLM 相关性度量的上限。评测集数据一般来自三个渠道搜索日志抽样、人工标注、线上 bad case 回流。最理想的是三者结合。从搜索日志中抽取真实 query 和曝光文档能让评估集贴近线上分布人工标注提供 ground truthbad case 回流帮助模型发现盲区。在构建相关性评测集时建议每条样本包含以下字段{ query_id: q_000123, query: 白色收腰连衣裙 夏季, doc_id: d_004567, doc_url: https://example.com/item/004567, doc_title: 夏季新款白色系带连衣裙, doc_image: https://example.com/img/004567.jpg, doc_text: 收腰设计显瘦版型适合日常通勤, label: 2 }label 可以使用三分类2 表示相关1 表示部分相关或弱相关0 表示不相关。这里需要特别注意“部分相关”的口径定义。建议只在出现“query 的某些条件被满足、某些条件明显不满足”时才给 1否则很容易出现标注人员全给 2、模型评价失去区分度的情况。数据构建过程中最容易犯的错误有两个。第一个错误是评测集太简单。如果抽样方式是随机曝光样本那么大量不相关样本会稀释评估集难度造成“模型什么都好”的假象。更好的做法是分层抽样并在评测集中刻意加入很多“看起来相关但实际不相关”的困难样本比如标题包含关键词但图片完全无关的样本。这类样本正是 VLM 相对文本模型最有优势的地方不加入困难样本VLM 的价值就无法体现。第二个错误是数据泄漏。如果评测集里的 query 或文档和训练语料高度重叠模型指标会虚高。尤其是从线上日志抽取数据时要注意训练集时间窗口和评估集时间窗口的切分避免用“已知答案”做评估。Web-Scale 场景推荐按时间切分比如用前 90 天的数据训练后 7 天作为验证。标注环节建议配合双人标注加仲裁机制。可以让标注人员面对“query 文本 文档标题 文档图片 文档正文片段”四要素打分这样能最接近真实用户看到的搜索结果形态。标注完成后至少计算一次标注一致率Kappa 值低于 0.6 的样本需要回到规则讨论阶段。6. 核心代码实现VLM 相关度打分流程完成数据集构建后我们用一个最小示例跑通 VLM 相关度打分流程。下面以常见的开源视觉语言模型和 transformers 接口为例模型路径请按实际项目替换。6.1 环境准备建议使用 Python 3.9 以上版本安装以下依赖pip install torch transformers accelerate pillow faiss-cpu其中 torch 和 transformers 为核心推理依赖pillow 负责图像读取faiss 用于示例中的向量检索环节。生产环境建议使用 GPU 推理并优先使用 ONNX Runtime 或 TensorRT 加速。6.2 加载模型并实现单条相关度打分# 文件路径src/vlm_relevance_scorer.py from transformers import AutoModel, AutoProcessor import torch MODEL_PATH your-vlm-model-path # 替换为实际模型路径或模型名 class VLMRelevanceScorer: def __init__(self, model_pathMODEL_PATH, devicecuda): self.device device self.processor AutoProcessor.from_pretrained(model_path) self.model AutoModel.from_pretrained(model_path).to(device) self.model.eval() def score(self, query_text: str, image_path: str) - float: image self.processor.image_loader(image_path) inputs self.processor(textquery_text, imagesimage, return_tensorspt, paddingTrue).to(self.device) with torch.no_grad(): outputs self.model(**inputs) # 这里的分数计算方式由实际模型决定 # 对比学习模型通常取 text_embeds 与 image_embeds 的余弦相似度 logits outputs.logits_per_image score torch.sigmoid(logits).item() return score if __name__ __main__: scorer VLMRelevanceScorer() s scorer.score(白色收腰连衣裙 夏季, test_item.jpg) print(frelevance score: {s:.4f})这段代码的注释说明了关键点不同 VLM 的输出字段不一致logits_per_image是常见对比学习模型的输出如果你的模型是生成式 VLM可能需要用 prompt 让模型输出分数或用生成 token 概率计算。所以实际项目里第一件事是确定模型输出层结构。6.3 使用 Prompt 模板做生成式相关度判断如果使用生成式多模态大模型更通用的做法是用 prompt 引导模型输出判断结果。# 文件路径src/prompt_relevance.py prompt_template 你是一个搜索相关性评测专家。 请判断用户搜索词和图片及文本描述之间的相关性只输出一个数字 2 表示相关1 表示部分相关0 表示不相关。 用户搜索词{query} 图片内容请结合图片进行判断。 文档标题{doc_title} 文档摘要{doc_summary} 输出 def build_prompt(query: str, doc_title: str, doc_summary: str) - str: return prompt_template.format( queryquery, doc_titledoc_title, doc_summarydoc_summary )这种方式的优点是判断过程可解释能知道模型为什么给这个分数缺点是推理延迟更高、成本更大。实际工程中生成式 VLM 更适合做离线评测集的打分和 bad case 分析在线重排阶段一般优先使用判别式或对比式的轻量 VLM。6.4 在线重排VLM 对候选集二次排序在候选集小规模重排时可以用 VLM 分数对文本召回结果进行重排。# 文件路径src/rerank_with_vlm.py from vlm_relevance_scorer import VLMRelevanceScorer scorer VLMRelevanceScorer() def rerank_candidates(query: str, candidates: list, top_k: int 20): scored [] for cand in candidates: # cand 是 dict包含 doc_id、image_path、title 等字段 score scorer.score(query, cand[image_path]) # 可以结合文本分数做加权融合 final_score 0.7 * score 0.3 * cand.get(text_score, 0.0) scored.append((cand[doc_id], final_score)) scored.sort(keylambda x: x[1], reverseTrue) return scored[:top_k]这里做了一个简单加权融合。实际项目中权重不能拍脑袋设需要用验证集做参数搜索避免 VLM 分数和文本分数量纲差异过大导致排序失效。6.5 离线评估脚本计算 NDCG有了打分结果后要立刻用离线指标检验。相关性评测最常见的指标是 NDCGK。# 文件路径src/evaluate_ndcg.py import math def dcg_at_k(labels, k): dcg 0.0 for i in range(min(k, len(labels))): dcg (2 ** labels[i] - 1) / math.log2(i 2) return dcg def ndcg_at_k(labels, predicted_order, k10): labels [labels[i] for i in predicted_order[:k]] ideal sorted([labels[i] for i in range(len(labels))], reverseTrue) dcg dcg_at_k(labels, k) idcg dcg_at_k(ideal, k) return dcg / idcg if idcg 0 else 0.0 # labels 是每个 doc 的人工标注predicted_order 是模型排序后的文档索引 labels [2, 1, 0, 2, 1] predicted_order [0, 1, 2, 3, 4] print(fNDCG5: {ndcg_at_k(labels, predicted_order, 5):.4f})这套代码只展示了评测最核心的部分。线上评估时还需要把多个 query 的 NDCG 做平均并根据 query 类型做分层分析比如图片类 query、文本类 query、歧义 query 分别计算。只看整体平均指标往往会掩盖模型在某个细分场景上的退步。7. 运行验证与效果评估完成代码实现后第一步不是直接跑全量评测集而是先做小样本人工目检。跑 20 到 30 个 query把 VLM 每个分数的排序结果打印出来由人快速判断“这个排序是否符合直觉”。这一步能发现很多隐藏问题比如图片加载失败、模型对中文适配差、prompt 描述和实际输入不一致。如果小样本目检通过再跑全量评测集。重点关注以下三类指标第一类是排序质量指标。NDCG10、MAP、MRR 是衡量排序整体质量的基础指标。VLM 相对文本模型提升多少通常看这些指标的变化。第二类是分类质量指标。如果评测集是二分类或三分类可以计算 Accuracy、Precision、Recall也可以分“相关/不相关”两个方向分别计算。重点要关注不相关内容的拦截率也就是“把不相关结果排到后面”的能力这往往比提升相关结果排到前面更难。第三类是人工一致性指标。抽取 200 到 300 条 VLM 打分结果与人工标注做一致性对比计算 Cohens Kappa。如果 Kappa 低于 0.6说明模型判分标准还不够稳定需要检查数据标注口径或 prompt 设计。运行失败时的排查顺序也很固定先看依赖和模型是否能正常加载再看图像路径是否能读取再看模型输入尺寸和处理器是否正确最后看输出字段是否匹配。多模态任务出现“模型能跑、结果全 0.5”的情况通常不是代码问题而是输入没有正确喂入图像或者处理器把图像缩得太小导致信息丢失。8. 常见问题与排查思路下面这张表来自多模态相关性项目中的常见经验按影响程度排序。问题现象可能原因排查方式解决方案模型全部输出 0.5 左右图像没有正确输入模型只看到空图或默认图打印输入图像尺寸抽样保存预处理后图像修正图像读取逻辑增加加载失败日志对中文 query 的效果明显偏差模型训练语料中文图文对不足在细分中文评测集上单独计算指标增加中文图文数据微调或选择中文能力更强的模型底座离线 NDCG 提升线上 CTR 下降评估集和线上分布不一致或分数未做校准对比线上 query 与评估集 query 的主题分布从线上日志重新抽样构建评估集并做分数校准VLM 分数梯度不明显输入图像分辨率过低或图文信息被截断检查图像预处理和文本截断长度提升输入分辨率增加图像切片编码GPU 推理延迟过高全量候选都过 VLM缺乏级联过滤分析各环节耗时占比引入轻量过滤限制 VLM 只处理前 50 条候选长尾 query 相关分波动大长尾 query 在训练数据中占比少按 query 频次分层分析指标针对长尾 query 定向补充数据并微调模型把“含关键词但图不符”判为相关文本信号权重过高视觉信号被忽视单看纯图像输入时的得分调整多模态融合权重增加图文矛盾样本训练其中“图文矛盾样本”是 VLM 相关性项目中最容易忽视的部分。很多团队直接用图文匹配数据集微调数据集里文本和图像通常是一致的但在真实搜索里标题包含关键词但封面图无关的情况非常常见。这类样本需要在评测集和训练集中刻意加入否则模型永远学不会“图不对文”应该如何判分。9. 最佳实践与工程上线建议上线 VLM 相关性度量不能只是替换一个模型接口。以下几个工程原则项目越早遵循后续返工越少。第一用小成本评估集先验证增量。不要一上来就构建百万级数据集。先标 1000 到 2000 条困难样本跑通 VLM 打分、评估、bad case 分析整个流程确认效果增量大于成本再扩大投入。相关性工作的投入产出比几乎完全取决于评估集是否精准。第二采用级联架构而不是全量替换。文本模型负责粗召回和快速过滤VLM 负责困难候选的精排。体验上用户感知到的是排在前面的结果更准了成本上只对少量候选跑 VLM整体算力可控。第三为 VLM 相关分数建立监控体系。重点监控分数的整体分布、不同类型 query 下的分位值、图文加载失败率、超时率。分数分布突然变宽或变窄往往意味着图片源质量变化或模型输入格式被改动。相关分数不能上线后就不管它和点击率一样需要日常监控。第四做分场景灰度上线。不要一次性全量切换排序策略。可以按 query 类型或者按流量比例灰度比如先在“商品类 query”上开放 10% 流量观察 CTR、长点击、无点击率等指标再逐步扩大。灰度期间要保留旧排序输出的备份方便快速回滚。第五考虑模型蒸馏。VLM 推理成本高不适合所有流量都跑。实践中可以先用 VLM 在大量样本上打分再把打分结果作为监督信号蒸馏到一个轻量级图文模型。这样线上用轻量模型仍能保留大部分 VLM 的相关性理解能力。第六注意图片资源和隐私合规。搜索系统涉及的图片来自第三方网页或用户上传上线前要确认图片抓取、存储、传输的合规性。尤其是涉及用户头像、UGC 图片、广告素材时要谨慎处理避免把敏感图片送入外部模型服务。自建模型部署时也要做好访问控制和日志脱敏。10. 总结与后续学习方向本文围绕“Advancing Relevance Measurement with Vision-Language Models for Web-Scale Search”展开核心观点是VLM 不会替代整套文本相关性体系而是补上传统模型在视觉理解上的结构性缺口。落地路径从评测集构建开始经历小样本目检、离线指标验证、级联架构上线、监控回流每一步都有明确的可执行动作。如果你所在的团队正计划尝试 VLM 相关性度量更稳妥的第一步不是直接买 GPU 集群或训练大模型而是先构建一份包含 1000 到 2000 条困难样本的小型多模态评测集找一个人工标注团队把相关性口径对齐然后用现有开源 VLM 在这份评测集上跑出分数看看相对于文本模型的增量到底有多大。这一步结果会直接告诉你这个方向在当前业务里值不值得继续投入。后续可以继续探索的方向包括多图对比与视频帧级别的相关性判断、VLM 打分结果蒸馏到轻量线上模型、VLM 与 LLM 联合做复杂意图相关性推理以及如何让评测集随线上内容变化保持持续更新。多模态相关性度量这个方向才刚刚开始离成熟标准还有不小距离也正因为如此早期投入的团队更容易建立真正的技术壁垒。