文档检索的"架构浪费"问题，被一篇论文正面解决了——NeoMME 用 260M 参数打败所有 <800M 竞品

  • 关联论文：2609.01657

你有没有想过 🤔：

你在公司文档库里搜一张发票的截图，问"这张发票上客户名是什么"。

现在的方案要拉一个几十亿参数的多模态大模型，让 VLM 把图像编码成向量，再去做相似度匹配。

但这件事根本不需要生成——你不需要 VLM 给你写一段话解释这张图，你只要"找到"它。

这就是当前视觉文档检索（ColPali、ColQwen 系）的结构性浪费：用一个为生成而生的模型去做一个完全不需要生成的任务。架构和任务根本不对齐。

arXiv 2609.01657（NeoMME） 正面解决了这件事——从架构上重新设计一个"原生为多模态非生成式编码"服务的模型。它小得多、快得多、便宜得多，而且精度还更高。

先说痛点：为什么这事值得每个人关心

如果你在做 RAG、文档检索、企业搜索、跨境电商商品检索、多语种客服知识库，这三个结构性浪费每天都在消耗你的钱：

  1. 参数浪费：ColPali 这种方案是把 GPT-4V 级别的 VLM 当 encoder 用，把生成式架构的全部参数继承下来用于非生成任务——为了"找到"，你付出了"理解"的算力。
  2. 存储浪费：late-interaction 检索（ColBERT 风格，token/patch 级别细粒度匹配）精度很高，但每个文档要存上百 KB 的向量，1 万页 PDF 就要存 750MB——生产环境根本吃不消。
  3. 多语言浪费：现成方案要么不支持多语言，要么支持多语言但不支持图像，要么都支持但极其昂贵——跨境电商、国际法务、多语种客服这三个场景被反复妥协。

NeoMME 三件事一起解决。

它的核心做法：单塔 + 双向 + 原生多模态 + 极致压缩

NeoMME 的架构选择每一条都直击痛点：

  • 单塔（single-tower）：文本 token 与图像 patch 在同一 Transformer 内交互，没有双塔信息流瓶颈。
  • 双向（bidirectional）：只做 encoding，不需要 causal mask，上下文完整利用。
  • 原生多模态：不像 ColPali 那样复用 VLM 权重再裁剪，从零按"原生编码"目标重新预训练——参数与算力效率显著提升。
  • 多语言原生：文本 token 不受英语限制。
  • late-interaction 工程化：dense head 粗排 + late-interaction head 精排，联合训练。
  • 极致压缩：层级 token pooling + 非对称量化（query 端浮点、document 端低 bit），把 late-interaction 向量压缩 255×，同时保留 ≥95% 的 baseline nDCG@10。

关键数字（来自 abstract 主表，可核验）

  • ViDoRe v3 文档检索基准：
  • NeoMME-260M：在 <800M 参数模型中取得最佳，nDCG@10 = 0.523。
  • NeoMME-800M：nDCG@10 = 0.556。
  • 吞吐（2048×2048 图像输入，NVIDIA L40S）：NeoMME-260M 比 ColModernVBERT 快约 2×。
  • 压缩：late-interaction 向量压缩 255×，保留 ≥95% baseline nDCG@10。
  • 上下文：16,384 token，够容纳 2 张标准 4K UHD 图像。
  • 开源：集成进 Hugging Face Transformers，Apache 2.0 释出，集合地址 hf.co/collections/Hcompany/neomme。

为什么这件事跟每个人都有关系

把这三个数字组合起来读：

  • 260M 打败所有 <800M 竞品 —— 你原来跑的 ColPali 几乎是它的 10 倍参数、慢得多、还更贵。
  • 2× 吞吐于 ColModernVBERT —— 你可以在同样的硬件预算下多服务一倍的查询量。
  • 255× 压缩 + ≥95% 保留 —— 原来存 1TB 的向量现在只需要 ~4GB，单节点内存可以装下大部分企业的全部文档向量。
  • Apache 2.0 + Hugging Face 集成 —— transformers.AutoModel.from_pretrained() 直接上手，集成成本接近零。

这意味着所有正在评估 ColPali / ColQwen / ColModernVBERT 升级路径的团队，都应该把 NeoMME-260M 列为下一个候选——一个不需要重写业务逻辑、几乎白送的精度与成本优化。

特别适合三类场景： 1. 跨境电商商品检索：需要同时支持多语言文本 + 商品图 + 强压缩。 2. 国际法务合同检索：长文档 + 多语言 + 精度优先 + 存储敏感。 3. 企业 RAG 系统升级：现有文档检索 encoder 直接换掉，看 nDCG@10 提升与硬件成本下降。

⚠️ 必须看清的限制

  1. 生成能力为零——不能做 VQA、caption、对话。需要生成还得另接 LLM（回到双塔）。
  2. 2 张 4K UHD 上限——对超长文档（>40 页 PDF）需要分片 + 跨 chunk 语义连续性策略，原文没给 hierarchical encoding 方案。
  3. ViDoRe v3 单基准主导——abstract 数据集中在 ViDoRe v3，其他文档检索基准（DuReader-Vis、ViDoRe v1/v2、MTEB 文档类）需要查 PDF 主表。
  4. 多语言覆盖范围不明——abstract 只说"multilingual"，具体语种、低资源语言表现需要查 model card。
  5. 从零预训练成本黑盒——训练 token 量与 GPU 小时未公开，对想要自己复现的团队是隐性门槛。

一句话总结

NeoMME 不是"又一篇 VLM 检索微调论文"，它正面回答了"非生成任务就该用非生成架构"这条工程原则，并用一个 260M 模型给出了可核验的硬数字：更快、更小、更便宜、还更准，而且 Apache 2.0 + Hugging Face 直接上手。

如果你正在维护任何一套文档检索系统，今天就该把 NeoMME-260M 跑一遍对比测试——很可能一个周末就能完成迁移，节省的可不止是服务器账单。

科普版由 Stephen 基于 flyP 深度解读与 Jay 工程核查改写。深度解读原文：/shared/research-kb/organized/promo/explainers/2609-01657.md