Benchmark de Modelos de Embedding de Código Aberto para RAG

Avaliamos 14 modelos de embedding de código aberto, hospedados localmente em uma única H100, em mais de 500 consultas de recuperação curadas manualmente abrangendo contratos legais, notas técnicas de suporte ao cliente e resumos médicos. NVIDIA Llama-Embed-Nemotron-8B lidera em precisão. Em termos de custo, o EmbeddingGemma-300m do Google roda aproximadamente 4x mais barato que o Nemotron, com um pequeno custo de perda de precisão.

Resultados do benchmark de modelos de embedding de código aberto

Métricas explicadas

nDCG@3: Ganho cumulativo descontado normalizado no corte 3. Com um documento relevante por consulta, é 1 / log2(rank + 1) quando o documento dourado cai no top 3, e 0 caso contrário. Rank 1 pontua 1.000, rank 2 pontua 0.631 e rank 3 pontua 0.500. Usamos nDCG@3 como a métrica principal porque pipelines de produção RAG alimentam os top 3 a 5 blocos no LLM, e o viés de primazia faz com que o rank 1 importe desproporcionalmente.

nDCG@10: Mesma fórmula com corte 10.

Recall@10: Fração de consultas onde o documento dourado aparece no top 10.

MRR@10: Reciprocidade média no corte 10. Dourado no rank 1 pontua 1.000, rank 2 pontua 0.500 e rank 10 pontua 0.100. Intenção semelhante ao nDCG@3, mas com uma penalidade de rank mais íngreme.

Top-1 hit: Fração de consultas onde o documento relevante dourado é o único resultado principal. A métrica mais estrita e a mais próxima de um fluxo de trabalho de consulta sem LLM.

Resultados nDCG@3 por domínio

O ranking AVG esconde inversões de domínio. Harrier vence o CUAD, mas fica em sétimo no TechQA. SFR-2 fica em segundo no TechQA, mas apenas em quarto no CUAD. KaLM-12B fica em quinto no MedRAG e em nono no TechQA. nDCG@3 por domínio:

BM25 é competitivo no MedRAG (0.7862, superando PubMedBERT e o Granite multilíngue) e fraco no CUAD (0.5844, onde 11 dos 14 modelos densos o superam). Contratos legais contêm linguagem densa de entidades que recompensa a correspondência lexical. Em resumos médicos, os principais modelos densos (Nemotron 0.9629, SFR-2 0.9620, jina-v5 0.9523) superam o BM25 em 0.17 a 0.18 pontos absolutos de nDCG@3.

Intervalos de confiança de 95% bootstrap por célula (modelo, domínio), incluindo um empate de quatro vias no topo do MedRAG e uma sobreposição Harrier-Nemotron no CUAD que o ranking de estimativa pontual achata, são relatados na seção de metodologia do benchmark.

Custo por milhão de tokens

O custo hospedado localmente é amortizado por GPU: a taxa horária dividida pelos tokens processados por hora. O pod que usamos foi um RunPod community-cloud H100 80GB SXM5 a $2.99/hr. O tempo de relógio por modelo em toda a passagem de 551 consultas, 3 corpora (~46.2M tokens no total) gera as seguintes estimativas de $/1M tokens:

A fórmula:

GPU $/hr = $2.99 (a taxa do RunPod community H100 80GB SXM5 do pod que usamos). wall_seconds = tempo total de relógio de cada modelo em toda a passagem de 551 consultas, 3 corpora. total_tokens ≈ 46.22M (soma de 3 corpora + 551 consultas, heurística de contagem de caracteres ÷ 4).

Exemplo trabalhado, Nemotron-8B: ($2.99 / 3600) × (1247.8 × 1.000.000 / 46.220.000) = $0.0224 por 1M tokens.

Cinco modelos lideram sua faixa de custo (nenhuma outra linha custa menos e pontua mais): Granite-278m-multilingual na base da escada de custos, depois Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small e Nemotron-8B no topo da escada de qualidade. Os endpoints variam 13x em custo ($0.0017/M a $0.0224/M) e 0.23 nDCG@3 absoluto (0.6952 a 0.9249).

Especialistas de domínio vs generalistas

PubMedBERT, ajustado finamente em pares de título-resumo do PubMed, é a "ferramenta certa" óbvia para recuperação de RAG médica no PubMed. Ele pontua nDCG@3 = 0.7084 no MedRAG, o que está abaixo da linha de base lexical BM25 (0.7862) no mesmo corpus. Generalistas modernos de código aberto o superam em 0.22 a 0.25 pontos absolutos em seu domínio de dados de treinamento:

A razão pela qual o especialista tem desempenho inferior é a idade e a receita. PubMedBERT é um BERT de 2022 com 110M de parâmetros com pooling médio simétrico e sem prefixo de instrução. Os generalistas de 2024-2026 são construídos em backbones maiores, prefixos de consulta e documento assimétricos e objetivos de recuperação ajustados por instrução. A lacuna arquitetônica importa mais do que a correspondência de domínio: um ajuste fino de 4 anos não consegue acompanhar um recuperador ajustado por instrução de geração atual, mesmo no corpus de treinamento do próprio ajuste fino.

A regra do comprador é testar um especialista de domínio contra um generalista moderno em consultas representativas antes de implantá-lo. A suposição de que "o especialista vencerá em seu domínio" não é mais segura para modelos de embedding de código aberto em 2026.

Descobertas do benchmark de embedding de código aberto

A liderança do Nemotron-8B no TechQA está estatisticamente separada do segundo lugar

Nemotron-8B AVG nDCG@3 = 0.9249. Por domínio, ele fica em 0.8602 no CUAD, 0.9515 no TechQA e 0.9629 no MedRAG. O resultado do TechQA (0.9515 0.923, 0.977) não se sobrepõe ao SFR-Embedding-2_R em segundo lugar (0.9109 0.869, 0.949). Os ICs bootstrap são de separação limpa. A base Llama-3.1 de 8B, ajustada por instrução para recuperação com um prefixo do lado da consulta Instruct: …\nQuery: … e um prefixo simétrico do lado do documento, impulsiona uma liderança absoluta de 0.04 nDCG@3 sobre a próxima linha em cargas de trabalho de suporte a documentos longos.

Os dois domínios onde o Nemotron vence diretamente (TechQA, MedRAG) são os corpora de documentos longos onde a assimetria do prefixo de instrução importa mais. CUAD é o único domínio onde ele não lidera: Microsoft’s Harrier-oss-v1-0.6b (0.8720) supera o Nemotron (0.8602) em contratos legais, apesar de ser 13x menor, embora os ICs se sobreponham e a liderança não esteja estatisticamente separada neste tamanho de amostra.

Um modelo Microsoft Harrier de 0.6B supera todos os modelos abertos com menos de 7B de parâmetros

Microsoft Harrier-oss-v1-0.6b (lançado em 2026-04 com uma base Qwen3-0.6B e licença MIT) fica em AVG nDCG@3 = 0.8911, quarto no geral. Ele supera o 12B Tencent KaLM-Gemma3 (0.8057, licença da comunidade Tencent), o 7B Salesforce SFR-Embedding-2_R no CUAD (0.8421 vs Harrier 0.8720) e o EmbeddingGemma-300m do Google (0.8706). Em uma comparação de mesma arquitetura, Harrier-0.6b (0.8911) fica 0.074 nDCG@3 acima do Qwen3-Embedding-0.6B (0.8168), construído na mesma base Qwen3-0.6B. O corpus de treinamento e a receita de instrução impulsionaram a lacuna, não a contagem de parâmetros.

Para compradores, o Harrier é a linha de código aberto mais bem classificada que vem com uma licença adequada para uso comercial sem restrições. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) e jina-v5 (CC-BY-NC) o superam na escada AVG, mas os três são apenas para pesquisa ou não comerciais.

Um embedder especialista médico perde para o BM25

NeuML’s PubMedBERT-base-embeddings foi ajustado finamente em pares de título-resumo do PubMed. É a "ferramenta certa" óbvia para um benchmark de RAG médico no PubMed. Ele pontua nDCG@3 = 0.7084 no MedRAG, o que é 0.078 absoluto abaixo da linha de base lexical BM25 (0.7862) no mesmo corpus. Os principais generalistas de código aberto no MedRAG ficam muito acima de ambos: Nemotron-8B 0.9629, SFR-Embedding-2_R 0.9620, Harrier-oss 0.9605, jina-v5 0.9523, KaLM-Gemma3-12B 0.9453.

Esta é a inversão que deve mudar como um comprador escolhe um especialista de domínio. PubMedBERT é um BERT de 2022 com 110M de parâmetros, com pooling médio simétrico e sem prefixo de instrução. O campo generalista de 2024 a 2026 é construído em backbones maiores, prefixos de consulta e documento assimétricos e objetivos de recuperação ajustados por instrução. Em consultas MedRAG que já incluem vocabulário médico, a correspondência lexical do BM25 é naturalmente forte, e a especialização do PubMedBERT não adiciona nada além disso.

A conclusão prática não é escolher um embedder especialista apenas pelo nome. Avalie-o em suas próprias consultas antes de comprometer.

Snowflake Arctic oscila 0.32 nDCG@3 entre domínios

Snowflake’s snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, derivado bge-m3-retromae, multilíngue) pontua nDCG@3 = 0.5846 em contratos legais CUAD e 0.9053 em resumos médicos MedRAG. O mesmo modelo, mesma receita, mesmo formato de consulta, com uma oscilação de 0.32 pontos entre dois domínios. Outros modelos na lista oscilam menos: SFR-2 varia de 0.8421 a 0.9620 (lacuna 0.12), Nemotron varia de 0.8602 a 0.9629 (lacuna 0.10), Harrier varia de 0.8408 a 0.9605 (lacuna 0.12).

O mecanismo é a composição dos dados de treinamento. Arctic foi ajustado em BEIR, MIRACL e CLEF; contratos legais não são representados. Para uma carga de trabalho de recuperação vertical, os dados de treinamento de domínio importam mais do que a contagem de parâmetros ou o comprimento do contexto.

Veja mais dos nossos benchmarks e insights baseados em dados na Pesquisa Google.

Adicionar como fonte preferencial

Como a inferência de embedding de código aberto funciona

Modelos de embedding de código aberto rodam em dois backends neste benchmark: sentence-transformers (12 modelos) e vLLM (4 modelos). A divisão não é sobre qualidade; é sobre eficiência de tempo de execução em modelos de 8B e maiores, onde o loop de inferência Python padrão do sentence-transformers é muito lento para ser viável.

A receita por modelo importa mais do que a escolha do backend. Modelos de recuperação modernos usam prefixos assimétricos: o lado da consulta é envolto em um prompt estilo Instruct (Instruct: Given a question, retrieve passages...\nQuery: <text>) enquanto o lado do documento é simples. O tipo de pooling varia: modelos derivados de BERT usam pooling CLS; modelos derivados de LLM (Llama, Mistral, Qwen3, Gemma3 base) usam pooling de último token; modelos multilíngues frequentemente usam pooling médio. O cartão HuggingFace de cada modelo é a fonte da verdade para qual combinação de prefixo e pooling está correta.

Tier de backend:

• vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
• sentence-transformers: Qwen3-0.6B, EmbeddingGemma-300m, trio Granite, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier

Padrões de prefixo assimétrico observados:

• Instruct + Consulta/Documento: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
• encode_query / encode_document embutido: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (parâmetro sentence-transformers): jina-v5, Snowflake Arctic, Harrier
• Sem prefixo (simétrico): trio Granite, Conan, PubMedBERT, GIST

Tipo de pooling por arquitetura base:

• Pooling CLS: trio Granite r2, Snowflake Arctic
• Pooling de último token: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Pooling médio: EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

Usar a receita errada degrada silenciosamente a qualidade da recuperação sem travar. Qualquer benchmark de embedders de código aberto deve incluir um piso de sanidade (Recall@10 abaixo de 0.5 em todos os domínios para qualquer modelo é um sinal de alerta para uma configuração incorreta, não um resultado).

Metodologia do benchmark de modelos de embedding de código aberto

Três domínios de recuperação foram avaliados: contratos legais CUAD (246 consultas, 509 contratos), notas técnicas de suporte ao cliente TechQA (151 consultas, 28000 IBM notas técnicas), resumos de saúde MedRAG-PubMed (154 consultas, 50000 resumos). Total de 551 consultas.

A metodologia de construção do conjunto de dados é compartilhada com nosso anterior benchmark de modelos de embedding em inglês: Geração de consulta por consenso de 3-LLM Protocolo-A (piscina de escritores rotativa, avaliador fixo, dois validadores não escritores por tentativa), fixação de corpus por hash SHA-256, listas brancas de tokens proibidos por entidade por domínio para evitar atalhos lexicais BM25, acordo interavaliador Cohen’s κ relatado por par de validadores, rankings de linha de base BM25 sintetizados do campo bm25_rank_at_target já presente em cada JSON de consulta (equivalente Pyserini). Métrica principal nDCG@3 (realista para RAG, o que sistemas de produção RAG consomem); métricas secundárias nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

Especificações específicas de código aberto:

• GPU: 1 x NVIDIA H100 80GB SXM5 via nuvem comunitária RunPod

• Modelo de Pod: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404

• Stack: PyTorch 2.10.0+cu128, vLLM 0.19.1, transformers 5.6.2, sentence-transformers 5.4.1

• Disparo por modelo: Camada principal do cartão de modelo HF. ST para 12 modelos, vLLM para Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.

• Fragmentação por modelo: truncamento em nível de caractere em max_seq_length x 4 caracteres por token, então o tokenizer do modelo truncar para seu comprimento de sequência máximo real.

• Recuperação assimétrica: cada modelo que suporta recebe o prefixo de consulta e documento documentado no cartão HF. Sem prefixo é o padrão documentado para alguns.

• Normalização L2: aplicada uniformemente pós-pooling. Alguns modelos fazem isso internamente. Re-normalizamos para garantir paridade em toda a lista.

• Chave de cache de embedding: inclui prefixo + tarefa + prompt_name + max_seq + backend, para que uma troca de prefixo no meio da execução não carregue silenciosamente embeddings desatualizados.

• Protocolo estatístico: 10K reamostragens bootstrap por célula (modelo, domínio, métrica), percentil 95% IC, seed=2026.

Modelos testados

Ordenado por rank AVG nDCG@3. Coluna Backend: ST = sentence-transformers, vLLM = vLLM 0.19.

Resultados dos intervalos de confiança bootstrap de 95%

O ranking completo acima é de execução única por célula (modelo, domínio). A variância de inicialização do modelo entre sessões não é medida. Para capturar a variância no nível da consulta dentro da execução, reamostramos o vetor de rank por consulta para cada célula (modelo, domínio) 10.000 vezes com reposição (método percentil, seed=2026, tamanhos de amostra CUAD n=246, TechQA n=151, MedRAG n=154). IC bootstrap 95% por domínio em nDCG@3:

Os ICs mudam quais inversões os dados suportam. No CUAD, Harrier (0.8720, [0.836, 0.906]) e Nemotron (0.8602, [0.821, 0.897]) se sobrepõem, então a liderança do Harrier no CUAD não está limpa-separada neste tamanho de amostra. No TechQA, Nemotron (0.9515, [0.923, 0.977]) e SFR-2 (0.9109, [0.869, 0.949]) não se sobrepõem, então a liderança do Nemotron no TechQA está estatisticamente separada. No MedRAG, os quatro principais (Nemotron 0.9629, SFR-2 0.9620, Harrier 0.9605, jina-v5 0.9523) estão dentro dos ICs um do outro e formam um empate estatístico de quatro vias. A inversão PubMedBERT-abaixo-de-BM25 no MedRAG (0.7084 [0.641, 0.772] vs BM25 0.7862) está na margem de sobreposição. A tendência central coloca claramente o especialista abaixo do BM25, mas uma passagem de 3 execuções entre sessões é necessária para resolvê-lo como separado em vez de sobreposto.

Limitações

Execução única por célula (modelo, domínio). A tabela IC bootstrap acima captura a variância no nível da consulta dentro da execução (10K reamostragens, método percentil, seed=2026), mas a variância de inicialização do modelo entre sessões não é medida. Uma passagem de 3 execuções entre meia-noite está planejada para a v2.1. Os laços mais próximos revelados pela tabela IC (por exemplo, o empate de quatro vias no topo do MedRAG, a sobreposição Harrier-Nemotron no CUAD, a inversão marginal PubMedBERT-vs-BM25) se beneficiariam mais da passagem de múltiplas execuções.

Confound de comprimento de contexto por modelo. Modelos com janelas de contexto de 512 tokens (Granite-278m-multilingual, PubMedBERT, Conan, GIST) veem apenas os primeiros ~2K caracteres de cada documento. Modelos com 8K ou 32K de contexto (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 english) veem o documento completo. Isso favorece modelos de contexto longo no TechQA (notas técnicas longas) e MedRAG (resumos longos).

Risco de contaminação de dados de treinamento do MedRAG. Vários dos modelos avaliados foram treinados em dados derivados do PubMed (PubMedBERT por definição, possivelmente Granite-278m-multilingual, possivelmente base Qwen3). Alguns ganhos de nDCG@3 no MedRAG podem refletir sobreposição de dados de treinamento em vez de qualidade de recuperação.

Conan-v1 é treinado em chinês. Incluí-lo em domínios apenas em inglês é um ponto de dados instrutivo sobre incompatibilidade de idioma em vez de um confronto justo na qualidade de recuperação em inglês. Esperamos desempenho inferior em relação aos pares treinados em inglês e é isso que os dados mostram.

Leitura adicional

Explore outros benchmarks RAG, como:

• Top 10 Modelos de Embedding Multilíngues para RAG
• Modelos de Embedding: OpenAI vs Gemini vs Voyage
• Top Banco de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de Reranker: Top 8 Modelos Comparados
• Modelos de Embedding Multimodal: Apple vs Meta vs OpenAI
• RAG Híbrido: Aumentando a Precisão do RAG
• RAG de Grafos vs RAG Vetorial

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{sar2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark de Modelos de Embedding de Código Aberto para RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Acessado em 3 Julho 2026}
}

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é pesquisador de IA na AIMultiple, com foco em automação inteligente, GPUs, agentes de IA e frameworks RAG.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário