Modelos de embedding: OpenAI vs Gemini vs Voyage

Hicimos un benchmark de 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 en 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 acumulada descontada normalizada con corte en 3. Con un documento relevante por consulta, es 1 / log2(rango + 1) cuando el documento dorado queda en los 3 primeros, y 0 en caso contrario. El rango 1 puntúa 1.000, el rango 2 puntúa 0.631, el rango 3 puntúa 0.500. Usamos nDCG@3 como métrica principal porque los pipelines de RAG en producción alimentan los 3 a 5 fragmentos principales al LLM, y el sesgo de primacía hace que el rango 1 importe de manera desproporcionada.

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 el rango 1 puntúa 1.000, el rango 2 puntúa 0.500, y el rango 10 puntúa 0.100. Intención similar a nDCG@3, pero con una penalización de rango más pronunciada.

Acierto en 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): Legal es el único dominio donde gana el especialista voyage-law-2; sus datos de entrenamiento ajustados a CUAD rinden +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 BM25: 0.5844.

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

Atención médica (MedRAG-PubMed, 154 consultas, 50.000 resúmenes): La atención médica es el clúster más cerrado 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 a la mayoría de las consultas al clúster superior. Suelo BM25: 0.7862, a 0.02 del modelo denso más débil. gemini-embedding-001 también supera a gemini-embedding-2-preview por su mayor margen aquí (+0.013).

Los vuelcos a nivel de dominio justifican el enfoque de promedio de 3 dominios: ningún dominio individual es un proxy justo de “qué modelo es el mejor”, y un comprador que elija basándose en un solo dominio cometerá errores de clasificación en los demás.

Los intervalos de confianza bootstrap por modelo del 95 % para cada celda de dominio, junto con los cuatro empates por pares que ocultan las clasificaciones de estimación puntual, 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 el embedding de 1M tokens de entrada, a fecha de 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 representa a $0.001/M para el renderizado en eje logarítmico. El coste real de autoalojamiento es $0.

Promedio de 3 dominios nDCG@3 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 de RAG con prioridad en coste, pplx-embed-v1-0.6b es la elección clara. A $0.004/M es entre 30 y 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 de nuestro benchmark compite en su mismo precio.
• Para RAG empresarial con prioridad en calidad, voyage-3.5 a través del SDK directo de Voyage logra el punto Pareto superior. Cambias una integración API adicional (frente a una pila exclusiva de OpenRouter) por un modelo ligeramente mejor que el buque insignia de Voyage a mitad de precio. El instinto de “elegir siempre lo más nuevo y lo más grande” es erróneo dentro del catálogo de Voyage.
• Para implementaciones 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 frente a voyage-3.5 en el promedio de 3 dominios, aunque voyage-3.5 es entre 2 y 3x más barato que cualquiera de ellos.

Conclusiones 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 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 voyage-3.5 de $0.06. El buque insignia gana en TechQA por 0.002 y 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 gama 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ó el top-2 en CUAD y TechQA. En MedRAG, gemini-embedding-001 irrumpió en el 2nd puesto (0.9814, por detrás de voyage-4-large con 0.9855), por delante de todos los demás modelos de Voyage. gemini-001 también alcanza el tercer puesto en CUAD. Ningún otro modelo que no sea de Voyage alcanza el top 2 en un solo dominio.

Un modelo heredado de Gemini supera a su hermano más nuevo “preview” en dos de tres dominios

google/gemini-embedding-001 (lanzado 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 nuevo solo gana en TechQA (0.9301 vs 0.8856), una brecha de 0.04 que viene con un aumento de precio del 33 % ($0.20 vs $0.15 por 1M tokens de entrada). El encuadre de “actualización multimodal más nueva” de Gemini 2 no se sostiene en la recuperación de texto en inglés en corpus legales o de atención médica.

Para las 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 el 2nd, 2-preview en el 3rd) es lo bastante grande como para que un comprador que se limite al modelo “más nuevo” pierda una calidad medible.

OpenAI text-embedding-3-large es de 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: los dos buques insignia de la serie Voyage 4 a $0.12, voyage-3.5 a mitad de precio, voyage-4-lite a 1/6 del precio, ambas variantes de embedding de 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 es 9 en TechQA (0.8581) y 11 en MedRAG (0.9296). La atención médica lo sitúa en un clúster superior cerrado (dispersión del 2nd al 11: 0.05 nDCG@3). En legal, la brecha es amplia y cara.

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” pagan 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 de la lista. 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 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 de RAG con prioridad en coste donde el embedding es una partida material, pplx-0.6b es la elección clara. La brecha de 30-50x respecto al precio de los buques insignia no aporta nada en calidad de recuperación, esencialmente en estos tres dominios.

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

En MedRAG-PubMed, BM25 puntúa 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 queda a 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 scorer estilo 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 0.33, en TechQA 0.36, en MedRAG 0.20. La densidad del vocabulario de 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étrico. 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 1st 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 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 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 implementa recuperación estilo CUAD con openai/text-embedding-3-large opera 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 elige 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 de “mejor modelo” entre industrias se equivoca en al menos una dirección.

Cuándo elegir voyage-law-2: recuperación de contratos en corpus legales comerciales que se asemejan estructuralmente a CUAD. Cuándo no: cualquier otra cosa de 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 de embeddings

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, y luego ordenamos el top-k para esa consulta. Con un documento dorado por consulta y relevancia binaria, el evaluador comprueba si el dorado aparece en el top-k y en qué rango. Ese rango alimenta nDCG@3 (nuestra métrica principal), nDCG@10 (para comparabilidad con BEIR/MTEB), Recall@10 y la 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 la consulta aplica una transformación y el lado del documento aplica otra. Invocar esos modelos de forma simétrica (“simplemente pasa el texto”) degrada silenciosamente la calidad de recuperación entre 0.05 y 0.45 nDCG@10. Nuestra selección se divide en cuatro modalidades:

Por qué nDCG@3 como métrica principal. Los pipelines de RAG en producción alimentan los 3 a 5 fragmentos principales al LLM, no los 10 primeros. El sesgo de primacía en los LLM de contexto largo hace que el rango 1 importe más que el rango 3, y cada distractor que quede por encima del dorado en el contexto del LLM es candidato a confabulación. Los rerankers aplanarían este efecto, pero la mayoría de los RAG de producción se ejecutan sin uno por razones de coste y latencia, de modo que el rango del embedder ES el rango 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 dominio + por qué)

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 con SHA256, de modo que cualquier lector pueda reproducir la celda exacta que ejecutamos.

PM209 (manuales de fabricación) se descartó: 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 LLM

Nuestras consultas son generadas por LLM bajo separación entre redactor y 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 redactores, viendo los 20 candidatos barajados sin ninguna pista sobre cuál era el documento base del redactor, deciden la aceptación. Además del consenso de los LLM, revisamos manualmente alrededor del 25 % del conjunto de consultas aceptadas (revisión del autor sobre la naturalidad de la consulta, la alineación con el documento objetivo y el cumplimiento de R9, independiente del voto del validador).

Todas las consultas pasaron por el siguiente pipeline antes de entrar en el conjunto de producción:

1. Redactor redacta una única consulta fundamentada en un documento muestreado aleatoriamente. El redactor rota entre Claude Sonnet 4.6, Qwen3.6-plus y Gemini 3 Flash preview para que ningún modelo domine la huella lingüística.
2. Scorer (fijo: Claude Sonnet 4.6) puntúa la consulta según una rúbrica de especificidad. Exigimos semantic_bridge ≥ 4 (la consulta debe describir semánticamente lo que afirma el documento, no solo coincidir por el 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. Comprobación de negativos duros: extraemos los 19 documentos distractores principales de BM25 más el objetivo y aplicamos un filtro de Jaccard de casi duplicados (>0.5 → rechazar toda la consulta por verdad fundamental ambigua).
4. Validadores (2 modelos, nunca incluyendo al redactor) eligen de forma independiente el documento objetivo del conjunto barajado de 20 candidatos. Ambos validadores deben coincidir en la ranura exacta del objetivo o la consulta se descarta. “Ninguna de las anteriores” y “múltiples respuestas correctas” son respuestas válidas del validador y también descartan la consulta.
5. Kappa de Cohen calculada por par de validadores. Cada consulta tuvo exactamente 2 evaluadores (los no redactores del grupo de 3 modelos), de modo que los 3 pares posibles con exclusión del redactor nos dan 3 valores kappa separados por dominio. Los presentamos individualmente y como media ponderada por n.

Kappa de Cohen por par con concordancia observada po y esperada por azar pe, calculada sobre las consultas aceptadas más todos los rechazos consensus_fail en los que ambos validadores tomaron 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 único número ponderado por cuántas consultas juzgó cada par; no es en sí misma un valor kappa para un conjunto de datos combinado, y su CI tendría que calcularse mediante remuestreo bootstrap a nivel de consulta (deferido 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 encuadre natural aquí son 3 cálculos de Cohen por pares, ya que queremos saber si dos modelos concretos coinciden, no si un panel de 3 evaluadores es coherente. El alfa de Krippendorff daría un único número, pero mezclaría los tres pares y ocultaría la varianza a nivel de par.

En CUAD específicamente: Claude × Qwen alcanza κ=0.974, mientras que Claude × Gemini y Gemini × Qwen rondan κ=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 poner de manifiesto, no promediar y ocultar.

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

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

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

• CUAD estricto. Prohíbe todas las entidades nombradas: nombres de partes, nombres de estados de EE. UU., personal, cantidades monetarias en dólares exactos, nombres de productos específicos. Obliga a una unicidad descriptiva: industria + rol + era temporal + rango monetario + alcance geográfico. El techo de BM25 cayó de 0.97 a 0.591 después de aplicar R9.
• TechQA Opción X. Se permiten los nombres de producto de IBM (son la principal señal de recuperación 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 implementación). Los nombres de clientes, estados de EE. UU. y personal siguen prohibidos. Techo de BM25: 0.664.
• MedRAG médicamente relajado + seguro frente a alucinaciones. Los nombres de fármacos, términos de enfermedades, anatomía y símbolos de genes se conservan literalmente de la fuente porque sustituir las etiquetas de clase de fármaco arriesga alucinaciones farmacológicas (“p-chloroamphetamine” es un liberador de serotonina de la clase de las anfetaminas, pero las traducciones de etiquetas de fármacos poco comunes por parte de LLM 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

En cada ejemplo, la consulta es el texto que alimentamos al modelo de embedding. El documento dorado es el único elemento del corpus (de 509 contratos CUAD, 28.000 notas técnicas de TechQA o 50.000 resúmenes de PubMed) que realmente responde a la consulta. La tarea de recuperación es: embeber la consulta, calcular la similitud coseno con cada documento del corpus y clasificarlos. Si el documento dorado cae en el rango 1, la consulta puntúa 1.000 en nDCG@3; el rango 2 puntúa 0.631; el rango 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 el COVID-19; el contrato especifica un pago por hito que vence cuando el primer paciente entra en la Fase I de un ensayo clínico. La consulta no contiene nombres de partes, ni cantidades monetarias, ni geografías más allá de dos tokens de país; la señal de recuperación es industria + temporal + estructura de hito.

TechQA (soporte al cliente)

Consulta:

Documento dorado (1 de 28.000 IBM notas técnicas): swg1IY43185, que documenta exactamente ese error de WebSEAL y nombra el parche que lo corrige. El nombre de producto de IBM (WebSEAL) está permitido según nuestra variante TechQA de R9, pero el discriminador es el patrón de comportamiento del error y el anclaje de orden de solicitudes, no solo el nombre del producto.

MedRAG (atención médica)

Consulta:

Documento dorado (1 de 50.000 resúmenes de 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 pura de BM25 por nombre de fármaco no acierte el objetivo por sí sola.

Protocolo estadístico

Los intervalos de confianza bootstrap del 95 % usan 10.000 remuestras, método percentil, semilla=2026 sobre el vector de métricas por consulta. Bootstrap emparejado sobre los mismos índices de consulta para la significación por pares entre el modelo A y el modelo B (la afirmación exige ≥95 % de remuestras donde A > B).

Una sola ejecución por celda (modelo, dominio). Una capa de varianza entre sesiones con 3 ejecuciones se difiere a v2.1 por motivos de coste. Las llamadas a la API de embedding dentro de una sesión son deterministas hasta unas pocas partes por millón de diferencia coseno, verificado en una comprobación puntual; por tanto, el CI bootstrap captura 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 matricial denso de embeddings normalizados L2. Esto es exacto, no aproximado, de modo que los empates de rango son empates reales del modelo y no artefactos de ANN.

Regla de fragmentación por modelo: los modelos de contexto 512 fragmentan con solapamiento de 512+64; los modelos de contexto 8K-20K fragmentan hasta el contexto sin solapamiento; los modelos de contexto 32K+ ingieren el documento completo cuando cabe (la cola larga del 9 % de CUAD supera todas las ventanas de contexto no-Nemotron y recurre a la fragmentación; la equidad entre modelos se preserva aplicando la misma política por tamaño de contexto a todos los modelos).

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

Framework de evaluación: ranx como motor principal de métricas; salida estilo trec_eval compatible con los envíos del leaderboard MTEB. El CI bootstrap lo calcula scripts/bootstrap_ci.py sobre los arrays de métricas por consulta guardados en la pasada de evaluación.

Modelos evaluados

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

nDCG@3 por modelo con CI bootstrap del 95 %

Intervalos de confianza bootstrap del 95 % calculados mediante 10.000 remuestras del vector de métricas por consulta (método percentil, semilla=2026). Las anchuras de CI de 0.03-0.07 con estos tamaños de muestra (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 el promedio de 3 dominios nDCG@3:

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

Limitaciones

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

Lecturas adicionales

Explora otros benchmarks de RAG, como:

• Top 10 Modelos de Embedding Multilingüe 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: comparativa de los 8 mejores modelos
• Modelos de Embedding Multimodal: Apple vs Meta vs OpenAI
• RAG híbrido: cómo mejorar 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 y analista de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

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