Modelos de Embedding: OpenAI vs Gemini vs Voyage

Evaluamos 15 modelos de embedding de texto en inglés y una línea base BM25 en más de 500 consultas curadas manualmente en tres dominios de recuperación: contratos legales (CUAD), soporte al cliente (IBM TechQA) y atención médica (MedRAG PubMed).

Voyage-3.5 ocupa el primer lugar general. Perplexity Embed V1 0.6b alcanza el nivel medio-alto al precio más bajo de nuestro benchmark.

Resultados del benchmark de modelos de embedding

Métricas explicadas

nDCG@3: Ganancia acumulativa descontada normalizada con corte en 3. Con un documento relevante por consulta, es 1 / log2(posición + 1) cuando el documento dorado aparece entre los 3 primeros, y 0 en caso contrario. La posición 1 puntúa 1.000, la posición 2 puntúa 0.631, la posición 3 puntúa 0.500. Usamos nDCG@3 como métrica principal porque los pipelines de RAG en producción alimentan al LLM con los 3 a 5 fragmentos principales, y el sesgo de primacía hace que la posición 1 importe desproporcionadamente.

nDCG@10: Misma fórmula con corte en 10.

Recall@10: Fracción de consultas donde el documento dorado aparece entre los 10 primeros.

MRR@10: Rango recíproco medio con corte en 10. El documento dorado en posición 1 puntúa 1.000, posición 2 puntúa 0.500, y posición 10 puntúa 0.100. Intención similar a nDCG@3 pero con una penalización de rango más pronunciada.

Acierto Top-1: Fracción de consultas donde el documento relevante dorado es el único resultado principal. La métrica más estricta y la más cercana a un flujo de trabajo de búsqueda sin LLM.

nDCG@3 por dominio

Legal (CUAD, 246 consultas, 509 contratos): El dominio legal es el único donde gana el especialista voyage-law-2; sus datos de entrenamiento ajustados a CUAD dan frutos con +0.040 nDCG@3 sobre voyage-4-large. openai/text-embedding-3-large ocupa el puesto 11º con 0.6430, por debajo de seis modelos más baratos. Suelo de BM25: 0.5844.

Soporte al cliente (TechQA, 151 consultas, 28,000 notas técnicas de IBM): La brecha entre voyage-4-lite y el siguiente modelo es de 0.018. gemini-embedding-001 cae al 7º puesto (0.8856), 0.045 por detrás de su hermano más reciente en TechQA, aunque gana en los otros dos dominios. Suelo de BM25: 0.6097.

Atención médica (MedRAG-PubMed, 154 consultas, 50,000 resúmenes): El dominio médico es el clúster más compacto de nuestro benchmark (14 modelos puntúan por encima de 0.88) porque el vocabulario médico es denso en palabras clave, lo que empuja la mayoría de las consultas al clúster superior. Suelo de BM25: 0.7862, a menos de 0.02 del modelo denso más débil. gemini-embedding-001 también supera a gemini-embedding-2-preview por su margen más amplio aquí (+0.013).

Los cambios a nivel de dominio justifican el enfoque de promedio en 3 dominios: ningún dominio único es un proxy justo para determinar "qué modelo es mejor", y un comprador que elija basándose en un solo dominio se equivocará en los otros.

Los intervalos de confianza bootstrap al 95% por modelo para cada celda de dominio, junto con los cuatro empates por pares que las clasificaciones de estimación puntual ocultan, se detallan en la sección de metodología.

Precisión vs precio: Coste por 1M tokens

Métricas explicadas

Precio por 1M tokens de entrada es el precio de lista para hacer embedding de 1M tokens de entrada, a fecha 2026-04-23. Los precios de Voyage provienen de la página de precios directa de Voyage. Los modelos servidos por OpenRouter usan la instantánea del catálogo de OpenRouter del mismo día. Los tokens de consulta y documento tienen el mismo precio en todos los proveedores evaluados. BM25 se sitúa en $0.001/M para la representación en eje logarítmico. El coste real autoalojado es $0.

Promedio nDCG@3 en 3 dominios es la media no ponderada del nDCG@3 por dominio en los tres corpus. Cada dominio contribuye por igual al promedio independientemente del número de consultas.

• Para plataformas RAG con prioridad de coste, pplx-embed-v1-0.6b es la elección clara. A $0.004/M es 30-50x más barato que cualquiera de los buques insignia comerciales y ofrece el 92% de la calidad de voyage-3.5 (0.8604 / 0.9429). Ningún otro modelo en nuestro benchmark compite en su punto de precio.

• Para RAG empresarial con prioridad de calidad, voyage-3.5 a través del SDK directo de Voyage ocupa el punto Pareto superior. Se sacrifica una integración de API adicional (frente a un stack basado solo en OpenRouter) por un modelo ligeramente mejor que el buque insignia de Voyage a mitad de precio. El instinto de "elegir siempre el más nuevo y más grande" es incorrecto dentro del catálogo de Voyage.

• Para despliegues OSS / autoalojables / on-premise, qwen3-embedding-8b gana. Es el embedder no trivial más barato de nuestro benchmark a $0.010/M, iguala o supera a todas las demás familias de codificadores OSS que probamos, y se distribuye con pesos autoalojables.

• Los buques insignia premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) pierden todos frente a voyage-3.5 en el promedio de 3 dominios, aunque voyage-3.5 es 2-3x más barato que cualquiera de ellos.

Hallazgos clave del benchmark de embedding

voyage-3.5 gana el promedio de 3 dominios y supera al buque insignia voyage-4-large a mitad de precio

voyage-3.5 promedia 0.9429 nDCG@3 en los dominios legal, soporte al cliente y atención médica. El buque insignia voyage-4-large promedia 0.9416 a $0.12 por 1M tokens, 2x el precio de $0.06 de voyage-3.5. El buque insignia gana en TechQA por 0.002 y gana en MedRAG por 0.032. Pierde en CUAD por 0.037 (0.8730 vs 0.9102), lo suficiente para que su promedio de 3 dominios quede por debajo de voyage-3.5. Dentro de la línea de Voyage, el modelo de gama media más antiguo es la mejor opción de propósito general. El buque insignia solo justifica su prima en atención médica.

Voyage ocupó el primer puesto en los tres dominios y barrió los dos primeros puestos en CUAD y TechQA. En MedRAG, gemini-embedding-001 irrumpió en el 2º puesto (0.9814, por detrás del 0.9855 de voyage-4-large), por delante de todos los demás modelos de Voyage. gemini-001 también alcanza el tercer puesto en CUAD. Ningún otro modelo no-Voyage alcanza los 2 primeros en ningún dominio individual.

Un modelo legacy de Gemini supera a su hermano "preview" más reciente en dos de tres dominios

google/gemini-embedding-001 (publicado en junio de 2025) supera a google/gemini-embedding-2-preview tanto en CUAD (0.8980 vs 0.8958) como en MedRAG (0.9814 vs 0.9685). El modelo más reciente solo gana en TechQA (0.9301 vs 0.8856), una brecha de 0.04 que viene acompañada de un aumento de precio del 33% ($0.20 vs $0.15 por 1M tokens de entrada). El encuadre de "actualización multimodal más reciente" de Gemini 2 no se sostiene en la recuperación de texto en inglés en corpus legales o médicos.

Para cargas de trabajo de RAG en esos dos dominios hoy, gemini-embedding-001 es la elección correcta de Gemini. El vuelco en MedRAG (001 en 2º, 2-preview en 3º) es lo suficientemente grande como para que un comprador que opte por el modelo "más reciente" pierda calidad medible.

OpenAI text-embedding-3-large está en el nivel medio en legal y soporte al cliente

openai/text-embedding-3-large ocupa el puesto 11º de 15 modelos densos en CUAD con 0.6430 nDCG@3. Ocho modelos estrictamente más baratos lo superan en contratos legales: ambos buques insignia Voyage serie 4 a $0.12, voyage-3.5 a mitad de precio, voyage-4-lite a 1/6 del precio, ambas variantes de embedding Qwen3, intfloat/e5-large-v2 a 1/13 del precio, y perplexity/pplx-embed-v1-0.6b (0.8031) a 1/32 del precio. El buque insignia de OpenAI queda 9º en TechQA (0.8581) y 11º en MedRAG (0.9296). En atención médica se sitúa en un clúster superior muy compacto (dispersión del 2º al 11º: 0.05 nDCG@3). En el dominio legal la brecha es amplia y costosa.

A $0.13 por 1M tokens de entrada es 32x más caro que pplx-embed-v1-0.6b. Los equipos que eligen OpenAI por defecto porque "es la opción segura" están pagando una prima que los datos de 3 dominios no justifican.

pplx-embed-v1-0.6b alcanza el nivel superior a una trigésima parte del precio de buques insignia comparables

perplexity/pplx-embed-v1-0.6b a $0.004 por 1M tokens promedia 0.8604 nDCG@3 en los tres dominios, solo por detrás de los cuatro modelos de Voyage, las dos variantes de Gemini y qwen/qwen3-embedding-8b. Supera a todos los modelos de OpenAI y OSS en la comparativa. También supera a openai/text-embedding-3-large por 0.16 nDCG@3 en CUAD, pierde por 0.012 en TechQA (0.8457 vs 0.8581), y gana por 0.003 en MedRAG. El siguiente modelo del top-10 más barato es qwen/qwen3-embedding-8b a $0.010 (2.5x más), también servido a través de OpenRouter.

Para plataformas RAG con prioridad de coste donde el embedding es una partida material, pplx-0.6b es la elección clara. La brecha de precio de 30-50x frente a los precios de los buques insignia no compra nada en calidad de recuperación, esencialmente en estos tres dominios.

BM25 está a menos de 0.02 del modelo denso más débil en resúmenes médicos

En MedRAG-PubMed, BM25 obtiene 0.7862 nDCG@3 frente a baai/bge-m3 (modo denso) con 0.8038, una brecha de 0.02. La búsqueda léxica se sitúa a menos de 0.15 de siete de los quince modelos densos en este corpus (bge-m3, e5-base-v2, openai-3-small, e5-large-v2, openai-3-large, pplx-0.6b, qwen3-4b). La razón es estructural: las consultas médicas son densas en palabras clave por diseño (nombres de fármacos, nombres de enfermedades, términos de diseño de estudios, símbolos de genes), y esos tokens transportan la mayor parte de la señal de recuperación. Un motor de puntuación tipo Lucene los empareja directamente sin necesidad de contexto semántico.

Un reranker sobre BM25 es una alternativa plausible y más barata a un embedder denso premium para corpus densos en palabras clave: la brecha de recuperación que deja BM25 (0.2 nDCG@3 respecto al nivel superior en MedRAG) es el tipo de brecha que un reranker de Cohere o Voyage puede cerrar. En CUAD la brecha de BM25 al mejor modelo denso es de 0.33, en TechQA de 0.36, en MedRAG de 0.20. La densidad de vocabulario del dominio es el mayor determinante de cuánto ayudan los embeddings densos.

Especialistas de dominio vs generalistas entre proveedores

Voyage valora voyage-law-2 a $0.12/M, idéntico a voyage-4-large. Los dos modelos comparten proveedor, tokenizador, SDK y esquema de invocación asimétrica. Solo difiere el énfasis de los datos de entrenamiento. Ejecutar ambos contra generalistas en CUAD, TechQA y MedRAG aísla el efecto del entrenamiento legal.

En CUAD, voyage-law-2 ocupa el 1º puesto con 0.9126: 0.0024 por encima de voyage-3.5, 0.0146 por encima de gemini-embedding-001, 0.040 por encima de voyage-4-large, 0.097 por encima de qwen3-embedding-8b, y 0.270 por encima de openai/text-embedding-3-large (0.6430). En TechQA, voyage-law-2 ocupa el 4º puesto con 0.9020, 0.064 por detrás de voyage-4-large y 0.063 por detrás de voyage-3.5. En MedRAG, ocupa el 6º puesto con 0.9409, 0.045 por detrás de voyage-4-large y 0.041 por detrás de gemini-embedding-001. El entrenamiento legal eleva el nDCG@3 en CUAD y lo reduce en los otros dos dominios.

Un equipo legal que despliegue recuperación tipo CUAD con openai/text-embedding-3-large funciona a 0.6430 nDCG@3 frente a voyage-law-2 a 0.9126, una brecha de 0.27. Un equipo de atención médica o soporte que elija voyage-law-2 porque quedó primero en CUAD pierde 0.045 frente a voyage-4-large en MedRAG y 0.064 en TechQA. Los modelos de embedding especializados por dominio no son mejoras directas para la recuperación genérica. Una única recomendación del "mejor modelo" para todos los sectores se equivoca en al menos una dirección.

Cuándo elegir voyage-law-2: recuperación de contratos en corpus legales comerciales que se asemejen estructuralmente a CUAD. Cuándo no: cualquier otra cosa en este benchmark. voyage-3.5 cuesta $0.06/M, queda 0.0024 por debajo de voyage-law-2 en CUAD, y lo supera tanto en TechQA como en MedRAG.

Cómo se evaluó el pipeline de recuperación con embedding

Cada modelo codifica un vector de consulta y N vectores de documento mediante un bi-encoder. Calculamos la similitud coseno entre el vector de consulta y cada vector de documento, luego ordenamos los top-k para esa consulta. Con un documento dorado por consulta y relevancia binaria, el evaluador verifica si el documento dorado aparece en el top-k y en qué posición. Esa posición alimenta nDCG@3 (nuestra métrica principal), nDCG@10 (para comparabilidad con BEIR/MTEB), Recall@10 y tasa de acierto Top-1.

Los codificadores de consulta y documento no siempre son la misma función. Algunos modelos se entrenan de forma asimétrica: el lado de consulta aplica una transformación, el lado de documento aplica otra. Invocar esos modelos de forma simétrica ("simplemente pasa el texto") degrada silenciosamente la calidad de recuperación entre 0.05-0.45 nDCG@10. Nuestra comparativa se divide en cuatro vertientes:

Por qué nDCG@3 como métrica principal. Los pipelines de RAG en producción alimentan al LLM con los 3 a 5 fragmentos principales, no con los 10 principales. El sesgo de primacía en los LLMs de contexto largo hace que la posición 1 importe más que la posición 3, y cada distractor que aparezca por encima del documento dorado en el contexto del LLM es candidato a confabulación. Los rerankers aplanarían este efecto, pero la mayoría de los RAGs en producción funcionan sin uno por razones de coste y latencia, por lo que la posición del embedder ES la posición final.

En MedRAG, Recall@10 alcanzó el techo de 1.000 para tres modelos de Voyage y para qwen3-8b; nDCG@3 preservó una dispersión de 0.10 en las mismas consultas. nDCG@10 mantiene la comparabilidad con BEIR pero suaviza las diferencias en los primeros puestos que importan operativamente.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Metodología del benchmark de modelos de embedding

Corpus (selección de dominios y justificación)

Elegimos tres dominios que ponen a prueba diferentes propiedades de recuperación y que cubren los tres RAG empresariales más comunes. Cada corpus está fijado por SHA256, por lo que cualquier lector puede reproducir la celda exacta que ejecutamos.

PM209 (manuales de fabricación) fue descartado: solo 209 documentos, demasiado pequeño para evitar el problema de atajo de entidades de BM25 con 150 consultas.

Generación de consultas: protocolo de consenso de 3 LLMs

Nuestras consultas son generadas por LLMs bajo separación escritor-validador: el LLM que redacta una consulta nunca juzga su propio objetivo de recuperación, por lo que el sesgo propio queda estructuralmente excluido. Solo los dos validadores no escritores, viendo los 20 candidatos barajados sin pistas sobre cuál era el documento base del escritor, deciden la aceptación. Además del consenso de LLMs, revisamos puntualmente aproximadamente el 25% del conjunto de consultas aceptadas a mano (revisión del autor sobre naturalidad de la consulta, alineación con el documento objetivo y cumplimiento R9, independientemente del voto de los validadores).

Cada consulta pasó el siguiente pipeline antes de entrar en el conjunto de producción:

1. Escritor redacta una única consulta basada en un documento muestreado aleatoriamente. El escritor rota entre Claude Sonnet 4.6, Qwen3.6-plus y Gemini 3 Flash preview para que ningún modelo único domine la huella lingüística.
2. Evaluador (fijo: Claude Sonnet 4.6) califica la consulta en una rúbrica de especificidad. Exigimos semantic_bridge ≥ 4 (la consulta debe describir semánticamente lo que el documento afirma, no solo coincidir por nombre) y unique_referent en 3-5 (los anclajes descriptivos deben identificar aproximadamente de uno a cinco documentos candidatos en el corpus, no miles ni exactamente uno).
3. Verificación de negativos duros: Tomamos los 19 documentos distractores principales de BM25 más el objetivo y ejecutamos un filtro Jaccard de casi duplicados (>0.5 → rechazar toda la consulta como verdad terreno ambigua).
4. Validadores (2 modelos, nunca incluyendo al escritor) seleccionan independientemente el documento objetivo del conjunto barajado de 20 candidatos. Ambos validadores deben coincidir en el espacio objetivo exacto o la consulta se descarta. "Ninguna de las anteriores" y "múltiples respuestas correctas" son respuestas válidas de los validadores y también descartan la consulta.
5. Kappa de Cohen calculada por par de validadores. Cada consulta tuvo exactamente 2 evaluadores (los no escritores del grupo de 3 modelos), por lo que los 3 posibles pares excluyendo al escritor nos dan 3 valores kappa separados por dominio. Los reportamos individualmente y como media ponderada por n.

Kappa de Cohen por par con acuerdo observado po y esperado por azar pe, calculada sobre consultas aceptadas más todos los rechazos consensus_fail donde ambos validadores llegaron a una decisión. Las celdas muestran n / po / pe / κ:

La media ponderada por n es un resumen descriptivo, no una estadística inferencial. Condensa las tres kappas por par en un solo número ponderado por cuántas consultas juzgó cada par; no es en sí mismo un valor kappa para un conjunto de datos agrupado, y el IC sobre él necesitaría calcularse mediante remuestreo bootstrap a nivel de consulta (diferido a v2.1).

Usamos la kappa de Cohen (no la kappa de Fleiss ni el alfa de Krippendorff) porque cada consulta tuvo exactamente 2 evaluadores: el enfoque natural aquí son 3 cálculos de Cohen por pares, ya que queremos saber si dos modelos específicos cualesquiera están de acuerdo, no si un panel de 3 evaluadores es coherente. El alfa de Krippendorff daría un solo número pero mezclaría los tres pares y ocultaría la varianza a nivel de par.

CUAD específicamente: Claude × Qwen alcanza κ=0.974 mientras que Claude × Gemini y Gemini × Qwen se sitúan alrededor de κ=0.86, lo que aísla a Gemini-3-flash-preview como el juez más ruidoso en contratos legales. Esa información es una señal metodológica que vale la pena mostrar, no promediar.

Promovimos un dominio a producción después de que la media ponderada por n de kappa superara 0.85. Los tres lo superaron. El 0.986 de MedRAG es efectivamente el techo: los dos desacuerdos en 156 intentos fueron en objetivos médicamente ambiguos donde ambos validadores eran internamente consistentes pero uno eligió un resumen relacionado pero no dorado.

Conjunto de reglas R9 de anonimización de entidades (por dominio)

R9 es una restricción estricta en el momento de generación de consultas. Sin ella, BM25 supera 0.97 nDCG@10 porque las entidades nombradas actúan como atajos perfectos de palabras clave; los embeddings densos no tienen margen semántico que medir. La regla se adapta por dominio para que los anclajes que realmente transportan la señal de recuperación en ese dominio sigan siendo utilizables:

• CUAD estricto. Prohibir todas las entidades nombradas: nombres de partes, nombres de estados de EE. UU., personal, montos monetarios en dólares exactos, nombres de productos específicos. Forzar unicidad descriptiva: sector + rol + era temporal + rango monetario + alcance geográfico. El techo de BM25 bajó de 0.97 a 0.591 tras aplicar R9.
• TechQA Opción X. Nombres de productos de IBM permitidos (son la señal de recuperación principal para un administrador de sistemas) SI la consulta también contiene un anclaje descriptivo secundario no relacionado con el producto (clase de síntoma, familia de códigos de error, era de versión, contexto de despliegue). Nombres de clientes, estados de EE. UU., personal siguen prohibidos. Techo de BM25: 0.664.
• MedRAG relajado para médicos + seguro contra alucinaciones. Nombres de fármacos, términos de enfermedades, anatomía, símbolos de genes se conservan textualmente de la fuente porque sustituir etiquetas de clase de fármaco arriesga alucinaciones farmacológicas ("p-cloroanfetamina" es un liberador de serotonina de clase anfetamínica, pero las traducciones de etiquetas de fármacos raros por LLMs fallan silenciosamente). La consulta debe contener ≥2 anclajes no farmacológicos para que la coincidencia pura por nombre de fármaco no determine el resultado. Techo de BM25: 0.809 (propiedad estructural del dominio, no un defecto metodológico).

Consultas de ejemplo

Para cada ejemplo, la consulta es el texto que alimentamos al modelo de embedding. El documento dorado es el único elemento en el corpus (de 509 contratos CUAD, 28,000 notas técnicas TechQA o 50,000 resúmenes PubMed) que realmente responde a la consulta. La tarea de recuperación es: hacer embedding de la consulta, calcular la similitud coseno con cada documento del corpus y ordenarlos. Si el documento dorado queda en la posición 1, la consulta puntúa 1.000 en nDCG@3; posición 2 puntúa 0.631; posición 3 puntúa 0.500; por debajo del top-3 puntúa 0.

CUAD (legal)

Consulta:

Documento dorado (1 de 509 contratos CUAD): ANIXABIOSCIENCESINC_06_09_2020-EX-10.1-COLLABORATION AGREEMENT. Es una colaboración de 2020 entre una empresa alemana y una biotecnológica estadounidense para el descubrimiento de fármacos contra COVID-19; el contrato especifica un pago por hito a realizar cuando el primer paciente entre en la Fase I de un ensayo clínico. La consulta no contiene nombres de partes, montos monetarios ni geografías más allá de dos tokens de país; la señal de recuperación es sector + temporal + estructura de hitos.

TechQA (soporte al cliente)

Consulta:

Documento dorado (1 de 28,000 notas técnicas de IBM): swg1IY43185, que documenta exactamente ese bug de WebSEAL y nombra el parche que lo soluciona. El nombre del producto de IBM (WebSEAL) está permitido bajo nuestra variante R9 de TechQA, pero el discriminador es el patrón de comportamiento del bug y el anclaje de ordenamiento de solicitudes, no solo el nombre del producto.

MedRAG (atención médica)

Consulta:

Documento dorado (1 de 50,000 resúmenes PubMed): PMID:231299, un ensayo clínico que compara las tasas de abandono por reacciones adversas entre cefradina y pivmecillinam en mujeres embarazadas con infecciones del tracto urinario. Los nombres de fármacos se conservan porque la comparación fármaco-contra-fármaco es la señal de recuperación, pero la consulta añade población de pacientes + duración del tratamiento + encuadre de eventos adversos para que una coincidencia BM25 pura por nombre de fármaco no acierte el objetivo por sí sola.

Protocolo estadístico

Los intervalos de confianza bootstrap al 95% usan 10,000 remuestreos, método percentil, semilla=2026 sobre el vector de métrica por consulta. Bootstrap emparejado sobre los mismos índices de consulta para significancia por pares entre el modelo A y el modelo B (la afirmación requiere ≥95% de remuestreos donde A > B).

Una sola ejecución por celda (modelo, dominio). Una capa de varianza entre sesiones de 3 ejecuciones se difiere a v2.1 por razones de coste. Las llamadas a la API de embedding dentro de una sesión son determinísticas dentro de unas pocas partes por millón de diferencia coseno, verificado en comprobaciones puntuales; el IC bootstrap captura por tanto el ruido a nivel de consulta, que es la fuente de varianza dominante con n=150-246.

Indexación y puntuación

Sin base de datos vectorial. Cada modelo codifica cada documento del corpus una vez; la similitud coseno se calcula directamente en NumPy como un producto de matriz densa de embeddings normalizados L2. Esto es exacto, no aproximado, por lo que los empates de posición son empates genuinos del modelo y no artefactos ANN.

Regla de fragmentación por modelo: modelos de 512 ctx fragmentan con solapamiento de 512+64; modelos de 8K-20K ctx fragmentan al contexto sin solapamiento; modelos de 32K+ ctx ingieren el documento completo cuando cabe (el 9% de cola larga de CUAD excede toda ventana de contexto que no sea Nemotron y recurre a fragmentación; la equidad entre modelos se preserva aplicando la misma política por tamaño de contexto a cada modelo).

La invocación de recuperación asimétrica por modelo es el detalle metodológico de mayor impacto y merece una sección dedicada. Es la razón por la que gemini-embedding-2-preview puntúa 0.46 nDCG@10 bajo el ejemplo de código documentado de OpenRouter frente a 0.91 bajo el formato Vertex IA de Google. Consulte "Cómo se evaluó el pipeline de recuperación con embedding" más arriba para la tabla por familia.

Framework de evaluación: ranx como motor principal de métricas; salida compatible con trec_eval para envíos al leaderboard MTEB. IC bootstrap calculado por scripts/bootstrap_ci.py sobre los arrays de métrica por consulta guardados en el pase de evaluación.

Modelos evaluados

Los precios son a fecha 2026-04-23 del catálogo de OpenRouter y la página de precios directa de Voyage.

nDCG@3 por modelo con IC bootstrap al 95%

Intervalos de confianza bootstrap al 95% calculados mediante 10,000 remuestreos del vector de métrica por consulta (método percentil, semilla=2026). Las amplitudes de IC de 0.03-0.07 con estos tamaños muestrales (n=154-246) significan que las brechas de estimación puntual por debajo de ~0.03 están dentro del ruido y deben tratarse como empates. Ordenado por promedio de nDCG@3 en 3 dominios:

Cuatro empates estadísticos donde las clasificaciones de estimación puntual no son significativas al IC del 95%:

Limitaciones

Revisión humana por un autor: Un autor revisó puntualmente aproximadamente el 25% de las consultas finales aceptadas en cuanto a naturalidad, alineación con el objetivo y cumplimiento R9.

Lecturas adicionales

Explore otros benchmarks de RAG, como:

• Top 10 Modelos de Embedding Multilingües para RAG
• Top 16 Modelos de Embedding de Código Abierto para RAG
• Top Bases de Datos Vectoriales para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de Rerankers: Top 8 Modelos Comparados
• Modelos de Embedding Multimodal: Apple vs Meta vs OpenAI
• RAG Híbrido: Mejorando la Precisión de RAG
• Graph RAG vs Vector RAG

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@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. Recuperado el 25 de Abril de 2026}
}

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA en AIMultiple, donde se centra en la automatización inteligente, las GPU, los agentes de IA y los marcos de trabajo RAG.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario