这项研究由阿里巴巴集团、中国科学院自动化研究所及中国科学院大学、耶鲁大学联合完成，论文编号为 arXiv:2608.02583，发布于 2026 年 8 月 4 日。有兴趣深入了解技术细节的读者可通过该编号在 arXiv 平台查阅完整原文。

当你在搜索引擎里敲下 " 北京最好吃的火锅 "，背后发生的事情远比你以为的复杂。搜索系统需要在几毫秒内，从数以亿计的网页里找出最相关的结果。这个过程依赖两种截然不同的 " 查找方式 "，而这篇论文做的事情，就是把这两种方式塞进同一个模型里，还顺手把文字之外的图片、视频也一并处理了。

在正式进入故事之前，有必要先解释一下这两种查找方式究竟是什么。把它们想成图书馆的两种找书方法：第一种是 " 稀疏检索 "，类似于传统的索引卡片柜，你按关键词找，词能对上就能找到，对不上就一无所获——这种方法快且精准，但一旦你用 " 汽车 " 搜索，它不认识 " 轿车 "；第二种是 " 稠密检索 "，类似于一位博学的图书管理员，他理解语义，知道 " 汽车 " 和 " 轿车 " 是一回事，但他工作起来更慢，而且没法直接告诉你他是怎么想的。现有的系统要么只用一种方法，要么需要两套独立的系统分别运行。

这项研究的主角—— UEmbed（统一嵌入模型）——就像是把这两位图书馆员合并成了一个人，让他既能快速翻卡片柜，又能深度理解语义，而且还能看懂图片和视频内容。更关键的是，这个 " 合体图书员 " 只需要过一遍材料，就能同时给出两种检索所需的信息，不用跑两趟。

一、为什么现有方案总是 " 顾此失彼 "

要理解 UEmbed 的价值，得先看清楚现有方案卡在哪里。

传统的稀疏检索方法，以 BM25 为代表，本质上就是统计词频——你的查询词在文档里出现几次、出现在什么位置，决定了相关性得分。这个方法极其高效，数十年来在工业界大量部署，但它的致命弱点是不懂语义。" 一张白纸 " 和 " 空白页面 " 在它眼里是两码事，尽管意思完全一样。

为了弥补这个缺陷，研究者们发展出了 " 学习型稀疏检索 "（Learned Sparse Retrieval，LSR），其中 SPLADE 系列模型最具代表性。这类方法用神经网络来赋予词汇权重，不仅能重新分配已有词的权重，还能 " 扩展 " 出原文没有的相关词汇——比如看到 " 笔记本电脑 "，它能自动联想到 "laptop"、" 电脑 " 等词一并编入索引。这大幅提升了稀疏检索的语义理解能力。

然而，SPLADE 这类方法有一个根深蒂固的架构限制：它们依赖双向注意力机制（就是 BERT 那类能看前后文的模型）。近年来最强大的大语言模型—— GPT、Llama、Qwen 等——都是 " 解码器 -only" 架构，也就是单向的，每个词只能看到它前面的词，看不到后面的。这种单向性带来了极大的效率优势和强大的生成能力，但也使得直接套用 SPLADE 的方法行不通。

之所以行不通，是因为 SPLADE 的做法是把所有词的隐藏状态都投影到词汇空间，然后取最大值作为每个词的权重。这个操作在双向模型里天然合理——每个位置都看过全文。但在单向模型里，靠前的词只看到了前面的内容，信息是残缺的，用它来代表全文显然不妥。

过去也有人尝试解决这个问题，但方案都不够优雅：要么把单向模型改造成双向的，损失了单向架构的部署优势；要么设计复杂的两阶段训练课程，增加了额外成本。多模态方面更是几乎空白——现有的多模态稀疏检索方法通常要加一个专门处理图片的辅助模块，结构复杂，扩展性差。

正是这三重困境——架构限制、模态局限、实用性未被充分探索——催生了 UEmbed 的诞生。

二、分切词汇表：一个看似简单却极为巧妙的解法

UEmbed 的核心创新，可以用一个烹饪学校的比喻来理解。

假设一所烹饪学校有一本厚厚的食材百科全书，收录了 20 万种食材。学校只有一位大厨，他的任务是读完一份菜谱后，从这本百科全书里标注出所有相关食材。问题是，20 万个词条太多了，一个人根本记不住全部，更别说同时给所有词条打分了。

UEmbed 的解法是：不派一位大厨，而是派 16 位助理厨师，每人只负责大约 1.25 万种食材（20 万 ÷ 16）。每位助理读完整份菜谱，然后在自己负责的那部分食材里打分。最后把 16 位助理的结果拼在一起，就是完整的评分向量。

这个比喻对应的技术方案如下：在输入序列的末尾，附加 16 个专门设计的 " 特殊令牌 "（可以理解为 16 位助理的身份牌）。由于是单向模型，这 16 个令牌排在所有内容之后，因此每个令牌都能 " 看到 " 它前面的全部内容，也就是完整的输入。然后，词汇表被划分为 16 个互不重叠的子集，每个特殊令牌负责一个子集，预测其中每个词的权重。16 个子集的结果拼接起来，形成完整的稀疏向量。

这个设计巧妙地绕开了单向架构的信息瓶颈。在传统方法里，用单个 EOS（序列结束）标记去投影整个词汇表，就像让那唯一的大厨独自搞定 20 万份评分，信息压缩率太高、表达能力有限。而分散到 16 个令牌后，每个令牌只需要专注于约 1.25 万个词，任务轻松多了，也更能专注。

词汇表的划分方式同样经过精心设计。研究团队没有随机分配，而是用 K-means 聚类算法把词汇按语义相似性分组——意思相近的词被分到同一个子集里。这样，每个特殊令牌就成了某个语义方向上的 " 软性专家 "，比如一个令牌专门负责与运动相关的词汇，另一个专门负责科技相关词汇。实验证明，这种语义聚类的分法优于随机分配和刻意最大化距离的分法。

在正式训练之前，研究团队还对词汇表做了一步压缩处理。现代大语言模型的词汇表往往存在大量 " 近亲词 " ——比如 "Hello"、"HELLO"、"h é ll ò " 在语义上完全一致，却占据不同位置。通过去重音符号、统一小写、折叠空白字符等标准化操作，词汇表从 24.8 万个条目压缩到 18.4 万个。评分时，同一组词只保留最高权重，既节省了空间，也避免了权重分散。

稠密检索的部分则更为简洁：直接取那个位于 16 个特殊令牌之前的 EOS 令牌的隐藏状态，作为代表整段内容的稠密向量。当用户只需要稠密检索时，16 个特殊令牌完全可以省去，没有任何额外计算开销。两种检索模式共用同一次前向计算，一次推理，两份结果。

三、训练这个 " 全能选手 " 需要哪些原料

理解了架构之后，再来看看训练过程——因为一个好的设计需要好的训练数据和合适的优化目标才能真正发挥作用。

训练数据来自三个公开数据集的混合。文本数据方面，使用了 Echo-Embedding 训练数据（覆盖广泛领域的查询 - 文档对）和 MLDR 训练数据（专注于长文档检索）；多模态数据方面，使用了 MMEB 训练集，涵盖图像分类、视觉问答、图文检索、视频理解、视觉文档检索等多种任务。最终混合比例大致是：文本 39.3%、图像 27.1%、视频 21.4%、视觉文档 12.2%，总计 394 万条样本。

训练目标由四个部分组成。稠密检索的对比学习损失（用余弦相似度衡量查询和正样本的相似性，并拉开与负样本的距离）、稀疏检索的对比学习损失（用内积衡量稀疏向量的相似性）、对查询稀疏向量的 FLOPS 正则化（鼓励稀疏性，减少非零激活）、对文档稀疏向量的 FLOPS 正则化。这四个目标通过可调权重平衡，其中稀疏和稠密的对比损失权重设为相等。

负样本的质量对稀疏检索的训练至关重要——如果只用随机负样本，模型很容易 " 躺平 "，学不到精细区分的能力。研究团队用 Qwen3-VL-Embedding-8B 作为教师模型，对每个查询从语料库里检索出最相似但并不相关的文档作为 " 困难负样本 "，迫使模型真正学会辨别细微差异。

训练的稳定性是一个实际挑战，因为稀疏向量的内积范围远大于稠密向量的余弦相似度（后者被限制在 -1 到 1 之间）。研究团队发现，混入文本训练数据能显著加速和稳定多模态稀疏模型的收敛——仅用图像和视频数据训练时，模型需要约 500 步才能开始稳定区分正负样本；加入文本数据后，这个过程在 100 步内就能完成。

在超参数方面，稀疏检索使用了比稠密检索大得多的温度值（τ s=32，稠密为 0.03）。这是因为稀疏内积的数值范围很大，如果用同一个温度，会导致 softmax 过于尖锐，训练不稳定。实验证明，解耦两个温度并给稀疏端用更大的值，能显著提升稀疏检索性能，同时不影响稠密端。特殊令牌的数量设为 16，实验显示这是性能和计算开销之间的最佳平衡点——增加到 32 时性能反而下降，因为每个子集太小，序列也变得更长。

研究团队在 16 到 32 张 A100 GPU 上训练了 2B、4B、9B 三个规模的模型，基座模型使用 Qwen3.5 系列，参数只通过 LoRA 方式微调（只训练注意力和 MLP 投影层），视觉编码器冻结不动。

四、跑分结果：在多模态排行榜上的表现

说了这么多原理，到底效果如何？研究团队在两个主要评测平台上进行了测试。

第一个是 MMEB-v2，这是目前最全面的多模态嵌入评测基准，包含 78 个子数据集，覆盖图像分类、视觉问答、图文检索、视频理解、视觉文档检索等几乎所有重要场景。

在这个平台上，UEmbed-9B 的稠密检索得到 71.8 分，稀疏检索得到 71.0 分——两者相差不到 1 分，这是最令人印象深刻的结果之一，因为此前几乎没有模型在多模态场景下同时跑过稀疏检索。对比已知的公开数据训练模型，UEmbed-9B（稠密）超越了 RzenEmbed-V2-7B（71.1 分）和 Ops-MM-Embed-7B（67.1 分）。更有趣的是，UEmbed-2B（稠密，66.5 分）甚至超过了一些 7B 规模的开源基线，比如 UniME-7B（64.1 分）——小身材发挥出了超越体量的性能。

唯一在总分上更高的是 Qwen3-VL-Embedding-8B（77.8 分），但研究团队在论文中明确指出，该模型经过了大规模私有数据的多阶段训练，本质上不是同一赛道的比较。通过进一步的错误分析，团队发现 UEmbed 落后的主要场景在于细粒度视觉识别（如 ImageNet-A、SUN397）、视频中的动作识别和长视频推理、以及多语言视觉文档。这些差距大多源于训练数据的覆盖不足，而非架构本身的限制。

从各大类别的分布看，UEmbed 的稀疏模型在视觉文档（VisDoc）任务上与稠密模型几乎持平（9B 模型：稀疏 79.1 vs 稠密 79.2），这与稀疏检索天然擅长处理结构化、关键词密集型文档的直觉吻合。相比之下，在视频类别上稀疏模型相对稠密模型的差距略大，这也符合预期——视频帧里几乎没有可以精确匹配的词汇信息，稀疏检索的优势难以发挥。

第二个测试平台是 BEIR，这是文本检索领域最主流的基准，研究团队选取了其中 9 个代表性数据集进行评测，使用 nDCG@10（排名靠前的结果质量综合指标）衡量。

在稠密检索端，UEmbed-9B 以 56.3 分的均值领先，超过了 Qwen3-VL-Embedding-8B（55.5 分）和 GME-7B（53.5 分）。在稀疏检索端，UEmbed-9B 以 55.2 分与 Echo-Mistral-SPLADE（55.2 分）持平——而后者是专门为稀疏检索设计的专用模型，UEmbed 在同时支持稠密、稀疏、多模态的前提下达到了相同水平，这意味着通用性的代价几乎为零。

五、实用价值：三个让这个研究走出实验室的场景

评测数据之外，研究团队还专门探索了 UEmbed 在三个实际场景中的价值，这也是这项工作相对于纯学术研究更有落地意义的部分。

第一个场景是 " 混合评分 " ——把稠密和稀疏的结果线性加权合并，看能否进一步提升效果。结果显示，在文本检索和视觉文档检索上，混合评分分别提升了 0.3 分和 0.5 分；对图像和视频类型则提升幅度微乎其微。这个模式与常识吻合：文字密集的内容（比如一篇论文或一份表格）既有关键词可以精确匹配，又有语义关系需要理解，两种检索各自贡献了互补的信息；而一张风景照或一段舞蹈视频，词汇层面几乎没什么可抓的，稀疏向量自然贡献有限。混合评分最大的优势是零额外成本——因为两个向量来自同一次推理。

第二个场景是部署效率。UEmbed 的架构保留了纯自回归特性，这意味着它可以直接接入 vLLM 等高吞吐量推理框架，充分利用已有的优化基础设施。与此同时，生成的稀疏向量可以直接对接 Lucene 等倒排索引系统，不需要任何转换或适配。研究团队做了一个粗略的对比实验，展示了稀疏检索在不同激活词数量上的速度 - 效果权衡曲线：减少每个查询的激活词数量（从 512 减到 64），检索延迟从约 100 毫秒降到约 20 毫秒，而 NDCG@5 从约 0.14 降到约 0.02。这个权衡曲线让工程师可以根据实际场景灵活调整，在响应速度和检索质量之间找到最合适的平衡点。

第三个场景最为有趣：智能体搜索。当大语言模型作为智能助手反复调用搜索工具来完成复杂任务时，它通常会发出短而关键词密集的查询——这恰恰是稀疏检索最擅长的领域。研究团队用 BrowseComp-Plus 基准测试了这个场景，这个基准模拟的是一个大语言模型智能体通过多轮搜索来回答复杂问题的过程，用 DeepResearch-30A3B 作为推理引擎。

结果显示，稀疏模式下的 UEmbed，在每个问题平均需要的搜索轮次上始终少于稠密模式。以 9B 模型为例，稠密模式平均需要 33.68 轮搜索，稀疏模式只需 31.05 轮，在最终准确率相同的情况下减少了约 8% 的工具调用次数。在成本敏感的生产环境里，每次 API 调用都有成本，减少搜索轮次意味着实际的金钱节省。这个结果也验证了一个反直觉的观点：并不是 " 更聪明的 " 稠密检索在所有场景下都更好，关键词驱动的查询配上稀疏检索，效率反而更高。

六、消融实验：每个设计选择都经过了验证

任何严谨的研究都需要回答一个问题：你说这些设计有用，是真的有用，还是看起来有用？UEmbed 的研究团队通过一系列对照实验来回答这个问题。

关于联合训练是否会导致两个模式相互拖累：实验结果是否定的。单独只训练稠密检索的模型，和联合训练后的稠密端，在 MMEB-v1 上几乎得分一致（64.6 vs 64.5）；稀疏端同样如此（63.0 vs 63.4）。两种模式在同一个模型里共存，基本没有互相 " 拖后腿 " 的现象。

关于使用单向模型是否真的比双向 SPLADE 更好：研究团队用完全相同的 Qwen3.5 基座、相同训练数据、相同 FLOPS 正则化，只是把注意力换成双向的并用标准 SPLADE 的 max-pooling 头，得到一个对照组。UEmbed-2B 在稠密端比这个对照高 3.2 分，稀疏端高 2.1 分。差距最显著的是图像问答类任务（稠密高 8.2 分，稀疏高 6.0 分），说明保留自回归模型天然的问答推理能力，对多模态嵌入是真实有益的，而不仅仅是带来了部署上的便利。

关于词汇分区策略：随机分配（63.0 分）、最大距离聚类（63.2 分）、语义聚类（63.4 分），语义聚类最优。差距虽然不大，但方向一致：让每个特殊令牌专门负责一组语义相关的词汇，比随机打散效果更好。

七、局限性与这个模型还不擅长什么

研究团队在论文里直接承认了三个主要局限，这种坦诚本身也值得注意。

第一是语言偏向问题。训练数据以英文和中文为主，导致稀疏头激活的词汇也以这两种语言为主。在多语言检索场景里，比如要检索日语、阿拉伯语或斯瓦希里语文档，稀疏表示的泛化能力明显不足。要真正实现多语言稀疏检索，需要更均衡的多语言训练数据。

第二是词汇表中的 " 异常令牌 " 问题。现代大语言模型的词汇表规模巨大（原始词汇表约 24.8 万条），其中包含大量非标准子词，比如 "_alt"、" ) a" 这类在人类看来毫无意义的分词碎片。压缩之后仍有 18.4 万条，这些边缘词汇有时会在稀疏激活中出现，影响了稀疏表示的可解释性。未来可能需要更激进的词汇剪枝或专门的过滤机制。

第三是视频类任务上的相对弱势。视频内容信息密度高、时序动态复杂，直接把多帧视觉信息压缩成一个平坦的稀疏向量，可能存在容量瓶颈。当前训练数据中视频比例也相对较少，导致视频类任务上稀疏模型与稠密模型的差距比文本和图像场景都要大一些。

归根结底，UEmbed 做到的是：在不牺牲任何单一能力的前提下，把多种能力集成到一个模型里，并在实际应用中证明了这种集成的意义。它没有声称在所有任务上都是最佳，但它提供了一种架构思路——稀疏检索可以从专用的双向编码器里解放出来，成为任何自回归多模态大模型的 " 天然副产品 "。

对于普通用户而言，这类技术进步最终会体现在搜索引擎返回结果更精准、AI 助手回答问题更高效、视觉文档检索更智能这些具体体验上。当然，从论文到产品落地还有相当长的路要走，但方向已经清晰了一大步。如果你对这些技术细节感兴趣，可以通过 arXiv 编号 2608.02583 查阅完整论文。

Q&A

Q1：UEmbed 的稀疏检索和传统 BM25 有什么本质区别？

A：BM25 依赖词频统计，只认识字面相同的词；UEmbed 的稀疏检索通过神经网络学习词汇权重，能自动扩展语义相关词汇，比如看到 " 汽车 " 也能关联 " 轿车 "，同时还能处理图片、视频等非文字内容，而 BM25 只能处理文本。

Q2：UEmbed 的分词汇表设计为什么选择 16 个特殊令牌而不是更多？

A：实验显示，特殊令牌数量在 16 时性能最佳。增加到 32 时效果反而下降，原因是每个令牌负责的词汇子集变得太小，且训练时序列变长增加了对比学习的难度。16 是性能与计算开销之间的实测最优平衡点。

Q3：UEmbed 在智能体搜索场景中为什么稀疏检索轮次比稠密检索少？

A：智能体在完成复杂任务时倾向于发出关键词密集的短查询，这类查询天然适合稀疏检索的精确词汇匹配机制。稀疏检索能更直接地命中相关文档，减少了需要反复搜索才能找到答案的情况，从而降低了总搜索轮次。