NeoMME: encoder multimodal open-source indexa página como imagem e cabe em 6 KB

A H Company publicou no blog da Hugging Face o NeoMME, uma família de encoders multimodais e multilíngues em dois tamanhos: 260M e 800M de parâmetros. O ângulo interessante para quem constrói RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → não é só o tamanho compacto, mas a decisão de arquitetura por trás: em vez de colar um encoder de visão pré-treinado a um modelo de linguagem causal, o NeoMME usa um único Transformer bidirecional que processa tokens de texto e patches de imagem no mesmo caminho computacional. Tudo treinado do zero, com pesos liberados sob Apache 2.0 e implementação no transformers disponível desde o dia do lançamento.

Para o dev brasileiro que quer IA multimodal em produção sem depender de API paga por token, isso é relevante por um motivo prático: o retrieval visual de documentos (a etapa cara de indexar PDFs) passa a rodar local, num modelo pequeno o bastante para caber numa GPU modesta.

O que muda na arquitetura

A maioria dos retrievers visuais recentes (ColPali, ColQwen, ColSmol) nasce da adaptação de VLMs generativos. Isso significa carregar três coisas: uma torre de visão pré-treinada (tipo SigLIP2), um projetor que mapeia features visuais para o espaço da linguagem, e um decoder causal. O problema, apontado pelos autores, é que tarefas de retrieval, classificação e labeling não geram texto autoregressivamente — então todo o overhead de parâmetro e compute do decoder causal é peso morto.

O NeoMME corta isso. Imagens viram uma grade de patches 32×32 projetados por um MLP pequeno; texto usa embeddings fatorizados; ambos entram no mesmo encoder bidirecional. Alguns detalhes técnicos que valem nota:

• Resolução dinâmica: a imagem mantém aspect ratio e tamanho, gastando mais tokens numa página densa e menos numa imagem simples.
• Contexto de 16.384 tokens, suficiente para até duas imagens 4K UHD, com atenção em janela deslizante na maioria das camadas e atenção global a cada sexta camada.
• Stack moderno: grouped-query attention, query-key normalization, gated attention, rotary embeddings 2D e MLPs squared-ReLU.
• Tokenizer BPE de 131k tokens treinado do zero em texto multilíngue, código, matemática e transcrições de imagem.

O pré-treino é o ponto menos convencional: em vez do masked language modeling clássico, usa um objetivo de difusão discreta mascarada. Para exemplos multimodais, a taxa de corrupção do texto fica entre 0.3 e 1, com os patches da imagem sempre visíveis. A ideia é forçar o modelo a descrever a partir da imagem: com pouco mascaramento, ele pode chutar "cat" em "The [MASK] sat on the mat" só pelo contexto textual; com mascaramento pesado, não tem escapatória a não ser olhar a imagem. Cada modelo processou cerca de 524 bilhões de tokens, orçamento pequeno perto dos 2 trilhões do ModernBERT, o que motivou o uso do otimizador NorMuon para ganhar eficiência de dados.

O NeoMME-Retriever e as duas cabeças

A versão útil no dia a dia é o NeoMME-Retriever, fine-tunado para retrieval de documentos pela abordagem de página-imagem do ColPali. Em vez de extrair texto de PDF com OCR e recortar em chunks, ele rankeia screenshots das páginas. Isso preserva layout, tabelas, gráficos, tipo e tamanho de fonte, coisas que nem um OCR perfeito captura.

O backbone ganha duas cabeças treinadas em conjunto, e uma única forward pass devolve as duas representações:

• Dense head: faz mean pooling dos hidden states num vetor normalizado. Compacto e ideal para busca aproximada (ANN).
• Late-interaction head: projeta cada token/patch num vetor de 128 dimensões. Preserva casamentos locais entre tokens da query e regiões da imagem.

A recomendação da equipe é usar late-interaction por padrão (mais poderoso, compatível com libs como NextPlaid). Para corpora muito grandes, dá para combinar: uma forward pass gera o dense embedding, um índice ANN recupera poucos candidatos e o late-interaction reranqueia. O termo "late-interaction", vale lembrar, é o que Omar Khattab (autor do ColBERT) defende como mais preciso que "multi-vector", porque descreve a granularidade da função de scoring, não só a contagem de vetores.

Os números do ViDoRe

Os resultados no benchmark ViDoRe (nDCG) colocam os dois modelos na fronteira de Pareto entre qualidade e tamanho:

O destaque honesto: o NeoMME-260M chega a 0.523 no ViDoRe v3, ficando a 0.002 do ColQwen2.5 que usa cerca de 14x mais parâmetros. O 800M fica a 0.009 do Vultron Flash, de tamanho parecido. Não é o topo absoluto do benchmark (o Vultron Flash de 850M ainda ganha), mas a relação qualidade/tamanho é o argumento central.

Onde o custo de produção cai de verdade

Dois pontos importam para quem paga a conta de GPU:

Throughput. Num mesmo input de 2048×2048 numa NVIDIA L40S, o NeoMME-Retriever-260M codifica cerca de 51 páginas por segundo, quase o dobro das 26 do ColModernVBERT. Indexar mais rápido significa menos tempo de GPU ligada para construir e atualizar o índice.

Storage do índice late-interaction. Esse é o calcanhar histórico da abordagem multi-vetor: o armazenamento cresce linear com o número de vetores, e uma página 2048×2048 gera ~4.200 vetores, ou cerca de 2.1 MB em float32 (média de ~1.5 MB por documento no ViDoRe v3). A equipe combina duas técnicas: hierarchical token pooling (agrupa vetores similares e guarda a média) e quantização assimétrica (documentos em int8 ou binário; queries em precisão maior, já que são geradas na hora). O resultado:

• Pooling 10 + int8 nos dois lados: de ~1.5 MB para 39 kB por página (39x menor), mantendo mais de 99% do nDCG@10.
• Pooling 8 + int8 na query + binário no documento: 6 kB por página (255x menor), mantendo mais de 95% da qualidade.

Essa é a diferença entre um índice de visual RAG que estoura o disco e um que roda numa infra enxuta.

Como usar

O modelo já está no transformers. Uma forward pass devolve dense e late-interaction juntos:

from transformers import NeoMMEForRetrieval, NeoMMEProcessor
from sentence_transformers.util import cos_sim, mean_maxsim
import torch

model_name = "Hcompany/NeoMME-260M-Retriever"
processor = NeoMMEProcessor.from_pretrained(model_name)
model = NeoMMEForRetrieval.from_pretrained(model_name, device_map="auto")

# queries multilíngues rodam no mesmo modelo
queries = [
    "Quelle partie de la production petroliere provient de champs en mer ?",
    "Which hour of the day had the highest overall electricity generation in 2019?",
]

Para fine-tuning, há checkpoints separados de dense e late-interaction compatíveis com Sentence Transformers v6, carregados via NeoMMEModel. Como o Sentence Transformers suporta uma cabeça por modelo, cada checkpoint treina uma cabeça; para treinar as duas juntas, é preciso NeoMMEForRetrieval com um Trainer customizado.

Quando não vale

Alguns pontos de cautela antes de jogar em produção. O NeoMME-Retriever é especializado em retrieval visual de página inteira: se o seu caso é busca de texto puro em chunks já extraídos, um encoder de texto tradicional continua mais simples e barato. A configuração de 6 kB por página é agressiva e perde ~5% de qualidade, então workloads sensíveis a recall devem calibrar o ponto na fronteira de compressão. Vale lembrar também que o próprio time descreve o projeto como "um side quest entre dois amigos", feito com tempo e compute limitados, e que os números de throughput e storage foram medidos por eles numa L40S específica: reproduzir na sua GPU é o teste que fecha a decisão. Ainda assim, para o cenário de visual RAG local, sem custo por token de API e com licença Apache 2.0, é uma das opções open-source mais interessantes a aparecer no espaço de encoders compactos.

Fonte: Hugging Face Blog