Conclusiones clave
- jina-embeddings-v3 gana en precisión global — 92% retrieval@10 en 4 tipos de documentos, con la menor varianza entre corpus en inglés, multilingüe y de código.
- bge-large-en-v1.5 gana en contenido solo en inglés — 91% en contratos legales y artículos de investigación, pero cae al 79% en texto multilingüe. Úsalo cuando el corpus sea en inglés y la precisión supere al rendimiento.
- nomic-embed-text-v2 gana en rendimiento CPU — 580 chunks/seg en una CPU moderna, ~5× más rápido que las alternativas de 1.024 dimensiones. La elección correcta cuando no hay GPU disponible.
- Las dimensiones más grandes solo ayudan hasta ~1.024. Más allá de eso, las ganancias de recall son inferiores a 1 punto porcentual y el almacenamiento se duplica. Los modelos Matryoshka (jina-embeddings-v3, nomic-embed-text-v2) permiten truncar sin re-embedder.
- La recuperación de código es la tarea más difícil. Los seis modelos pierden entre 5 y 10 puntos en una base de código TypeScript/Python frente a documentos en lenguaje natural. Ninguno de los seis es un verdadero "embedder de código" — para corpus con mucho código, considera un modelo específico para código.
- El soporte multilingüe no es gratuito. Los embedders solo en inglés (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) pierden 10–15 puntos en texto de idiomas mixtos. Para documentos en alemán, francés, japonés o chino, usa jina-embeddings-v3, nomic-embed-text-v2 o BAAI/bge-m3.
- Cambiar de embedder obliga a reindexar completamente en todas las plataformas de RAG local probadas. Presupuesta 30–90 minutos por cada 5.000 páginas en hardware de consumo y planifica el cambio en consecuencia.
¿Cómo se comparan los 6 modelos de embedding en 2026?
Probados en 4 tipos de documentos (contratos legales, artículos de investigación, código fuente y wiki empresarial multilingüe) con 100 consultas evaluadas por modelo. Hardware: NVIDIA RTX 4070 (12 GB VRAM) para datos GPU; Apple M3 Pro (18 GB de memoria unificada) para datos CPU. Tamaño de chunk 256 tokens, tamaño de lote 32. Los números son medianas de tres ejecuciones.
| Modelo | Dim | Velocidad (CPU) | Velocidad (GPU) | Memoria | retrieval@10 | Multilingüe | Mejor para |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 chunks/s | 4.800 chunks/s | 1,2 GB | 88% | 100+ idiomas (MoE) | Despliegues solo CPU, hardware de gama media |
| bge-large-en-v1.5 | 1.024 | 95 chunks/s | 1.400 chunks/s | 2,4 GB | 91% (Ing) / 79% (multi) | Solo inglés | RAG crítico en precisión, solo inglés |
| gte-large | 1.024 | 110 chunks/s | 1.600 chunks/s | 2,2 GB | 90% (Ing) / 78% (multi) | Enfocado en inglés | Despliegues con licencia Apache-2.0 |
| mxbai-embed-large-v1 | 1.024 | 105 chunks/s | 1.500 chunks/s | 2,1 GB | 89% (Ing) / 80% (multi) | Enfocado en inglés | RAG en inglés equilibrado con licencia permisiva |
| snowflake-arctic-embed-l-v2.0 | 1.024 | 130 chunks/s | 1.800 chunks/s | 1,9 GB | 87% (Ing) / 86% (multi) | ~30 idiomas | Chunks de contexto largo (8k tokens), multilingüe |
| jina-embeddings-v3 | 1.024 (Matryoshka → 256) | 220 chunks/s | 3.200 chunks/s | 2,0 GB | 92% (Ing) / 89% (multi) | 89 idiomas | Elección que supera al predeterminado para la mayoría de RAG local |
¿Qué modelo de embedding deberías elegir?
La elección correcta depende de tres factores: si tienes GPU, si el corpus es solo en inglés y si esperas cambiar dimensiones más adelante. Usa este atajo de decisión:
| Tu situación | Elige |
|---|---|
| Corpus mixto en idiomas, GPU disponible, mejor precisión global | jina-embeddings-v3 |
| Legal o investigación solo en inglés, GPU disponible, precisión crítica | bge-large-en-v1.5 |
| Laptop solo CPU, precisión aceptable sin GPU | nomic-embed-text-v2 |
| Necesitas licencia permisiva Apache-2.0 para producto comercial | gte-large o mxbai-embed-large-v1 |
| Documentos largos (chunks de 8k+ tokens) y multilingüe | snowflake-arctic-embed-l-v2.0 |
| Quieres flexibilidad para truncar dimensiones después (control de costos de almacenamiento) | jina-embeddings-v3 (Matryoshka) |
| Corpus con mucho código (TypeScript, Python, Rust) | Ninguno de los seis — usa un embedder específico para código |
| El multilingüe es el requisito dominante, GPU disponible | BAAI/bge-m3 (no incluido en este benchmark, multilingüe dedicado) |
Cómo probamos 6 modelos de embedding en 4 tipos de documentos
Mismos chunks, mismo conjunto de consultas, mismo pipeline de recuperación. La única variable es el embedder. Todos los números a continuación provienen de esta única ejecución controlada.
- Hardware: NVIDIA RTX 4070 (12 GB VRAM, 32 GB RAM del sistema) en Windows 11 para datos GPU; Apple M3 Pro (18 GB de memoria unificada, sin GPU discreta) para datos CPU. Cada ejecución se repitió tres veces; los números reportados son medianas.
- Corpus: cuatro conjuntos de documentos, ~1.200 páginas cada uno. Conjunto 1 — arrendamientos comerciales y acuerdos maestros de servicios (legal). Conjunto 2 — artículos de investigación de arXiv sobre transformers y recuperación (investigación). Conjunto 3 — código TypeScript y Python de una base de código Next.js pública (código). Conjunto 4 — exportaciones de wiki de ingeniería interna en inglés, alemán, francés, japonés y chino (multilingüe).
- Chunking: 256 tokens fijos con 32 tokens de superposición. El mismo chunker para todos los modelos, por lo que los límites de los chunks son idénticos y solo varía el paso de embedding.
- Vector store: Qdrant 1.x en modo local, similitud coseno, top-K=10. Configuración idéntica para los seis modelos. La reindexación se realizó de forma limpia entre ejecuciones.
- Conjunto de consultas: 100 consultas — 25 por tipo de documento — escritas por lectores del dominio y evaluadas a ciegas contra un conjunto de respuestas conocidas. retrieval@10 = % de consultas donde el chunk de referencia aparece en los 10 primeros resultados.
- Medición de velocidad: chunks/seg con tamaño de lote 32 sobre un calentamiento de 1.000 chunks más 10.000 chunks medidos. La memoria se midió al tamaño máximo del conjunto residente durante el embedding.
- **Lo que *no* probamos:** calidad de respuesta de extremo a extremo. El modelo de chat es idéntico (Llama 3.3 8B Q4_K_M) en todas las ejecuciones, pero la calidad de respuesta depende de la plantilla de prompt y el conteo de chunks. Aislamos la recuperación aquí para que el embedder sea la única variable.
📌Note: El acceso a la red se desactivó después de las descargas de modelos. Toda la inferencia se ejecutó localmente — confirmado mediante Wireshark en Windows y Little Snitch en macOS. Seis modelos × cuatro conjuntos de documentos × tres ejecuciones = 72 corpus indexados más los 100 embeddings de consultas cada uno.
Precisión de recuperación por tipo de documento (retrieval@10)
retrieval@10 = % de consultas donde el chunk correcto aparece en los 10 primeros resultados. Mayor es mejor. Los números provienen de 25 consultas evaluadas por tipo de documento por modelo.
| Modelo | Legal | Investigación | Código | Multilingüe | Global |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
💡Tip: jina-embeddings-v3 es el único modelo en la prueba que se mantiene por encima del 87% en todos los tipos de documento. Los modelos solo en inglés (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) le superan en texto puramente en inglés, pero pierden 10–15 puntos en contenido multilingüe. Si tu corpus es mixto, la trampa del "mejor en inglés" es real.
Velocidad de embedding en CPU (chunks por segundo)
Rendimiento con tamaño de lote 32, chunks de 256 tokens, en Apple M3 Pro (sin GPU). Mayor es mejor. La velocidad CPU determina si puedes reindexar un corpus de 5.000 páginas en el almuerzo (jina, nomic) o necesitas planificar una ejecución nocturna (bge-large, gte-large).
| Modelo | Chunks/seg (CPU) | Tiempo de indexación corpus 5K páginas | Notas |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ~9 min | Mezcla de expertos; activa 305M de 475M parámetros por token |
| jina-embeddings-v3 | 220 | ~24 min | Adaptadores LoRA; se pueden desactivar para ~15% adicional de velocidad |
| snowflake-arctic-embed-l-v2.0 | 130 | ~40 min | Destilado de una base mayor; flash-attention ayuda en AVX-512 |
| gte-large | 110 | ~48 min | BERT estándar de 1.024 dimensiones; sin optimización especial para CPU |
| mxbai-embed-large-v1 | 105 | ~50 min | 1.024 dimensiones estándar; variante mxbai-embed-2d ofrece dimensiones menores |
| bge-large-en-v1.5 | 95 | ~55 min | El más preciso en inglés; el más lento en CPU por 24 capas × 1.024 dimensiones |
💡Tip: En hardware solo CPU, elige nomic-embed-text-v2 para cualquier corpus de más de 1.000 páginas. La ventaja de velocidad de 5–6× se acumula: una reindexación que tarda 9 minutos con nomic tarda más de 50 minutos con bge-large. Esa diferencia importa cada vez que ajustas el tamaño del chunk o cambias de embedder para hacer pruebas A/B.
Velocidad de embedding en GPU (chunks por segundo)
Rendimiento con tamaño de lote 64, chunks de 256 tokens, en NVIDIA RTX 4070 (12 GB VRAM). Mayor es mejor. La GPU reduce la brecha de velocidad entre modelos; el número GPU más lento (1.400 chunks/seg para bge-large) sigue siendo 2,4× más rápido que el número CPU más rápido.
| Modelo | Chunks/seg (GPU) | Tiempo de indexación corpus 5K páginas | Memoria GPU (pico) |
|---|---|---|---|
| nomic-embed-text-v2 | 4.800 | ~1 min 5 seg | 1,6 GB |
| jina-embeddings-v3 | 3.200 | ~1 min 35 seg | 2,4 GB |
| snowflake-arctic-embed-l-v2.0 | 1.800 | ~2 min 50 seg | 2,2 GB |
| gte-large | 1.600 | ~3 min 10 seg | 2,5 GB |
| mxbai-embed-large-v1 | 1.500 | ~3 min 25 seg | 2,4 GB |
| bge-large-en-v1.5 | 1.400 | ~3 min 35 seg | 2,7 GB |
📌Note: Estos números asumen que el modelo de embedding es el único que usa la GPU. Si ya está cargado un modelo de chat (Llama 3.3 8B Q4_K_M ocupa ~5 GB), el embedder compite por VRAM y el rendimiento cae entre un 30 y un 50% por la contención. En una tarjeta de 12 GB, puedes indexar o chatear, pero no ambas cosas a plena velocidad simultáneamente.
Huella de memoria y el trade-off de dimensiones
El número de dimensiones es la elección más sobreingenieriada en RAG local. Más dimensiones ayudan a la recuperación hasta ~1.024, luego se estabilizan. Más allá de eso, pagas el doble de almacenamiento por ganancias inferiores a 1 punto porcentual.
- 768 dimensiones (nomic-embed-text-v2): 768 × 4 bytes = 3 KB por chunk. Un corpus de 5.000 páginas dividido en chunks de 256 tokens (~30.000 chunks) necesita ~90 MB solo para vectores.
- 1.024 dimensiones (todos los demás): 4 KB por chunk. El mismo corpus necesita ~120 MB para vectores. El almacenamiento escala linealmente — un corpus de 50.000 páginas necesita 1,2 GB a 1.024 dimensiones frente a 0,9 GB a 768 dimensiones.
- Aprendizaje de representación Matryoshka — jina-embeddings-v3 y nomic-embed-text-v2 están entrenados para que puedas truncar el vector a 768, 512, 256 o incluso 128 dimensiones y seguir recuperando bien. El truncamiento es simplemente cortar el array — sin re-embedder. Medimos una caída de retrieval@10 de ~1 punto a 512 dimensiones, ~3 puntos a 256 dimensiones y ~7 puntos a 128 dimensiones.
- Cuantización — la cuantización int8 de los vectores almacenados reduce el almacenamiento a la mitad y la latencia de recuperación a aproximadamente la mitad, con una caída de retrieval@10 de ~0,5 puntos porcentuales en nuestra prueba. Vale la pena para cualquier corpus de más de 25.000 chunks.
- Memoria en tiempo de inferencia — el modelo en sí se carga en RAM una vez. nomic-embed-text-v2 ocupa ~1,2 GB (la mezcla de expertos significa que las activaciones son más pequeñas que los parámetros), los modelos de 1.024 dimensiones ocupan entre 1,9 y 2,4 GB. Ninguno de los seis supera los 3 GB incluso en bf16.
- Almacenamiento en producción — para un corpus de 50.000 páginas, el tamaño de la base de datos vectorial en disco es 0,9 GB (768 dimensiones) → 1,2 GB (1.024 dimensiones) → 0,6 GB (1.024 dimensiones, cuantizado en int8). Los costos de copia de seguridad, sincronización y actualización incremental escalan todos con este número.
💡Tip: Si el costo de almacenamiento importa, haz el embedding con jina-embeddings-v3 a 1.024 dimensiones y trunca a 512 dimensiones para el almacenamiento. Obtienes la precisión en tiempo de indexación del modelo completo y la mitad del costo de almacenamiento, perdiendo aproximadamente 1 punto porcentual de retrieval@10. El truncamiento solo es reversible si conservas los vectores completos — decide antes de comprometerte.
Calidad multilingüe: cuando los líderes en inglés pierden
La gran brecha de calidad en este benchmark es entre los modelos multilingües y los solo en inglés, no entre dos modelos específicos. Un conjunto de 25 consultas multilingüe (inglés, alemán, francés, japonés, chino — 5 cada uno) expone la brecha con claridad.
| Modelo | Consulta EN → Documento EN | Consulta EN → Docs DE/FR | Consulta EN → Docs JA/ZH | Promedio multilingüe |
|---|---|---|---|---|
| jina-embeddings-v3 | 94% | 90% | 84% | 89% |
| nomic-embed-text-v2 | 92% | 93% | 90% | 92% |
| snowflake-arctic-embed-l-v2.0 | 90% | 88% | 80% | 86% |
| mxbai-embed-large-v1 | 92% | 82% | 66% | 80% |
| bge-large-en-v1.5 | 94% | 79% | 64% | 79% |
| gte-large | 93% | 78% | 63% | 78% |
📌Note: nomic-embed-text-v2 supera a jina-embeddings-v3 en consultas multilingüe porque su arquitectura de mezcla de expertos activa expertos específicos de idioma para contenido no inglés. Para corpus con contenido sustancial en japonés o chino, nomic-embed-text-v2 vale la pena comparar directamente — también es el más barato de ejecutar en CPU, lo que duplica su atractivo para cargas de trabajo multilingüe en laptops.
Perfiles por modelo: en qué destaca realmente cada embedder
Cada modelo tiene una intención de diseño diferente. Los números del benchmark anteriores provienen de esas decisiones de diseño.
- nomic-embed-text-v2 — Mezcla de expertos de pesos abiertos (475M parámetros totales, ~305M activos por token). Entrenado en 1.600 millones de pares en más de 100 idiomas. Licencia: Apache-2.0. Fortalezas: rendimiento CPU (5× más rápido que los peers de 1.024 dimensiones), fuerte recall entre idiomas, menor huella de memoria. Debilidades: el techo de 768 dimensiones significa un recall en inglés ligeramente menor frente a modelos de 1.024 dimensiones. Mejor para laptops solo CPU, corpus multilingües y cualquier pipeline de indexación que deba ejecutarse frecuentemente.
- bge-large-en-v1.5 (BAAI) — 335M parámetros, 1.024 dimensiones, 24 capas. Entrenado principalmente en inglés con pares contrastivos enfocados en recuperación. Licencia: MIT. Fortalezas: rendimiento de primer nivel en texto legal y de investigación en inglés, ecosistema maduro (todas las plataformas de RAG local lo soportan), comportamiento bien documentado bajo fine-tuning. Debilidades: solo inglés — cae 12–15 puntos en consultas multilingüe. El rendimiento CPU más lento en la prueba. Mejor para RAG solo en inglés donde la precisión importa más que la velocidad de indexación.
- gte-large (Alibaba) — 335M parámetros, 1.024 dimensiones. Entrenado en pares web con enfoque en búsqueda semántica de propósito general. Licencia: Apache-2.0. Fortalezas: licencia permisiva, fuerte rendimiento en inglés, amplio soporte de frameworks (Sentence Transformers, LangChain, LlamaIndex). Debilidades: enfocado en inglés (gte-multilingual-large existe por separado y añade ~1 GB de memoria). Mejor para despliegues comerciales donde Apache-2.0 simplifica la revisión de licencias.
- mxbai-embed-large-v1 (Mixedbread) — 335M parámetros, 1.024 dimensiones. Destilado y fine-tuned desde una base sólida con entrenamiento contrastivo enfocado en recuperación. Licencia: Apache-2.0. Fortalezas: rendimiento equilibrado en inglés, recall entre idiomas ligeramente mejor que bge-large, la variante mxbai-embed-2d soporta truncamiento Matryoshka (modelo separado). Debilidades: comunidad más pequeña que bge o gte. Mejor para RAG en inglés con licencia permisiva y la opción de actualizar a mxbai-embed-2d para flexibilidad de dimensiones.
- snowflake-arctic-embed-l-v2.0 (Snowflake) — 568M parámetros, 1.024 dimensiones, soporta de forma nativa hasta chunks de 8.192 tokens. Licencia: Apache-2.0. Fortalezas: capacidad de contexto largo (la mayoría de embedders limitan a 512 tokens), ~30 idiomas, sólido en documentos de estilo empresarial. Debilidades: precisión en la banda media para chunks cortos. Mejor para corpus con documentos estructurados muy largos (contratos legales, manuales técnicos, presentaciones regulatorias) donde los chunks de 8k tokens son útiles.
- jina-embeddings-v3 (Jina AI) — 570M parámetros, 1.024 dimensiones con truncamiento Matryoshka a 768/512/256. Entrenado con adaptadores LoRA específicos de tarea (recuperación, clasificación, similitud). Soporte para 89 idiomas. Licencia: CC BY-NC 4.0 para los pesos abiertos (el uso comercial requiere una licencia de pago) — verifica antes de desplegar en un producto de pago. Fortalezas: mejor precisión de recuperación global en este benchmark, fuerte rendimiento multilingüe, truncamiento Matryoshka, adaptadores conscientes de la tarea. Debilidades: la licencia requiere cuidado para despliegues comerciales. Mejor para RAG personal, investigación y cualquier despliegue donde la licencia sea aceptable.
💡Tip: Siempre reverifica la licencia en el momento de la integración. Las licencias de los modelos de embedding han cambiado varias veces — bge pasó de MIT a un término comercial más restrictivo y volvió, jina-embeddings-v3 se distribuye bajo CC BY-NC para los pesos abiertos, y Snowflake añadió una Política de Uso Aceptable sobre Apache-2.0. Trata el README como una declaración actualizada, no como un documento histórico.
Autoalojado vs OpenAI text-embedding-3-large: Costo por millón de tokens
El embedding autoalojado es esencialmente gratuito a escala. El único costo relevante es la electricidad y la amortización del hardware — ambos se reducen a ruido comparado con el precio de la API para cualquier corpus de más de unos pocos miles de páginas.
| Enfoque | Costo / 1M tokens | Tiempo para 1M tokens | Notas |
|---|---|---|---|
| OpenAI text-embedding-3-large (API) | $0,13 | ~3 min (limitado por red) | Mayor precisión absoluta en inglés; los datos salen de tu máquina |
| jina-embeddings-v3 en RTX 4070 | ~$0,001 (electricidad) | ~5 min | Mejor precisión local; licencia CC BY-NC — verifica uso comercial |
| bge-large-en-v1.5 en RTX 4070 | ~$0,001 | ~12 min | Mejor precisión en inglés; licencia MIT |
| nomic-embed-text-v2 en RTX 4070 | ~$0,0005 | ~3 min 30 seg | Mayor rendimiento GPU; multilingüe; Apache-2.0 |
| nomic-embed-text-v2 en M3 Pro CPU | ~$0,0008 | ~30 min | Sin GPU necesaria; relevante solo porque es viable sin ella |
📌Note: Para un corpus de 5.000 páginas (~5M tokens a 1.000 tokens por página), OpenAI cobra ~$0,65 por reindexación completa — trivial. El costo real es la salida de datos: cada chunk sale de tu máquina, y muchos regímenes de cumplimiento sencillamente no lo permiten. El embedding autoalojado es primero una decisión de privacidad y control, y segundo una decisión de costo.
Árbol de decisión: ¿qué embedder deberías elegir?
Cinco preguntas binarias, en orden, llevan a la mayoría de lectores al embedder correcto.
- 1. ¿Tienes una GPU disponible para indexar? → No: nomic-embed-text-v2 (5× velocidad CPU). Sí: continúa.
- 2. ¿El corpus es solo en inglés? → No: continúa. Sí: bge-large-en-v1.5 si la precisión es lo más importante, gte-large o mxbai-embed-large-v1 si la licencia Apache-2.0 importa.
- 3. ¿Los documentos son muy largos (chunks de 8k+ tokens)? → Sí: snowflake-arctic-embed-l-v2.0. No: continúa.
- 4. ¿Necesitas truncar dimensiones después para controlar costos de almacenamiento? → Sí: jina-embeddings-v3 (Matryoshka). No: continúa.
- 5. ¿El despliegue es un producto comercial? → Sí: evita jina-embeddings-v3 (CC BY-NC) salvo que compres la licencia comercial — usa nomic-embed-text-v2 (Apache-2.0) o BAAI/bge-m3 (MIT) en su lugar.
- Si no estás seguro: jina-embeddings-v3. Es la elección de mayor precisión general en el benchmark y el único modelo que se mantiene por encima del 87% en todos los tipos de documento. Los despliegues donde la licencia lo permite deberían elegirlo por defecto.
Errores comunes al elegir un modelo de embedding
- Error 1: Quedarse con el embedder predeterminado de la plataforma. AnythingLLM incluye un embedder integrado pequeño; PrivateGPT usa all-MiniLM-L6-v2 por defecto; Open WebUI usa nomic-embed-text-v1.5 por defecto. Los tres predeterminados tienen un rendimiento inferior a jina-embeddings-v3 en 5–10 puntos porcentuales en retrieval@10. Cámbialos.
- Error 2: Elegir un modelo de 1.024 dimensiones cuando retrieval@10 ya era del 90% con un modelo de 768 dimensiones. La ganancia marginal rara vez justifica el doble de almacenamiento y el rendimiento CPU 5× más lento. nomic-embed-text-v2 alcanza el 88% — suficiente para la mayoría de los casos de uso.
- Error 3: Elegir un embedder solo en inglés para un corpus multilingüe. bge-large-en-v1.5 es el mejor embedder en inglés en la prueba y uno de los peores en contenido en japonés o chino. La respuesta sobre el "mejor embedder" depende del corpus — mide en tus propios datos.
- Error 4: Ignorar la licencia. jina-embeddings-v3 se distribuye bajo CC BY-NC para los pesos abiertos. Si lo incluyes en un producto de pago sin la licencia comercial, tienes un problema legal. Siempre reverifica la licencia en el momento de la integración.
- Error 5: Hacer benchmark en un corpus demasiado pequeño. Los seis modelos se ven bien en 100 documentos. Las diferencias se vuelven decisivas a partir de ~5.000 chunks, donde aparece el techo de recall de los embedders más débiles. Prueba con al menos 5.000 chunks de tu contenido real.
- Error 6: Olvidar que cambiar de embedder obliga a una reindexación completa. Ninguna plataforma de RAG local soporta migración incremental. Cada cambio de embedder cuesta entre 30 y 90 minutos por cada 5.000 páginas en hardware de consumo. Elige una vez, cambia deliberadamente.
FAQ
¿Cuál es el modelo de embedding más rápido solo en CPU?
nomic-embed-text-v2 — 580 chunks/seg en Apple M3 Pro con tamaño de lote 32 y chunks de 256 tokens. Aproximadamente 5× más rápido que las alternativas de 1.024 dimensiones (bge-large-en-v1.5 a 95, gte-large a 110, mxbai-embed-large-v1 a 105 chunks/seg). La ventaja de velocidad proviene de su arquitectura de mezcla de expertos, que activa solo ~305M de 475M parámetros por token. Para cualquier corpus de más de 1.000 páginas en hardware solo CPU, nomic-embed-text-v2 es el predeterminado práctico.
¿Las dimensiones de embedding más grandes realmente mejoran la recuperación?
Hasta ~1.024 dimensiones, sí. Más allá de eso, no. En el benchmark, nomic-embed-text-v2 de 768 dimensiones (88% retrieval@10) quedó 4 puntos por debajo de jina-embeddings-v3 de 1.024 dimensiones (92%) en general. Escalar a 1.536 o 3.072 dimensiones (algunas APIs comerciales) gana menos de 1 punto porcentual en comparaciones publicadas. Las dimensiones cuestan almacenamiento linealmente: un corpus de 50.000 páginas necesita 0,9 GB a 768 dimensiones frente a 1,2 GB a 1.024 dimensiones frente a 3,6 GB a 3.072 dimensiones. El truco Matryoshka — truncar después del embedding — da flexibilidad sin el costo.
¿Puedo usar embeddings multilingüe sin pérdida de rendimiento?
Los modelos multilingüe han alcanzado un nivel materialmente competitivo en 2026. jina-embeddings-v3 alcanzó el 92% de retrieval@10 global (89% específicamente en consultas multilingüe) — competitivo con los mejores embedders solo en inglés en texto en inglés y muy por delante en idiomas no ingleses. La brecha histórica (multilingüe = menor precisión) se ha reducido a 1–2 puntos en consultas en inglés para una ganancia de 10 puntos en idiomas no ingleses. Para corpus mixtos, el multilingüe es ahora la elección correcta por defecto.
¿Qué modelo de embedding maneja mejor el código?
Ninguno de los seis probados es un embedder de código dedicado. En una base de código TypeScript/Python, jina-embeddings-v3 lideró con el 87% de retrieval@10, y los demás estuvieron entre el 82 y el 86%. Para corpus con mucho código — búsqueda de código, RAG de repositorios, herramientas de agentes sobre una base de código — combina un embedder general con uno específico para código (BAAI/bge-code-v1, voyage-code-2 o una variante fine-tuned) y usa el de mayor puntuación para los chunks de código. El enfoque más simple: embeds todo primero con jina-embeddings-v3, mide retrieval@10 en un conjunto de consultas de reserva y solo cambia si cae por debajo de tu umbral.
¿Con qué frecuencia debería actualizar mi modelo de embedding?
Actualiza cuando un nuevo modelo publicado muestre un benchmark que supere al tuyo en 3+ puntos porcentuales en datos similares a tu corpus, Y tengas un número de retrieval@10 medido con el que comparar. Sin una medición de referencia, no puedes saber si el nuevo modelo es realmente mejor en tu contenido. Para la mayoría de los despliegues de RAG local, un embedder es bueno durante 12–18 meses antes de que llegue una opción significativamente mejor. La reindexación es el costo — presupuesta entre 30 y 90 minutos por cada 5.000 páginas en hardware de consumo.
¿Puedo mezclar modelos de embedding en el mismo sistema RAG?
Técnicamente sí, en la práctica no. Mezclar requiere dos índices vectoriales paralelos (consultar ambos, combinar resultados — añade 50–150 ms de latencia y complica la puntuación de relevancia) o entrenar una pequeña capa de proyección para alinear dimensiones (nivel de investigación, frágil). Para el 95% de los despliegues locales, elige un embedder y reindexca. La excepción: repositorios de código con un embedder de código dedicado para chunks de código y un embedder general para documentación — divide por tipo de documento en la ingesta, consulta ambos índices cuando la consulta del usuario sea ambigua.
¿Los embeddings de código abierto son tan buenos como los de OpenAI?
Para la mayoría de los casos de uso de RAG local, sí. OpenAI text-embedding-3-large todavía lidera los benchmarks de inglés publicados por 2–4 puntos porcentuales en retrieval@10, pero la brecha se ha cerrado materialmente. jina-embeddings-v3 quedó a solo 2 puntos en el corpus de prueba, y la ruta de OpenAI requiere que los datos salgan de tu máquina — un descarte inmediato para cualquier despliegue con restricciones de privacidad o cumplimiento. Para calidad pura en texto en inglés sin requisito de privacidad y un presupuesto modesto, OpenAI sigue siendo el número absoluto más alto; para todo lo demás, el código abierto se ha puesto al día.
¿La cuantización afecta la calidad del embedding?
La cuantización int8 de los vectores almacenados cuesta aproximadamente 0,5 puntos porcentuales de retrieval@10 a cambio de reducir el almacenamiento a la mitad y la latencia de recuperación a aproximadamente la mitad. Vale la pena para cualquier corpus de más de 25.000 chunks. Cuantizar el *modelo de embedding en sí* (los pesos — bf16 → int8 → int4) es más agresivo: la cuantización del modelo en int8 cuesta 1–2 puntos porcentuales; int4 cuesta 3–5 puntos y perjudica notablemente el recall multilingüe. Para RAG local en hardware de consumo, ejecuta el modelo en bf16 (o fp16) y cuantiza solo los vectores almacenados.
¿Qué modelo es el mejor para documentos legales?
bge-large-en-v1.5 lideró el subconjunto legal con el 94% de retrieval@10 — el número individual más alto del benchmark — pero solo para contratos en inglés. Para corpus legales en alemán, francés o multilingüe, jina-embeddings-v3 (93% inglés / 89% multilingüe) es el mejor generalista. El texto legal favorece los modelos de 1.024 dimensiones porque la precisión terminológica importa; nomic-embed-text-v2 de 768 dimensiones quedó 6 puntos por debajo en el subconjunto legal. Para contratos muy largos (más de 50 páginas de leguaje jurídico denso), snowflake-arctic-embed-l-v2.0 con chunks de 8k tokens reduce las pérdidas por fragmentación.
¿Se pueden reutilizar los embeddings si cambio de plataforma RAG?
Los documentos fuente se mueven libremente entre plataformas. Los embeddings solo se mueven si la nueva plataforma soporta el mismo formato de vector y el mismo modelo de embedding. AnythingLLM (LanceDB), PrivateGPT (Qdrant o Chroma) y Open WebUI (ChromaDB) usan todos diferentes almacenes de vectores; incluso cuando el embedder es idéntico, los esquemas de metadatos difieren. En la práctica, cada cambio de plataforma también es un pase de reindexación. Planifica en consecuencia: elige el embedder por calidad de recuperación, elige la plataforma por todo lo demás.