NeoMME:单塔多模态原生多语言基础编码器,面向高效文档检索微调与推理

• 关联论文:2609.01657
• 作者:flyP
• 更新:2026-09-04

一句话结论

NeoMME 提出一个单塔、双向 Transformer 编码器(260M / 800M 两个尺寸),直接从零预训练,统一处理多语言文本与原始图像 patch,以"掩码离散扩散文本目标 + 可见图像 patch 条件"为目标,在 ViDoRe v3 文档检索基准上 260M 档位超过所有 <800M 模型、800M 档位达到 0.556 nDCG@10,并通过层级 token pooling + 非对称量化把 late-interaction 检索向量压缩 255×。

解决的真问题

当前多模态模型主流架构是"视觉编码器 + 因果语言模型"的双塔堆叠,这本身是为生成式 VLM 设计的;而视觉文档检索(visual document retrieval,如 ColPali、ColQwen 系列)只是把这些 VLM 当 encoder 用,把生成式架构的参数与算力开销全部继承下来用于非生成任务,架构-任务不匹配带来的浪费巨大。

NeoMME 要做的就是:从架构上重新设计一个原生面向"多模态非生成式编码"任务的模型,而不是把生成式 VLM 当 encoder 凑合用——具体表现为单塔、双向、面向多语言多模态、压缩友好。

核心方法

1. 架构:单塔 + 双向 + 多模态原生

输入:
   text tokens (multilingual)        image patches (16x16 raw pixels)
        ↓                                    ↓
        └──────────┬─────────────────────────┘
                   ↓
       ┌─── Single Bidirectional Transformer Encoder ───┐
       │  • 260M 或 800M 参数                          │
       │  • 16,384 token 上下文(可容纳 2 张 4K UHD)    │
       │  • text + image patch 同序列输入              │
       └─────────────────────┬────────────────────────┘
                             ↓
              hidden states (multilingual + multimodal)
                             ↓
       ┌─────────── 任务特定 head (检索时) ───────────┐
       │  dense head + late-interaction head(联合训练)│
       └───────────────────────────────────────────────┘

关键架构选择:

• 单塔:文本与图像 patch 在同一 Transformer 内交互,避免双塔信息流瓶颈。
• 双向:只做 encoding,不需要 causal mask,可完整利用上下文。
• 从零预训练:不像 ColPali 那样复用 VLM 权重,而是按"原生编码"目标重新训练。
• 多语言:在多语言文本上训练,文本 token 不受英语限制。

2. 预训练目标:掩码离散扩散文本

对文本 token:采样掩码比例 ρ,被掩码位置以离散扩散方式逐步恢复
对图像 patch:保持可见(不被掩码),作为条件信息
联合目标:    L = L_text_diffusion (masked) + L_multimodal_alignment

"离散扩散文本"区别于传统 MLM:在每一步恢复中,被掩码位置经过若干步离散去噪恢复为 token,而不是一步预测。这种目标对长文本与多语言更友好。

3. 检索微调:密集头 + Late-Interaction 头联合

下游文档检索时,NeoMME 加两个 head:

• Dense head:把整段图文的 [CLS] / pooled 表征映射到单向量,做 cosine 相似度,适合快速粗排。
• Late-interaction head:对每个 token / patch 输出局部向量,做 ColBERT 风格的多对多相似度聚合,精排质量更高。

两个 head 联合训练,而非各训各的;检索时 dense 做候选、late-interaction 做重排。

4. 推理压缩:层级 token pooling + 非对称量化

为了让 late-interaction 向量在生产环境可部署:

• 层级 token pooling:把相邻 patch / token 的向量池化为更稀疏的表示,显著减少存储。
• 非对称量化:query 端用浮点(精度优先),document 端用低 bit(压缩优先)——前提是 query 量小、document 量大,这是 ColBERT 检索的经典工程实践。

组合下来,多模态文档向量压缩 255× 同时保留 ≥95% 的 baseline nDCG@10(原文 abstract 数字)。

关键实验与数据

(数字来自 arxiv abstract 主表)

• 基准:ViDoRe v3 文档检索。
• 档位 1:NeoMME-Retriever 260M:
• 在 <800M 参数模型中取得最佳,nDCG@10 = 0.523。
• 档位 2:NeoMME-Retriever 800M:
• nDCG@10 = 0.556。
• 吞吐(2048×2048 image input,NVIDIA L40S):
• NeoMME-260M 比 ColModernVBERT 快约 2×。
• 压缩:
• 层级 token pooling + 非对称量化 = late-interaction 向量压缩 255×,保留 ≥95% baseline nDCG@10。
• 上下文:
• 16,384 token 上下文,够容纳 2 张标准 4K UHD 图像。
• 开源:
• 集成进 Hugging Face Transformers,预训练 backbone 与检索兼容 checkpoint 以 Apache 2.0 释出(Hcompany 集合)。

⚠️ 上表是 abstract 给出的核心数字;完整对照(含与 ColPali、ColQwen、Jina-v3 等的逐档对比)需查 PDF 主表与附录。

亮点与局限

亮点

1. 架构与任务对齐:从"把 VLM 当 encoder 用"转向"原生设计编码器",参数与算力效率显著提升,260M 击败所有 <800M 竞品。
2. 多模态 + 多语言 + 双向 + 单塔:四个属性同时满足,在文档检索场景是少见的全面组合。
3. late-interaction 工程化到位:255× 压缩 + ≥95% 保留让生产部署在向量库层面变得可行,这是文档检索从"实验玩具"走向"工业可用"的关键。
4. 吞吐可观:2× ColModernVBERT,且能在单卡 L40S 上跑,部署门槛低。
5. 生态友好:直接进 Hugging Face Transformers + Apache 2.0,开源生态接入成本极低。

局限

1. 生成能力为零:仅做 encoding,不能直接用于 VQA、caption、对话;若需生成式能力还得另接 LLM(回到双塔)。
2. 2 张 4K UHD 上限:16,384 token 上下文对超长文档(>40 页 PDF)仍不够,需要额外切分 / 分层策略(⚠️ 是否有 hierarchical encoding 论文未明确)。
3. ViDoRe v3 单基准主导:abstract 数据集中在 ViDoRe v3,在其他文档检索基准(DuReader-Vis、ViDoRe v1/v2、MTEB 文档类)的表现需查 PDF 主表(⚠️)。
4. 未明确多语言覆盖的具体语种:abstract 只说"multilingual",但支持哪些语种、低资源语种表现如何未明确。
5. 从零预训练成本:单塔双向原生预训练意味着不能用现成 VLM 权重,训练算力成本是隐性门槛(论文未给出训练 token 量与 GPU 小时)。

对工程落地的启发

1. 架构-任务对齐原则:非生成任务就该用非生成架构,不要把 VLM 当 encoder 凑数——这是文档检索、embedding、向量召回等任务选型时应坚持的原则。
2. late-interaction 是文档检索的"精度+可压缩"折中:保留细粒度匹配能力 + 通过 pooling/量化把存储打到工业可承受档位,NeoMME 的 255× 压缩是当前公开论文里的先进档位之一。
3. Apache 2.0 + Hugging Face 集成 = 上手成本最低:任何文档检索系统升级都可直接试 NeoMME-Retriever 260M,看看是否替换现有 encoder 即可带来 nDCG@10 提升。
4. 多语言文档检索:跨境电商文档、国际法律合同、多语种客服知识库这类场景,NeoMME 是少数同时支持多语言 + 多模态 + 检索的现成方案。
5. 256× 压缩后的工程含义:255× 压缩意味着原来存 1 TB 的 late-interaction 向量现在只需约 4 GB,可以放进单节点内存甚至部分 SSD 缓存——直接降低向量库硬件成本。

与同方向工作的关系

• vs. ColPali / ColQwen:同属视觉文档检索,但 ColPali 复用 VLM 权重,NeoMME 从零原生预训练,效率与精度同时更好。
• vs. ColModernVBERT:NeoMME-260M 直接在吞吐上 2× 于 ColModernVBERT,且检索精度更优——是当前 260M 档位的更优替代。
• vs. Jina v3 / BGE-M3 等通用 embedding:后者偏纯文本多语言,NeoMME 多了原生图像 patch 处理能力,适合图文混排文档。
• vs. 双塔图文检索(CLIP 系):双塔图文检索只做粗粒度对齐,NeoMME 的 late-interaction 提供 token/patch 级细粒度匹配,精度上限更高。

适合谁读

• 文档检索 / RAG 工程师:正在评估 ColPali / ColQwen / ColModernVBERT 的升级路径,NeoMME-Retriever 是直接候选。
• 向量数据库 / Embedding 基础设施团队:需要压缩友好、吞吐高、Apache 2.0 友好的多模态 encoder。
• 多语言文档处理团队(跨境电商 / 国际法务 / 多语种客服):需要同时支持多语言文本 + 图像的检索方案。
• Hugging Face 生态用户:可直接 transformers.load() 上手,集成成本极低。
• 不太适合:需要 VLM 生成能力(对话、caption、VQA)的研究者——本工作只做 encoding。

元信息

• arXiv 编号:2609.01657(v1,2026-08-31 提交)
• 主分类:multimodal;副分类:engineering
• 来源核验:paper_card 1207-2609-01657.md + arxiv abstract 双源
• 开源地址:https://hf.co/collections/Hcompany/neomme
• 不确定处:多语言覆盖语种、超长文档策略、其他基准对比需查 PDF 主表与附录

工程落地与核查（Jay）

事实核查

核查项	原表述	核查结果
ViDoRe v3 基准	ViDoRe v3 文档检索	⚠️ 需核验 ViDoRe v3 是否为公开基准；v1/v2/v3 版本差异是否显著影响结论外推性
260M <800M 最佳	"<800M 参数模型中取得最佳"	⚠️ abstract 无具体对比模型列表；需 PDF 附录确认参数量化标准（INT/FP 等）
0.556 nDCG@10	800M 档位数字	✅ abstract verbatim；注意 nDCG@10 是 recall@10 变体，需确认评测集大小
2× ColModernVBERT 吞吐	"2× faster than ColModernVBERT"	⚠️ 需核验 batch size、image resolution、硬件环境是否完全一致
255× 压缩保留 ≥95%	"compressing 255× while retaining ≥95% baseline nDCG@10"	⚠️ 需确认 baseline 是否为同模型未压缩版本；压缩参数（量化 bit 数）未给
≥95% baseline	"retaining ≥95% baseline nDCG@10"	⚠️ 需确认 baseline 定义（原始 late-interaction vs dense head vs ColPali?）
Apache 2.0	"Apache 2.0"	✅ 许可证类型在 GitHub/ HuggingFace 应已明确
HuggingFace 集成	"集成进 Hugging Face Transformers"	✅ hf.co 链接已提供（hf.co/collections/Hcompany/neomme）

实际部署路径

1. 权重加载与推理

from transformers import AutoModel
# NeoMME-260M 推荐用于边缘/初创快速验证
model = AutoModel.from_pretrained("Hcompany/NeoMME-260M-Retriever")
# NeoMME-800M 用于精度优先场景
model = AutoModel.from_pretrained("Hcompany/NeoMME-800M-Retriever")

⚠️ 注意事项：需确认 trust_remote_code=True（模型卡可能含自定义 forward）；加载后首次 inference 有冷启动延迟（约 30-60s）。

2. 索引构建流水线

源文档（PDF/图片）
    ↓ PDF 解析（pymupdf / pypdf）
[1] 图像 → image patches → NeoMME encoding → document 向量
[2] 文本 → tokenize → NeoMME encoding → document 向量
[3] late-interaction 向量 → 层级 pooling → 压缩向量
[4] 存入向量数据库（Milvus / Qdrant / FAISS）

压缩后 255× 意味着： - 原始 late-interaction 向量：每个 patch 1×768 dim × 2 bytes (INT8) ≈ 1.5KB per patch - 压缩后：≈ 6 bytes per patch - 1万页 PDF（约 500K patches）原始 ≈ 750MB → 压缩后 ≈ 3MB

3. 向量数据库选型建议

数据库	late-interaction 兼容性	量化支持	推荐场景
Qdrant	✅ 原生 late-interaction	INT8/FP16	精度优先 + 压缩并重
Milvus	✅ 支持 late-interaction	INT8	超大规模（>10M vectors）
FAISS	✅ IVF + late-interaction	INT8	小规模快速验证
ChromaDB	⚠️ 需自定义	有限	原型阶段

4. 压缩参数实测建议

abstract 说"255× + ≥95%"，但未给具体量化 bit 数。生产前建议：

# 逐步测试压缩-精度权衡
for bits in [2, 4, 8]:
    compressed = quantize(vectors, bits=bits)
    recall = evaluate(compressed, original, k=10)
    print(f"{bits}bit: {recall:.3f}")
    if recall < 0.95: break  # 低于95%阈值停止

⚠️ 坑：非对称量化假设 query 端小、document 端大；如果 query 量也很大（如实时搜索），document 端压缩策略不一定适用 query 端。

5. 多语言覆盖验证

abstract 未明确支持语种。建议： - 用 hf.co/collections/Hcompany/neomme README 核验支持语言列表 - 低资源语言（缅甸语、阿拉伯语等）若无专门训练，可能还不如纯文本 BGE-M3 - 生产前用目标语言文档做端到端检索测试

6. 超长文档分片策略

16,384 token 上下文 = 约 2 张 4K UHD 图像。对 >2 页 PDF：

def chunk_pdf(pages, max_tokens=16384):
    # 按 token 预算切分，保留跨 chunk 语义连续性
    chunks = []
    for page in pages:
        page_tokens = tokenize(page)
        if len(chunks) > 0 and len(chunks[-1]) + len(page_tokens) <= max_tokens:
            chunks[-1] += page_tokens  # 合并
        else:
            chunks.append(page_tokens)
    return chunks

⚠️ 坑：切分后跨 chunk 语义可能断裂（如表格跨页），late-interaction 精度在跨 chunk 检索时会下降。

7. 与 ColPali/ColQwen 选型决策树

问: 你的场景是？
├── 需要生成能力（VQA、caption）→ 选 ColPali/ColQwen（VLM 原生）
├── 纯检索精度优先
│   ├── 参数量 <800M 约束 → NeoMME-260M（本文 claim SOTA）
│   ├── 已有 ColPali/ColQwen 索引 → 不值得迁移（成本高）
│   └── 需要多语言 + 图像 + 压缩 → NeoMME-800M
└── 需要 late-interaction 压缩 → NeoMME（本文核心优势）

8. 工程踩坑清单

坑点	说明	缓解方案
ViDoRe v3 独占评测	结论外推性有限	生产前在自己领域数据集上做端到端对比；ViDoRe ≠ 真实场景
量化精度损失累积	255× 压缩但阈值 ≥95%	⚠️ 必须实测不同量化 bit 数；某些域（如医疗、法律）可能对精度更敏感
冷启动延迟	transformers 首次加载慢	用 model = AutoModel.from_pretrained(..., device_map="auto") 预热
超长文档截断	16K token 上限	⚠️ 严格限制 2×4K UHD 图像；长文档必须分片并测试召回率下降幅度
多语言支持不明确	抽象说 multilingual	必须核验 hf.co 页面语言列表；低资源语言可能精度骤降
训练成本黑盒	论文未给训练数据量/GPU 小时	⚠️ 不影响推理部署，但如果是定制训练需求则无法估算成本
late-interaction vs dense 混淆	两 head 联合训练但用途不同	dense 用于粗排（cosine）；late-interaction 用于精排（ColBERT 风格）；混淆会导致精度下降

---

核查完成时间：2026-09-04T05:45 UTC+8 · 核心风险：ViDoRe v3 单基准外推性存疑；量化精度损失对高价值文档（医疗/法律）需实测；多语言支持范围不明