Modelos de Embedding: OpenAI vs Gemini vs Voyage

Fizemos benchmark de 15 modelos de embedding de texto em inglês e de um baseline BM25 em mais de 500 consultas curadas manualmente em três domínios de recuperação: contratos jurídicos (CUAD), suporte ao cliente (IBM TechQA) e saúde (MedRAG PubMed).

Voyage-3.5 fica em primeiro lugar geral. Perplexity Embed V1 0.6b alcança o nível intermediário superior com o menor preço em nosso benchmark.

Resultados do benchmark de modelos de embedding

Métricas explicadas

nDCG@3: Ganho cumulativo descontado normalizado com corte em 3. Com um documento relevante por consulta, é 1 / log2(posição + 1) quando o documento gold fica no top 3, e 0 caso contrário. A posição 1 pontua 1.000, a posição 2 pontua 0.631, a posição 3 pontua 0.500. Usamos nDCG@3 como métrica principal porque pipelines de produção de RAG alimentam os 3 a 5 principais trechos para o LLM, e o viés de primazia faz a posição 1 importar desproporcionalmente.

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

Recall@10: Fração de consultas em que o documento gold aparece entre os 10 primeiros.

MRR@10: Posto recíproco médio com corte em 10. O gold na posição 1 pontua 1.000, na posição 2 pontua 0.500, e a posição 10 pontua 0.100. Intenção semelhante ao nDCG@3, mas com penalidade de posição mais acentuada.

Acerto no Top-1: Fração de consultas em que o documento gold relevante é o único primeiro resultado. A métrica mais rigorosa e a mais próxima de um fluxo de consulta sem LLM.

nDCG@3 por domínio

Jurídico (CUAD, 246 consultas, 509 contratos): O domínio jurídico é o único em que o especialista voyage-law-2 vence; seus dados de treinamento ajustados ao CUAD rendem +0.040 de nDCG@3 sobre o voyage-4-large. O openai/text-embedding-3-large fica na posição 11 com 0.6430, abaixo de seis modelos mais baratos. Piso do BM25: 0.5844.

Suporte ao cliente (TechQA, 151 consultas, 28.000 IBM notas técnicas): A distância do voyage-4-lite para o próximo modelo é de 0.018. O gemini-embedding-001 cai para a posição 7 (0.8856), 0.045 atrás de seu irmão mais novo no TechQA, embora vença nos outros dois domínios. Piso do BM25: 0.6097.

Saúde (MedRAG-PubMed, 154 consultas, 50.000 resumos): Saúde é o agrupamento mais compacto do nosso benchmark (14 modelos pontuam acima de 0.88) porque o vocabulário médico é denso em palavras-chave, o que empurra a maioria das consultas para o agrupamento superior. Piso do BM25: 0.7862, dentro de 0.02 do modelo denso mais fraco. O gemini-embedding-001 também supera o gemini-embedding-2-preview por sua maior margem aqui (+0.013).

As inversões no nível de domínio justificam o enquadramento da média de 3 domínios: nenhum domínio isolado é um proxy justo para “qual modelo é o melhor”, e um comprador que escolher com base em um único domínio errará a classificação nos demais.

Os intervalos de confiança bootstrap de 95% por modelo para cada célula de domínio, além dos quatro empates pareados que as classificações por estimativa pontual ocultam, estão detalhados na seção de metodologia.

Precisão versus preço: custo por 1M tokens

Métricas explicadas

Preço por 1M tokens de entrada é o preço de tabela para embedding de 1M tokens de entrada, em 2026-04-23. Os preços da Voyage vêm da página de preços diretos da Voyage. Modelos servidos via OpenRouter usam a captura do catálogo do OpenRouter do mesmo dia. Tokens de consulta e de documento têm o mesmo preço em todos os fornecedores testados. O BM25 é plotado a $0,001/M para renderização em eixo logarítmico. O custo real de auto-hospedagem é $0.

Média de nDCG@3 nos 3 domínios é a média não ponderada do nDCG@3 por domínio nos três corpora. Cada domínio contribui igualmente para a média, independentemente do número de consultas.

• Para plataformas de RAG com foco em custo, pplx-embed-v1-0.6b é a escolha clara. A $0,004/M, é 30-50x mais barato do que qualquer um dos carros-chefe comerciais e entrega 92% da qualidade do voyage-3.5 (0.8604 / 0.9429). Nenhum outro modelo em nosso benchmark compete nesse ponto de preço.
• Para RAG empresarial com foco em qualidade, o voyage-3.5 via SDK direto da Voyage assume o melhor ponto de Pareto. Você troca uma integração extra de API (versus uma stack apenas com OpenRouter) por um modelo marginalmente melhor do que o próprio carro-chefe da Voyage pela metade do preço. O instinto de “sempre escolher o mais novo e maior” está errado dentro do catálogo da Voyage.
• Para implantações OSS / auto-hospedáveis / on-prem, o qwen3-embedding-8b vence. É o embedder não trivial mais barato em nosso benchmark a $0,010/M, iguala ou supera todas as outras famílias de codificadores OSS que testamos e acompanha pesos auto-hospedáveis.
• Os carros-chefe premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) todos perdem para o voyage-3.5 na média dos 3 domínios, embora o voyage-3.5 seja 2-3x mais barato do que qualquer um deles.

Principais conclusões do benchmark de embedding

voyage-3.5 vence a média dos 3 domínios e supera o carro-chefe voyage-4-large pela metade do preço

voyage-3.5 tem média de 0.9429 de nDCG@3 em jurídico, suporte ao cliente e saúde. O carro-chefe voyage-4-large tem média de 0.9416 a $0,12 por 1M tokens, 2x o preço do voyage-3.5 de $0.06. O carro-chefe vence no TechQA por 0.002 e vence no MedRAG por 0.032. Ele perde no CUAD por 0.037 (0.8730 vs 0.9102), o suficiente para que sua média nos 3 domínios fique abaixo do voyage-3.5. Dentro da linha Voyage, o modelo intermediário mais antigo é a melhor escolha para propósito geral. O carro-chefe só justifica seu preço premium em saúde.

A Voyage conquistou a primeira posição nos três domínios e dominou as duas primeiras posições em CUAD e TechQA. No MedRAG, o gemini-embedding-001 entrou na 2nd posição (0.9814, atrás do voyage-4-large com 0.9855), à frente de todos os outros modelos Voyage. O gemini-001 também alcança o terceiro lugar no CUAD. Nenhum outro modelo fora da Voyage alcança o top 2 em qualquer domínio individual.

Um modelo legado do Gemini supera seu irmão “preview” mais novo em dois dos três domínios

O google/gemini-embedding-001 (lançado em junho de 2025) supera o google/gemini-embedding-2-preview tanto no CUAD (0.8980 vs 0.8958) quanto no MedRAG (0.9814 vs 0.9685). O modelo mais novo vence apenas no TechQA (0.9301 vs 0.8856), uma diferença de 0.04 que vem com aumento de preço de 33% ($0,20 vs $0,15 por 1M tokens de entrada). O enquadramento de “upgrade multimodal mais novo” do Gemini 2 não se sustenta na recuperação de texto em inglês em corpora jurídicos ou de saúde.

Para cargas de trabalho de RAG nesses dois domínios hoje, o gemini-embedding-001 é a escolha correta do Gemini. A inversão no MedRAG (001 em 2nd, 2-preview em 3rd) é grande o suficiente para que um comprador que opte pelo modelo “mais novo” perca qualidade mensurável.

OpenAI text-embedding-3-large está no nível intermediário em jurídico e suporte ao cliente

O openai/text-embedding-3-large ocupa a posição 11 entre 15 modelos densos no CUAD, com 0.6430 de nDCG@3. Oito modelos estritamente mais baratos o superam em contratos jurídicos: os dois carros-chefe Voyage série 4 de $0,12, o voyage-3.5 pela metade do preço, o voyage-4-lite a 1/6 do preço, ambas as variantes de embedding Qwen3, intfloat/e5-large-v2 a 1/13 do preço e perplexity/pplx-embed-v1-0.6b (0.8031) a 1/32 do preço. O carro-chefe da OpenAI fica em 9 no TechQA (0.8581) e em 11 no MedRAG (0.9296). Em saúde, ele fica em um agrupamento superior apertado (diferença da posição 2nd à 11: 0.05 de nDCG@3). Em jurídico, a diferença é ampla e cara.

A $0,13 por 1M tokens de entrada, é 32x mais caro do que o pplx-embed-v1-0.6b. Equipes que optam pela OpenAI porque “é a escolha segura” estão pagando um prêmio que os dados dos 3 domínios não justificam.

pplx-embed-v1-0.6b alcança o nível superior por um trigésimo do preço dos carros-chefe comparáveis

O perplexity/pplx-embed-v1-0.6b a $0,004 por 1M tokens tem média de 0.8604 de nDCG@3 nos três domínios, atrás apenas dos quatro modelos Voyage, das duas variantes do Gemini e do qwen/qwen3-embedding-8b. Ele supera todos os modelos OpenAI e OSS da linha. Também supera o openai/text-embedding-3-large por 0.16 de nDCG@3 no CUAD, perde por 0.012 no TechQA (0.8457 vs 0.8581) e vence por 0.003 no MedRAG. O próximo modelo top-10 mais barato é o qwen/qwen3-embedding-8b a $0,010 (2.5x mais caro), também servido via OpenRouter.

Para plataformas de RAG com foco em custo em que o embedding é um item de custo relevante, o pplx-0.6b é a escolha clara. A diferença de 30-50x para o preço dos carros-chefe não compra nada em qualidade de recuperação, essencialmente nesses três domínios.

O BM25 fica a 0.02 do modelo denso mais fraco em resumos médicos

No MedRAG-PubMed, o BM25 pontua 0.7862 de nDCG@3 contra o baai/bge-m3 (modo denso) com 0.8038, uma diferença de 0.02. A busca lexical chega a 0.15 de sete dos quinze modelos densos nesse corpus (bge-m3, e5-base-v2, openai-3-small, e5-large-v2, openai-3-large, pplx-0.6b, qwen3-4b). O motivo é estrutural: consultas médicas são densas em palavras-chave por design (nomes de medicamentos, doenças, termos de design de estudo, símbolos de genes), e esses tokens carregam a maior parte do sinal de recuperação. Um scorer estilo Lucene os encontra diretamente sem precisar de contexto semântico.

Um reranker sobre o BM25 é uma alternativa plausível e mais barata a um embedder denso premium para corpora densos em palavras-chave: a lacuna de recuperação deixada pelo BM25 (0.2 de nDCG@3 para o nível superior no MedRAG) é o tipo de lacuna que um reranker Cohere ou Voyage pode fechar. No CUAD, a lacuna do BM25 para o melhor modelo denso é de 0.33, no TechQA 0.36, no MedRAG 0.20. A densidade do vocabulário do domínio é o maior determinante isolado de quanto os embeddings densos ajudam.

Especialistas de domínio vs generalistas entre fornecedores

A Voyage precifica o voyage-law-2 a $0,12/M, idêntico ao voyage-4-large. Os dois modelos compartilham fornecedor, tokenizer, SDK e esquema de invocação assimétrica. Apenas a ênfase dos dados de treinamento difere. Executar ambos contra generalistas em CUAD, TechQA e MedRAG isola o efeito do treinamento jurídico.

No CUAD, o voyage-law-2 ocupa a posição 1st com 0.9126: 0.0024 acima do voyage-3.5, 0.0146 acima do gemini-embedding-001, 0.040 acima do voyage-4-large, 0.097 acima do qwen3-embedding-8b e 0.270 acima do openai/text-embedding-3-large (0.6430). No TechQA, o voyage-law-2 fica em 4 com 0.9020, 0.064 atrás do voyage-4-large e 0.063 atrás do voyage-3.5. No MedRAG, fica em 6 com 0.9409, 0.045 atrás do voyage-4-large e 0.041 atrás do gemini-embedding-001. O treinamento jurídico aumenta o nDCG@3 no CUAD e o reduz nos outros dois domínios.

Uma equipe jurídica que implementa recuperação no estilo CUAD com openai/text-embedding-3-large opera com 0.6430 de nDCG@3, contra voyage-law-2 com 0.9126, uma lacuna de 0.27. Uma equipe de saúde ou suporte que escolhe o voyage-law-2 porque ele ficou em primeiro no CUAD perde 0.045 para o voyage-4-large no MedRAG e 0.064 no TechQA. Modelos de embedding especialistas de domínio não são substituições diretas para recuperação genérica. Uma única recomendação de “melhor modelo” entre setores erra em pelo menos uma direção.

Quando escolher o voyage-law-2: recuperação de contratos em corpora jurídicos comerciais que se assemelham estruturalmente ao CUAD. Quando não escolher: qualquer outra coisa neste benchmark. O voyage-3.5 custa $0,06/M, fica 0.0024 abaixo do voyage-law-2 no CUAD e o supera tanto no TechQA quanto no MedRAG.

Como o pipeline de recuperação por embedding foi avaliado

Cada modelo codifica um vetor de consulta e N vetores de documento por meio de um bi-encoder. Calculamos a similaridade de cosseno entre o vetor da consulta e cada vetor de documento e, em seguida, ordenamos o top-k para essa consulta. Com um documento gold por consulta e relevância binária, o avaliador verifica se o gold aparece no top-k e em qual posição. Essa posição alimenta o nDCG@3 (nossa métrica principal), o nDCG@10 (para comparabilidade com BEIR/MTEB), o Recall@10 e a taxa de acerto no Top-1.

Os codificadores de consulta e documento nem sempre são a mesma função. Alguns modelos são treinados de forma assimétrica: o lado da consulta aplica uma transformação, o lado do documento aplica outra. Invocar esses modelos de forma simétrica (“basta passar o texto”) degrada silenciosamente a qualidade da recuperação em 0.05-0.45 de nDCG@10. Nossa linha se divide em quatro grupos:

Por que nDCG@3 como métrica primária. Pipelines de RAG em produção alimentam os 3 a 5 principais trechos para o LLM, não os 10 principais. O viés de primazia em LLMs de contexto longo faz a posição 1 importar mais do que a posição 3, e cada distrator que fica acima do gold no contexto do LLM é candidato a confabulação. Rerankers achatariam esse efeito, mas a maioria dos RAGs em produção roda sem um por motivos de custo e latência, então a posição do embedder É a posição final.

No MedRAG, o Recall@10 atingiu o teto de 1.000 para três modelos Voyage e para o qwen3-8b; o nDCG@3 preservou uma dispersão de 0.10 nas mesmas consultas. O nDCG@10 mantém a comparabilidade com BEIR, mas suaviza as diferenças no topo da lista que importam operacionalmente.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Metodologia do benchmark de modelos de embedding

Corpora (seleção de domínio + por quê)

Escolhemos três domínios que tensionam diferentes propriedades de recuperação e que cobrem os três RAG empresariais mais comuns. Cada corpus é fixado por SHA256, para que qualquer leitor possa reproduzir exatamente a célula que executamos.

O PM209 (manuais de fabricação) foi descartado: apenas 209 documentos, pequeno demais para evitar o problema de atalho de entidade do BM25 em 150 consultas.

Geração de consultas: protocolo de consenso de 3 LLMs

Nossas consultas são geradas por LLM sob separação escritor-validador: o LLM que elabora uma consulta nunca julga seu próprio alvo de recuperação, então o autoviés é estruturalmente excluído. Somente os dois validadores não escritores, vendo os 20 candidatos embaralhados sem pista sobre qual era o documento de ancoragem do escritor, decidem a aceitação. Além do consenso de LLM, revisamos manualmente cerca de 25% do conjunto de consultas aceitas (revisão do autor sobre naturalidade da consulta, alinhamento com o documento-alvo e conformidade com R9, independente do voto do validador).

Cada consulta passou pelo seguinte pipeline antes de entrar no conjunto de produção:

1. Escritor elabora uma única consulta ancorada em um documento amostrado aleatoriamente. O escritor alterna entre Claude Sonnet 4.6, Qwen3.6-plus e Gemini 3 Flash preview para que nenhum modelo domine a impressão digital linguística.
2. Avaliador (fixo: Claude Sonnet 4.6) classifica a consulta em uma rubrica de especificidade. Exigimos semantic_bridge ≥ 4 (a consulta deve descrever semanticamente o que o documento afirma, não apenas corresponder por nome) e unique_referent entre 3 e 5 (as âncoras descritivas devem identificar aproximadamente de um a cinco documentos candidatos no corpus, não milhares nem exatamente um).
3. Verificação de hard negatives: Pegamos os 19 principais documentos distratores do BM25 mais o alvo e executamos um gate de Jaccard de quase duplicação (>0.5 → rejeita toda a consulta como verdade de referência ambígua).
4. Validadores (2 modelos, nunca incluindo o escritor) escolhem independentemente o documento-alvo do conjunto embaralhado de 20 candidatos. Ambos os validadores devem concordar com o slot exato do alvo, caso contrário a consulta é descartada. “Nenhuma das anteriores” e “múltiplas respostas corretas” são respostas válidas do validador e também descartam a consulta.
5. Kappa de Cohen calculado por par de validadores. Cada consulta teve exatamente 2 avaliadores (os não escritores do pool de 3 modelos), então os 3 pares possíveis que excluem o escritor nos dão 3 valores de kappa separados por domínio. Nós os reportamos individualmente e como média ponderada por n.

Kappa de Cohen por par com concordância observada po e esperada ao acaso pe, calculado sobre as consultas aceitas mais todas as rejeições consensus_fail em que ambos os validadores chegaram a uma decisão. As células mostram n / po / pe / κ:

A média ponderada por n é um resumo descritivo, não uma estatística inferencial. Ela condensa os três kappas por par em um único número ponderado por quantas consultas cada par julgou; não é em si um valor de kappa para um dataset agrupado, e o IC sobre ela precisaria ser calculado via reamostragem bootstrap no nível da consulta (adiado para a v2.1).

Usamos o kappa de Cohen (não o kappa de Fleiss nem o alfa de Krippendorff) porque cada consulta teve exatamente 2 avaliadores: o enquadramento natural aqui são 3 cálculos de Cohen pareados, já que queremos saber se quaisquer dois modelos específicos concordam, e não se um painel de 3 avaliadores é coerente. O alfa de Krippendorff daria um único número, mas misturaria os três pares e ocultaria a variância no nível do par.

Especificamente no CUAD: Claude × Qwen atinge κ=0.974, enquanto Claude × Gemini e Gemini × Qwen ficam em torno de κ=0.86, o que isola o Gemini-3-flash-preview como o juiz mais ruidoso em contratos jurídicos. Essa informação é um sinal metodológico que vale a pena destacar, não diluir em uma média.

Promovemos um domínio à produção após o kappa médio ponderado por n ultrapassar 0.85. Os três ultrapassaram. O 0.986 do MedRAG está efetivamente no teto: as duas divergências em 156 tentativas ocorreram em alvos medicamente ambíguos, em que ambos os validadores estavam internamente consistentes, mas um escolheu um resumo relacionado, porém não gold.

Conjunto de regras R9 de anonimização de entidades (por domínio)

O R9 é uma restrição rígida no momento da geração da consulta. Sem ele, o BM25 sobe acima de 0.97 de nDCG@10 porque entidades nomeadas funcionam como atalhos perfeitos de palavras-chave; os embeddings densos não têm vantagem semântica para medir. A regra é ajustada por domínio para que as âncoras que realmente carregam o sinal de recuperação naquele domínio permaneçam utilizáveis:

• CUAD estrito. Proíbe todas as entidades nomeadas: nomes de partes, nomes de estados dos EUA, pessoal, valores monetários em dólares exatos, nomes de produtos específicos. Força a singularidade descritiva: setor + função + era temporal + faixa monetária + escopo geográfico. O teto do BM25 caiu de 0.97 para 0.591 após a aplicação do R9.
• TechQA Opção X. Nomes de produtos IBM são permitidos (são o principal sinal de recuperação para um sysadmin) SE a consulta também contiver uma âncora descritiva secundária não relacionada a produto (classe de sintoma, família de código de erro, era de versão, contexto de implantação). Nomes de clientes, estados dos EUA e pessoal continuam proibidos. Teto do BM25: 0.664.
• MedRAG relaxado para termos médicos + seguro contra alucinação. Nomes de medicamentos, termos de doenças, anatomia e símbolos de genes são mantidos literalmente da fonte, porque substituir rótulos de classes de medicamentos arrisca alucinação farmacológica (“p-cloroanfetamina” é um liberador de serotonina da classe das anfetaminas, mas as traduções de rótulo de medicamentos mais raros por LLM falham silenciosamente). A consulta deve conter ≥2 âncoras não relacionadas a medicamentos para que a correspondência pura por palavra-chave do nome do medicamento não carregue o resultado. Teto do BM25: 0.809 (propriedade estrutural do domínio, não uma falha metodológica).

Exemplos de consultas

Para cada exemplo, a consulta é o texto que alimentamos ao modelo de embedding. O documento gold é o único item do corpus (dentre 509 contratos CUAD, 28.000 notas técnicas TechQA ou 50.000 resumos PubMed) que realmente responde à consulta. A tarefa de recuperação é: gerar o embedding da consulta, calcular a similaridade de cosseno em relação a cada documento do corpus e classificá-los. Se o documento gold ficar na posição 1, a consulta pontua 1.000 no nDCG@3; a posição 2 pontua 0.631; a posição 3 pontua 0.500; abaixo do top-3 pontua 0.

CUAD (jurídico)

Consulta:

Documento gold (1 de 509 contratos CUAD): ANIXABIOSCIENCESINC_06_09_2020-EX-10.1-COLLABORATION AGREEMENT. Trata-se de uma colaboração de 2020 entre uma empresa alemã e uma biotech dos EUA para descoberta de medicamentos contra COVID-19; o contrato especifica um pagamento de marco devido quando o primeiro paciente entrar na Fase I de um ensaio clínico. A consulta não contém nomes de partes, valores monetários nem geografias além de dois tokens de países; o sinal de recuperação é setor + temporal + estrutura de marco.

TechQA (suporte ao cliente)

Consulta:

Documento gold (1 de 28.000 notas técnicas IBM): swg1IY43185, que documenta exatamente esse bug do WebSEAL e nomeia o patch que o corrige. O nome de produto IBM (WebSEAL) é permitido sob nossa variante R9 do TechQA, mas o discriminador é o padrão comportamental do bug e a âncora de ordenação de requisições, não apenas o nome do produto.

MedRAG (saúde)

Consulta:

Documento gold (1 de 50.000 resumos PubMed): PMID:231299, um ensaio clínico comparando taxas de abandono por reações adversas entre cefradina e pivmecillinam em gestantes com infecções do trato urinário. Os nomes dos medicamentos são mantidos porque a comparação medicamento-versus-medicamento é o sinal de recuperação, mas a consulta adiciona população de pacientes + duração do tratamento + enquadramento de eventos adversos para que uma correspondência pura no BM25 pelo nome do medicamento não acerte o alvo sozinha.

Protocolo estatístico

Intervalos de confiança bootstrap de 95% usam 10.000 reamostragens, método percentil, seed=2026 sobre o vetor de métrica por consulta. Bootstrap pareado nos mesmos índices de consulta para significância pareada entre o modelo A e o modelo B (a afirmação exige ≥95% das reamostragens em que A > B).

Execução única por célula (modelo, domínio). A camada de variância entre sessões com 3 execuções foi adiada para a v2.1 por motivos de custo. Chamadas de API de embedding dentro da sessão são determinísticas dentro de alguns partes por milhão de diferença de cosseno, verificado em verificação pontual; portanto, o IC bootstrap captura o ruído no nível da consulta, que é a fonte de variância dominante em n=150-246.

Indexação e pontuação

Sem banco de vetores. Cada modelo codifica cada documento do corpus uma vez; a similaridade de cosseno é calculada diretamente no NumPy como um produto de matrizes densas de embeddings normalizados L2. Isso é exato, não aproximado, portanto empates de posição são empates reais de modelo, não artefatos de ANN.

Regra de chunking por modelo: modelos com contexto de 512 fazem chunk de 512+64 de sobreposição; modelos com contexto de 8K-20K fazem chunk até o limite do contexto sem sobreposição; modelos com contexto 32K+ ingerem o documento completo quando este cabe (a cauda longa de 9% do CUAD excede todas as janelas de contexto que não são Nemotron e cai para chunking; a imparcialidade entre modelos é preservada aplicando a mesma política por tamanho de contexto a todos os modelos).

A invocação de recuperação assimétrica por modelo é o detalhe metodológico mais impactante e merece uma seção dedicada. É a razão pela qual gemini-embedding-2-preview pontua 0.46 de nDCG@10 no exemplo de código documentado da OpenRouter, contra 0.91 no formato Vertex IA do Google. Veja “Como o pipeline de recuperação por embedding foi avaliado” acima para a tabela por família.

Framework de avaliação: ranx como motor primário de métricas; saída no estilo trec_eval compatível com submissões ao leaderboard do MTEB. O IC bootstrap foi calculado por scripts/bootstrap_ci.py sobre os arrays de métricas por consulta salvos na passada de avaliação.

Modelos testados

Os preços são de 2026-04-23, obtidos no catálogo do OpenRouter e na página de preços diretos da Voyage.

nDCG@3 por modelo com IC bootstrap de 95%

Intervalos de confiança bootstrap de 95% calculados via 10.000 reamostragens do vetor de métrica por consulta (método percentil, seed=2026). Larguras de IC de 0.03-0.07 nesses tamanhos de amostra (n=154-246) significam que diferenças de estimativa pontual abaixo de ~0.03 estão dentro do ruído e devem ser tratadas como empates. Ordenado pela média de nDCG@3 nos 3 domínios:

Quatro empates estatísticos em que as classificações por estimativa pontual não são significativas a 95% de IC:

Limitações

Revisão humana por um autor: Um autor revisou pontualmente cerca de 25% das consultas final aceitas quanto a naturalidade, alinhamento com o alvo e conformidade com R9.

Leitura adicional

Explore outros benchmarks de RAG, como:

• Top 10 Modelos de Embedding Multilíngues para RAG
• Top 16 Modelos de Embedding Open Source para RAG
• Top Bancos de Dados Vetoriais para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de Rerankers: Top 8 Modelos Comparados
• Modelos de Embedding Multimodais: Apple vs Meta vs OpenAI

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{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Modelos de Embedding: OpenAI vs Gemini vs Voyage}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/embedding-models}},
  note   = {AIMultiple. Acessado em 25 Abril 2026}
}

Registro de alterações

4 atualizações

1. 202624 Abr

   Substituído o benchmark por 15 modelos e uma linha de base BM25 testados em corpora jurídicos, de suporte ao cliente e de saúde.

2. 202525 Nov

   Adicionada a seção Razões potenciais por trás das diferenças de desempenho do modelo de incorporação.

3. 18 Jul

   Atualizada a seção Conclusão com novas recomendações de modelos.

4. 10 Jul

   Substituído Google por Gemini na introdução.

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Cientista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

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