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

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

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

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 entra en el top 3, y 0 en caso contrario. El rango 1 puntúa 1.000, el rango 2 puntúa 0.631 y el rango 3 puntúa 0.500. Usamos nDCG@3 como métrica principal porque los pipelines de producción de RAG 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 dorado aparece en el top 10.

MRR@10: Rango recíproco medio con corte en 10. El documento dorado 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 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.

Resultados de nDCG@3 por dominio

El ranking AVG oculta inversiones por dominio. 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 modelos densos lo superan). Los contratos legales contienen un lenguaje denso de entidades que premia la coincidencia léxica. En los resúmenes médicos, los mejores modelos densos (Nemotron 0.9629, SFR-2 0.9620, jina-v5 0.9523) superan a BM25 por 0.17 a 0.18 puntos absolutos de nDCG@3.

Los intervalos de confianza bootstrap del 95 % por celda (modelo, dominio), incluido un empate cuádruple en MedRAG en la parte superior y una superposición Harrier-Nemotron en CUAD que la clasificación por estimación puntual aplana, se reportan en la sección de metodología del benchmark.

Coste por millón de tokens

El coste autoalojado está amortizado por GPU: la tarifa por hora dividida por 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 modelo 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 RunPod community del H100 80GB SXM5 del pod que utilizamos). wall_seconds = tiempo total de reloj de cada modelo 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 práctico, Nemotron-8B: ($2,99 / 3600) × (1247.8 × 1.000.000 / 46.220.000) = $0,0224 por 1M tokens.

Cinco modelos lideran su nivel de coste (ninguna otra fila cuesta menos y puntúa más alto): Granite-278m-multilingual en la parte inferior de la escalera de costes, 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 frente a generalistas

PubMedBERT, ajustado con pares título-resumen de PubMed, es la obvia «herramienta adecuada» para la recuperación de 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 por 0.22 a 0.25 puntos absolutos en el dominio de sus datos de entrenamiento:

La razón del bajo rendimiento del especialista es la antigüedad y la receta. PubMedBERT es un BERT de 2022 con 110M parámetros, con mean pooling simétrico y sin prefijo de instrucciones. Los generalistas de 2024-2026 están construidos sobre 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 la generación actual ajustado por instrucciones, ni siquiera en el propio corpus de entrenamiento del fine-tune.

La regla para el comprador es probar un especialista de dominio contra un generalista moderno en consultas representativas antes de desplegarlo. La suposición de que «el especialista ganará en su dominio» ya no es segura para los modelos 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

El nDCG@3 AVG de Nemotron-8B = 0.9249. Por dominio, obtiene 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 lugar SFR-Embedding-2_R (0.9109 0.869, 0.949). Los IC bootstrap separan claramente. La base 8B 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 del lado del documento, impulsa 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 donde Nemotron gana claramente (TechQA, MedRAG) son los corpus de documentos largos donde la asimetría del prefijo de instrucciones importa más. CUAD es el único dominio donde no lidera: Harrier-oss-v1-0.6b de Microsoft (0.8720) supera a Nemotron (0.8602) en contratos legales a pesar de ser 13x más pequeño, aunque los IC se solapan y la ventaja no está estadísticamente separada con este tamaño de muestra.

Un modelo Harrier de 0.6B de Microsoft supera a todos los modelos abiertos con menos de 7B parámetros

Microsoft Harrier-oss-v1-0.6b (publicado en 2026-04 con una base Qwen3-0.6B y una licencia MIT) obtiene nDCG@3 AVG = 0.8911, cuarto en 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) se sitúa 0.074 nDCG@3 por encima de Qwen3-Embedding-0.6B (0.8168), construido sobre la idéntica base Qwen3-0.6B. El corpus de entrenamiento y la receta de instrucciones marcaron la diferencia, 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 médico pierde frente a BM25

PubMedBERT-base-embeddings de NeuML fue ajustado con pares título-resumen de PubMed. Es la obvia «herramienta adecuada» para un benchmark de RAG médico en PubMed. Obtiene nDCG@3 = 0.7084 en MedRAG, lo que está 0.078 absoluto por debajo de la línea base léxica BM25 (0.7862) en el mismo corpus. Los mejores generalistas de código abierto en MedRAG quedan 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 parámetros, con mean pooling simétrico y sin prefijo de instrucciones. El campo generalista 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 aporta nada por encima.

La conclusión práctica es no elegir un embedder especializado solo por el nombre. Ponlo a prueba con tus propias consultas antes de comprometerte.

Snowflake Arctic oscila 0.32 nDCG@3 entre dominios

Snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, derivado de bge-m3-retromae, multilingüe) obtiene nDCG@3 = 0.5846 en los contratos legales de CUAD y 0.9053 en los resúmenes médicos de MedRAG. El mismo modelo, la misma receta, el mismo formato de consulta, con una oscilación de 0.32 puntos entre dos dominios. Otros modelos 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 fue ajustado 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 del contexto.

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

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

La receta por modelo importa más que la elección del backend. Los modelos 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 pooling varía: los modelos derivados de BERT usan CLS pooling; los modelos derivados de LLM (Llama, Mistral, Qwen3, base Gemma3) usan last-token pooling; los modelos multilingües a menudo usan mean pooling. La tarjeta de HuggingFace de cada modelo es la fuente de verdad para saber qué combinación de prefijo y pooling es correcta.

Nivel de backend:

• vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
• sentence-transformers: Qwen3-0.6B, EmbeddingGemma-300m, trío 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
• encode_query / encode_document integrados: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (parámetro de sentence-transformers): jina-v5, Snowflake Arctic, Harrier
• Sin prefijo (simétrico): trío Granite, Conan, PubMedBERT, GIST

Tipo de pooling por arquitectura base:

• CLS pooling: trío Granite r2, Snowflake Arctic
• Last-token pooling: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Mean pooling: 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 cordura (Recall@10 por debajo de 0.5 en todos los dominios para cualquier modelo es una señal de alerta de 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 modelos de embedding de código abierto

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

La metodología de construcción del dataset es compartida con nuestro benchmark de modelos de embedding en inglés: generación de consultas por consenso de 3-LLM Protocol-A (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 reportado por par de validadores, rangos de referencia BM25 sintetizados a partir del campo bm25_rank_at_target ya presente en el JSON de cada consulta (equivalente a Pyserini). Métrica principal nDCG@3 (realista para RAG, lo que consumen los sistemas de 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 a través de la nube comunitaria de RunPod
• Plantilla de 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 modelo: ruta principal de la tarjeta de modelo HF. ST para 12 modelos, vLLM para Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
• Fragmentación por modelo: truncamiento a nivel de carácter en max_seq_length x 4 caracteres por token; luego, el tokenizador del modelo trunca a su longitud de secuencia máxima real.
• Recuperación asimétrica: todo modelo que lo soporta recibe el prefijo de consulta y documento documentado en la tarjeta HF. Para algunos, el valor predeterminado documentado es sin prefijo.
• Normalización L2: aplicada uniformemente después del pooling. Algunos modelos lo hacen internamente. Volvemos a normalizar 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 (modelo, dominio, métrica), IC percentil del 95 %, semilla=2026.

Modelos probados

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

Resultados de los intervalos de confianza bootstrap del 95 %

La tabla de clasificación completa anterior es de una sola ejecución por celda (modelo, dominio). No se mide la varianza de inicialización del modelo entre sesiones. Para capturar la varianza a nivel de consulta dentro de una ejecución, remuestreamos el vector de rangos por consulta para cada celda (modelo, dominio) 10.000 veces con reemplazo (método percentil, semilla=2026, tamaños de muestra CUAD n=246, TechQA n=151, MedRAG n=154). IC bootstrap del 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 se separa claramente 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, por lo 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 de cuatro. 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 pone claramente al especialista por debajo de BM25, pero se necesita una pasada de 3 ejecuciones entre sesiones para resolverlo como separado en lugar de solapado.

Limitaciones

Ejecución única por celda (modelo, dominio). La tabla de IC bootstrap anterior captura la varianza a nivel de consulta dentro de la ejecución (10K remuestreos, método percentil, semilla=2026), pero no se mide la varianza de inicialización del modelo entre sesiones. Está prevista una pasada de 3 ejecuciones cruzando la medianoche para la v2.1. Los empates más estrechos detectados por la tabla de IC (p. ej., el empate cuádruple de MedRAG en la parte superior, la superposición Harrier-Nemotron en CUAD, la inversión marginal de PubMedBERT frente a BM25) se beneficiarían más de la pasada de múltiples ejecuciones.

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

Riesgo de contaminación de datos de entrenamiento de MedRAG. Varios de los modelos evaluados fueron entrenados con datos derivados de PubMed (PubMedBERT por definición, posiblemente Granite-278m-multilingual, posiblemente la base Qwen3). Parte del incremento de nDCG@3 en MedRAG puede reflejar solapamiento de datos de entrenamiento en lugar de calidad de recuperación.

Conan-v1 está entrenado en chino. Incluirlo en dominios solo en inglés es un dato instructivo sobre el desajuste de idioma, en lugar de una comparación justa de la 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:

• Los 10 mejores modelos de embedding multilingüe para RAG
• Modelos de embedding: OpenAI vs Gemini vs Voyage
• Mejor base de datos vectorial para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de rerankers: comparativa de 8 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  = {{Benchmark de modelos 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}
}

Registro de cambios

4 actualizaciones

Todas4General3Metodología1

1. 202625 de Abr

   Se reemplazó el benchmark Top-K de 16 modelos sobre reseñas de Amazon por uno de 14 modelos con nDCG@3 y costes en CUAD, TechQA y MedRAG.

2. 8 de Ene

   Se añadió Licencia y uso comercial a la descripción general de los modelos de incrustación de código abierto.

3. 6 de Ene

   Se amplió el benchmark para incluir cinco modelos de código abierto adicionales.

4. 6 de Ene

   Actualizados el hardware, el tamaño del lote y la precisión en la configuración de evaluació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