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 puesto 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 de referencia queda en los 3 primeros, y 0 en caso contrario. El rango 1 obtiene 1.000, el rango 2 obtiene 0.631, el rango 3 obtiene 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 en las que el documento relevante aparece entre los 10 primeros.

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

Top-1 hit: Fracción de consultas en las que el documento relevante es el único primer resultado. Es 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 el especialista voyage-law-2 gana; sus datos de entrenamiento ajustados a CUAD rinden +0.040 de 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 (0.8856), 0.045 por detrás de su hermano más nuevo 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): Atención médica es el grupo más compacto de nuestro benchmark (14 modelos superan 0.88) porque el vocabulario médico es denso en palabras clave, lo que empuja a la mayoría de las consultas al grupo superior. Suelo de 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 cambios a nivel de dominio justifican el enfoque de promedio de 3 dominios: ningún dominio individual es un proxy justo para «qué modelo es el mejor», y un comprador que elige en un solo dominio obtendrá una clasificación errónea en los demás.

Los intervalos de confianza bootstrap del 95 % por modelo 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 por incrustar 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 se facturan a la misma tarifa en todos los proveedores evaluados. BM25 se representa a $0,001/M para la representación en eje logarítmico. El verdadero coste de autoalojamiento es de $0.

Promedio de 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 de RAG con prioridad en 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 92 % de la calidad de voyage-3.5 (0.8604 / 0.9429). Ningún otro modelo de nuestro benchmark compite en su punto de precio.
• Para RAG empresarial con prioridad en calidad, voyage-3.5 a través del SDK directo de Voyage ocupa el mejor punto de Pareto. Se intercambia una integración de API adicional (frente a una pila que solo use 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 incorrecto dentro del catálogo de Voyage.
• Para implementaciones OSS / autoalojables / locales, 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 de 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 $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 frente a 0.9102), lo suficiente para que su promedio de 3 dominios quede por debajo de voyage-3.5. Dentro del catálogo 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 obtuvo el primer puesto en los tres dominios y copó los dos primeros puestos en CUAD y TechQA. En MedRAG, gemini-embedding-001 entró en el 2nd lugar (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 los 2 primeros puestos en un solo dominio.

Un modelo heredado de Gemini supera a su hermano más nuevo en «vista previa» 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 frente a 0.8958) como en MedRAG (0.9814 frente a 0.9685). El modelo más nuevo solo gana en TechQA (0.9301 frente a 0.8856), una brecha de 0.04 que viene con un aumento de precio del 33 % ($0,20 frente a $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 opte por el modelo «más nuevo» pierda una calidad medible.

OpenAI text-embedding-3-large está en la gama media en legal y soporte al cliente

openai/text-embedding-3-large ocupa el puesto 11 de 15 modelos densos en CUAD con 0.6430 de 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). En atención médica queda en un grupo superior compacto (dispersión del 2nd al 11: 0.05 de nDCG@3). En 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 de 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 gama evaluada. También supera a openai/text-embedding-3-large por 0.16 de nDCG@3 en CUAD, pierde por 0.012 en TechQA (0.8457 frente a 0.8581) y gana por 0.003 en MedRAG. El siguiente modelo más barato del top-10 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 frente 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 obtiene 0.7862 de nDCG@3 frente a baai/bge-m3 (modo denso) con 0.8038, una brecha de 0.02. La búsqueda léxica 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, enfermedades, términos de diseño de estudios, símbolos genéticos), y esos tokens transportan la mayor parte de la señal de recuperación. Un sistema de puntuación de 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 de nDCG@3 hasta el 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 y en MedRAG de 0.20. La densidad del vocabulario del dominio es el mayor determinante de cuánto ayudan los embeddings densos.

Especialistas de dominio frente a generalistas entre proveedores

Voyage fija el precio de voyage-law-2 en $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 1st 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 aumenta el nDCG@3 en CUAD y lo reduce en los otros dos dominios.

Un equipo legal que implementa recuperación al estilo CUAD con openai/text-embedding-3-large funciona a 0.6430 de nDCG@3 frente a voyage-law-2 con 0.9126, una brecha de 0.27. Un equipo de atención médica o de 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 de «mejor modelo» entre industrias elige mal en al menos una dirección.

Cuándo elegir voyage-law-2: recuperación de contratos en corpus legales comerciales que se parecen 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 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 los top-k para esa consulta. Con un documento relevante por consulta y relevancia binaria, el evaluador comprueba si el documento relevante 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 aciertos 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 de nDCG@10. Nuestra gama se divide en cuatro grupos:

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 LLMs de contexto largo hace que el rango 1 importe más que el rango 3, y cada distractor que quede por encima del documento relevante en el contexto del LLM es candidato a una confabulación. Los rerankers aplanarían este efecto, pero la mayoría de los RAGs de producción funcionan sin uno por razones de coste y latencia, por lo 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 conservó 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 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 mediante SHA256, por lo que cualquier lector puede reproducir exactamente la celda 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 se generan con 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, que ven 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 de forma puntual aproximadamente el 25 % del conjunto de consultas aceptadas (revisión del autor sobre naturalidad de la consulta, alineación con el documento objetivo y 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 basada 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. Puntuador (fijo: Claude Sonnet 4.6) califica la consulta con una rúbrica de especificidad. Exigimos semantic_bridge ≥ 4 (la consulta debe describir semánticamente lo que afirma el documento, no solo coincidir por nombre) y unique_referent en 3-5 (los anclajes descriptivos deben identificar aproximadamente entre uno y cinco documentos candidatos en el corpus, no miles ni exactamente uno).
3. Comprobación de negativos duros: tomamos los 19 documentos distractores principales de BM25 más el objetivo y ejecutamos una puerta de Jaccard de casi duplicados (>0.5 → rechazar toda la consulta por verdad de referencia ambigua).
4. Validadores (2 modelos, sin incluir nunca al redactor) eligen de forma independiente el documento objetivo del conjunto barajado de 20 candidatos. Ambos validadores deben coincidir en la posición 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 pareja de validadores. Cada consulta tuvo exactamente 2 evaluadores (los no redactores del grupo de 3 modelos), por lo que las 3 posibles parejas que excluyen al redactor nos dan 3 valores kappa separados por dominio. Los informamos individualmente y como media ponderada por n.

Kappa de Cohen por pareja con acuerdo observado po y esperado por azar pe, calculada sobre las consultas aceptadas más todos los rechazos de 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 pareja en un único número ponderado por cuántas consultas juzgó cada pareja; no es en sí mismo un valor kappa para un conjunto de datos combinado, y su intervalo de confianza tendría que calcularse mediante remuestreo bootstrap a nivel de consulta (aplazado para 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 parejas, 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 las tres parejas y ocultaría la varianza a nivel de pareja.

En CUAD específicamente: Claude × Qwen alcanza κ=0.974, mientras que Claude × Gemini y Gemini × Qwen se sitúan en torno a κ=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 sacar a la luz, no promediar.

Promovimos 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 efectivamente un techo: los dos desacuerdos en 156 intentos correspondieron a objetivos médicamente ambiguos en los que ambos validadores eran internamente coherentes, pero uno eligió un resumen relacionado que no era el de referencia.

Reglas R9 de anonimización de entidades (por dominio)

R9 es una restricción estricta en el momento de generar consultas. Sin ella, BM25 sube por encima de 0.97 de 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 aportan la señal de recuperación en ese dominio sigan siendo utilizables:

• CUAD estricto. Prohíbe todas las entidades nombradas: nombres de partes, estados de EE. UU., personal, importes monetarios en dólares exactos y nombres de productos específicos. Obliga a la unicidad descriptiva: industria + rol + era temporal + rango monetario + ámbito geográfico. El techo de BM25 bajó de 0.97 a 0.591 tras aplicar R9.
• TechQA Opción X. Se permiten los nombres de producto de IBM (son la señal de recuperación principal para un administrador de sistemas) SI la consulta también contiene un anclaje descriptivo secundario que no sea de 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 relajado en lo médico y seguro frente a alucinaciones. Los nombres de fármacos, términos de enfermedades, anatomía y símbolos genéticos se conservan literalmente de la fuente, porque sustituir etiquetas de clases de fármacos arriesga alucinaciones farmacológicas («p-cloroanfetamina» es un liberador de serotonina de la clase de las anfetaminas, pero las traducciones de etiquetas de fármacos más raros por parte de los LLM fallan silenciosamente). La consulta debe contener ≥2 anclajes que no sean fármacos para que la coincidencia por palabra clave del nombre puro del fármaco no se lleve 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 introducimos en el modelo de embedding. El documento de referencia es el único elemento del corpus (de 509 contratos de 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 consiste en: incrustar la consulta, calcular la similitud coseno con cada documento del corpus y clasificarlos. Si el documento de referencia queda en el rango 1, la consulta obtiene 1.000 en nDCG@3; en el rango 2 obtiene 0.631; en el rango 3 obtiene 0.500; por debajo de los 3 primeros obtiene 0.

CUAD (legal)

Consulta:

Documento de referencia (1 de 509 contratos de 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 la 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, importes monetarios ni geografías más allá de dos tokens de país; la señal de recuperación es industria + temporal + estructura de hitos.

TechQA (soporte al cliente)

Consulta:

Documento de referencia (1 de 28.000 notas técnicas de IBM): swg1IY43185, que documenta exactamente ese error de WebSEAL y menciona el parche que lo corrige. El nombre de producto de IBM (WebSEAL) está permitido en nuestra variante R9 de TechQA, 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 de referencia (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 pivmecilinam 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 + contexto 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 remuestreos, método percentil, seed=2026 sobre el vector métrico 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 requiere ≥95 % de remuestreos donde A > B).

Una única ejecución por celda (modelo, dominio). Una capa de varianza entre sesiones con 3 ejecuciones se aplaza a v2.1 por razones de coste. Las llamadas a la API de embedding dentro de la misma sesión son deterministas con una diferencia de coseno de pocas partes por millón, verificado en una comprobación puntual; por lo tanto, el IC 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 de matrices densas de embeddings normalizados con L2. Esto es exacto, no aproximado, por lo 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 de 512 fragmentan con solapamiento de 512+64; los modelos de contexto de 8K-20K fragmentan hasta el contexto sin solapamiento; los modelos de contexto de 32K+ ingieren el documento completo cuando cabe (el 9 % de cola larga de CUAD supera todas las ventanas de contexto que no son Nemotron y recurre a la fragmentación; la imparcialidad 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 obtiene 0.46 de nDCG@10 con la muestra de código documentada de OpenRouter frente a 0.91 con el formato de Vertex IA de Google. Consulta «Cómo se evaluó el pipeline de recuperación con embeddings» más arriba para ver la tabla por familia.

Marco de evaluación: ranx como motor principal de métricas; salida estilo trec_eval compatible con los envíos a la tabla de clasificación de MTEB. El IC bootstrap se calcula mediante scripts/bootstrap_ci.py sobre los arreglos métricos por consulta guardados en la pasada de evaluación.

Modelos evaluados

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

nDCG@3 por modelo con IC bootstrap del 95 %

Los intervalos de confianza bootstrap del 95 % se calculan mediante 10.000 remuestreos del vector métrico por consulta (método percentil, seed=2026). Las amplitudes de IC de 0.03-0.07 con estos tamaños de muestra (n=154-246) significan que las diferencias de estimación puntual por debajo de ~0.03 están dentro del ruido y deben tratarse como empates. Ordenado por el 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ó de forma puntual aproximadamente el 25 % de las consultas finales aceptadas en cuanto a naturalidad, alineación con el objetivo y cumplimiento de R9.

Lecturas adicionales

Explora otros benchmarks de RAG, como:

• Los 10 mejores modelos de embedding multilingües para RAG
• Los 16 mejores modelos de embedding de código abierto para RAG
• La mejor base de datos vectorial 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

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}
}

Registro de cambios

5 actualizaciones

1. 202629 de Jun

   Se añadió la definición de la métrica Top-1 hit a la metodología del benchmark de embeddings.

2. 24 de Abr

   Reemplazó el benchmark por 15 modelos y una línea base BM25 probados en corpus legales, de soporte al cliente y de salud.

3. 202525 de Nov

   Se añadió la sección Razones potenciales detrás de las diferencias de rendimiento del modelo de incrustación.

4. 18 de Jul

   Se actualizó la sección Conclusión con nuevas recomendaciones de modelos.

5. 10 de Jul

   Se reemplazó Google por Gemini en la introducción.

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico 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