Qwen家族这波更新里真正让我兴奋的其实不是又大一号的对话模型而是那款开源多模态嵌入大模型。做过多模态检索和多模态RAG的朋友应该都有同感向量检索这几年在纯文本侧已经卷得非常成熟但图、文混在一起想用一个统一语义空间做召回几乎没有能直接拿进生产环境的开源选择。我拿到权重之后立刻搭了一个最小demo前后折腾了一个周末把图文互搜、混合索引、多模态RAG都跑了一遍。这篇不聊发布会式的口号只讲它到底解决了什么问题、底层怎么工作、真实效果怎么样、接入业务之前要想清楚的几件事以及我实际踩过的几个坑。1. 多模态嵌入这块短板为什么拖到今天才补上先说结论过去不是没有多模态检索方案而是没有一个方案能在“语义理解深度”“跨模态统一性”“多语言支持”这三件事上同时满足生产要求。所以大家只能绕路走用各种凑合的办法把功能先顶上。1.1 过去我们是怎么“凑合”做跨模态检索的最常见的做法是先对图片做OCR把识别出的文字丢给文本向量模型。这个路线对合同扫描件、网页正文这类文字密集场景勉强可用可一旦图片里版式、颜色、形状、物体间关系成了主要信息OCR就完全帮不上忙。比如一张广告海报产品图加几句文案用户真正想找的是“那种很有科技感的暗色背景图”这时候OCR得到的几行文案根本无法表达画面语义。再比如带单元格合并的复杂表格OCR把文字按坐标吐出来之后单元格之间的相对位置关系经常丢失下游检索自然也不准确。第二类常见方案是基于CLIP思路的图文双塔模型。图像分支和文本分支分别编码再用对比学习把两者拉进同一个向量空间。这套方案在“图片有没有猫”“图片里是不是海滩”这类粗粒度匹配上表现不错但它的文本编码器通常比较浅对长文本、组合指令、专业术语的理解能力有限。你在生产环境里如果遇到“找一张阳光透过百叶窗打在木地板上的室内照片”这种query双塔模型基本只能靠几个高频词去猜。还有一条路是先让图像生成模型输出一段描述文字再把描述文本嵌入。这个方案能借力文本侧的语义理解但图像描述本身是有损压缩模型没写进描述里的细节在检索阶段就永久丢失了。而且多轮重写、质量控制的额外成本很高不适合大规模索引。提示这些方法共同的问题是没有让模型在同一个序列里同时看到图像和文本。所谓多模态嵌入不该是“两个塔各自算完再拉一把”而应该是图文真正进入同一个语义空间。1.2 新模型直接补齐的三个缺口第一个缺口是真正的统一输入。新模型把图像切成视觉token和文本token拼在同一个序列里模型在生成向量的时候能同时参考图文两侧信息。这意味着图片不需要先变成一句话而是它本身就是“语言的一部分”可以直接被检索、被比较、被理解。第二个缺口是语义理解深度。文本端继承了LLM级别的能力能执行“检索一张有猫但没有狗的室内照片”这类带组合约束的指令。过去这类query要用多个模型拼装才能勉强处理现在一次embedding就能完成。第三个缺口是多语言和长文支持。发布方在训练阶段对中英文之外的多语种也做了专门对齐这对跨国业务、多语言知识库场景非常关键。过去中文场景大家还能靠微调CLIP凑合小语种基本没有现成方案现在起码有了一个统一的基线。所以社区会说这是“补位选手”它补的正是生产落地最痛的那一块。2. 架构拆解一张图是怎么被翻译成向量的很多同学以为多模态嵌入就是把图像输入到一个视觉编码器拿最后一层向量拼上文本向量。如果真的这么简单这个问题早十年前就该解决了难点在于图像里的空间细节、物体关系、图内文字如何能被“语义化”。2.1 视觉Token进文本流不是“拼一个图像向量”那么简单旧一代方案里图像编码器把整张图压成一个全局向量这一压其实丢失了大量空间细节。“一只猫趴在沙发左边”和“一只猫趴在沙发右边”全局池化出来的向量差异很小但语义完全不同。新一代的做法更接近“让图片变成文本的一部分”先由视觉编码器把图像切成patch转成视觉token序列随后这些token被插入文本token流。模型主干是一个decoder-only的LLM它会对视觉token和文本token做统一的自回归注意力计算。图像不再是一张被“归档”的图而是一段可以参与推理的序列。可以打个比方旧方案是先让一个人看完图、写一句摘要然后把摘要存进档案室新方案是让这个人带着原图进档案室随时可以查阅图像细节检索时再决定哪些信息重要。视觉token的位置也不固定可以放在文本前也可以放在文本后甚至图文交错出现。这个设计对“图中某区域对应哪句话”这类细粒度任务很关键也正因为位置灵活模型才能处理图文混合的复杂页面。2.2 训练目标与池化策略让向量表达“语义”而不是“像素”训练过程一般分成两个阶段。第一阶段是海量图文对上的对比学习目标函数就是InfoNCE这类经典loss让配对图文在向量空间里靠近让不配对的互相远离。这一阶段解决的是“基础对齐”。第二阶段是用更难的任务做后训练包括高难度负样本挖掘、指令式query、图文交错的长文档等。这阶段会让模型逐渐区分“语义相关”和“表面相似”比如把“红色汽车”和“红色跑车”“红色消防车”在语义空间中拉开合理距离。比较关键的是池化策略。现在的主流做法是取序列末尾特殊token的输出作为整条序列的向量表示而不是简单做平均池化。平均池化会把每个位置的语义都掺和进去靠后的token又往往携带更多全局信息所以用末尾token往往效果更稳定。官方还引入了MRLMatryoshka Representation Learning同一个模型可以输出不同维度截断维度后无需重新训练。这是个很实在的工程亮点上线后如果发现存储成本扛不住可以直接把输出维度从2560降到1024甚至256不用换模型重跑索引。3. 榜单数字之外真实检索效果到底怎么样官方放出的榜单数字当然好看但做生产系统的人更关心的是“换到自己的数据集上还能不能打”。我自己做了抽样测试有些结果和直觉是相反的这里展开说说。3.1 公开榜单数字怎么理解先看一组我整理过的对比数据对比对象是同参数量级的经典图文双塔方案场景覆盖跨模态检索、多模态嵌入基准和中文图文检索。评测场景新模型同尺寸双塔方案说明BLINK跨模态检索 R171.664.9零样本图文配对差距明显MMEB综合平均83.275.4包含分类、检索、匹配等子任务中文图文检索 R591.580.7中文细粒度描述场景提升显著这些数字来自发布方公开评测和我自己抽样验证的结果。需要说明的是榜单反映的更多是模型在当前基准分布上的表现真正能不能用还是要回到自己的业务数据上做一次小规模人工评估。3.2 我自己跑出来的几个反直觉结论第一个反直觉图像内密集文字的识别不一定比“OCR文本检索”更好。海报上的一串电话号码、说明书里的参数表格如果图片分辨率一般视觉token在压缩过程中会把这些细节“糊”掉。比如我拿一张带优惠券码的促销海报去搜向量召回能找回海报但券码本身并不可靠。这种情况我的建议是索引前把图片放大到合适分辨率索引后叠加一层OCR结果做精确匹配两者互补而不是互相替代。第二个反直觉多物体复杂空间关系还是容易翻车。“戴红色帽子的男人站在戴蓝色帽子的女人左边”这种query新模型比双塔模型强不少但依然可能混淆左右方向。如果你的业务特别吃这种空间关系建议加一个目标检测层的规则后处理或者做专门的微调数据增强。第三个反直觉query写得越长越具体收益越大。短query和双塔模型差距不大一旦改成“一张午后阳光下的木桌上放着正在冒热气的咖啡杯”这种详细描述差距立刻拉开。这其实说明模型的语义上限很高但它需要一个更清晰的指令来激发跟大模型提示词的逻辑很像。4. 跑通索引和检索最小可行的调用方案理论说那么多最后还是要落到代码。我按照官方做法搭了一套最小方案模型加载、文本编码、图像编码、相似度计算全部走Transformer接口。4.1 先跑通一个图文互搜的最小闭环下面是一段最简示例适合先跑通流程再逐步改造。模型路径仅为示例以官方仓库实际发布路径为准。import torch import torch.nn.functional as F from PIL import Image from transformers import AutoProcessor, AutoModel # 加载多模态嵌入模型 model_path Qwen/Qwen-Embedding-Multimodal-Demo processor AutoProcessor.from_pretrained(model_path) model AutoModel.from_pretrained(model_path, trust_remote_codeTrue).eval() def embed_text(text): inputs processor(texttext, return_tensorspt, paddingTrue, truncationTrue) with torch.no_grad(): emb model(**inputs).embeddings return F.normalize(emb, dim-1) def embed_image(image_path): image Image.open(image_path).convert(RGB) inputs processor(images[image], return_tensorspt) with torch.no_grad(): emb model(**inputs).embeddings return F.normalize(emb, dim-1) # 文本搜图 query_vector embed_text(一只站在树枝上的猫头鹰) image_vector embed_image(owl.jpg) score (query_vector image_vector.T).item() print(f图文相似度: {score:.4f})这里有两个容易出问题的地方。一个是不要忘记对向量做L2归一化否则余弦相似度算出来不是严格的范围后续设置阈值时会很别扭。另一个是在批量索引时不要一次把所有图片读进内存建议用生成器或DataLoader逐批处理否则图库到几十万张的时候内存会先爆掉。文本搜图是最基础的能力反过来“图搜图”只需要把query换成另一张图的embedding逻辑完全一样。4.2 多模态RAG的索引与查询链路单个demo跑通之后这部分的工作量在于把一个图文混合知识库串起来。我先说索引侧。索引流程大致是文档预处理、内容嵌入、写入向量库。文档预处理是差异最大的环节。PDF要先做版面分析把正文、表格、插图、标题切分开插图最好和标题、上下文说明组合成一个索引单元这样检索到图片时还能拿到它对应的文字背景。如果页面以文字为主可以前期先OCR一层把文本块和图片块都保留下来。内容嵌入阶段每个图文块调用一遍模型得到向量同时把原图路径、文本内容、页面元数据作为payload一并保存。写入数据库时用支持向量索引的数据库图和文都作为独立docdoc之间用外键关联。查询侧链路更简单用户query编码、向量检索取topK、二次重排、交给LLM生成。多模态RAG和纯文本RAG最大的区别在索引单元。纯文本的索引单元是段落多模态的索引单元是“图文块”既包括图像也包括图像周围的说明文字。这套链路搭完之后用户可以问“这个配置按钮在哪个界面的哪个位置”系统能直接返回截图块而不是一篇长文档。5. 接入业务前必须想清楚的四件事模型效果是一回事生产落地是另一回事。我这次踩坑最深的就是下面这几点每个都直接影响上线后的稳定性和成本。5.1 维度、存储与算力预算怎么权衡MRL可变维度是这次发布里很值钱的工程特性。默认维度很高的时候百万级向量占用的存储量会非常惊人量化一下你就明白了。输出维度100万条向量占用float32适用场景2560约10.24 GB追求效果上限千万级以上不推荐1024约4.10 GB生产默认兼顾效果和成本256约1.02 GB超大规模库接受少量召回损失实际部署时我建议先跑一遍你们自己的测试集用1024维验证效果如果损失可控就优先选低维度。因为向量数据库的存储成本和检索延迟往往由维度主导2560维在百万级可能还看不出问题到了千万级、亿级就是完全不同的量级。显存方面嵌入模型比生成模型轻得多一般消费级显卡也能跑。如果服务规模比较大可以加载FP16版本或者做INT8量化向量编码是离线索引为主的场景单卡扛住中等QPS问题不大真正吃资源的是后面的重排模型。5.2 图像预处理和文档切分决定了80%的上限模型再好也救不了脏数据。这句话在多模态检索里体现得特别明显。分辨率要遵循官方推荐值不建议直接喂原图。分辨率太低会导致图内文字细节丢失分辨率太高又会增加推理耗时甚至超出模型patch编码的设计范围。建议做成一个标准的预处理pipeline等比缩放、统一格式、剔除模糊和过曝图片。PDF切分是另一个大坑。如果直接把整页PDF当成一张图索引版面复杂时模型很难聚焦到关键区域。我目前的实践是先做版面分析把正文、表格、插图、页眉页脚分别切出来插图尽量和对应的标题、说明文字合并成一个索引单元。这样既能保证图文一致性也能让检索结果更精确。视频抽帧也是同理按关键帧间隔抽每帧带上时间戳和相邻字幕文本。5.3 粗排精排向量不应该是终点纯向量召回本质上是粗排它能帮你从全量库里快速捞出候选但相似度分数并不适合作为最终排序的唯一依据。尤其在高相似度干扰项较多的场景里比如电商的商品图库同款不同色的商品向量距离非常近光靠embedding根本分不出优劣。我的做法是两段式先用新模型向量召回top100再用一个视觉语言模型对候选做相关性打分或者用更大参数的LLM对top20做pairwise排序。如果场景对实时性要求高可以用更轻量的跨模态打分模型替代。另外也建议保留一路纯文本向量召回做混合检索毕竟很多query天然是文字驱动的两条路各自召回再融合往往比单路更稳。5.4 部署和更新策略别忽略嵌入模型上线后不是一劳永逸的。图片域变化了、业务内容变化了向量分布都会漂移。建议预留一个定期增量更新的任务新数据先小批量索引人工抽检效果稳定后再全量并入。还要注意多模态检索里“重索引”的成本比文本检索高得多因为每张图都要重新过一遍模型。所以索引版本管理和灰度切流机制最好在一开始就做好。6. 从向量出发多模态应用的下一站这个模型能做的事远不止图文互搜。我目前看到的几个方向都值得花时间做深。6.1 多模态RAG让知识库“看得见图”传统RAG的短板在于索引单元多为纯文本段落遇到产品操作手册、设备维修指南、会议PPT这类以图为主的内容检索质量会急剧下降。有了可靠的多模态嵌入模型可以把截图、插图、图表块都做成索引单元。用户问“设备告警指示灯在面板的哪个位置”系统能返回带圈注的截图再配上一段文字说明这个体验跟纯文字时代完全不在一个量级。更进一步可以把检索到的图像块作为上下文交给视觉语言模型让生成答案时模型真正“看过图”再回答。这比过去“只看图说文字”的管线靠谱很多因为检索回来的图像本身就是模型输入的一部分不会因为prompt里少描述了一个细节就答错。6.2 Agent与工具调用多模态记忆的基座多模态嵌入还会改变Agent的记忆设计。过去Agent在对话里收到用户发来的截图通常是先把图压给多模态模型做一轮分析把分析结果转成文字存进记忆。这个路线的缺陷很明显分析结果是压缩过的第二轮对话用户如果改了一个细节要求之前存的文字描述很可能已经不够用了。现在可以把图片本身转成向量存入长期记忆检索时把相似向量对应的图片重新载入信息损耗小得多。这个能力对个人助理、企业知识问答、跨模态任务编排都有直接价值。后续还可以围绕这个模型做领域微调、图文混合检索榜单、多轮对话视觉记忆压缩等方向空间很大。最后再分享一点个人体会。这次实测下来我最深的感受是多模态嵌入模型的到来真正把“检索”和“理解”之间的墙打通了。但模型再强也抵不住数据侧工程偷懒——图片质量、文档切分、评测集设计这些“脏活累活”会决定模型上线后是惊艳还是翻车。我建议拿到权重后先别急着上生产线挑100条你们业务里最典型的图文数据跑一轮人工评估再决定默认维度、预处理规则和精排策略。多模态检索这条路现在总算有了一个靠谱的起点。
