NeoMME 发布：多模态检索不必再“各看各的”

H Company 于近日发布 NeoMME，试图用一个多模态原生、多语言编码器，统一处理文本、图片以及图文组合输入。按照官方在 Hugging Face 发布页 给出的定位，NeoMME 面向的不是聊天或内容生成，而是搜索、匹配、聚类和 RAG 召回：它把不同语言、不同模态的内容映射到可比较的向量空间，再交给向量数据库完成近邻检索。

NeoMME 是一个面向多模态与多语言检索的原生编码器。 这里的“原生”比“支持图片”更重要，因为它意味着模型不是先让视觉编码器看图、文本编码器读字，最后再把两个结果机械拼起来，而是尽可能在编码阶段理解图片与文字之间的联合语义。

截至 2026 年 9 月 3 日，NeoMME 最值得关注的并不是又多了一个 embedding 模型，而是它把多模态检索的竞争重点从“图片和文本能否对齐”，继续推向“图文组合能否被当成一个完整对象理解”。对于商品搜索、视觉文档 RAG、截图检索和跨语言知识库，这个变化有实际价值；对于纯文本 FAQ 或英文单语搜索，它则未必比成熟文本编码器更划算。

NeoMME 解决的不是看图，而是图文联合检索

多模态检索是利用文本、图片等不同类型输入查找相关内容的信息检索方式。 一个典型请求可能是“找出与这张设备故障照片相似、并且发生在低温环境下的维修记录”，其中照片提供故障外观，文字补充环境条件；任何一部分被忽略，召回结果都会偏离用户意图。

传统跨模态方案通常采用双塔架构。图片进入视觉塔，文字进入文本塔，两边各自产生向量，再通过对比学习把相关图文拉近。这种设计成就了 CLIP 一类模型，优势是吞吐高、索引简单，而且文档向量可以离线计算；问题是两座塔在编码时基本“各看各的”，细粒度的图文关系往往只能在最终向量空间里间接体现。

联合编码是让图片与文字在生成检索表示之前发生交互的编码方式。 如果一张图是红色运动鞋，旁边文字写着“仅展示旧款鞋底，新款已改为耐磨橡胶”，后期拼接方案容易被醒目的视觉信息带偏；联合编码器则有机会理解文字是在修正、限定甚至否定图片中的部分内容。

NeoMME 的核心卖点正是这种联合处理能力。查询可以只有文字，也可以包含图片和文字；待检索对象同样可以是文本、图片或图文组合。模型的目标不是分别回答“图里有什么”和“文字说了什么”，而是为完整输入生成适合相似度计算的语义表示。

这一路线与 2025 年以来兴起的联合融合编码思路一致。相关研究已经指出，早期跨模态交互在需要真正融合图文信息的任务上，通常比单纯的图搜文、文搜图更有优势。NeoMME 的产品意义，在于尝试把这一研究方向变成可直接接入检索系统的编码器，而不是要求开发者调用一个生成式多模态大模型，逐条产出冗长描述后再做文本检索。

“多语言”不是附赠功能

多语言编码器是把不同语言的相同或相近语义映射到统一向量空间的模型。 理想情况下，用户用中文输入“仪表盘出现电池警告”，系统也能召回英文维修手册里的“battery warning indicator”、法语工单以及没有中文标注的故障截图。

NeoMME 把多语言与多模态放在同一个模型目标里，这比先做机器翻译、再做视觉检索少了一层误差传递。翻译模型可能把产品型号、缩写、品牌词和界面按钮翻错，多模态编码器则可以同时利用原始文字与视觉上下文判断语义，特别适合跨境电商、全球企业知识库和多语言客服资料。

多语言能力也不能只看“支持多少种语言”。真正影响检索质量的是低资源语言是否被充分训练、同一概念的跨语言距离是否稳定，以及文字出现在图片内部时能否被正确利用。英语、中文、西班牙语上的平均分不错，并不等于泰语界面截图、阿拉伯语商品海报或中英混排 PDF 也能保持同样表现。

NeoMME 的现实价值取决于跨语言与跨模态能力能否同时成立。 如果模型只能做好纯文本跨语言检索，成熟的多语言 embedding 模型已经足够；如果它只能做好英文图文匹配，CLIP、SigLIP 及大量视觉检索模型也有更成熟的生态。NeoMME 真正需要证明的是：用户拿着一种语言描述、一张图片和若干限定条件，仍能从另一种语言的图文语料中找出正确结果。

它和 CLIP、ColPali 以及文本 embedding 有什么区别

NeoMME 的竞争对手并不是单一模型，而是三类不同的检索技术路线。 第一类是 CLIP、SigLIP 式双塔模型，第二类是 ColPali 一类视觉文档多向量检索器，第三类是 BGE-M3 等多语言文本编码器配合 OCR 的工程组合。

| 路线或模型 | 主要输入 | 表示方式 | 多语言能力 | 图文联合理解 | 索引与部署特点 | |---|---|---|---|---|---| | NeoMME | 文本、图片、图文组合 | 统一检索表示 | 官方定位为多语言 | 核心设计目标 | 强调效率，但实际吞吐与显存仍需按硬件实测 | | CLIP / SigLIP 类 | 图片或文本 | 双塔单向量 | 取决于具体 checkpoint | 较弱，通常分别编码 | 速度快、生态成熟、适合大规模图文对齐 | | ColPali 类 | 页面图片与文本查询 | 多向量、token 级匹配 | 取决于语言模型底座 | 擅长页面视觉布局 | 精度潜力高，但向量数量和存储成本更高 | | BGE-M3 等文本编码器 | 文本 | 稠密、稀疏或多向量 | 通常较强 | 不直接理解原始图片 | 需先做 OCR、版面解析和切块，工程链条较长 | | Llama 3.2 NeMo Retriever Multimodal | 页面图片与查询 | 2,048 维 embedding | 依赖模型训练覆盖 | 面向视觉文档检索 | 约 16 亿参数，适合表格、图表和页面截图 |

CLIP 类模型依然是高吞吐图片搜索的基准方案。若任务只是“用一句文字找相似照片”，双塔模型足够简单，也更容易把数亿张图片离线编码后放入向量数据库。NeoMME 的优势场景不是替代所有 CLIP 部署，而是处理输入本身就由多个模态共同构成的复杂查询。

ColPali 类模型则代表另一种取舍。它们把 PDF 页面当作图片处理，并保留多个 token 级向量，让查询词与页面局部区域进行细粒度匹配，因此特别擅长表格、图表、排版和扫描件；代价是每个页面需要保存的不再是一个向量，而是一组向量，索引体积、内存占用和检索计算量都会增加。

纯文本 embedding 加 OCR 仍然是最稳妥的企业方案。它可以保留关键词倒排、字段过滤、权限标签和可解释文本片段，出现问题时也容易排查。但 OCR 会丢失图标、颜色、空间关系和图表趋势，复杂页面还需要版面分析、表格识别与阅读顺序恢复，任何一环出错都会污染后续召回。

NeoMME 更像是单向量效率与联合理解能力之间的一次折中。 它希望保留向量检索可扩展、可离线建库的特点，同时减少双塔模型在图文交互上的信息损失。这个方向是对的，但“高效”必须落实到每秒编码量、首批延迟、峰值显存和索引体积，而不能只用模型参数量或单项 benchmark 下结论。

单向量为什么仍然重要

单向量检索是每个查询或文档只使用一个固定长度向量参与近邻搜索的方案。 它牺牲了一部分 token 级细节，却能直接兼容 HNSW、IVF、PQ 等成熟近似最近邻索引，是目前最容易扩展到千万乃至亿级语料的工程路径。

向量维度会直接转化为存储账单。以 1,000 万条数据为例，如果每条保存一个 1,024 维 FP32 向量，裸向量数据约为 40.96 GB；如果是 2,048 维，则约为 81.92 GB。这还没有计算 HNSW 图结构、元数据、副本、删除标记与缓存占用，实际集群容量通常会明显更高。

多向量方案的成本增长更快。假设一个页面保存 128 个、每个 128 维的 FP16 向量，仅向量本体就是 32 KB；1,000 万页约需 320 GB，尚未包含索引开销。若 NeoMME 能用一个紧凑表示保留足够多的图文联合语义，它在大规模生产环境中的价值可能比 benchmark 上多出的几个百分点更大。

模型侧的高效不等于系统侧的高效。 一张 2,000×3,000 像素的扫描页需要缩放或切片，长文本需要截断，图片解码和预处理也会占用 CPU；如果输入端持续发送高分辨率图片，视觉编码成本仍可能成为瓶颈。因此，评估 NeoMME 时至少应同时记录图片分辨率、文本长度、batch size、向量维度、GPU 型号和数值精度。

NeoMME 最适合哪些场景

NeoMME 最适合查询或文档天然包含图片与文字，而且语料跨越多种语言的检索任务。 这类场景过去往往需要视觉模型、OCR、翻译模型和文本 embedding 串成一条链路，维护成本高，也很难判断错误究竟来自哪一层。

可以优先考虑的场景包括：

• 跨境电商搜索： 用户上传商品照片，并补充“寻找同款但不要皮革材质”，系统在不同语言的商品标题、详情图与规格中召回候选。
• 视觉文档 RAG： 直接检索 PDF 页面、产品手册、财报图表、幻灯片和扫描件，减少 OCR 对布局信息的破坏。
• 工业故障库： 用设备照片、告警文字和运行条件共同查询历史工单，跨语言召回海外工厂的维修记录。
• 界面与截图搜索： 根据自然语言和参考截图查找应用界面、设计稿或测试案例，保留按钮位置、颜色与页面结构。
• 品牌与内容审核： 把图片、海报文案和多语言描述一起建模，识别视觉相近但文字语义不同的内容。

纯文本知识库不必急着迁移。若企业资料已经完成高质量 OCR、结构化切块和字段治理，查询也主要是文字，成熟文本 embedding 加关键词检索通常更便宜、更可解释。换用多模态编码器不会自动修复错误元数据、重复文档和糟糕的权限设计。

实时以图搜图也需要谨慎评估。移动端上传的照片可能包含压缩、旋转、遮挡和无关背景，服务器还要承担图片解码与视觉编码延迟。对于强调 100 毫秒级响应的业务，轻量视觉模型负责首轮召回、NeoMME 负责较小候选集的二次检索，可能比全量使用大编码器更现实。

不要把编码器当成完整 RAG 系统

编码器只负责把输入变成便于比较的表示，并不负责事实验证、权限控制或最终答案生成。 NeoMME 即使能够提高召回质量，也不能代替文档解析、混合检索、重排、引用定位和生成模型。

一条更可靠的多模态 RAG 链路通常包括四层：

1. 离线处理层： 保留原图、页面截图、OCR 文本、语言标签、文档层级和访问权限。
2. 召回层： 使用 NeoMME 对文字、图片或图文组合进行编码，并通过向量索引取回候选。
3. 重排层： 用 cross-encoder 或视觉语言模型重新判断查询与候选页面的细粒度相关性。
4. 生成层： 将高相关页面及必要文字交给生成模型回答，同时返回页码、区域或原始文档链接。

混合检索也不应被放弃。产品编号、法规条款、错误码和人名往往更适合 BM25 或字段过滤，视觉语义则适合向量召回。把关键词结果与 NeoMME 的向量结果融合，通常比押注单一相似度分数更稳。

NeoMME 的联合表示也可能降低局部可解释性。 当一张页面包含多个图表、脚注和段落时，单一向量很难说明究竟是哪一块内容触发了匹配。生产系统最好保留 OCR 文本、页面坐标和缩略图，并在召回后增加区域级分析，而不是只向用户展示一个无法解释的相似度分数。

Benchmark 应该怎么看

检索 benchmark 是在固定数据集上衡量模型排序与召回能力的评测集合。 常见指标包括 Recall@K、MRR 和 nDCG@10：Recall@K 关注正确结果是否进入前 K 个候选，MRR 强调第一个正确结果出现的位置，nDCG@10 则考虑前 10 名中不同相关等级的排序质量。

多模态模型尤其容易受到评测设置影响。把页面截图缩小到不同分辨率、是否提供 OCR 文本、查询是否带图片、是否加入提示模板，都会改变结果。比较 NeoMME 与其他模型时，必须确认输入条件相同，不能拿“图片加 OCR”的成绩与“只看低分辨率页面”的成绩直接横比。

公开数据集也无法代表企业内部语料。真实知识库里会出现水印、低清扫描、重复版本、手写标注、混合语言、超宽表格和权限隔离，这些因素在标准 benchmark 中往往覆盖不足。更可靠的做法是从线上查询抽取至少数百条代表性样本，人工标注相关文档，再同时测量质量、延迟与成本。

建议开发者重点记录以下指标：

• 文本查询、图片查询和图文组合查询各自的 Recall@5、Recall@20；
• 不同语言及跨语言查询的 nDCG@10，而不是只看宏平均分；
• 单张图片与单页文档的平均编码时间、P95 延迟和峰值显存；
• 每 100 万文档的向量存储量与索引构建时间；
• 加入重排器后，端到端答案命中率提高多少；
• OCR 缺失、图片模糊和语言混排时的性能下降幅度。

我们的判断：方向成立，但别只看“原生”两个字

NeoMME 是多模态检索从模态对齐走向联合语义理解的一次明确推进。 它瞄准了当前 RAG 最难处理的一类数据：内容既不是纯文本，也不是一张没有上下文的图片，而是图表、排版、标题、说明文字与多种语言共同构成的信息单元。

它的产品定位也比直接拿生成式多模态大模型做检索更合理。生成模型逐页描述图片会产生额外延迟和 token 成本，描述文本还可能遗漏视觉细节；专门编码器则可以离线建库，并复用成熟向量搜索基础设施。对于规模化召回，这是两种完全不同的成本结构。

不过，NeoMME 是否成为生产级选择，仍取决于三个问题。第一，它在企业真实图片分辨率和文本长度下是否足够快；第二，跨语言优势是否覆盖低资源语言，而非集中在英语及少数高资源语言；第三，单向量表示在复杂页面上的精度，是否足以抵消多向量模型更强的细粒度匹配能力。

开发者当前最合适的动作不是立即替换现有索引，而是做一轮并行评测。 保留原有 OCR 与文本检索链路，让 NeoMME 作为新增召回通道，在同一批真实查询上比较召回率、跨语言表现、索引成本和 P95 延迟。只有当它在图文组合查询上提供稳定增益，并且端到端成本可控，所谓“多模态原生”才真正从模型标签变成业务价值。

参考来源

• Hugging Face：NeoMME——高效的多模态原生、多语言编码器：H Company 的官方发布介绍，说明 NeoMME 的模型定位、设计思路与检索能力。