企业官网建设流程全解析

多模态检索系统里，新手和老手最大的分歧，往往不在模型选型，而在一个非常基础的问题：你到底应该用稀疏嵌入，还是稠密嵌入？如果只做文本检索，这问题已经被讨论过无数遍；可一旦输入变成了图像、视频、音频、PDF 和表格的混合体，很多人就会默认“多模态嵌入模型既然能生成统一向量，那我只要把稠密向量做好就行”。我在实际项目里见过太多反例：用纯稠密向量做多模态检索，召回来的结果“感觉相关”，但用户最想找的品牌型号、文档编号、合同条款却排在后面。UEmbed（Unified Sparse and Dense Multimodal Embeddings）这个方向之所以值得关注，不是因为它多了一个输出头，而是它把“精确匹配”和“语义匹配”重新放进了同一个 embedding 系统里，让多模态检索从一个“只能用向量猜意图”的黑盒，变成一个“既能理解语义又能指出证据”的协同系统。

1. 先搞清楚多模态检索里“稀疏”和“稠密”到底在争什么

很多人第一次听到“稀疏嵌入”和“稠密嵌入”时，容易把它们理解成同一种东西的两种存储方式。实际上，这两种表示背后是两套完全不同的检索假设：稀疏嵌入强调的是“特定概念或词项是否出现”，稠密嵌入强调的是“语义是否相近”。这两者在文本检索时代就已经是长期争论的焦点，到了多模态场景，又被模型架构和训练方式放大了。

1.1 稠密嵌入：把一切都变成向量，但丢掉了很多精度

稠密嵌入的原理，是用一个固定长度的实数向量表示一段文本、一张图片、一段音频。常见的做法是训练一个编码器，让相似的输入在向量空间里靠近，不相似的输入互相远离。多模态模型之所以受欢迎，核心能力就在于能把图像和文本映射到同一个向量空间，比如给定一张“城市夜景”的图片，它的图像向量会和一段描述“霓虹灯下的街道”的文本向量距离很近。

这种设计擅长处理模糊查询和同义改写。用户说“有没有那种晚上城市灯光的图”，系统能通过向量距离找到接近“城市夜景”的图像，哪怕用户没有使用任何图片标签里的词。

但稠密嵌入也有一个很实际的问题：为了把语义压缩进一个向量，模型必须做信息取舍。模型会把“iPhone 15 Pro Max 256GB 深蓝色”和“最新款苹果手机”在语义上拉近，可如果用户的目标就是要找存档里那台设备的具体型号字符串，稠密向量往往不能给出精确匹配。品牌名、编号、合同条款、产品批次、人名、病毒名称，这些“低语义但高精确度”的信息，恰恰是纯稠密向量最容易丢失的部分。

这还不是最麻烦的。稠密向量一旦生成，就很难被业务规则干预。如果运营想加一条规则——“型号字段必须精确命中”，在稠密向量空间里几乎没法操作，因为向量是模型学出来的黑盒表示，你无法直接告诉它“这个维度代表型号”。

1.2 稀疏嵌入：传统词汇匹配的延续，却很少被用在多模态上

稀疏嵌入的历史比深度学习向量要长得多。经典的 BM25、词袋模型，本质上都是稀疏表示：向量的维度对应词典里的词项，每个文档只激活极少数维度，其他维度都是零。现代一点的稀疏嵌入，类似 SPLADE，会学习每个词项的权重，但仍然保持高维稀疏的结构。

在多模态场景里，稀疏嵌入的处境有些尴尬。文本可以轻松地用 tokenizer 生成词项权重，但图像怎么得到稀疏表示？音频怎么得到稀疏表示？一个更通用的思路是：稀疏嵌入的维度不一定必须对应文本 token，它可以对应“视觉概念”“OCR 识别出的文本”“音频事件标签”“检测出的物体类别”等。比如一张图片，稀疏向量可能激活“夕阳”“海面”“沙滩”“人物剪影”这些概念；一段音频，可能激活“说话人”“翻页声”“环境噪音”等。

这种做法的价值在于，它让“精确证据”有了显式的位置。当用户查询里出现一个准确的地名或人名，系统可以直接在稀疏维度上找到对应权重，而不是在稠密空间里靠距离猜。同时，稀疏表示天然有更好的可解释性，你能看到一条结果是因为哪个概念被命中而来。

但稀疏嵌入的短板也很明显：它很难处理同义改写和跨模态语义。用户说“晚上城市的灯光”，图片稀疏表示里可能只有“夜景”“建筑”“灯光”，但这三个概念不一定同时激活，稀疏匹配就可能漏掉相关结果。

1.3 UEmbed 的核心假设：两者本来就不该互相替代

UEmbed 这个方向最核心的假设，不是“稀疏比稠密好”或“稠密比稀疏强”，而是“单一表示模式根本无法覆盖所有多模态检索意图”。

检索意图从来不是同质的。有些查询是语义模糊的，比如“找一个适合做PPT封面的科技感背景图”，这种时候靠稠密向量；有些查询是精确的，比如“文件名里带 Q3_Report 的 PDF”，这种时候靠稀疏匹配；还有更多查询是两种混合，比如“2023年第三季度科技行业报告”，既包含语义概念“科技行业报告”，也包含精确字段“2023年第三季度”。

如果模型只输出一种表示，就等于逼着用户做选择。UEmbed 的统一之处，不是简单地把两个向量拼接起来，而是在同一个多模态输入上同时学习两个输出头，让它们共享底层语义编码能力，但各自的输出形式保留各自的优势。这个设计假设看起来温和，真正落地时改变了很多系统层面的东西：检索服务不再只能调用一个向量索引，而是可以同时用倒排索引和稠密向量索引；排序阶段也不再用单一距离计算，而是做稀疏分数和稠密分数的融合。

这一点，才是 UEmbed 名字里 “Unified” 的真正含义。

2. 为什么多模态模型生成的嵌入，会同时遇到稀疏和稠密的问题

概念上说清楚稀疏和稠密的区别之后，还需要回答一个问题：为什么多模态场景特别需要“统一”，而不是像文本检索那样，用混合检索在工程层面拼一拼就行？原因在于，多模态输入的语义粒度差异太大了，普通后融合方案很难从根上解决对齐问题。

2.1 图像/音频/文本的语义粒度差异

文本自带离散的语言单元，词、短语、句子之间有清晰的层级。图像不是这样，图像是连续像素，模型需要自己决定“视野”里哪些区域构成一个对象、一个场景、一个属性。音频更特殊，它既包括人说话的语义内容，也包括语气、环境音、背景音乐这些非语义信息。

把这些不同粒度的输入统一编码成同一个稠密向量，本质上是在做非常激进的信息压缩。一个视频片段里可能同时有人物、场景、字幕、对话、背景音乐，稠密向量能表达“这一段大概是在下雨的城市街头”，但很难精确表达“字幕里出现了合同续约日期”或“对话中提到项目编号 PRJ-2025-001”。

更麻烦的是，不同模态的信息精确程度不一样。文本中的专有名词是天然的高精确度信号，图像中的 OCR 文字也接近这种特性，但音频里的专有名词如果没有经过 ASR 转写，可能只是模糊的声音片段。如果模型只输出一个稠密向量，它只能把这些信息“融”在一起，最终结果就是这个向量既不擅长语义理解，也不擅长精确匹配，两头都不占。

所以，多模态系统天然需要两种不同性质的表示：一种负责把语义浓缩，另一种负责把精确证据保留下来。UEmbed 的核心不是发明了新概念，而是把这个天然需求变成了模型输出的一部分。

2.2 常见多模态嵌入模型只输出稠密向量的三个后果

现在的多模态嵌入模型，很多都只输出一个稠密向量。这在很多比赛、榜单上看着够用，真正投到业务里会产生三个容易被低估的后果。

第一个后果是无法做精确字段检索。图像里的 OCR 文字、文档里的页码、音频里的口令词，一旦被压缩进稠密向量，就失去了独立检索的可能。你想做“只匹配文档编号”的约束，根本无从下手。

第二个后果是可解释性差。系统返回“这张图片与查询相关”，但它为什么相关？哪个区域、哪个关键词促使模型给出这个结果？稠密向量给不出答案。对需要回复用户“命中依据”的客服系统、知识库系统、合规审查系统，这几乎是致命的。

第三个后果是在线干预困难。业务里经常会有临时规则，比如“某品牌名必须精确匹配”“某些敏感词不能出现在召回中”。在稠密向量上做这种干预，要么重新训练模型，要么在应用层做硬过滤，两种方式都没法平滑地融合进排序过程。

当只有稠密向量时，这三个问题不是 bug，而是架构天然缺失的能力。UEmbed 这类方案试图用额外输出头补上这一块。

2.3 统一输出的关键不是“再加一个向量”，而是共享语义空间

有人会想，那我让模型同时输出一个稠密向量和一个稀疏向量不就行了？技术上确实可以，但如果两个输出头只是各算各的，最后结果大概率是“稀疏部分像一个文本词表分类器，稠密部分像一个纯视觉编码器”，彼此毫无协同。

真正的关键在于，两个输出头必须共享一个语义空间。什么意思？就是模型对“文本里的猫”和“图像里的猫”要有同一个内部理解，然后在这个基础上，稀疏头决定把“猫”这个概念的权重升高，稠密头决定把整个语义压缩进一个向量。共享空间会让两个头在训练时互相约束：稠密头可以告诉稀疏头“这个词项对这个文档很重要”，稀疏头也可以告诉稠密头“这个维度的证据缺失会导致精确匹配失败”。

这里可以借用最近讨论得比较多的“多模态引导”概念。在一个统一的输出空间里，给定一个查询，模型实际上是在做两件事：第一，识别出哪些输入元素是“语义线索”，比如概念、主题、场景；第二，识别出哪些输入元素是“精确线索”，比如专有名词、编号、OCR 文本。这两种线索合在一起，相当于一个向导，既知道大方向，又能报出具体的门牌号。UEmbed 的稀疏和稠密输出，本质上就是这两种引导信号的具体化。

3. 理解 UEmbed 的架构：一个统一的输出空间，而不是两个独立管道

前面讲了很多理念，这一节落地到架构层面。虽然 UEmbed 没有一个统一的官方开源实现可以照抄，但结合现有技术和这类方案的常见设计，我们可以拆出一个比较清晰的参考结构。

3.1 输入编码器与共享投影层

一个多模态嵌入模型，输入可能是图像、文本、音频、视频帧或者它们的任意组合。第一步通常是进入各自模态的编码器，比如视觉 transformer、文本编码器、音频编码器。这些编码器会输出各自模态的 token 序列或特征序列。

接下来的关键设计是：所有模态的编码结果都要进入一个共享投影层，把不同模态的特征映射到同一个语义空间中。这个投影层的维度就是一个超参数，设得太低，语义容量不够，细节容易丢；设得太高，后面的稀疏头会很难训练，因为概念空间太大，负样本太多。

我见过一些项目在第一步就踩坑：为了省显存，直接把不同模态编码器的输出 concat 一下就送进任务头，中间没有一个真实的共享投影层。这样做的后果是，文本编码器和图像编码器可能各自已经把语义空间学习好了，但两者之间不对齐，后续无论是稀疏头还是稠密头，都得从头学一个“翻译”，效果往往很差。共享投影层虽然听起来只是一个线性层，但它是统一语义空间的物理基础。

3.2 稀疏输出头与稠密输出头如何协同

共享投影层之后，模型分出两个分支。

稠密输出头相对好理解，它把共享向量进一步压缩成一个固定维度向量，比如 1024 维，后续用余弦相似度或内积做语义检索。

稀疏输出头则复杂一些。它的输出维度通常等于“概念词表大小”，这个词表可能是文本词表、视觉概念标签、OCR 字符集、音频事件标签的并集。模型对每个概念输出一个权重，然后通过类似 top-k 激活的方式，只保留权重最大的若干维度，其余都置为零。这样既保证了稀疏性，也让每次检索只需要处理少数活跃维度，计算成本和存储成本都可控。

协同在哪里体现？训练时，稀疏头不能只靠文本监督，还要结合多模态对齐信号。比如一张图片配了一段描述文字，那图片的稀疏输出中，“沙滩”“天空”“海浪”这些概念的权重就应该升高；如果描述文字里有“2024 年夏季旅行”，那 OCR 或文本匹配出来的“2024”也值得提升权重。稠密头则负责优化整段语义的紧凑表示。两者共享同样的底层特征，但各自有自己的预测目标。

推理时，一个输入同时拿到两个输出：稀疏向量用来做倒排召回或精确匹配，稠密向量用来做语义近似召回。两者不是互相替代，而是互补。

3.3 一个最小推理示例

下面给出一个简化到不能再简化的参考结构，便于理解这种设计的数据流。它不是一个真实 API，只是帮助你建立直觉的占位实现。

@dataclass class UEmbedOutput: sparse: Dict[int, float] # concept_id -> weight dense: np.ndarray # 1024-dim dense vector class UEmbedEncoder(nn.Module): def __init__(self, backbone, shared_dim, dense_dim, vocab_size): super().__init__() self.backbone = backbone # 多模态编码器，输出 hidden states self.projection = nn.Linear(hidden_size, shared_dim) self.dense_head = nn.Linear(shared_dim, dense_dim) self.sparse_head = nn.Linear(shared_dim, vocab_size) def forward(self, inputs): hidden = self.backbone(inputs) shared = self.projection(hidden) dense = self.dense_head(shared) sparse_logits = self.sparse_head(shared) sparse = top_k_activation(sparse_logits, k=32) return UEmbedOutput(sparse=sparse, dense=dense)

在检索服务里，可以这样理解它的使用方式：

• 索引端：对每个文档doc，调用编码器得到UEmbedOutput，将dense写入向量索引，将sparse写入倒排索引。
• 查询端：对查询query做同样处理。
• 召回阶段：用稀疏索引做精准匹配召回，得到sparse_hits；用稠密向量索引做 ANN 召回，得到dense_hits。
• 融合排序：合并两个命中集合，按融合分数重排。

一个最简单的融合公式参考：

score = alpha * norm(sparse_score) + beta * norm(dense_score)

这里最关键的一点，是sparse_score和dense_score必须分别做归一化。稀疏分数的分布和稠密距离的分布完全不同，直接相加会让某一个信号主导，另一个失效。alpha和beta不要拍脑袋定，应该在一个小验证集上做网格搜索，找到最适合当前数据分布的比例。

4. 落地时要注意的五个坑

从理解结构到真正上线，中间隔着很多工程细节。这里挑五个最常见的坑展开，每一个都值得在项目启动前想清楚。

4.1 数据标注：没有对齐监督信号，稀疏嵌入就是空壳

稀疏头并不是天生就能学会“哪些概念重要”。如果只是用图文对做对比学习，模型很可能倾向于把高频概念都激活一遍，最后稀疏向量变成稠密向量的粗糙版本，完全没有“精确证据”的能力。

要让稀疏头真正学会输出精确概念，需要细粒度的监督信号。比如：

• 图片对应的描述文本中，哪些词是关键词；
• 图像里是否出现 OCR 文字，内容是什么；
• 音频里是否提到特定的实体、编号或短语；
• 文档中哪些字段具有唯一标识性质。

如果项目里没有这些标注，至少要做一个弱监督版本：用现成的 OCR、ASR、实体抽取工具，先给训练数据打一层“伪精确标签”。这比完全不标注要好得多。但也要意识到，弱监督标签会带入噪声，需要后续人工抽检。

4.2 向量维度和词表设计：稀疏嵌入不是直接把文本 token 搬过来

多模态稀疏嵌入的词表设计是一个容易被低估的问题。如果只把文本词表拿过来用，图像中的“视觉概念”和音频中的“事件标签”就没有对应的索引。模型训练得再好，也无法在这个词表上表达图像内容。

一种常见做法是构造“概念词表”：把文本高频词、视觉概念标签、OCR 字符、音频事件标签合并，并做频率统计。然后根据场景需要，保留高频高价值的概念，同时留一些“罕见词”的回退策略，比如把不常见 token 映射到一个统一的[UNK]，避免词表无限膨胀。

词表太小的后果是，专有名词无法被表达，精确匹配能力直接归零。词表太大的后果是训练难度增加，尤其对稀疏头来说，负样本空间太大，很容易把权重学到高频词上。建议先做一轮词频统计和业务关键词清单，再决定词表规模。

4.3 索引与存储：稀疏和稠密要放在同一个检索服务里

很多团队在技术验证时，会分别用 Elasticsearch 存稀疏倒排索引，用 Faiss 存稠密向量索引，然后业务层各查一次，合并结果。短期实验可以这样做，但长期运行很痛苦。

问题在于，两个索引的文档 ID 必须保持一致，数据的更新流程也要同步。新增一个文档，如果稠密索引写入成功，稀疏索引写入失败，就会出现召回不一致。更麻烦的是，如果某一个索引出了故障，线上会直接降级成单路召回，而业务层还不一定能感知到。

更稳妥的做法是，使用支持混合检索的索引服务，或者自己维护一个统一的文档主数据流，确保同一个doc_id对应的稠密向量和稀疏向量总是一起更新。如果确实用两个独立系统，那就要在文档写入流程里加入事务性补偿机制，以及定期一致性校验。

4.4 融合策略：分数归一化不是简单相加

混合检索最容易被忽视的环节是分数融合。稀疏分数和稠密分数的数值分布通常差异巨大。稀疏分数可能来自倒排索引的 BM25 变体，范围可能是 0 到几十；稠密分数可能是余弦相似度，范围在 -1 到 1 之间。直接把两个分数相加，等于让稀疏分数主导排序。

正确的做法是，先分别对两路分数做归一化。可以用 min-max 归一化，也可以用 softmax 或 rank 归一化，把分数变成同一量纲。然后，在验证集上学习alpha和beta。不要小看这一步，很多项目在模型上花了很多力气，最后排序效果不好，其实就是因为融合权重不对。

另外，如果某个业务场景特别强调精确匹配，可以考虑“稀疏硬约束 + 稠密精排”的组合方式。先要求某些关键字段必须命中，再用稠密分数对已经命中的结果排序。这种策略比单纯的加权融合更可控。

4.5 评估指标：不能只盯 Recall@K

用离线指标评估统一嵌入效果时，会遇到一个有趣的现象：加了稀疏输出之后，Recall@K 可能提升不大，甚至在某些标准数据集上略降。这时候不要急着否定方向，而要追问：我们真正关心的是什么？

正确评估维度应该包括：

• 精确匹配率：查询中包含的专有名词是否被正确召回；
• 首条结果可解释性：用户是否容易判断“为什么推荐这条结果”；
• 人工评估中的“明显不相关比例”；
• 业务侧干预能力的度量，比如能否通过调整某些概念权重，快速改变召回结果。

这些维度在纯稠密模型上往往很难提升，但 UEmbed 这类统一方案可以。所以，评估指标必须和业务价值绑定，不能只依赖单一指标。

5. 从单模态到多模态统一嵌入：一个可复用的调试与排查链路

当你自己实现或调试一个类似 UEmbed 的系统时，很容易陷入“效果不好先调 alpha/beta”的误区。实际上，混合检索效果差，大概率不是最后的融合参数出了错，而是前面某一层已经坏了。下面这条排查链路，可以帮你按顺序定位问题。

5.1 先确认单模态嵌入是否正常

不要一上来就测多模态混合检索。先分别测：

• 文本查询 vs 文本文档，看稀疏头是否命中核心关键词，稠密头是否能召回语义相近文档；
• 图像查询 vs 图像文档，看稠密头是否能召回相似图像，稀疏头是否激活了“场景”“物体”类概念；
• 音频查询 vs 音频文档，如果有音频，看稀疏头是否能召回包含特定词句的片段。

如果单模态内部就不合理，比如一个纯文本查询，稀疏头命中的关键词和查询毫无关系，那问题基本在编码器或训练数据集，而不是融合策略。这时候去调 alpha/beta 是浪费时间。

5.2 再检查跨模态对齐

单模态正常后，再测跨模态。准备一批“文本描述-图像”对，检查：

• 一段描述“沙滩上的日落”，能否在稠密空间找到对应的图像；
• 同一张图像，稀疏头输出的概念标签是否包括“沙滩”“日落”“天空”；
• 如果查询文本包含精确字段，比如“图中有 NO PARKING 标志”，稀疏头是否在图像 OCR 概念上激活。

这一阶段能帮你判断两个输出头是否真的共享了语义空间。如果文本可以匹配，但图像稀疏头总是输出一些不相关的高频概念，说明跨模态对齐训练不足，需要补充更多细粒度对齐样本。

5.3 记录日志与样本分析

建议在检索服务里记录一份详细日志，至少包含：

• 查询 ID；
• 稀疏命中列表及权重；
• 稠密 TopK 列表及相似度；
• 融合分数构成；
• 最终排序结果。

遇到 badcase 时，首先看“两路信号是否都在场”。比如一个查询包含了文档编号，但稀疏命中结果里根本没有这个编号，说明稀疏头没学到精确字段；如果稀疏命中了编号，但稠密 TopK 里全是不相关的文档，说明两个头的排序语义没有对齐。通过日志可以快速区分这两种情况，避免靠猜。

5.4 用一个小步调优的顺序

如果确实需要调优，建议严格按照下面的顺序：

1. 先修编码器和训练数据，确保单模态表示合理；
2. 再修跨模态对齐，确保两个头共享语义空间；
3. 再修索引同步，确保稠密和稀疏索引数据一致；
4. 然后调融合权重和归一化方式；
5. 最后才考虑模型结构改动和资源占用优化。

这个顺序的核心原则是：不要让上层方案替下层问题背锅。很多人把大量时间花在调融合权重上，最后发现根因是跨模态对齐根本没做好。先做小步验证，能省很多事。

6. UEmbed 这类方案真正改变了什么（长期价值与适用边界）

最后，我们把视角拉远一点：UEmbed 这类统一稀疏和稠密多模态嵌入的方案，真正改变的到底是什么？它不只是让检索多了一个可用的分数来源，而是改变了整个多模态检索系统的设计假设。

6.1 它让多模态检索变成可解释、可干预、可组合

纯稠密向量系统最让人头疼的一点，是不可解释性和不可干预性。你无法回答“为什么这条结果排在前面”，也无法在不重训模型的情况下加入一条业务规则。

有了稀疏输出之后，这两件事变得可能。稀疏向量的每个维度对应一个可理解的概念，系统可以展示“这条结果命中了哪些概念和关键词”。业务侧如果想调整规则，比如提高“品牌名”的权重，或者要求某个敏感词必须被过滤，可以直接在稀疏维度上操作。这意味着多模态检索系统从“靠感觉调向量”变成了“能部分用规则管理”。

更重要的是，稀疏和稠密的组合让检索系统可以根据场景重新组织：纯语义场景可以只跑稠密；精确匹配场景可以只跑稀疏；混合场景可以两路融合甚至叠加硬约束。同一个模型，不再需要为每个场景重新训练。

6.2 适合什么场景，不适合什么场景

任何方案都有适用边界。UEmbed 这类统一嵌入方案，在以下场景里价值很明显：

• 多模态知识库检索，文档里包含大量专有名词、编号、表格、图表文字；
• 多模态 RAG，需要为生成模型提供可引用的证据片段；
• 视频/音频内容检索，用户会搜索句子片段、人名、数字；
• 需要合规审计和可解释性的行业应用。

但在另外一些场景，统一嵌入可能不是最优选择。比如纯语义探索式推荐场景，用户没有明确的关键词需求，稀疏信号反而可能引入噪声；再比如对延迟极其敏感、只有几毫秒预算的极简检索架构，同时维护两套索引和两次召回会带来额外成本；又比如训练数据本身就很稀疏、标注质量差的场景，硬做统一训练可能不如先用一个现成的纯稠密模型兜底。

6.3 对普通开发者的建议：不要一上来就重构

如果你现在正在做一个多模态检索项目，UEmbed 听起来很诱人，但我不建议直接推翻现有系统，重头训练一个统一模型。更理性的路径，是先做“伪统一”实验。

具体来说：用现有模型生成稠密向量，再用 OCR、ASR、关键词抽取等工具生成文档的稀疏表示，然后在一个小样本集合上做混合检索。观察之前纯稠密召回解决不了的 badcase 是否有所改善。如果改善明显，说明统一方向值得投入；如果改善不明显，问题可能不在表示类型，而在标注质量或评估指标。

即便决定要做统一训练，也要控制增量。可以先固定共享编码器，只训练稀疏输出头，对比旧稠密系统是否有提升；然后再逐步放开共享层联合微调。这样每一步都有可验证的收益，也方便定位问题。

说到底，UEmbed 这类方案能带来价值的根本原因，不是“稀疏”或“稠密”哪个更正确，而是多模态世界的检索需求足够复杂，单一表示永远不够。一个真正健壮的系统，应该像一个有经验的向导那样，既听得懂你很抽象的描述，也能准确找到你要的那个具体门牌号。而统一嵌入，正好是给系统同时装上这两种能力的第一步。