腾讯开源 WeMM-Embedding：一个模型把文字、图片、视频塞进同一向量空间，Agent 记忆的地基要换了

你上周刚把 RAG 跑起来，用的还是纯文本 embedding。现在有人告诉你：你搜的那些"图片里的信息"、“视频里的内容”，其实根本进不了你的向量库——因为它们和文字不在同一个语义空间里。你以为是"检索不够准"，其实是地基没打通。

微信视觉团队这周开源的 WeMM-Embedding，干的就是把这件事打通：文本、图片、视频、图文交错文档，全部塞进同一个向量空间。听起来像论文里的概念？不，权重、代码、评测全开源，pip install 就能跑，而且 2B 一个小模型，越级打平了别人 8B 的大模型。

今天不吹"榜单第一"这种新闻稿角度，聊三件程序员真用得上的事：为什么 embedding 是 Agent 记忆的地基、2B 凭什么能打赢 8B、以及 Matryoshka 维度裁剪怎么让你省 90% 的存储和检索成本。

先搞明白：多模态 embedding 到底解决了什么"老问题"

你天天用的 RAG 是这样跑的：把文档切成 chunk → 每个 chunk 过 embedding 模型变成向量 → 存进向量库。查询时把问题也变成向量，按相似度召回。

这套流程有个很隐蔽的天花板：如果你用的还是单模态文本 embedding，那图片、视频、截图里的信息，全都得先被 OCR、ASR、caption 转成文字，才能进向量库。

问题就出在"转"这一步。

每一次把非文本信息"转成文字"，都是一次信息衰减：表格结构没了、UI 层级没了、视频里的动作序列也没了。

而 WeMM-Embedding 这种多模态模型，做法完全不同——图片直接编码成图片的向量，视频直接编码成视频的向量，和文字向量放在同一个空间里直接比相似度。没有中间的"转译"，信息不衰减。

这还不是最关键的。真正让它在 2026 年值得写的，是它把 Agent 记忆这个场景也卷进来了。

为什么说 embedding 是 Agent 记忆的地基

上周那篇 harness 拆解里，我们讲到 Agent 的五个模块，其中"记忆"是很多人忽略的一块。现在很多 Agent 框架吹"长记忆"，但落地时你会发现：记忆的本质就是检索——Agent 要把历史对话、工具调用结果、你喂给它的文档，在需要的时候"想起来"。

“想起来"靠什么？靠 embedding 把历史内容变成向量，按当前问题的相关性召回。embedding 就是 Agent 记忆检索的底层物理层。

而这个底层，过去是纯文本的。Agent 记住的只能是文字。现在 WeMM-Embedding 直接把这条路打通到多模态——Agent 可以把一张截图、一段录屏、一份图文混排的 PDF 都变成可检索的记忆。

这不是我脑补的，是数据说话：在 MMEB-v3 的 47 项 agent 任务上，WeMM-Embedding-9B 拿了 51.0 分，断层领先所有对比模型——排第二的 Qwen3-VL-Embedding-8B 只有 38.4，4B 版本也有 49.0。在多模态 agent 场景，它是目前开源的明显第一梯队。

反常识的地方：2B 凭什么越级打赢 8B

数字要先摆出来，因为这是整篇最有冲击力、也最值得追问的一点：

MMEB-v2 上（78 项任务），WeMM-Embedding-2B 平均 77.9，直接超过了 Qwen3-VL-Embedding-8B 的 77.8。 一个 2B 的模型，在综合任务上打平甚至略胜 8B 的对手。4B 是 79.2，9B 是 80.6 登顶总榜。

按直觉，参数翻 4 倍，效果应该明显更好才对。2B 凭什么？ 这才是比"榜单第一"更值得写的地方，答案是三个词：架构红利、两阶段训练、数据协议。

第一，底座选得好。 WeMM-Embedding 基于原生多模态的 Qwen3.5 架构，天然支持任意图文交错输入，用因果注意力掩码。对比老一代双塔 CLIP 架构——文本塔和视觉塔是分开的，跨模态信息在中间断掉了——Qwen3.5 这种原生多模态底座，输入直接就是统一的多模态 token 流，信息从头到尾都在一条通道里流动。

第二，两阶段训练。 先做大规模多模态对齐（数亿级配对数据，对比学习目标），再做精修阶段（细粒度相关性监督 + 跨尺度知识迁移）。不是把模型喂大，而是把"怎么比相似度"这件事训练到极致。

第三，统一 Pair 协议。 团队把分类、图文检索、视频定位、问答推理……全都抽象成"源实例 vs 目标候选"的相关性度量。一个协议统一了所有任务，训练数据可以跨任务共享、互相增强。

这三条加在一起，才让 2B 能越级。这说明 embedding 这个赛道，也从"堆参数量"卷到了"拼架构和训练方法论”。 对做工程的人来说，这是个明确信号：选型的时候，别再唯参数量论。

最值钱的部分：Matryoshka 维度裁剪，让成本降 90%

技术含金量说完，落到"明天能用"的层面。WeMM-Embedding 全系支持 Matryoshka 维度裁剪——同一个模型，输出维度可以从 64 维一路到 2048/4096 维自由选。

官方给的模型维度档位很直白：

• 2B：64 / 128 / 256 / 512 / 1024 / 2048
• 4B：64 / 128 / 256 / 512 / 1024 / 2560
• 9B：64 / 128 / 256 / 512 / 1024 / 2048 / 4096

维度意味着什么？向量维度直接决定存储和检索成本——一个 4096 维的向量，占用和计算量是 256 维的 16 倍。传统做法是"选完模型就定死维度"，Matryoshka 让你在同一个模型里、同一套向量库上，按场景自由切换精度和成本。

官方给了一个能直接拿来算账的数字：2B 模型在 256 维输出下，保留全维度图像与视频检索性能的 98.7%——用 1/8 的维度，几乎不掉效果。

向量维度决定你向量库的存储和检索成本。Matryoshka 让你用 1/8 的维度，换 98.7% 的效果——成本砍下来，精度几乎不掉。

举个具体的：假设你原来用 2048 维存 1000 万条向量，换成 256 维，存储占用直接除以 8，检索的浮点计算量也除以 8。对个人开发者或者小团队的自建 RAG 来说，这是实打实的成本差异，不是概念。

而且部署生态是开箱即用的——transformers、sentence-transformers、vLLM、SGLang 全都支持。vLLM 0.27.0、SGLang 0.5.9 官方测过，一条命令就能起服务。也就是说，“多模态 RAG"从"论文里的概念"变成了"今天就能 pip install 跑起来的东西”。

账得算全：它不是万能的

坦诚说几个限制，免得你部署了才踩坑。

第一，不支持音频。 官方明确说了"Audio input is not currently supported"——音频在 MMEB-v3 里是 0 分。所以如果你要搜的是语音内容，这条不适用。

第二，它很重。 即便 2B，也是个多模态大模型，跑起来要 GPU。跟 BGE-M3 这种几百 MB 的轻量文本模型比，部署成本不是一个量级。它解决的是多模态检索问题，如果你的场景纯文本，用轻量文本模型更划算。

第三，榜单数据是厂商自报。 MMEB 榜单上的 80.6、59.5 都是官方报告的数字，是否复现、在你自己数据上好不好用，得自己跑一遍。这也是所有 embedding 模型的老问题——榜单第一 ≠ 你的业务最优。

但即使有这些限制，WeMM-Embedding 的意义很明确：它把多模态 embedding 从"专有 API"拉到了"开源可部署"，而且用一个小模型证明了这个方向的价值。

明天就能试的那件事

想验证"多模态检索"到底有没有用，不用搭完整系统，用一条命令就够了。

打开你的 Hugging Face，把 tencent/WeMM-Embedding-2B 换成你代码里现在的文本 embedding 模型，用 sentence-transformers 跑一次：

1
2
3
4
5

from sentence_transformers import SentenceTransformer
model = SentenceTransformer("tencent/WeMM-Embedding-2B", trust_remote_code=True)
text_emb = model.encode("一条含图片链接的商品描述")
img_emb = model.encode("图片文件路径", dimension=256)   # Matryoshka 裁剪到 256 维
sim = model.similarity(text_emb, img_emb)               # 文本和图片直接比相似度

把你手头那个"一直搜不准"的 RAG 场景——比如商品库（图文混排）、截图笔记、带视频的文档——拿一张真实图片和一个真实问题试一次召回。如果它确实找回了纯文本方案找不到的东西，你就知道自己的应用该不该升级多模态检索了。

Embedding 是这个行业里最"隐形"的一层：没人天天提它，但所有搜索、推荐、Agent 记忆都踩在它上面。微信把它开源，等于把 Agent 记忆地基的"下一层"也交了出来——该不该换，试一次就知道。