Benchmark de models de embedding de código abierto para RAG

NVIDIA Llama-Embed-Nemotron-8B lidera en precisión. En coste, Google EmbeddingGemma-300m se ejecuta aproximadamente 4x más barato que Nemotron a costa de una pequeña pérdida de precisión.

Resultados del benchmark de models de embedding de código abierto

Explicación de las métricas

nDCG@3: Ganancia acumulada descontada normalizada con corte en 3. Con un documento relevante por consulta, es 1 / log2(rango + 1) cuando el documento gold queda en las 3 primeras posiciones, y 0 en caso contrario. El rango 1 obtiene 1.000, el rango 2 obtiene 0.631 y 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 forma desproporcionada.

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

Recall@10: Fracción de consultas en las que el documento gold aparece entre los 10 primeros.

MRR@10: Rango recíproco medio con corte 10. El gold en el rango 1 obtiene 1.000, el rango 2 obtiene 0.500 y el rango 10 obtiene 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 gold-relevante 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.

Resultados de nDCG@3 por dominio

El ranking AVG oculta inversiones entre dominios. Harrier gana en CUAD, pero queda séptimo en TechQA. SFR-2 ocupa el segundo lugar en TechQA, pero solo el cuarto en CUAD. KaLM-12B es quinto en MedRAG y noveno en TechQA. nDCG@3 por dominio:

BM25 es competitivo en MedRAG (0.7862, superando a PubMedBERT y al Granite multilingüe) y débil en CUAD (0.5844, donde 11 de 14 models densos lo superan). Los contratos legales contienen lenguaje denso de entidades que favorece la coincidencia léxica. En los resúmenes médicos, los mejores models densos (Nemotron 0.9629, SFR-2 0.9620, jina-v5 0.9523) superan a BM25 por entre 0.17 y 0.18 puntos absolutos de nDCG@3.

Los intervalos de confianza bootstrap al 95 % por celda (model, dominio), incluido un empate a cuatro bandas en MedRAG en la parte superior y una superposición Harrier-Nemotron en CUAD que el ranking de estimación puntual aplana, se informan en la sección de metodología del benchmark.

Coste por millón de tokens

El coste autoalojado se amortiza por GPU: la tarifa por hora dividida entre los tokens procesados por hora. El pod que utilizamos fue un H100 80GB SXM5 de la nube comunitaria de RunPod a $2.99/h. El tiempo de reloj por model en la pasada de 551 consultas y 3 corpus (~46.2M tokens en total) produce las siguientes estimaciones de $/1M tokens:

La fórmula:

GPU $/h = $2.99 (la tarifa del pod H100 80GB SXM5 de la comunidad de RunPod que utilizamos). wall_seconds = tiempo de reloj total de cada model en la pasada de 551 consultas y 3 corpus. total_tokens ≈ 46.22M (suma de 3 corpus + 551 consultas, heurística de recuento de caracteres ÷ 4).

Ejemplo resuelto, Nemotron-8B: ($2.99 / 3600) × (1247.8 × 1.000.000 / 46.220.000) = $0.0224 por 1M tokens.

Cinco models lideran su tramo de coste (ninguna otra fila cuesta menos y puntúa más alto): Granite-278m-multilingual en la parte inferior de la escalera de coste, luego Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small y Nemotron-8B en la parte superior de la escalera de calidad. Los extremos abarcan 13x en coste ($0.0017/M a $0.0224/M) y 0.23 nDCG@3 absoluto (0.6952 a 0.9249).

Especialistas de dominio vs generalistas

PubMedBERT, ajustado con pares título-resumen de PubMed, es la obvia «herramienta correcta» para la recuperación RAG médica en PubMed. Obtiene nDCG@3 = 0.7084 en MedRAG, por debajo de la línea base léxica BM25 (0.7862) en el mismo corpus. Los generalistas modernos de código abierto lo superan entre 0.22 y 0.25 puntos absolutos en el dominio de sus datos de entrenamiento:

La razón por la que el especialista rinde peor es la antigüedad y la receta. PubMedBERT es un BERT de 2022 con 110M de parámetros, agrupación media simétrica y sin prefijo de instrucciones. Los generalistas de 2024-2026 se basan en backbones más grandes, prefijos asimétricos de consulta y documento, y objetivos de recuperación ajustados por instrucciones. La brecha arquitectónica importa más que la coincidencia de dominio: un fine-tune de hace 4 años no puede seguir el ritmo de un recuperador de generación actual ajustado por instrucciones, incluso en el propio corpus de entrenamiento del fine-tune.

La regla para el comprador es probar un especialista de dominio frente a un generalista moderno en consultas representativas antes de implementarlo. La suposición de que «el especialista ganará en su dominio» ya no es segura para los models de embedding de código abierto en 2026.

Hallazgos del benchmark de embedding de código abierto

La ventaja de Nemotron-8B en TechQA está estadísticamente separada del segundo lugar

Nemotron-8B nDCG@3 AVG = 0.9249. Por dominio, se sitúa en 0.8602 en CUAD, 0.9515 en TechQA y 0.9629 en MedRAG. El resultado de TechQA (0.9515 0.923, 0.977) no se solapa con el segundo clasificado, SFR-Embedding-2_R (0.9109 0.869, 0.949). Los intervalos de confianza bootstrap están claramente separados. La base 8B de Llama-3.1, ajustada por instrucciones para la recuperación con un prefijo del lado de la consulta Instruct: …\nQuery: … y un prefijo simétrico en el lado del documento, genera una ventaja absoluta de nDCG@3 de 0.04 sobre la siguiente fila en cargas de trabajo de soporte de documentos largos.

Los dos dominios en los que Nemotron gana claramente (TechQA, MedRAG) son los corpus de documentos largos donde más importa la asimetría del prefijo de instrucciones. CUAD es el único dominio en el que no lidera: Microsoft Harrier-oss-v1-0.6b (0.8720) supera a Nemotron (0.8602) en contratos legales a pesar de ser 13x más pequeño, aunque los intervalos de confianza se solapan y la ventaja no está estadísticamente separada con este tamaño de muestra.

Un 0.6B Microsoft Harrier model supera a todos los open models con menos de 7B parámetros

Microsoft Harrier-oss-v1-0.6b (publicado en 2026-04 con una base Qwen3-0.6B y licencia MIT) se sitúa en nDCG@3 AVG = 0.8911, cuarto en la clasificación general. Supera al 12B Tencent KaLM-Gemma3 (0.8057, licencia comunitaria de Tencent), al 7B Salesforce SFR-Embedding-2_R en CUAD (0.8421 frente a Harrier 0.8720) y a Google EmbeddingGemma-300m (0.8706). En una comparación de la misma arquitectura, Harrier-0.6b (0.8911) está 0.074 nDCG@3 por encima de Qwen3-Embedding-0.6B (0.8168), construido sobre la misma base Qwen3-0.6B. El corpus de entrenamiento y la receta de instrucciones impulsaron la brecha, no el número de parámetros.

Para los compradores, Harrier es la fila de código abierto mejor clasificada que se distribuye con una licencia apta para uso comercial sin restricciones. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) y jina-v5 (CC-BY-NC) lo superan en la escalera AVG, pero los tres son solo de investigación o no comerciales.

Un embedder especialista en medicina pierde contra BM25

El PubMedBERT-base-embeddings de NeuML se ajustó con pares título-resumen de PubMed. Es la obvia «herramienta correcta» para un benchmark RAG médico en PubMed. Obtiene nDCG@3 = 0.7084 en MedRAG, lo que supone 0.078 absolutos por debajo de la línea base léxica BM25 (0.7862) en el mismo corpus. Los principales generalistas de código abierto en MedRAG están muy por encima de ambos: Nemotron-8B 0.9629, SFR-Embedding-2_R 0.9620, Harrier-oss 0.9605, jina-v5 0.9523, KaLM-Gemma3-12B 0.9453.

Esta es la inversión que debería cambiar la forma en que un comprador elige un especialista de dominio. PubMedBERT es un BERT de 2022 con 110M de parámetros, agrupación media simétrica y sin prefijo de instrucciones. El grupo de generalistas de 2024 a 2026 está construido sobre backbones más grandes, prefijos asimétricos de consulta y documento, y objetivos de recuperación ajustados por instrucciones. En las consultas de MedRAG que ya incluyen vocabulario médico, la coincidencia léxica de BM25 es naturalmente fuerte, y la especialización de PubMedBERT no añade nada encima.

La conclusión práctica es no elegir un embedder especialista solo por su nombre. Evalúalo con tus propias consultas antes de comprometerte.

Snowflake Arctic oscila 0.32 nDCG@3 entre dominios

El Snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, derivado de bge-m3-retromae, multilingüe) obtiene nDCG@3 = 0.5846 en contratos legales de CUAD y 0.9053 en resúmenes médicos de MedRAG. El mismo model, la misma receta, el mismo formato de consulta, con una oscilación de 0.32 puntos entre dos dominios. Otros models del conjunto oscilan menos: SFR-2 abarca de 0.8421 a 0.9620 (brecha de 0.12), Nemotron abarca de 0.8602 a 0.9629 (brecha de 0.10), Harrier abarca de 0.8408 a 0.9605 (brecha de 0.12).

El mecanismo es la composición de los datos de entrenamiento. Arctic se ajustó con BEIR, MIRACL y CLEF; los contratos legales no están representados. Para una carga de trabajo de recuperación vertical, los datos de entrenamiento del dominio importan más que el número de parámetros o la longitud de contexto.

Cómo funciona la inferencia de embedding de código abierto

Los models de embedding de código abierto se ejecutan en dos backends en este benchmark: sentence-transformers (12 models) y vLLM (4 models). La división no tiene que ver con la calidad, sino con la eficiencia en tiempo de ejecución en models de 8B o más grandes, donde el bucle de inferencia Python por defecto de sentence-transformers es demasiado lento para ser viable.

La receta de cada model importa más que la elección del backend. Los models de recuperación modernos usan prefijos asimétricos: el lado de la consulta se envuelve en un prompt de estilo Instruct (Instruct: Given a question, retrieve passages...\nQuery: <text>) mientras que el lado del documento es plano. El tipo de agrupación varía: los models derivados de BERT usan agrupación CLS; los models derivados de LLM (Llama, Mistral, Qwen3, base Gemma3) usan agrupación por último token; los models multilingües a menudo usan agrupación media. La tarjeta de HuggingFace de cada model es la fuente de verdad sobre qué combinación de prefijo y agrupación es la correcta.

Nivel de backend:

• vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
• sentence-transformers: Qwen3-0.6B, EmbeddingGemma-300m, trío de Granite, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier

Patrones de prefijo asimétrico observados:

• Instruct + Query/Document: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
• Integrado encode_query / encode_document: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (parámetro de sentence-transformers): jina-v5, Snowflake Arctic, Harrier
• Sin prefijo (simétrico): trío de Granite, Conan, PubMedBERT, GIST

Tipo de agrupación por arquitectura base:

• Agrupación CLS: trío Granite r2, Snowflake Arctic
• Agrupación por último token: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Agrupación media: EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

Usar la receta incorrecta degrada silenciosamente la calidad de la recuperación sin provocar fallos. Cualquier benchmark de embedders de código abierto debería incluir un suelo de sanity check (Recall@10 por debajo de 0.5 en todos los dominios para cualquier model es una señal de alerta de una mala configuración, no un resultado).

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 models de embedding de código abierto

Se evaluaron tres dominios de recuperación: contratos legales de CUAD (246 consultas, 509 contratos), notas técnicas de soporte al cliente de TechQA (151 consultas, 28000 notas técnicas de IBM) y resúmenes de salud de MedRAG-PubMed (154 consultas, 50000 resúmenes). Total: 551 consultas.

La metodología de construcción del dataset se comparte con nuestro benchmark de models de embedding en inglés anterior: generación de consultas por consenso Protocol-A de 3-LLM (grupo rotatorio de redactores, evaluador fijo, dos validadores no redactores por intento), fijación del corpus por hash SHA-256, listas blancas de tokens prohibidos por entidad y dominio para evitar atajos léxicos de BM25, acuerdo interanotador κ de Cohen informado por par de validadores, rangos de la línea base BM25 sintetizados a partir del campo bm25_rank_at_target ya presente en cada JSON de consulta (equivalente a Pyserini). Métrica primaria nDCG@3 (realista para RAG, lo que consumen los sistemas RAG en producción); métricas secundarias nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

Especificaciones específicas de código abierto:

• GPU: 1 x NVIDIA H100 80GB SXM5 mediante la nube comunitaria de RunPod
• Plantilla del pod: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
• Stack: PyTorch 2.10.0+cu128, vLLM 0.19.1, transformers 5.6.2, sentence-transformers 5.4.1
• Despacho por model: ruta principal de la tarjeta de model de HF. ST para 12 models, vLLM para Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
• División por model: truncamiento a nivel de carácter a max_seq_length x 4 caracteres por token; luego el tokenizador del model trunca a su longitud máxima real de secuencia.
• Recuperación asimétrica: todo model que la soporta recibe el prefijo de consulta y de documento documentado en la tarjeta de HF. Para algunos, la ausencia de prefijo es el valor predeterminado documentado.
• Normalización L2: aplicada uniformemente después de la agrupación. Algunos models la hacen internamente. Renormalizamos para garantizar la paridad en todo el conjunto.
• Clave de caché de embedding: incluye prefijo + task + prompt_name + max_seq + backend, de modo que un cambio de prefijo a mitad de ejecución no pueda cargar silenciosamente embeddings obsoletos.
• Protocolo estadístico: 10K remuestreos bootstrap por celda (model, dominio, métrica), IC percentil al 95 %, seed=2026.

Models probados

Ordenados por rango de nDCG@3 AVG. Columna de backend: ST = sentence-transformers, vLLM = vLLM 0.19.

Intervalos de confianza bootstrap al 95 %

La tabla de clasificación completa anterior es de una sola ejecución por celda (model, dominio). No se mide la varianza de inicialización del model entre sesiones. Para capturar la varianza a nivel de consulta dentro de la ejecución, remuestreamos el vector de rangos por consulta para cada celda (model, dominio) 10.000 veces con reemplazo (método de percentiles, seed=2026, tamaños de muestra CUAD n=246, TechQA n=151, MedRAG n=154). IC bootstrap al 95 % por dominio en nDCG@3:

Los IC sí cambian qué inversiones respaldan los datos. En CUAD, Harrier (0.8720, [0.836, 0.906]) y Nemotron (0.8602, [0.821, 0.897]) se solapan, por lo que la ventaja de Harrier en CUAD no está claramente separada con este tamaño de muestra. En TechQA, Nemotron (0.9515, [0.923, 0.977]) y SFR-2 (0.9109, [0.869, 0.949]) no se solapan, así que la ventaja de Nemotron en TechQA está estadísticamente separada. En MedRAG, los cuatro primeros (Nemotron 0.9629, SFR-2 0.9620, Harrier 0.9605, jina-v5 0.9523) están dentro de los IC de los demás y forman un empate estadístico a cuatro bandas. La inversión de PubMedBERT por debajo de BM25 en MedRAG (0.7084 [0.641, 0.772] frente a BM25 0.7862) está en el margen de solapamiento. La tendencia central coloca claramente al especialista por debajo de BM25, pero se necesita una pasada de 3 ejecuciones entre sesiones para resolver si está separado en lugar de solapado.

Limitaciones

Una sola ejecución por celda (model, dominio). La tabla de IC bootstrap anterior captura la varianza a nivel de consulta dentro de la ejecución (10K remuestreos, método de percentiles, seed=2026), pero no se mide la varianza de inicialización del model entre sesiones. Para v2.1 se planea una pasada de 3 ejecuciones que cruce la medianoche. Los empates más cercanos que muestra la tabla de IC (p. ej., el empate a cuatro bandas en MedRAG en la parte superior, la superposición Harrier-Nemotron en CUAD, la inversión marginal PubMedBERT frente a BM25) serían los que más se beneficiarían de la pasada de varias ejecuciones.

Confusión por longitud de contexto por model. Los models con ventanas de contexto de 512 tokens (Granite-278m-multilingual, PubMedBERT, Conan, GIST) solo ven los primeros ~2K caracteres de cada documento. Los models con contexto de 8K o 32K (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 english) ven el documento completo. Esto favorece a los models de contexto largo en TechQA (notas técnicas largas) y MedRAG (resúmenes largos).

Riesgo de contaminación por datos de entrenamiento en MedRAG. Varios de los models evaluados se entrenaron con datos derivados de PubMed (PubMedBERT por definición, posiblemente Granite-278m-multilingual, posiblemente la base Qwen3). Parte del aumento de nDCG@3 en MedRAG puede reflejar una superposición de datos de entrenamiento, no calidad de recuperación.

Conan-v1 está entrenado en chino. Incluirlo en dominios solo en inglés es un dato instructivo sobre desajuste de idioma, no una comparación justa cara a cara de calidad de recuperación en inglés. Esperamos un rendimiento inferior frente a pares entrenados en inglés, y eso es lo que muestran los datos.

Lecturas adicionales

Explora otros benchmarks de RAG, como:

• Top 10 models de embedding multilingües para RAG
• Models de embedding: OpenAI vs Gemini vs Voyage
• La mejor base de datos vectorial para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de rerankers: comparativa de los 8 mejores models
• Models de embedding multimodal: Apple vs Meta vs OpenAI
• Hybrid RAG: 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  = {{Benchmark de models de embedding de código abierto para RAG}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Recuperado el 10 de Agosto 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