简介：多模态 Embedding 正从“图文双塔分离”走向“统一 Transformer 深融”，并出现多向量、原生宽高比等新机制。本文从定义、核心原理、典型场景、选型注意事项等角度系统拆解这一技术演进，帮助开发者建立面向 2025 年及以后的模型选型与落地判断框架。文中不绑定特定厂商，只讨论通用技术能力与行业常见方案。
多模态 Embedding 是一种将不同类型输入，例如文本、图片、视频、音频、表格、界面截图、PDF 页面等，映射到统一向量空间的技术。它的核心目标是：让语义相近的内容，即使来自不同模态，也能在向量空间中距离更近；语义无关的内容则距离更远。
从使用视角看，多模态 Embedding 主要解决一个问题：如何让机器像人一样，同时阅读文字、观察图像、理解视频，而不是把不同模态当成彼此孤立的数据。
从技术视角看，多模态 Embedding 经历了两个明显阶段：
双塔分离式 Embedding
文本走文本编码器，图片走图片编码器，各自生成向量，再通过对比学习拉近语义相近的图文对。这种方式结构简单、检索效率高，但文本与图像之间缺乏细粒度交互，容易出现“模态鸿沟”。
统一 Transformer 深融式 Embedding
不再分别为文本和图像设计完全独立的编码路径，而是将图像切片为视觉 Token，与文本 Token 一起送入同一个 Transformer 模型。文本与图像在模型内部进行深层次注意力交互，最终形成更贴近真实语义的联合表示。
因此，当前语境下的多模态 Embedding，不只是“把图片转成向量”，而是更接近于“构建一个能够理解图文关系、页面结构、视觉细节与文本语义的联合编码系统”。
早期多模态 Embedding 主要服务于图文检索，例如“输入一句话，找出一张最匹配的图片”。这类任务对理解深度的要求相对有限，模型只需要判断大方向是否一致，例如图片里是否有人、是否是户外场景、是否有车。
但随着企业知识库、智能客服、文档问答、合同解析、UI 自动化、视频内容分析等场景兴起，传统粗粒度图文匹配已经不够用了。典型难点包括：
这些场景要求 Embedding 模型不仅“看得到”，还要“读得懂”。统一 Transformer 架构的价值正在于此：它允许模型在文本 Token 与视觉 Token 之间进行连续、多次、双向的注意力计算，从而理解“图中的红色曲线”与“Q3 销售额下滑”之间的对应关系。
另一个重要背景是，企业侧的数据越来越多地以非结构化形式存在，尤其是扫描件、截图、演示文稿、视频会议记录、产品界面等。传统做法是先用 OCR 抽取文字，再对文字建立索引，但 OCR 会丢失版式、颜色、空间关系、图形含义等信息。多模态 Embedding 可以在不依赖单一 OCR 结果的情况下，直接对页面图像进行编码，为后续检索和问答提供更完整的语义基础。
因此，多模态 Embedding 的价值可以归纳为三点：
统一 Transformer 路线的第一步，是将图像切分为若干 Patch，并将每个 Patch 映射为视觉 Token。视觉 Token 与文本 Token 在表示层面被对齐后，输入同一个 Transformer。
例如，一张文档截图不再是“一个整体图片向量”，而是变成一组按空间位置排列的 Token 序列。模型可以在这组 Token 中关注表格区域、标题区域、图例区域或签名区域。
这种设计使得模型具备类似“阅读图片”的能力：不是被动地提取整体特征，而是主动地在图像内部进行注意力分配。
传统双塔模型中，文本编码器只处理文本，图像编码器只处理图像，二者在最后才做相似度计算。统一架构则不同，文本 Token 和视觉 Token 会进入同一层 Transformer，进行联合自注意力计算。
这样做的直观结果是：当模型看到“异常增长”这个词时，它可以在图像 Token 中主动寻找曲线陡峭上升的区域；当模型看到表格中的某个数值时，它也可以反向关注问题中的相应条件。
这种细粒度交互，是统一 Transformer 相较传统双塔模型的本质差异之一，也是其在复杂文档理解任务中表现更好的关键原因。
受文本检索中延迟交互机制的启发，近年视觉检索中出现了一类重要变化：不再把一张图片压缩为单个向量，而是保留多个 Patch 向量，例如 128 到 768 个向量，每个向量对应一个图像区块。
查询时，文本 Token 会与这些 Patch 向量逐一计算相似度，常用方式是 MaxSim，即对于每个查询 Token，找到最相似的 Patch，再聚合得分。这样可以在保留细粒度匹配能力的同时，避免把所有信息压缩进单一向量带来的信息损失。
多向量表示在视觉文档检索中具有显著优势，尤其适用于页面布局复杂、信息分散的 PDF 或截图场景。
传统的图像 Embedding 通常会先将图片缩放到固定尺寸，例如 224×224，以便输入视觉编码器。但这种做法会带来一个问题：长条形图片、宽表格或高分辨率截图可能因为强行缩放而丢失细节。
当前一些视觉编码器开始支持更灵活的输入尺寸策略，例如使用原生宽高比或自适应切块方式。其核心目标是尽可能保留图像原始结构，让 Embedding 更真实地反映图片内容。
这类能力对于发票、合同扫描件、产品长图、宽幅报表等场景尤其重要。
我们可以将多模态 Embedding 的典型工作流程拆解为以下步骤：
输入标准化
读取文本、图片、视频帧或 PDF 页面。对于图片，可根据任务需要保留原始宽高比，或按规则切分为多个子块。
编码阶段
文本被转换为文本 Token；图像被切分为 Patch 并映射为视觉 Token。两类 Token 输入统一 Transformer，经过多层注意力计算后，得到上下文相关的表示。
表示生成阶段
根据任务不同，可以生成：
相似度计算阶段
以检索任务为例，查询内容经过编码后，与候选集中的 Embedding 进行相似度计算。单向量通常使用余弦相似度；多向量则使用 MaxSim、求和近似或其他延迟交互方式。
结果排序与召回
根据相似度得分排序，返回最相关文档、页面、截图或视频片段。
在这个过程中，统一 Transformer 架构的优点是明显的：文本和视觉信息在早期就发生交互，而不是到最后才进行粗粒度比较。
这是多向量 Embedding 最典型的应用之一。企业中存在大量 PDF、扫描合同、票据、制度文件、产品手册等。用户希望用自然语言快速找到相关页面，而不是逐页翻阅。
例如，用户提问：“哪一页说明了违约金计算方式？”系统需要在大量页面图像中，找到同时包含“违约金”文字和相应表格或条款的页面。传统全文检索可能只匹配文字，而视觉文档检索还能利用版式、位置和表格结构进行判断。
在多模态知识库中，答案可能藏在图表、流程截图、组织架构图或演示文稿中。Embedding 模型需要理解“这张图讲的是审批流程”以及“流程中的某个节点对应某个部门”。
统一 Transformer 和多向量机制可以提升召回质量，从而减少后续生成模型“无中生有”的风险。
在智能体操作界面、自动化测试、用户行为分析等场景中，模型需要理解按钮含义、输入框用途、弹窗提示关系等。多模态 Embedding 可以帮助系统判断“当前页面是否出现登录失败提示”“是否存在未填写的必填项”等。
相比传统截图分类或纯文本解析，多模态 Embedding 能同时利用图标、颜色、位置和文字信息，更适合复杂界面。
视频可以拆解为关键帧序列。通过对关键帧进行多模态 Embedding，可以支持“找到出现白板讲解但没出现标题的那一段”这类细粒度查询。多向量表示尤其适合在长视频中捕捉一闪而过的细节。
在内容安全、合规审核、广告检查等场景中，需要同时判断图片中的文字、图像内容和上下文语境。例如，一段文字本身没有违规，但配图构成暗示，传统单模态审核可能漏掉。多模态 Embedding 可以联合编码图文内容，提高审核准确性。
CLIP 式模型属于双塔分离结构，优点是训练和检索效率较高，缺点是对图文细粒度关系理解不足。多模态 Embedding 的新趋势是统一 Transformer，文本和图像在编码过程中深度交互，理解能力更强，但计算成本通常也更高。
单向量 Embedding 把整张图片或整段文本压缩为一个向量，适合大规模快速召回；多向量 Embedding 保留多个子表示，检索更准，但存储和计算开销更大。实际系统中常见做法是“多向量精排 + 单向量粗排”或“多向量召回 + 近似索引”。
传统做法是先 OCR 抽取文字，再对文字做 Embedding。这种方式会丢失版面、颜色、线条、空间关系和图像语义。视觉 Embedding 直接编码页面图像，可以保留更多信息，但模型更复杂，部署成本也更高。两者并非互斥，实际系统中可以融合。
Embedding 模型的目标是表示和检索，不直接生成自然语言。多模态生成模型则用于看图说话、视觉问答、图像生成等。二者可以组合：先用 Embedding 召回相关页面或片段，再交给生成模型作答。
如果任务是简单图文匹配、商品图搜索或粗粒度视频分类，传统双塔模型可能已经够用，且部署成本更低。如果任务涉及复杂 PDF、UI 截图、细粒度视频检索或强图文关系理解，则应优先考虑统一 Transformer 或多向量方案。
多向量 Embedding 在精度上通常更有优势，但会给向量数据库、内存、索引构建和查询延迟带来压力。选型前应评估：
必要时可以采用分层检索：先用轻量单向量召回，再用多向量精排。
对于长图、宽表、多栏 PDF，固定尺寸缩放可能导致信息丢失。选型时应关注模型是否支持原生宽高比、动态切块或自适应分辨率。如果模型不支持，可以在预处理阶段自行切块，但要注意避免语义割裂。
统一 Transformer 模型通常比双塔模型更大，推理耗时也更高。在云端部署时，需要评估 GPU 或加速推理资源的可用性。如果采用切片、多向量等策略，还要考虑请求并发和批处理能力。
企业文档、合同、用户界面截图等通常包含敏感信息。使用云上 Embedding 服务时，需要关注数据加密、访问控制、日志留存和合规要求。建议在企业内部或可信环境中部署模型，避免将敏感原始数据直接暴露到不可控外部服务。
多模态 Embedding 的评估需要结合具体业务。例如，在文档检索中，应关注页面级召回率、P@1、MRR 等；在 UI 理解中，应关注任务成功率；在视频检索中，应关注片段定位误差。单一的公开数据集分数不能完全代表其在企业真实场景的表现。
Embedding 模型与生成模型应当尽量解耦。这样可以在不改变生成模型的情况下，单独升级或替换 Embedding 方案；也可以在 Embedding 召回结果不理想时，针对性地优化索引与精排策略，降低整体系统风险。
多模态 Embedding 的本质，已经从“将不同模态分别编码到同一空间”演进为“让文本与图像在统一模型中进行深度语义交互”。这一变化带来三个直接结果：复杂文档可读、细粒度关系可解、多向量检索更准。
但更强的理解能力也意味着更高的计算成本、存储压力和部署复杂度。开发者在选型时，不能只关注模型是否“最新”或“更准”，而要回到具体业务问题：任务是否需要细粒度图文理解，数据是否包含复杂版式与表格，查询负载是否允许引入多向量索引，部署环境是否具备足够推理能力。
只有把技术能力与场景约束放在一起评估，才能真正发挥多模态 Embedding 的价值。它不是一个单纯的模型升级，而是一整套从表示、索引、召回到应用设计的系统工程。理解这一点，是做好技术选型的前提。