多模态嵌入模型一直被一个很不起眼的瓶颈死死卡着：一个 token 能携带的信息实在太少了。当你试图把图像、文本、甚至视频压缩进一个向量时，就像要求一个人用一口气说完一整本小说——能传达个大概，细节基本全丢。而 UEmbed 这帮人干了一件特别狠的事：他们直接让一个解码器模型在单次前向传播中，同时吐出稀疏词级表示和稠密向量。不是做两次推理，也不是接两个不同的模型头，就是一次跑通，你想要的稀疏和稠密都有了。而且稀疏模式精度接近稠密，还天然兼容倒排索引。这意味着，那些长期靠双模型架构过日子的多模态搜索系统，可能要重新算账了。
单 token 过顶，多模态模型集体忍了一件事
解码器的天然包袱
如果你在搜索引擎团队待过，就知道自回归解码器用在嵌入任务上有多拧巴。标准做法是把模型最后的隐状态或者某个聚合 token 直接当作内容表征，整条序列被压缩成一个固定维度的向量。这做法粗暴有效，但对信息密度极高的多模态输入简直是灾难。一条图文混排的电商描述，一帧包含人脸、文字、街道的监控画面，全得塞进一个点。信息瓶颈不是某个模型的短板，而是整个技术路线的结构性缺陷。单 token 信息瓶颈这个问题，大厂工程团队早就心知肚明，只不过多数人选择打补丁——把输入切碎、分块编码、再融合，工作量暴涨不说，检索延迟也跟着往上窜。
多模态叠加，成本不是加法是乘法
到了多模态场景，事情更麻烦。文本可以走稀疏的 BM25 或稠密向量，图像一般只能走稠密，音频又得单独处理。于是很多系统被迫上了双模型甚至三模型架构：一个专门搞稠密，一个专门搞稀疏，然后融合分数。调度开销、模型维护、显存占用，每一项都是实打实的工程债务。更荒诞的是，有时稀疏检索召回的候选集质量已经很高，但因为和稠密打分不在同一个语义空间，融合时反而拖累最终的排序精度。大家不是不知道统一模型好，而是此前没人证明，一个解码器就能把两份活都干到及格线以上。
稀疏和稠密，被强行拆散的兄弟
我见过不少论文试图调和稀疏与稠密表征。有的先算稠密再映射到词汇表做稀疏，有的反过来用稀疏监督稠密训练。但所有方案都绕不开一个底层尴尬：现有模型的输出头就是为好做的，token 级预测和全局表征需要不同的归纳偏置。UEmbed 的想法则相当直接——别将就了，把词汇表拆开。他们重新设计了可学习的特殊 token 和词汇表分区，让模型在前向传播时一次性输出两种类型的信息。这思路很像硬件里的多路复用，一条物理信道跑多路逻辑信号。单 forward 落地，工程上立刻省掉一半以上的推理时间。
一次前向传播，两份产出，凭什么
特殊 token 不是噱头
UEmbed 的模型里插入了若干可学习的特殊 token，这些 token 不是传统意义上的文本标记，而是专门用来激活稀疏和稠密两种生成路径的“开关”。推理时，特殊 token 触发模型在对应的分区上进行预测，一部分输出变成词表上的 logits，对应稀疏词级表示；另一部分输出则转化成稠密向量。同一个解码器，同一套因果注意力，没有任何额外分支网络。可学习特殊 token在这里起的作用，和以往那些“CLS token 解决一切”的思路有本质差别——它不是全局信息的收纳箱，而是路径控制指令。这让表征的生成可控、可解释，且训练时能分别优化两条路径的损失。
把词汇表切成两块，粗暴但有效
突破单 token 信息量限制的另一个关键，是词汇表分区。研究团队把整个词汇表按功能划分，一块负责稠密语义空间的投影，另一块负责稀疏词级表示。两部分共享底层特征，但在输出端被严格隔开。这种隔离不是形而上的概念，而是直接影响训练目标：稀疏端被带去向量的稀疏性约束和倒排索引友好性优化，稠密端则走标准的对比学习或匹配损失。这样一来，模型不必费劲在一个单一输出空间里兼顾不可兼得的特性，稀疏那头的词级表示甚至显式对应到实际单词，直接用现有分词器就能还原成可检索的词元序列。这对倒排索引简直是份大礼。
因果前向传播下的共享与分离
还有一个细节值得花笔墨：UEmbed 坚守因果前向传播，没有动用双向自注意力。这意味着它在训练时就能天然模拟推理时的状态，做检索系统的朋友很清楚这价值——生成式检索通常要求自回归，双向编码器再强也得额外改造。共享的底层 Transformer 层在因果掩码下提取多模态特征，当信号走到最后几层，两条路径才开始分化。这个设计让稀疏和稠密表示共享大部分计算，却保留了各自不同的归纳偏置。实验结果显示，稀疏模式的召回率在多个多模态基准上只比稠密差不到两个点，某些长尾查询上甚至反超。而你要知道，这个稀疏模式是可以直接入库建倒排索引的。
搜索系统的技术账本，该重算了
扔掉一套模型，省下的不只是显存
工业界部署多模态检索系统，一直存在一个不成文的共识：稀疏和稠密必须各走各的路。BM25 或学习型稀疏检索负责第一轮粗筛，稠密模型再对 Top-K 做精细排序。两套模型意味着两套特征管线、两套索引存储、两套在线服务。UEmbed 给出的答案是一次推理就完成，显存和算力瞬间砍半。对日请求量过亿的系统，这差值折算成 GPU 电费，数字非常可观。更重要的是延迟。实时交互场景里，每一毫秒都值钱，一个统一模型少了调度和网络开销，P99 延迟能降一大截。
倒排索引不是上世纪的遗产
大模型时代，倒排索引差点被当成落后产能。但现实是，倒排索引的可解释性、更新效率和运维成本远远优于纯稠密向量检索。UEmbed 的稀疏词级表示直接输出可索引的词元，不需要做近邻图或 HNSW 索引，也不需要为每个新文档重算聚类。搜索团队可以直接沿用 Lucene 生态，甚至把稀疏表示和现有的 BM25 权重混合起来，老系统无缝升级。这种兼容性是很多炫技模型做不到的——它们产出的稀疏权重是黑箱，没法映射到具体词。UEmbed 的稀疏 token 直接可读，运维、调试、干预都方便很多。
精度和效率的新平衡点
通常我们会默认，稀疏检索精度总是低于稠密。但这项工作的数据显示，两者的差距并非不可抹平。当稀疏表示来自同一个深度解码器，并且用专门的分区训练时，它已经不再是传统意义上的统计稀疏，而是带有全局语义的稀疏。换句话说，模型学会了在有限词元里塞入更多上下文信息。对于团队来说，这提供了一种全新的架构选项：你完全可以只保留稀疏索引作为主检索通路，在召回能力足够的情况下把稠密全去掉，进一步简化系统。那些对成本敏感，又无法牺牲检索质量的中小团队，可能会是第一批受益者。重新算过技术账之后，双模型方案看起来突然没那么香了。
