前言：微信视觉团队开源WeMM-Embedding多模态Embedding模型，统一文本图像视频向量空间，2B版本在MMEB-v2榜单反超8B，支持Matryoshka套娃向量截断，为多模态RAG检索提供云端闭环基础设施。
前两天刷推的时候，刷到一条消息。
微信视觉团队开源了一个多模态Embedding模型，叫WeMM-Embedding。
我当时就有点懵。微信？开源？Embedding模型？
这三个词放一块，怎么听怎么违和。微信在我心里一直是那个把东西捂得严严实实的产品，公众号接口抠抠搜搜，朋友圈连个正经API都不给，突然把视觉团队的核心模型往外掏，这不像它的作风啊。
好奇心上来了，压不住那种。
我就去把它的GitHub仓库翻了个底朝天，技术报告也从头读到尾，对着榜单一个一个数字比对下来。
翻完之后我愣了一下。
这玩意儿比我预想的猛太多了，而且它戳中的那个点，恰恰是现在AI应用里最被忽视、又最要命的一环。
先说这个模型是干嘛的，怕有些朋友没接触过这块。
Embedding这个词，翻译过来叫「嵌入」，听着挺玄乎，其实干的事儿特别朴素。就是把一段文字、一张图、一个视频，变成一串数字，一串几千维的数字。变成数字之后，语义相近的东西，在这串数字里离得也近。
你搜「海边跳舞的女孩」，系统把这句话变成一串数字，然后去图库里挨个比对，离得最近的那些图，就是你要的。
就这么个事儿。
听着简单，但这是整个AI检索的地基。RAG能召回正确的文档，推荐系统能推到你想看的内容，搜索引擎能以文搜图以图搜视频，底下全是这玩意儿在扛。
而WeMM-Embedding干的事，就是把文本、图片、视频、视觉文档（就是那种扫描件、PPT截图、合同照片），全部塞进同一个向量空间里。
注意，是同一个。
这事儿有多难呢，以前你要做以文搜图，得专门训一个图文匹配的模型，做以图搜视频又得换一个，处理那种歪歪扭扭的扫描合同还得再来一个。每个模态一套模型，一套向量空间，互相不通气。现在微信说，不用，我一套全给你包了。
我翻技术报告的时候注意到一个细节，这个模型底座是Qwen3.5，分2B、4B、9B三个尺寸。2B就是20亿参数，9B是90亿。
光说参数没感觉，我给你看个数字。
在MMEB-v2这个榜单上，覆盖78个数据集，WeMM的2B版本拿了77.9分。
之前开源圈同尺寸最强的Qwen3-VL-Embedding 2B是73.2。更离谱的是，这个2B的分数，反超了人家8B的版本，8B那个是77.8。
20亿参数的，干翻了80亿参数的。
你想想看，参数量差了四倍，分数还更高，这在模型圈基本等于以下犯上。
9B版本就更狠了，80.6，直接登顶。
我当时对着这个数字看了半天，心里只有一个念头。
微信内部到底喂了多少数据。
技术报告里写了一句，说这个模型已经在微信的视频号、公众号、朋友圈、还有电商业务里跑过了，做了14个线上A/B测试，全部有提升。
14个。
我看到这个数字的时候，突然就理解了为什么这个模型能这么猛。它不是那种在实验室里拿公开数据集训出来、刷个榜就完事的学术模型。它在微信那个每天几亿人用的真实场景里，已经被反复锤打过了。
你想想微信里有多少内容，视频号每天上传的视频量，公众号文章里的配图，朋友圈的图片，小程序电商里的商品图。这些全是天然的、海量的、带真实用户反馈的训练数据。
这种数据，外面的人想要都要不到。
说真的，我有时候觉得，大厂开源模型这事儿，你得辩证地看。它确实把权重放出去了，但你永远不知道它把最好的数据藏在了哪里。开源的是结果，不是过程。
不过话说回来，能把这个结果放出来，已经挺够意思了。
回到这个模型本身，我翻仓库的时候还发现一个挺骚的设计。
它支持一种叫Matryoshka的Embedding，就是套娃表示。
啥意思呢，正常的Embedding模型，输出是固定维度的，比如2048维，你要存要算都是2048。但WeMM支持把向量截断，从2048砍到1024、512、256、128、64，砍完重新归一化一下，照样能用。
而且技术报告里说，2B模型砍到256维的时候，还能保留完整维度98.7%的性能。
这个设计太懂业务了。
我给你算笔账。你做一个微信这种体量的搜索系统，图库里可能有几十亿张图，每张图都要存一个向量。2048维和256维，存储差了8倍，检索时候的算力差得更多。
实际工程里你可以这么玩，先用256维做一轮粗排，把99%不相关的图先过滤掉，再用2048维对剩下那1%做精排。两段式检索，速度和精度都拿到了。
这种细节，没在真实业务里趟过坑的人，是想不出来的。
顺着这块再聊聊它的部署。
我看了下官方给的部署方案，vLLM和SGLang，都是服务端推理框架。vLLM要0.27.0版本，SGLang要0.5.9。
这俩东西是干嘛的呢，就是专门在GPU服务器上跑高并发推理的，优化吞吐量、调度算力那种。
也就是说，这个模型从设计之初就是奔着服务端去的。
这其实很好理解。你想啊，9B的模型，光加载就得十几个G的显存，再加上它要处理视频，视频抽帧之后吐出来的视觉Token是海量的，手机端根本扛不住。就算是最小的2B，常规精度加载也得几个G显存，你总不能让用户手机里常驻一个这玩意儿。
所以它的业务链路是这样的，客户端只负责采集和上传，图片视频传到服务端，服务端用WeMM生成向量，向量直接写进向量数据库，检索的时候也是服务端自己内部倒腾，客户端只拿到最终结果。
整个多模态理解、向量化、检索，全在云端闭环。
我翻到这儿的时候，脑子里突然蹦出一个念头。
这个模型解决的，压根不是「算得准」的问题。
它解决的是「找得到」。
你想想看，现在大家聊AI，聊的都是大模型多聪明、推理多强、能不能写代码能不能做数学题。但真到了业务落地，卡住你的往往不是模型不够聪明。
是你有一堆PDF、一堆PPT截图、一堆操作录屏，用户问了个问题，你的LLM根本不知道该去翻哪一份资料。
RAG为什么火，就是因为LLM自己记不住那么多东西，得靠检索去喂。而喂什么、喂得准不准，全看embedding那一步。
embedding要是烂，你召回的就是错的文档，LLM再聪明也是巧妇难为无米之炊。垃圾进，垃圾出。
WeMM这种多模态embedding，干的就是把「找得到」这件事做到极致。文本、图片、视频、扫描件，不管你资料是什么形态，它都能映射到同一个空间里去比对。
我举个具体的场景。
你公司有个知识库，里面混着PDF合同、产品截图、操作录屏、还有几份扫描的纸质档案。以前你要做检索，得分成好几套系统，文档检索一套，图片检索一套，视频检索一套，互相还串不起来。
现在用这种统一的多模态embedding，全部编码进同一个向量库。用户问「去年那个采购合同的违约条款怎么写的」，系统能直接把那份扫描合同里对应的那一页召回出来，连带相关的邮件截图、审批流程截图一起给你。
这才是多模态RAG该有的样子。
而不是现在大多数所谓的多模态RAG，其实就是文本RAG套了层皮，图片视频走个过场。
说到这儿我得泼盆冷水。
这个模型再猛，它也只是个embedding模型，它干的活儿是「召回」，不是「抽取」也不是「计算」。
什么意思呢，比如你有一堆发票，你想让AI帮你把每张发票的总金额抽出来做个汇总。这个任务里，embedding负责的是把对的发票召回回来，但金额的识别和加总，得靠LLM去做。
embedding解决「找得到」，LLM解决「算得准」，这俩是配合关系，不是一个模型包打天下。
我看到有人问，那纯代码检索呢，这个模型行不行。坦率的讲，代码这种高度结构化的文本，建议还是搭配专门的code embedding，术业有专攻。WeMM的主场是那种图文混合的、非结构化的、真实业务里乱七八糟的资料。
它不是万能药，它是特定场景下的重型武器。
翻完整个仓库和报告，我坐在那儿想了挺久。
我一直在琢磨一个事儿。
我们平时聊AI，聊的永远是水面上那部分。哪个大模型又刷新纪录了，哪个Agent又能自己干活了，哪个产品又融了多少钱。这些是冰山尖尖，是看得见的。
但水面下那块巨大的、沉默的、把万物变成向量让机器能「找到」彼此的基础设施，没人聊。
它太底层了，底层到不性感。
可你想想，微信每天几亿人在搜东西、刷视频号、看公众号推荐，底下支撑这些体验的，就是这种embedding模型在默默把每一条内容变成向量，算你和它近不近。
没有它，你搜不到想看的视频，推荐刷不到对味的内容，知识库问什么答什么全是错的。
雨果说过一句话，下水道是一个城市的良心。
我觉得embedding模型就是AI应用的下水道。它不露脸，不发声，没人夸它，但没有它，上面那些光鲜亮丽的大模型应用，全得瘫。
微信这次把这个「下水道」开源出来，不管出于什么目的，我觉得都是件好事。
至少让更多人看到，AI应用真正难的那部分，不在水面上。
我翻完仓库那天晚上，发了条朋友圈，就一句话。
「找得到，比算得准难多了。」
发完之后我盯着这句话看了半天，越看越觉得，这可能是这两年我做AI应用最真的一句心得。
你做过的每一个RAG，每一个推荐系统，每一个搜索引擎，最后卡住你的，永远都是「找得到」。
模型再聪明，找不到该看的东西，也是白搭。
而WeMM-Embedding这种模型，就是在把「找得到」这件事，一点一点往前推。
它不性感，但它重要。
说真的，我挺希望多几个大厂把这种底层的东西开源出来的。比起又一个会聊天的模型，我更想看到更多让AI真正能落地的基础设施。
毕竟，光有会聊天的脑子，没有能找到东西的手，这AI也干不了活儿啊。
/ 注意，本项目仅在 SyncMein 的500人小群分享。
/ 谢谢你看完了我的文章，我们下次再见吧。
/ 作者：明察
/ 投稿或爆料，请联系邮箱：mingcha@gqmg.com
标签：Embedding WeMM 多模态RAG 向量检索 微信开源
– END –
暂无评论内容