多模态Embedding评测：架构演进与选型维度拆解

一、评测概述：评什么、给谁看

本文的评测对象是多模态Embedding模型及其配套检索方案，覆盖当前主流的三代技术形态：以“视觉编码器+文本编码器”为代表的传统双塔对比架构，以原生多模态大模型为骨干的统一向量架构，以及受文本晚交互检索启发的多向量视觉检索方案。评测要回答的核心问题是一个工程问题：在当前技术条件下，多模态检索系统应该如何做能力评估与选型。

适合阅读本文的读者包括：正在搭建多模态RAG、以图搜图、视觉文档检索、内容推荐召回系统的开发者；需要评估模型升级收益与迁移成本的架构师；以及需要在效果、性能、成本与可维护性之间做权衡的技术负责人和企业技术团队。

需要先说明的是，本文不试图给出“某个模型最好”的绝对结论。多模态Embedding的选型高度依赖业务场景：文档密集型团队与电商图像团队的最优解可能完全不同；存储预算充裕与受限的团队，面对多向量方案的判断也可能相反。评测的价值在于建立一套可复现、可解释、可落地的验证框架，让选型决策建立在证据而不是直觉之上。

二、评测背景：为什么选型思路必须变

在2024年之前，多模态检索的标准答案是图文对比学习方案：视觉侧使用视觉Transformer类编码器，文本侧使用双向文本编码器，训练时拉近匹配图文对在向量空间中的距离，推理时计算余弦相似度。这个架构统治了以图搜图、图文召回等场景多年，至今仍是许多生产系统的可用基线。

但它存在两个结构性缺陷。第一，模态鸿沟：两种模态在训练和表示上是相互隔离的，向量空间中只能完成粗粒度的语义对齐，很难理解“图表中的红色曲线”与文本中“Q3销售额下滑”之间的对应关系。第二，信息压缩损失：一张图片无论多复杂，都被压缩成一个固定长度的向量，表格、公式、UI布局这类结构化视觉信息在压缩过程中大量丢失。

随着新一代原生多模态大模型的崛起，Embedding模型正在经历一场从“独立特征提取器”向“统一视觉语言大脑”的进化。2025年出现的统一多模态向量模型（下文称方案A类）将图片切片映射为视觉Token，与文本Token混合后输入同一个大模型Transformer进行深度自注意力交互，模型开始像阅读文字一样“阅读”图片：能看懂PDF里的复杂表格、理解UI界面上的按钮含义、捕捉视频中一闪而过的细节。与此同时，视觉晚交互方案（下文称方案B类）不再把一张图压成一个向量，而是保留128~768个图块级多向量，在视觉文档检索上表现出无需OCR、直接把PDF页面当图片搜索的能力。

架构形态变了，评测思路必须跟着变。如果继续沿用“只看整体召回率”的老办法，会同时犯两类错误：低估统一架构在细粒度语义理解上的价值，也忽视多向量方案带来的存储与算力成本。这正是本文系统拆解评测框架的原因。

三、评测对象说明：三代技术形态与能力边界

3.1 传统双塔对比架构：沿用多年的基线

• 结构：视觉编码器与文本编码器各自独立工作，图片生成向量A，文本生成向量B，检索时计算余弦相似度，打分逻辑可概括为 score(q, d) = cos(E_text(q), E_vision(d))。
• 优势：结构简单、推理开销低、索引体积小，图向量可离线批量生成，非常适合大规模在线检索。
• 局限：模态隔离训练导致“模态鸿沟”；整图压缩为单向量，细粒度信息丢失；对表格、公式、UI等复杂版式的理解能力弱。
• 评测中的角色：作为所有对比实验的基线，任何新架构的收益都必须“相对基线”来度量。

3.2 统一VLM骨干架构：从“翻译图片”到“阅读图片”

• 结构：图片被切片并映射为“视觉Token”，直接与“文本Token”混合，输入同一个Transformer大模型中进行深度自注意力交互，最终产出统一表示。
• 核心价值：模型能真正“理解”图文关系。例如它能明白“图表中的红色曲线”对应文本里的“Q3销售额下滑”，这是传统双塔架构在原理上难以做到的。
• 评测要点：细粒度语义对齐能力、对指令式查询的支持程度、模型体积带来的推理成本，以及长文本与高分辨率输入下的表现衰减情况。

3.3 视觉晚交互：多向量与MaxSim机制

• 原理：受文本检索领域晚交互范式的启发，不再把一张图压缩成一个向量，而是保留128~768个多向量，每个向量对应图片的一个图块。查询时，文本Token与这几百个图块向量逐一计算相似度并取最大值后聚合，打分逻辑可概括为 score(q, d) = Σᵢ maxⱼ sim(qᵢ, dⱼ)。
• 杀手级应用：视觉文档检索。它不需要OCR，直接把PDF页面当图片检索，能命中复杂表格、数学公式和特殊排版——这些恰恰是“OCR+文本检索”传统管线的重灾区。
• 代价：索引体积和查询计算量显著上升，存储与算力开销必须作为独立评测项，而不是附带说明。

3.4 新一代纯视觉编码路线：Sigmoid损失与原生宽高比

• Sigmoid损失：业界头部研究机构推动的新一代对比式视觉语言预训练，采用对每个图文对独立做二元判断的Sigmoid损失，而非批内全局softmax对比，训练过程对批量规模更鲁棒，已成为纯视觉编码的重要标杆路线。
• 原生宽高比：引入自适应机制支持原生宽高比输入。以前为了凑齐固定的正方形分辨率（例如224×224这类常用规格），必须把长条形的商品图、海报压扁，导致特征丢失；现在可以原样输入，保留全部细节。
• 评测要点：极端宽高比下的特征保留度、批量推理吞吐、与下游检索链路的衔接成本。

四、评测维度设计：把“好不好”拆成可验证的指标

评测型文章最忌讳只写“性能好、效果佳”。下表是本文建议的评测框架，随后逐条展开每个维度“为什么重要、怎么测、结果怎么解读”。

评测维度	核心问题	典型验证方法
功能完整性	支持哪些模态与输入形态	多类型样本覆盖测试
检索有效性	细粒度语义是否真的更好	分桶Recall@K、MRR对比
性能表现	时延、吞吐、索引体积	压测与资源监控
稳定性	异常输入下的容错表现	边界样本与异常注入
易用性	接入与调试成本	POC走查与人工计时
兼容性	与现有链路的适配程度	端到端集成验证
安全性	数据隔离与访问控制	权限与审计检查
可观测与可维护性	问题定位与升级成本	日志指标核查、版本演练
成本结构	长期使用的总成本	推理/存储/迁移成本建模

1. 功能完整性。 多模态Embedding的能力差异首先体现在输入形态覆盖上：纯图片、长条图、PDF页面、表格截图、UI截图、视频帧是否都能处理？评测时应按输入类型建立样本清单，逐一验证编码是否成功、输出向量是否稳定，并记录每种形态的限制条件（如最大分辨率、最大页数、帧数上限）。功能缺失不是“扣分项”而是“排除项”——如果业务以PDF检索为主，不支持文档页输入的方案可以直接出局。

2. 检索有效性。 不要只看整体平均召回率，必须按查询类型和文档类型分桶统计：整体查询（“一张海滩日落照片”）与细粒度查询（“图表中红色曲线对应的季度”）应分开报告；表格页、公式页、UI截图也应单独成桶。可以重点观察：方案A类在细粒度桶上是否有一致提升、方案B类在文档页桶上是否明显优于基线。分桶结果的差异往往比平均值更能揭示架构的真实价值。

3. 性能表现。 需要拆成四个可观察指标：向量化时延（编码一张图/一段文本耗时）、批量吞吐（单位时间可处理的文档量）、索引体积（每百万文档占用存储）、查询时延（含MaxSim多向量计算的开销）。特别注意方案B类的索引膨胀可能是单向量方案的数十倍量级，评测时必须记录“每文档平均向量数”和“每向量维度”两个基础参数，让成本可推算。

4. 稳定性。 构造边界样本：极端宽高比图片、超长PDF、模糊图、含大量文字的密集版式、损坏文件。观察行为是报错、截断还是静默降级，并将异常行为是否可控、是否可感知作为评分依据。稳定的静默降级优于偶发报错，可感知的报错优于静默出错。

5. 易用性。 从发起评测到跑通第一条检索链路的人工耗时、接口设计是否统一（图与文是否同一套编码入口）、文档与示例的完备程度、调试时能否方便地查看中间结果（如切片数量、向量维度）。易用性差异在POC阶段影响不大，但会直接决定团队后续的迭代速度。

6. 兼容性。 重点验证与现有向量数据库、检索服务、OCR管线的适配：输出维度是否需要重建索引、多向量方案是否有对应的存储与检索引擎支持、是否需要改造现有召回链路。兼容性成本经常被低估，它往往是迁移决策的真正瓶颈。

7. 安全性。 检查身份认证、权限控制、数据隔离、传输加密与日志审计能力。对数据敏感的业务，还应评估是否支持私有化部署形态，以及部署后的资源门槛。

8. 可观测性与可维护性。 关注调用日志、延迟与错误指标是否齐备，版本升级时向量语义是否变化（很多模型升级后需要全量重建索引，这是一笔必须提前测算的隐性成本）。

9. 成本结构。 分为推理成本（编码算力）、存储成本（索引体积，多向量方案尤其突出）、迁移成本（重建索引与链路改造）和运维成本（监控、扩容、故障处理）。建议用“每百万文档的总拥有成本”做统一口径的横向估算。

五、评测环境与前提条件

评测结论的可信度取决于环境是否受控。测试前应明确并固定以下条件：

• 硬件与推理配置：统一的计算资源配置、推理框架版本、批处理大小、量化策略（是否启用及精度）；
• 输入策略：图片分辨率处理方式（缩放/裁剪/原生宽高比）、文本最大长度与截断规则；
• 检索参数：统一的topK设置、相似度度量方式、索引构建参数；
• 数据准备：评测集建议覆盖图文对、文档页、表格截图、UI截图、视频片段五大类，每类数百到上千条，并人工标注“查询—相关文档”对；
• 基线设定：至少包含传统双塔方案与经典关键词检索算法两条基线，便于分层归因；
• 变量控制：同一批数据、同一索引参数、同一并发模型下运行所有候选方案，避免环境差异污染结论。

六、评测方法与流程

推荐按“先功能、再效果、后工程”的顺序执行六步流程：

1. 明确评测问题：先写下本次评测要回答的3~5个具体问题（例如“细粒度查询召回是否提升30%以上”“索引体积是否在预算内”），避免指标堆砌却无法指导决策；
2. 构建评测集：按业务真实分布采样，覆盖典型与长尾样本，并对标注质量做双人抽检；
3. 建立基线：在相同条件下完整跑通基线方案并记录全部指标；
4. 分维度验证：依次执行功能覆盖测试、有效性对比、性能压测、异常注入测试与集成验证；
5. 记录过程数据：保存每次请求的响应、时延、错误码、资源占用与异常样本，形成可回溯的原始记录；
6. 分析结果边界：明确每条结论适用的数据分布与负载条件，不外推。

以下是一份通用评测流程的示意伪代码（非真实接口，仅说明逻辑）：

# 多模态Embedding通用评测流程（示意代码）
candidates = [dual_tower_baseline, unified_vlm, late_interaction, vision_encoder]
eval_set   = load_cases(["图文对", "PDF页面", "表格截图", "UI截图", "视频片段"])
for model in candidates:
    index = build_index(model, eval_set.docs)        # 单向量或多向量索引
    for query, ground_truth in eval_set.queries:
        result = search(index, model.encode(query), top_k=10)
        log(
            recall_at_k(result, ground_truth),       # 分桶统计
            mrr(result, ground_truth),
            encode_latency, query_latency,
            index_size, vectors_per_doc,             # 多向量方案关键参数
            error_behavior                            # 异常输入处理方式
        )
report = compare_with_baseline(results, baseline="双塔方案")

七、结果解读：什么样的结果支撑什么样的判断

• 细粒度查询显著提升、通用查询基本持平：说明统一架构的价值集中在语义理解，可优先用于复杂文档与专业领域检索，而不是全量替换现有图文召回；
• 多向量方案文档检索召回更好，但索引体积大幅上升：这一组合结果不能简单判优，需要代入业务的存储预算与查询时延目标做条件化判断——文档密集、更新频率低的场景更容易接受；
• 原生宽高比支持在长条图上表现更稳：说明特征保留能力更强，对电商商品图、海报类业务是直接相关的能力项；
• 端到端时延上升：应先定位瓶颈来源（模型体积、分辨率策略、多向量MaxSim计算、网络链路），再决定是通过量化、批处理优化还是降低输入分辨率来缓解，而不是直接否定方案；
• 平均指标接近但分桶差异大：应相信分桶结果。平均分会掩盖“表格页全崩、普通图很好”这类对特定业务致命的短板。

八、适用场景分析与选型决策矩阵

业务场景	更适配的架构形态	优先验证的指标	关键注意事项
通用图文检索、推荐召回	双塔或统一单向量方案	Recall@K、查询时延、索引体积	关注细粒度查询是否退化
视觉文档检索（PDF/表格/公式/排版）	多向量晚交互方案	文档页分桶召回率、查询时延、索引膨胀比	免OCR是核心优势，存储与算力需专项评估
UI截图、界面元素理解	统一VLM骨干方案	按钮/布局语义对齐表现、高分辨率输入支持	确认分辨率策略与切片粒度
长条形图像（商品图、海报）	支持原生宽高比的编码方案	极端宽高比下的细节召回	避免强制缩放导致特征丢失
视频片段检索	统一多模态方案+时序采样	关键帧捕捉能力、帧采样密度与成本平衡	采样策略本身是重要变量，需单独调优
大规模低延迟在线服务	单向量方案+量化压缩	QPS、长尾时延、索引内存占用	多向量方案需重新评估资源预算
数据敏感、需私有化部署	可私有化的统一或双塔方案	部署资源占用、数据隔离与审计能力	评估模型体积与推理硬件门槛

九、风险与限制

评测过程中需要警惕以下几类系统性偏差：

• 评测集偏差：若评测集与模型训练数据分布接近，会系统性高估能力；应尽量使用业务真实数据补充公开测试集；
• 环境差异：硬件型号、批处理大小、分辨率策略都会影响结论，跨环境比较时必须声明条件；
• 成本低估：多向量方案的存储膨胀是长期成本，POC阶段的小规模数据无法暴露，需按目标规模外推估算；
• 协议不固定：统一架构类模型对输入指令、提示词较敏感，评测协议不固定会导致结果不可复现；
• 时效性：该领域迭代极快，任何评测结论都有明确的时效边界，建议建立季度级复评机制；
• 视频评测的特殊性：帧采样密度、切片策略本身就是超参数，不同设置下的结论不可直接比较。

十、选型与使用建议

基于上述评测逻辑，给出几条中立的工程建议：

1. 先定场景，再定架构：从业务输入形态（文档为主还是图片为主）和查询粒度出发反推架构形态，而不是追逐最新的模型类型；
2. 用自有数据做小规模POC：公开榜单只能证明“能力下限”，业务数据才能证明“匹配度”，POC规模建议覆盖至少三类核心输入形态；
3. 灰度与A/B验证：新旧方案并行双跑，用在线点击、转化等业务信号做最终裁决，离线指标只做初筛；
4. 考虑混合检索：关键词检索与向量检索多路召回、再融合排序，在多数场景下比单路方案更稳健；
5. 把迁移成本写进决策：向量维度变化意味着全量重建索引，版本升级策略与重建窗口必须提前规划；
6. 合理利用云上能力：如果团队倾向于托管而非自建，可以关注百度智能云等平台提供的模型服务、向量检索、对象存储等通用能力类别，并将其纳入同一套评测框架用自有数据验证，而不是默认可用即适用。

十一、总结

多模态Embedding正在从“把图片翻译成一个向量”的双塔时代，走向“像阅读文字一样阅读图片”的统一视觉语言时代，并衍生出多向量晚交互、原生宽高比编码等技术路线。对技术团队而言，选型的关键不再是“哪个模型更强”，而是：用分桶指标验证细粒度理解的真实收益，用索引体积与查询时延核算多向量的工程代价，用异常样本检验稳定性，用自有数据的POC与灰度实验收敛最终决策。本文提供的评测维度、测试流程与选型决策矩阵，可直接作为团队构建评测方案的骨架；所有结论都应结合自身数据分布、资源预算与长期维护成本重新验证——这既是评测的边界，也是评测的价值所在。