Modelos de Embedding: OpenAI vs Gemini vs Voyage

Comparamos 15 modelos de embedding de texto em inglês e uma linha de base BM25 em mais de 500 consultas curadas manualmente em três domínios de recuperação: contratos legais (CUAD), suporte ao cliente (IBM TechQA) e saúde (MedRAG PubMed).

Voyage-3.5 fica em primeiro lugar no geral. Perplexity Embed V1 0.6b alcança o nível médio-superior ao menor preço em nosso benchmark.

Resultados do benchmark de modelos de embedding

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 de referência fica no top 3 e 0 caso contrário. Rank 1 pontua 1.000, rank 2 pontua 0.631, rank 3 pontua 0.500. Usamos nDCG@3 como métrica primária porque os pipelines de RAG em produção alimentam os 3 a 5 principais blocos no LLM, e o viés de primazia faz o rank 1 importar desproporcionalmente.

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

Recall@10: Fração de consultas em que o documento de referência aparece no top 10.

MRR@10: Rank recíproco médio no corte 10. Referência 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 penalidade de rank mais acentuada.

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

nDCG@3 por domínio

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

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

Saúde (MedRAG-PubMed, 154 consultas, 50.000 resumos): Saúde é o cluster mais apertado em 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 cluster superior. Piso BM25: 0.7862, a 0.02 do modelo denso mais fraco. gemini-embedding-001 também supera gemini-embedding-2-preview aqui por sua maior margem (+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 domínio classificará incorretamente nos outros.

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.

Acurácia vs 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 o snapshot do catálogo da OpenRouter do mesmo dia. Tokens de consulta e documento são precificados à mesma taxa em todos os fornecedores testados. O BM25 é plotado a $0.001/M para renderização em eixo logarítmico. O custo real auto-hospedado é $0.

Média de nDCG@3 entre 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 principais modelos comerciais e entrega 92% da qualidade do voyage-3.5 (0.8604 / 0.9429). Nenhum outro modelo em nosso benchmark compete nessa faixa de preço.
• Para RAG empresarial com foco em qualidade, o voyage-3.5 via SDK direto da Voyage ocupa o melhor ponto de Pareto. Você troca uma integração extra de API (em comparação com uma stack somente OpenRouter) por um modelo marginalmente melhor do que o principal modelo da própria 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, 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 é fornecido com pesos auto-hospedáveis.
• Os modelos premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) todos perdem para o voyage-3.5 na média entre os 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 entre os 3 domínios e supera o principal voyage-4-large pela metade do preço

voyage-3.5 tem média de 0.9429 nDCG@3 em legal, suporte ao cliente e saúde. O principal 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 principal vence o TechQA por 0.002 e vence o MedRAG por 0.032. Ele perde no CUAD por 0.037 (0.8730 vs 0.9102), o suficiente para que sua média entre os 3 domínios fique abaixo do voyage-3.5. Dentro da linha Voyage, o modelo intermediário mais antigo é a melhor escolha de uso geral. O principal só compensa seu preço premium em saúde.

A Voyage conquistou a primeira posição nos três domínios e varreu o top-2 em CUAD e TechQA. No MedRAG, gemini-embedding-001 entrou em 2nd lugar (0.9814, atrás dos 0.9855 do voyage-4-large), à frente de todos os outros modelos Voyage. 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 isolado.

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

google/gemini-embedding-001 (lançado em junho de 2025) supera 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 um aumento de preço de 33% ($0.20 vs $0.15 por 1M tokens de entrada). O enquadramento de “atualização multimodal mais nova” do Gemini 2 não se sustenta na recuperação de texto em inglês em corpora legais ou de saúde.

Para cargas de trabalho de RAG nesses dois domínios hoje, gemini-embedding-001 é a escolha correta da 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 é de nível intermediário em legal e suporte ao cliente

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

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

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

perplexity/pplx-embed-v1-0.6b a $0.004 por 1M tokens tem média de 0.8604 nDCG@3 nos três domínios, atrás apenas dos quatro modelos Voyage, das duas variantes Gemini e do qwen/qwen3-embedding-8b. Ele supera todos os modelos OpenAI e OSS na linha. Também supera o openai/text-embedding-3-large em 0.16 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 do top 10 mais barato é qwen/qwen3-embedding-8b a $0.010 (2.5x mais caro), também servido via OpenRouter.

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

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

No MedRAG-PubMed, o BM25 pontua 0.7862 nDCG@3 contra 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 neste corpus (bge-m3, e5-base-v2, openai-3-small, e5-large-v2, openai-3-large, pplx-0.6b, qwen3-4b). A razão é estrutural: consultas médicas são densas em palavras-chave por design (nomes de medicamentos, nomes de doenças, termos de desenho de estudo, símbolos de genes), e esses tokens carregam a maior parte do sinal de recuperação. Um scorer estilo Lucene os corresponde diretamente sem precisar de contexto semântico.

Um reranker em cima do BM25 é uma alternativa plausível e mais barata a um modelo de embedding denso premium para corpora densos em palavras-chave: a lacuna de recuperação que o BM25 deixa (0.2 nDCG@3 para o nível superior no MedRAG) é o tipo de lacuna que um reranker da Cohere ou da Voyage pode fechar. No CUAD, a lacuna do BM25 para o melhor modelo denso é 0.33, no TechQA 0.36, no MedRAG 0.20. A densidade de vocabulário do domínio é o maior determinante 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, tokenizador, SDK e esquema de invocação assimétrica. Apenas a ênfase nos dados de treinamento difere. Executar ambos contra generalistas em CUAD, TechQA e MedRAG isola o efeito do treinamento jurídico.

No CUAD, voyage-law-2 fica em 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, 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 eleva o nDCG@3 no CUAD e o reduz nos outros dois domínios.

Uma equipe jurídica que envia recuperação no estilo CUAD em openai/text-embedding-3-large opera com 0.6430 nDCG@3 contra voyage-law-2 com 0.9126, uma lacuna de 0.27. Uma equipe de saúde ou suporte que escolher voyage-law-2 porque ele ficou em primeiro no CUAD perde 0.045 para voyage-4-large no MedRAG e 0.064 no TechQA. Modelos de embedding especializados por domínio não são atualizaçõ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 voyage-law-2: recuperação de contratos em corpora jurídicos comerciais que estruturalmente se assemelham ao CUAD. Quando não escolher: qualquer outra coisa neste benchmark. 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 de embedding foi avaliado

Cada modelo codifica um vetor de consulta e N vetores de documentos por meio de um bi-encoder. Calculamos a similaridade de cosseno entre o vetor de consulta e cada vetor de documento e, em seguida, ordenamos o top-k para aquela consulta. Com um documento de referência por consulta e relevância binária, o avaliador verifica se o documento de referência aparece no top-k e em qual posição. Essa posição alimenta o nDCG@3 (nosso principal), nDCG@10 (para comparabilidade com BEIR/MTEB), Recall@10 e a taxa de acerto 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 simetricamente (“basta passar o texto”) degrada silenciosamente a qualidade de recuperação em 0.05-0.45 nDCG@10. Nossa linha se divide em quatro caminhos:

Por que nDCG@3 como principal. Os pipelines de RAG em produção alimentam os 3 a 5 principais blocos no LLM, não o top 10. O viés de primazia em LLMs de contexto longo faz o rank 1 importar mais do que o rank 3, e cada distrator que fica acima do documento de referência no contexto do LLM é um candidato a confabulação. Rerankers achatariam esse efeito, mas a maioria dos RAGs em produção roda sem um por razões de custo e latência, então o rank do embedder É o rank final.

No MedRAG, Recall@10 atingiu o teto de 1.000 para três modelos Voyage e para qwen3-8b; o nDCG@3 preservou uma dispersão de 0.10 nas mesmas consultas. O nDCG@10 mantém a comparabilidade com o 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 estressam 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 a célula exata que executamos.

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 3-LLM

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

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

1. Redator redige uma única consulta baseada em um documento amostrado aleatoriamente. O redator alterna entre Claude Sonnet 4.6, Qwen3.6-plus e Gemini 3 Flash preview para que nenhum modelo individual domine a impressão digital linguística.
2. Pontuador (fixo: Claude Sonnet 4.6) avalia 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 ao nome) e unique_referent em 3-5 (as âncoras descritivas devem identificar aproximadamente de um a cinco documentos candidatos no corpus, não milhares ou exatamente um).
3. Verificação de negativos difíceis: puxamos os 19 principais documentos distratores do BM25 mais o alvo e executamos um portão de Jaccard de quase duplicação (>0.5 → rejeitamos toda a consulta como verdade de referência ambígua).
4. Validadores (2 modelos, nunca incluindo o redator) escolhem independentemente o documento-alvo do conjunto embaralhado de 20 candidatos. Ambos os validadores devem concordar com o slot exato do alvo ou a consulta é descartada. “Nenhuma das anteriores” e “múltiplas respostas corretas” são respostas válidas dos validadores e também descartam a consulta.
5. Kappa de Cohen calculado por par de validadores. Cada consulta teve exatamente 2 avaliadores (os não redatores do pool de 3 modelos), portanto os 3 pares possíveis excluindo o redator nos dão 3 valores kappa separados por domínio. Nós os relatamos individualmente e como uma média ponderada por n.

Kappa de Cohen por par com concordância observada po e esperada ao acaso pe, calculado em 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 número ponderado por quantas consultas cada par julgou; não é em si um valor kappa para um conjunto de dados 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 pareados de Cohen, uma vez que queremos saber se quaisquer dois modelos específicos concordam, e não se um painel de 3 avaliadores coere. O alfa de Krippendorff daria um número único, 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 legais. Essa informação é um sinal metodológico que vale a pena destacar, não eliminar por média.

Promovemos um domínio à produção depois que o kappa médio ponderado por n ultrapassou 0.85. Todos os três ultrapassaram. O 0.986 do MedRAG está efetivamente no teto: as duas discordâncias em 156 tentativas foram em alvos medicamente ambíguos, onde ambos os validadores eram internamente consistentes, mas um escolheu um resumo relacionado, mas não referência.

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

R9 é uma restrição rígida no momento da geração de consultas. Sem ela, o BM25 sobe acima de 0.97 nDCG@10 porque entidades nomeadas atuam como atalhos perfeitos de palavras-chave; embeddings densos não têm vantagem semântica a medir. A regra é adaptada por domínio para que as âncoras que realmente carregam 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 específicos de produtos. 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 da 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 ao 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 medical-relaxed + hallucination-safe. 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-chloroamphetamine” é um liberador de serotonina da classe das anfetaminas, mas as traduções de rótulos de medicamentos mais raros pelo LLM falham silenciosamente). A consulta deve conter ≥2 âncoras não medicamentosas para que a correspondência pura de palavras-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).

Consultas de exemplo

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

CUAD (jurídico)

Consulta:

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

TechQA (suporte ao cliente)

Consulta:

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

MedRAG (saúde)

Consulta:

Documento de referência (1 de 50.000 resumos PubMed): PMID:231299, um ensaio clínico comparando taxas de abandono por reação adversa entre cefradina e pivmecilinam 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 evento adverso para que uma correspondência pura do 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 no vetor de métricas por consulta. Bootstrap pareado nos mesmos índices de consulta para significância pareada entre o modelo A e o modelo B (a afirmação requer ≥95% das reamostragens onde A > B).

Execução única por célula (modelo, domínio). Uma camada de variância entre sessões com 3 execuções é adiada para a v2.1 por razões de custo. Chamadas de API de embedding dentro da sessão são determinísticas dentro de algumas partes por milhão de diferença de cosseno, verificado em verificação pontual; o IC bootstrap, portanto, 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 matriz densa de embeddings normalizados por L2. Isso é exato, não aproximado, portanto empates de rank são empates genuínos do modelo, e não artefatos de ANN.

Regra de chunking por modelo: modelos de 512 ctx dividem em chunks com 512+64 de sobreposição; modelos de 8K-20K ctx dividem até o contexto sem sobreposição; modelos de 32K+ ctx ingerem o documento completo quando ele cabe (a cauda longa de 9% do CUAD excede todas as janelas de contexto não Nemotron e recorre ao chunking; a justiça entre modelos é preservada aplicando a mesma política por tamanho de contexto a todos os modelos).

A invocação assimétrica de recuperação por modelo é o detalhe metodológico de maior impacto e merece uma seção dedicada. É a razão pela qual gemini-embedding-2-preview pontua 0.46 nDCG@10 no exemplo de código documentado da OpenRouter versus 0.91 no formato Vertex IA do Google. Consulte “Como o pipeline de recuperação de 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 MTEB. IC bootstrap 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, do catálogo da OpenRouter e da 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étricas por consulta (método percentil, seed=2026). Larguras de IC de 0.03-0.07 nesses tamanhos de amostra (n=154-246) significam que lacunas 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 entre 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 por amostragem cerca de 25% das consultas finais aceitas quanto a naturalidade, alinhamento ao 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 de Código Aberto para RAG
• Top banco de vetores para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de Rerankers: Top 8 Modelos Comparados
• Modelos de Embedding Multimodais: Apple vs Meta vs OpenAI
• RAG híbrido: aumentando a acurácia do RAG
• RAG de Grafo 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{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}
}

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Analista 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