NeoMME Retriever: um mapa prático de recall de candidatos para recuperação visual de documentos

Por que o NeoMME importa para recuperação de imagens de páginas agora

A H Company lançou o NeoMME em 3 de setembro de 2026 como uma família de codificadores multilíngues e multimodais de 260M e 800M. O lançamento merece atenção por um motivo prático: o NeoMME Retriever pode produzir embeddings densos e embeddings de interação tardia a partir da mesma passagem direta. Para equipes de recuperação visual de documentos, isso leva o modelo de curiosidade de benchmark a decisão de arquitetura.

A recuperação de imagens de páginas pesquisa páginas renderizadas, não apenas texto extraído. A evidência relevante pode estar em uma tabela, em um rótulo de diagrama, em um apêndice escaneado, em uma nota multilíngue ou em um layout em que o contexto espacial muda o significado. OCR ainda importa. Em PDFs limpos com identificadores exatos, pode ser a linha de base mais forte. Mas um design somente com OCR deixa de fora uma classe de perguntas sobre documentos em que a própria imagem da página carrega o sinal.

O limite é onde os construtores precisam de disciplina. Um codificador de recuperação recupera páginas. Ele não gera respostas, não prova a fidelidade de RAG visual nem elimina a necessidade de avaliar um VLM ou modelo de linguagem downstream. Pontuações de recuperação publicadas podem orientar a seleção, mas não devem ser reformuladas como alegações de precisão de resposta. A mesma lógica está por trás do artigo da Optijara sobre comparabilidade de benchmarks e testes de relevância: uma métrica só é útil quando todos concordam sobre o que ela mede. Para planejamento de produção, o teste de realidade de implantação de modelos pequenos da Optijara faz o mesmo ponto em outro contexto: medir o artefato, ambiente de execução, hardware e carga de trabalho antes que a arquitetura endureça.

A pergunta prática não é se um índice ANN consegue armazenar muitos vetores. A pergunta é se a busca densa de primeira etapa traz de volta as páginas certas com frequência suficiente para que a interação tardia melhore a ordem. Se o conjunto de candidatos for fraco, o reranker está melhorando a lista curta errada.

A arquitetura em linguagem simples: um codificador, duas cabeças de recuperação

O NeoMME usa um único Transformer bidirecional sobre tokens de texto e patches de imagem bruta. Os materiais da H Company descrevem patches de 32 por 32 pixels, um contexto de 16,384 tokens e nenhuma torre de visão pré-treinada separada ou modelo de linguagem causal no caminho de recuperação. O card do retriever de 260M lista 263M parâmetros, tamanho oculto de 1,024, embeddings densos de 1,024 dimensões com dimensões Matryoshka e embeddings multivetor de 128 dimensões por token de texto ou patch de imagem. O card de 800M lista 800M parâmetros, tamanho oculto de 1,792 e a mesma rota multivetor de 128 dimensões.

A cabeça densa é o motor de busca de candidatos. Ela cria uma representação compacta que pode ser pesquisada com similaridade de cosseno em infraestrutura vetorial conhecida. Em geral, é por aqui que equipes de produção começam porque isso se encaixa em indexação ANN, filtros de metadados, controles de acesso e logs de recuperação.

A cabeça de interação tardia mantém uma malha mais detalhada de tokens ou patches. Os cards dos modelos descrevem embeddings multivetor normalizados por L2 pontuados com MeanMaxSim. Esse estilo de pontuação pode preservar evidências locais melhor do que um único vetor denso quando a consulta depende de uma célula de tabela, legenda, rótulo de diagrama ou pequena região de uma página. O ponto de atenção é que os detalhes importam. Padding, masking, normalização, precisão da consulta, precisão do documento e a função de pontuação exata podem alterar qualidade e custo.

Também há checkpoints separados do Sentence Transformers. O modelo denso ST gera apenas embeddings densos. O modelo ST de interação tardia gera apenas embeddings multivetor. Esse não é o mesmo caminho operacional do modelo Transformers padrão, que retorna embeddings densos e multivetor juntos por meio de NeoMMEForRetrieval. Se uma avaliação mistura esses artefatos, o relatório deve dizer isso em linguagem simples.

O gargalo de recall de candidatos: o que o reranking não consegue recuperar

A lição central é direta: dense recall@K define o teto para o reranking downstream. A interação tardia pode reordenar páginas retidas, mas não consegue resgatar uma página relevante que nunca chega à lista curta.

Considere uma busca hipotética em relatório anual. Um usuário pergunta por uma divulgação de risco específica. A resposta aparece uma única vez, em letras pequenas dentro de uma tabela de apêndice. Um embedding denso de página pode recuperar a seção narrativa de riscos e várias páginas visualmente parecidas, enquanto perde a página do apêndice em K igual a 20. O reranker de interação tardia pode refinar essas 20 páginas, mas a página da tabela permanece invisível. Aumentar K pode fazê-la aparecer. Isso também acrescenta trabalho de reranking, movimentação de memória e talvez mais páginas para um VLM downstream inspecionar.

É por isso que equipes devem separar candidate recall@K, nDCG@10 do reranker, correção da resposta e qualidade da citação. Colapsar tudo em uma única pontuação de RAG esconde o modo de falha. Se a precisão da resposta melhora depois de aumentar K, o ganho pode vir de recall de candidatos, não de um gerador melhor. Se a qualidade da resposta piora depois da compressão, a regressão pode estar na recuperação, no ranqueamento ou na síntese da resposta.

O dimensionamento do conjunto de candidatos é uma variável real de design. K baixo pode manter sistemas rápidos enquanto limita silenciosamente o recall. K alto melhora a chance de que a página certa chegue ao reranker, mas pode aumentar a latência de interação tardia, leituras de índice, pressão sobre GPU ou CPU e ruído no contexto downstream. O valor certo depende do corpus. Mistura de idiomas, densidade de layout, qualidade do escaneamento, frequência de tabelas e letras pequenas importam. O mapa de avaliação Vaani da Optijara usa um hábito parecido: manter fatias visíveis em vez de deixar pontuações agregadas esconderem os casos desconfortáveis.

O Mapa de Recall Página para Candidato: um fluxo de avaliação prático

O framework recomendado para recuperação visual no estilo NeoMME é um Mapa de Recall Página para Candidato. Seu trabalho é simples. Ele mapeia cada consulta para as páginas que deveriam ser alcançáveis, a etapa que as encontra ou perde e as verificações de resposta que dependem da recuperação.

Comece pelos artefatos. Fixe o checkpoint exato do NeoMME, configuração do processador, revisão da biblioteca, ferramenta de renderização, tamanho da imagem, identificadores de página e formato de armazenamento. Não presuma que uma versão estável posterior da biblioteca se comporte como a página de documentação atual. Crie julgamentos de relevância em nível de página e depois estratifique-os. Um PDF limpo, digital nativo e em inglês, uma tabela multilíngue, um scan rotacionado e uma página densa de apêndice não devem ter média calculada em conjunto antes que alguém revise os erros. Mantenha um conjunto de retenção e inspecione falhas manualmente. Letras pequenas, layouts quase duplicados, cabeçalhos, rodapés e tabelas longas são onde demos polidas costumam diferir do comportamento em produção.

Depois compare rotas. Recuperação por texto OCR continua sendo uma linha de base séria para PDFs limpos, termos exatos, identificadores e revisão de conformidade. Recuperação NeoMME somente densa testa recall amplo de candidatos. Avaliação somente tardia, quando viável, mostra o custo e a qualidade da correspondência detalhada. Lista curta densa mais reranking tardio testa a rota híbrida provável. Meça candidate recall@K e nDCG@10 antes da geração de respostas. Depois acrescente latência por etapa, bytes de índice, tempo de pré-processamento, correção de páginas recuperadas para resposta e fidelidade de citação.

O que as medições publicadas dizem, e o que não incluem

O lançamento da H Company relata ViDoRe v3 nDCG@10 de 0.523 para o NeoMME Retriever 260M e 0.556 para o NeoMME Retriever 800M. A página do artigo vinculada repete esses valores relatados pelos autores e afirma que o modelo de 260M supera modelos avaliados estritamente abaixo de 800M parâmetros nesse benchmark. Números mais antigos de ViDoRe v1 e v2 usam nDCG@5 nas tabelas dos cards dos modelos, então não devem ser comparados com v3 nDCG@10 como se a métrica e o cenário fossem idênticos.

O lançamento também relata cerca de 51 páginas por segundo para a configuração de 260M com tamanho de entrada de imagem pareado de 2048 por 2048 em uma GPU NVIDIA L40S. Leia isso de forma estreita. Refere-se a tensores pré-processados com configurações de lote calibradas. Não inclui renderização de PDF, upload, indexação, tratamento de consultas, orquestração de reranking downstream, geração, observabilidade ou revisão humana.

Alegações de compressão precisam do mesmo cuidado. O blog descreve pooling hierárquico de tokens e quantização assimétrica reduzindo o armazenamento de índice de interação tardia de cerca de 1.5 MB para cerca de 6 kB por página, 255 vezes menor, mantendo mais de 95 por cento do nDCG@10 de linha de base no ViDoRe v3. Esse é um resultado específico médio de embedding de interação tardia, não uma pegada total de armazenamento vetorial. Vetores densos, metadados, imagens de página, sobrecarga de índice, backups, logs de acesso e dados de monitoramento ainda contam. Os mesmos materiais discutem uma configuração diferente de pooling e int8 em torno de 39 kB por página com mais de 99 por cento de qualidade retida. Trate-as como compromissos separados, não como configurações padrão.

Compromissos de rota: denso, interação tardia e recuperação visual híbrida

Somente denso pode bastar para navegação grossa, páginas semelhantes a duplicatas ou recuperação por tópico amplo. A interação tardia justifica seu custo quando a evidência relevante é local, visual, tabular ou facilmente borrada dentro de um único vetor denso. A recuperação híbrida é atraente porque uma passagem de codificação do NeoMME pode produzir ambas as representações. Ainda assim, a rota híbrida só funciona quando a lista curta de primeira etapa é ampla o bastante para que o reranker veja as páginas certas.

O orçamento de recursos deve ser explícito. Se uma equipe está decidindo se executa recuperação localmente, usa inferência hospedada ou divide cargas de trabalho, as perguntas se parecem com as do teste de realidade de implantação de modelos pequenos da Optijara: artefato exato, ambiente de execução exato, hardware exato, carga de trabalho exata e condições claras de reversão.

Checklist de implementação, erros comuns e ressalvas

Os erros comuns são ordinários, exatamente por isso continuam acontecendo. Equipes tratam nDCG do reranker como precisão de resposta. Reduzem K antes de medir recall de candidatos. Confundem compressão de embedding com custo total de armazenamento. Presumem que suporte multilíngue nativo significa desempenho equilibrado em todos os idiomas. Pulam linhas de base de texto OCR. Ignoram tempo de renderização porque o benchmark começa depois do pré-processamento. Esquecem que pesos de modelo Apache 2.0 não resolvem permissões de documentos.

Ressalvas operacionais pertencem à revisão de design. A distribuição de consultas pode mudar. Embeddings em cache podem ficar desatualizados após atualizações de documentos. Documentos privados podem exigir controles mais rígidos de armazenamento, retenção e acesso. Conjuntos de avaliação podem representar páginas limpas em excesso. Um VLM downstream pode alucinar mesmo quando a recuperação é boa, ou citar a página errada mesmo quando a página certa está presente. Capacidade multilíngue nativa não prova qualidade de respostas em árabe, recursos baixos, manuscritas ou sem OCR para um dado corpus.

{
  "model_family": "NeoMME Retriever",
  "retrieval_routes": ["ocr_text_baseline", "dense_only", "late_interaction", "dense_shortlist_plus_rerank"],
  "must_measure": ["candidate_recall_at_k", "ndcg_at_10", "per_stage_latency", "index_bytes", "answer_correctness", "citation_faithfulness"],
  "excluded_costs_to_add_back": ["pdf_rendering", "upload", "indexing", "metadata", "page_images", "generation", "observability"],
  "deployment_caveats": ["dense_recall_caps_reranking", "compression_is_workload_specific", "retrieval_is_not_answer_generation"]
}

Um próximo experimento útil é pequeno e disciplinado: escolha documentos representativos, fixe artefatos, construa julgamentos em nível de página, varra K, teste compressão separadamente e depois conecte páginas recuperadas a verificações de resposta e citação. Se sua equipe precisar de ajuda, a Optijara pode ajudar a construir esse mapa de avaliação antes que escolhas de arquitetura se transformem em custo de produção.