多模态Embedding与MLLM怎么选？CLIP路线 vs 生成式模型落地对比-北京尧图网络

1. 为什么多模态 Embedding 是检索系统的分水岭多模态 Embedding 这个词这两年已经被提到很多但真正在业务里跑过的人应该都有同感跨模态检索从“能跑通”到“能扛业务”中间隔了很长一段路。我自己是从单模态搜索转到多模态检索的最早接触 CLIP 一系模型时确实被“一句话搜图”的能力震撼过但也真被它的工程短板坑过不少次。这篇内容就从工程视角聊聊以 jina-clip-v2 为代表的 CLIP 路线迭代以及它和现在很火的 MLLM多模态大语言模型范式到底有什么不同、实际项目里该怎么选。先说为什么我把多模态 Embedding 看作检索系统的分水岭。过去很多系统的做法是把文本和图像分开处理文本走全文检索图片走标签或者 OCR 结果。这种结构在内容量小的时候没问题可一旦数据规模上来问题立刻暴露。标签是人工标的永远标不全OCR 只能识别图中文字识别不出画面内容而用户真正想问的往往长这样——“找一张春季新款、浅色系、适合通勤的背包图”。这种自然语言 query单靠标签和 OCR 都无解必须依靠模型把画面和文字放进同一个语义空间去比对。1.1 跨模态检索为什么不是两个单模态系统的拼接真正把多模态检索做好的方式是让文本和图像落在同一个向量空间里。Embedding 模型在这里扮演的是“坐标转换器”的角色无论输入是一段文字、一张商品图、一个视频帧还是一段语音最终都被映射成一组固定维度的向量。检索系统不再关心你输入的是文本还是图片它只做一件事算向量之间的距离距离近的就是相关内容。这套设计解决的不只是“文本搜图”还能做图像搜图、图像搜文本、多模态相似推荐。我后来发现自己遇到的大多数检索场景本质上都可以概括成“给定一个模态找相关的另一个模态”。比如用户上传一张产品外包装图想找到对应的商品详情页再比如运营人员拿一张活动海报想找出素材库里所有风格相似的海报。这些需求天然依赖多模态 Embedding传统分开索引的做法完全没有办法支撑。1.2 对比学习CLIP 式模型的核心机制CLIP 这类模型的基础是双塔结构一个文本编码器、一个图像编码器。训练时把配对的文本和图像当作正样本把同一个 batch 里其他样本当作负样本用对比损失拉近正样本对的向量距离、推远负样本对的向量距离。训练结束后文本和图像都被压缩成同一维度的向量比如 768 维或者更高。如果只用机器学习的术语解释对比学习可能不太好懂。我习惯用一个类比两个编码器就像两个翻译官一个负责翻译文字一个负责翻译画面训练目标是把每种内容都翻译成同一门“语义外语”。起初两个翻译官各说各话对比损失就是反复纠正他们翻译姿势的教练同样的意思必须落到词典里相近的位置否则就扣分。这里的关键不是向量维度而是“对齐”本身。同一条图像向量和正确文本向量的距离必须比和错误文本向量的距离更近。这种相对关系稳定了检索结果才是可靠的。CLIP 式模型刻意训练这种相对关系所以它天然适合做 Embedding而不是另一个只会生成描述的模型。2. CLIP 路线迭代jina-clip-v2 到底改了什么CLIP 这个概念虽然很美好但早期模型拿来落地时被吐槽最多的就是“道理我都懂一跑全是问题”。如果只拿它做 Demo 没问题一旦接进真实系统各种边界情况能把人折磨疯。所以我觉得jina-clip-v2 最有价值的不是某一个指标的提升而是把 CLIP 路线的生产短板一块一块补上了。2.1 老 CLIP 模型在工程侧的四个短板第一是文本长度限制。老 CLIP 的文本编码器接受的 token 数很有限模型卡里写着一个非常保守的上限。实际业务里用户搜图根本不会只输入一个词而是输入一大段描述“灰色羽绒服立领设计袖口有松紧收口适合北方冬天穿”。这种长 query 喂进去后半段关键信息基本被截断检索结果自然一塌糊涂。第二是图像分辨率限制。老 CLIP 一般先把图缩放到一个比较小的固定尺寸再送进模型这对细节敏感的产品图、截图、文档里的图表都非常不友好。相机照片里的小字、包装上的规格参数、扫描件里歪歪扭扭的批注缩放之后信息全丢了模型只能看到一个大致的轮廓。第三是语言覆盖问题。早期 CLIP 类模型在英文上的表现和对中文的支持程度差距很大尤其在中文长句上经常出现语义漂移。同一个 query换成中文和英文检索结果的差异可能非常明显这给国内业务落地带来了不少麻烦。第四是模型本身的表达能力有限。早期 CLIP 模型的参数量不算大处理复杂场景时对“属性组合”的建模能力偏弱。比如“一只站在树枝上的蓝色鹦鹉”和“一只站在桌上的蓝色杯子”模型可能把蓝色和鸟类搞混这类细粒度区分能力不足的问题直接影响了排序质量。2.2 jina-clip-v2 的变化处处对着短板打jina-clip-v2 在我看来的核心变化是换用了更强调长文本语义对齐的文本编码器上下文长度从原来几十个 token 直接拉高到数千量级。这对检索是质变长描述、长问句、整段说明书文本都可以整段编码不用再担心截断问题。图像端也支持接近原图分辨率的输入处理不再强行压缩成小图。这个改动对包含小字、标注、图表的业务场景非常关键。我做过一个行业图纸检索的项目图纸上有大量尺寸标注和材质说明老模型把图缩完后标注文字变成了一团模糊的噪声换了 v2 这类支持高分辨率输入的模型后图纸上的关键标注能参与语义匹配检索精度提升非常明显。多语言覆盖也是 v2 的一个重点。它在中文场景下的跨模态检索效果比我预期中要好。过去我处理中文搜索经常要先做分词、同义词扩展现在模型本身对中文语义的对齐能力强了不少很多预处理逻辑可以直接砍掉省了一大笔维护成本。我强调一句我不是说 jina-clip-v2 完美了任何模型都做不到完美。但它是那种“针对生产场景做减法”的模型知道用户真正要的是什么稳定的向量、可对比的距离、扛得住脏数据。2.3 快速体验一段描述找一张图如果你还没用过这类模型我把最核心的流程拆给你看其实不复杂加载模型对图片编码对文本编码算余弦相似度。下面是一段伪代码具体接口以模型托管平台的最新说明为准。# 伪代码演示核心流程 model load_multimodal_embedding(jina-clip-v2) img_vec model.encode_image(商品图.png) text_vec model.encode_text(红色手柄、带防滑橡胶的金属阀门) score cosine_similarity(img_vec, text_vec) print(score)这段代码在老一代 CLIP 模型上的失败方式非常有代表性“红色手柄”还能勉强命中但“带防滑橡胶的金属阀门”这种长尾属性组合基本不在模型的语义射程内。而在 jina-clip-v2 上整段文本可以完整编码多个属性信息能同时和图像区域建立关联检索体验就完全不一样了。3. MLLM 范式它能理解但未必适合 Embedding聊完了 CLIP 路线再来看看 MLLM 范式。这两年多模态大模型非常火很多人会惯性思维既然大模型这么强直接把多模态大模型拿来做 Embedding不是更省事这个想法我在项目里试过结论是MLLM 确实能“理解”图像但它给出的表示和检索系统需要的 Embedding 是两回事。3.1 MLLM 的基本架构与训练目标MLLM 的典型结构是“视觉编码器投影层大语言模型”。图像先被切成 patch变成一串视觉 token投影层把这些 token 映射到大语言模型能理解的向量空间之后和文本 token 拼接在一起由大模型做自回归生成。于是 MLLM 能做图文对话、视觉问答、图表推理这些事。这套结构的能力边界在于它的主任务是生成不是表示。训练目标是预测下一个 token模型关心的是“这段上下文接下来最可能的输出是什么”而不是“两张图的语义距离应该多近”。这两种目标在数学上完全不搭模型内部算出来的向量自然也不会天然具备检索友好的性质。3.2 为什么不能直接把 MLLM 的输出层当 Embedding 用我经常被人问大模型内部到处都是向量直接抽一层的向量当 Embedding 行不行我的回答是能抽能不能用就另说了。第一生成式模型的中间层向量没有刻意做“相似对象近邻”约束。比如一张红色汽车图和一张红色椅子图中间层向量可能更关注语言上的上下文关联而不是视觉内容本身的相似性。你拿它做近邻搜索出来的结果往往是不可解释的。第二MLLM 输出的是变长 token 序列不是固定维度向量。检索系统需要把每个样本压缩成一条固定维度的向量才好写进索引做 ANN、聚类。变长序列要么池化要么拼接但是任意池化都会破坏语义结构想要可靠结果就得重新训练一个嵌入头那已经是另一套工程了。第三跨模态对齐的机制不一样。CLIP 式模型在训练时直接对文本向量和图像向量做对比约束隐空间里的距离天然有意义MLLM 虽然图文一起输入但对齐是在跨层注意力里隐式完成的最终得到的特征未必能在统一空间里直接算距离。我常用一个比喻MLLM 像一位很会讲解的导游你问他路线他能用各种方式描述得明明白白但如果你需要一张可以直接量距离的地图他还是拿不出来因为导游的职业训练里没有“画标准坐标”这一项。你想让他同时当好导游和制图师就得额外教他绘图课那就是二次训练。3.3 两种范式的关键差异一张表看懂对比维度jina-clip-v2 为代表的 CLIP 式嵌入模型MLLM 范式输出形态固定维度向量直接进向量库变长 token 序列需要额外策略才能转向量训练目标对比对齐拉近匹配对、推远不匹配对自回归生成预测下一个 token跨模态检索天然支持直接用余弦距离不直接可用需要二次开发或重新训练工程复杂度低部署轻索引友好高显存占用大推理链路长核心适用任务召回、排序、去重、聚类、RAG 最近邻图文问答、内容理解、摘要生成、复杂推理这张表基本解释了我对两个方向的定位CLIP 式 Embedding 是“检索的底座”MLLM 是“理解与生成的大脑”。两者在真实项目里往往是配合关系而不是替代关系。4. 三个落地场景里的对比观察光聊概念没有意思我直接把两种范式放到三个常见业务场景里做了对比结果很能说明问题。4.1 场景一以文搜图某内容库产品希望支持用户用自然语言找图。我采用 jina-clip-v2 式模型把全部图片离线编码好写入向量索引用户输入文本 query 后编码成向量去库里做近似最近邻检索。上线后最明显的变化有两个一是 query 长一些也没关系二是细节词都能命中。作为对比如果我用 MLLM 来做这个场景的角色分配它的强项是 query 改写。用户说“帮我找一张看着很专业、适合做汇报封面的图”MLLM 可以把这个口语话的请求改写成“商务风、蓝灰色调、简洁构图、适合 PPT 背景”然后再交给嵌入模型做召回。这个混搭方案效果很好因为擅长什么就让谁干什么。4.2 场景二多模态 RAG 的知识召回现在很多 RAG 系统处理的是图文混合文档比如产品手册、设备说明书、研究报告。这类文档里大多是段落文字但关键信息经常藏在图表、截图和流程图里。如果只做文本切块图片中的信息就全部丢失了。我的做法是图像和表格单独切出来用 CLIP 式嵌入模型做向量化和文本向量放在同一个索引里。用户提问时先由嵌入模型做多模态召回把相关的文字段落和图片片段都捞出来再丢给 MLLM 做阅读理解生成最终答案。分工非常明确召回归嵌入模型理解归 MLLM。还有个可行变体先用 MLLM 给每张图生成描述把描述加进文本侧再由嵌入模型编码。等于让 MLLM 担任“信息预处理官”把图片内容翻译成文本嵌入模型再负责把这些内容统一成索引向量。这个方案对召回率的提升也很明显。4.3 场景三相似内容去重内容平台经常需要判断两张图是否属于同一主题比如用户上传的重复活动海报、相似商品图。这个任务对 Embedding 的稳定性要求很高模型提取的特征要经得住裁剪、轻微调色、压缩等干扰相似对象之间的距离仍然要稳定。CLIP 式嵌入模型因为训练时直接约束匹配距离这种稳定性是它的禀赋。配合一个相似度阈值可以粗召回大量重复内容。MLLM 在这个场景里更适合做“精判”先用 Embedding 召回一批疑似重复项再让 MLLM 对候选做一次确认性判断给出结构化结果。我实践下来的体感是粗召回靠 Embedding精判靠 MLLM效率最高。5. 我曾尝试把 MLLM 当嵌入模型用一次完整踩坑复盘这一段我专门拿出来讲因为我相信很多人都有过类似的想法也都会踩同样的坑。有一段时间团队要处理一批行业图纸和说明书的检索。当时有个观察CLIP 式嵌入模型对“图中文字很多”的数据总是不够“懂”因为图里的大量文字描述被视觉特征稀释了。于是团队里有人提出不如直接把 MLLM 当作 Embedding 模型用毕竟它理解力更强。听起来很有道理我们就做了一次完整实验。5.1 起因被 MLLM 的理解能力打动我先选了一个开源多模态小模型作为骨干把图纸图片喂进去取它倒数第二层的平均池化作为图像向量文本侧也一样处理把问题文本编码成向量然后用向量数据库做检索。最初设想很简单MLLM 对图像的理解能力明显强于对比学习模型它编码出的图像向量应该语义更丰富。但我们忘了一个关键差异——理解能力和检索能力是两回事。实验结果很快给了我们一记重击。5.2 现象相似图检索完全没有规律第一轮测试跑完现象非常明显单独查图像与图像时语义上明明同一类的图纸向量距离忽远忽近有时甚至和不相关图纸的距离差不多。我拿到结果一度以为索引写错了反复检查了好几遍。排查第一步我用一批人工标注好的相似图对分别计算 MLLM 特征和 CLIP 式嵌入的相似度分布。结果是 CLIP 式嵌入的区分度很清晰相关图的距离明显更近MLLM 特征则几乎看不出规律相关图与不相关图的距离重叠严重。第二步检查输出层。我把最后一层和倒数第二层都试了一遍发现向量空间差异不大但稳定性不好同一张图稍微翻转或裁剪一下余弦相似度波动很大。这说明问题不在预处理而在模型本身的表示空间里并没有一个“相似物体距离近”的约束。第三步做跨模态验证把文本 query 和 MLLM 图像特征做混合检索。这个环节的结果更差。文本和图像在自回归训练中并没有被显式地做对比对齐所以两种模态的向量根本不在一个可比较的分布里强行算相似度结果和随机排序也没太大区别。5.3 根因与修复让嵌入回归嵌入经过这轮排查根因已经很清楚了MLLM 的表示空间是“面向生成的”不是“面向检索的”。它的主任务是推理生成以此为目标的训练方式没有给我们想要的距离度量性质。想要获得稳定的检索特征必须额外做对比学习训练或者外挂一个嵌入头这个成本相当于重新训练一个小型检索模型。最后我把方案改成了两条腿走路先用 jina-clip-v2 式嵌入模型做图像和文本的召回保证索引可比较、距离稳定再用 MLLM 对 topK 结果做二次理解与排序让“懂内容”的能力出现在后半段。对于图中文字多的场景我额外加了 OCR 流程把图里文字提取出来挂到图像旁作为文本补充。这样既发挥了 MLLM 的理解优势又保住了检索链路的稳定性。回头总结这条坑踩得不冤它让我彻底理解了“检索需要嵌入理解需要生成”这句话也让我后续做所有方案选型时先问一句输入输出形态再动手。6. 落地选型与部署避坑清单最后聊点实用的。如果你现在要上一个多模态检索项目面对一堆模型名词不知道怎么选我把自己的判断逻辑和部署经验分享出来。6.1 选型判断看任务不看热度我一直强调技术选型不要看热搜榜看任务本身要什么输出。我把任务分成三类大家可以直接对号入座任务性质建议主体模型选择原因跨模态检索、相似推荐、去重聚类CLIP 式嵌入模型输出固定向量对齐天然向量库友好图文问答、内容理解、摘要生成MLLM强项是推理与生成不需要承担检索职责检索与理解混合的业务嵌入模型 MLLM 分工召回阶段用嵌入理解与重排阶段用 MLLM这张表不是绝对的但能解决 80% 的选型纠结。核心逻辑是如果你的链路最后需要“算距离、排序、拿 topK”那就一定要有一个稳定且对齐良好的 Embedding 空间如果你需要“描述内容、回答问题、生成结论”那就交给 MLLM。6.2 部署时要盯住的几个细节第一模型精度和显存。CLIP 式嵌入模型一般比 MLLM 参数少很多部署压力小但也别掉以轻心。建议先用半精度或者 INT8 跑一轮压测确认峰值显存和延迟再上生产。图像输入尺寸大、文本长度长这两类高负载场景要分开规划。第二向量维度一旦定下来尽量别中途换模型。换模型意味着所有文档向量都要重新生成否则旧 query 向量和新 doc 向量不在同一个语义空间检索结果会是灾难性的。做灰度时务必新旧索引同时保留逐步切换。第三向量索引参数不要照抄。HNSW 的 M 和 efConstruction 会影响召回率和内存占用我一般从 M32、efConstruction200 起步再用业务数据调优。图文混合投递时单次 batch 大小和线程数要专门测不能想当然按纯文本场景设置。第四上线前务必准备硬负样本集做召回率评测。我会挑 200 个正样本、200 个难负样本比如视觉上相似但语义不同的图片对看模型能否稳定区分。没有这一步再好的模型上线都像闭着眼睛开飞机。6.3 最后再分享一点个人体会如果用一句话总结这次迭代复盘带来的实际收益那大概是我越来越不迷信模型名词而是先问自己——我要的是统一向量空间里的相似匹配还是跨模态理解与生成。前者首选把对比对齐做到极致的 CLIP 式嵌入模型后者再看 MLLM。两者组合在一起能覆盖绝大多数检索业务。将来嵌入模型如果也能借助更强的生成能力做数据增强比如用 MLLM 生成更多难样本、做模态补全那只会让召回变得更好并不会改变“检索需要嵌入、理解需要生成”的基本分工。至少在我目前做过的项目里这个分工始终有效。

多模态Embedding与MLLM怎么选？CLIP路线 vs 生成式模型落地对比

相关推荐

视频孪生与空间智能赋能智慧管廊：从方案设计到落地复盘

人工智能辅助数学猜想生成：模式挖掘、过滤与人机协作

Linux压缩命令实战：从tar、gzip到zip/7z的完整指南

更多资讯

递归特征金字塔RFP改进YOLO11，解决小目标漏检

KV Cache量化实战：显存占用计算与INT8/INT4选型指南

C#贪吃蛇最简实现：命令行状态机教学版

AI智能模式重构Web自动化测试：从脚本维护到元素定位与自愈

STM32F407 FreeRTOS移植实战：从裸机轮询到多任务调度

AI术语辨析：latency与delay的本质区别及优化实践

今日更新

NetSpot 实战：用信道分析与频宽优化解决 Wi-Fi 卡顿

C++ split() 字符串分割的五种实现与性能实测

R语言坐标轴范围设置：从xlim/ylim到coord_cartesian的完整指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？