nomic-embed-text: embeddings abiertos competitivos
Actualizado: 2026-05-03
En febrero de 2024 Nomic AI liberó nomic-embed-text-v1 y, semanas después, la variante v1.5 con representaciones Matryoshka. No es el primer modelo de embeddings open source, pero sí el primero que llega a la vez con tres cosas: pesos bajo Apache 2.0, datos de entrenamiento completamente auditables y un número de MTEB lo bastante cerca de text-embedding-3-small como para que la conversación deje de ser “open source o calidad” y pase a ser “open source con calidad suficiente”.
Puntos clave
- 137M de parámetros, vectores de 768 dimensiones y hasta 8192 tokens de contexto: el triple de la mayoría de modelos abiertos anteriores.
- Licencia Apache 2.0 con datos de entrenamiento publicados: sin lock-in de proveedor.
- La variante v1.5 añade Matryoshka Representation Learning: truncar a 256 dimensiones pierde solo 2-3 puntos de MTEB.
- Los prefijos de tarea (
search_query:,search_document:) son obligatorios; omitirlos es el error más común al migrar desde OpenAI. - Compatible con Ollama, LangChain, LlamaIndex y pgvector sin plugins adicionales.
Por qué importan los embeddings abiertos
Un embedding es la parte más silenciosamente cara de un sistema RAG. No por el precio por token, sino por el acoplamiento. Si indexas millones de documentos con un modelo propietario y ese modelo cambia de versión o desaparece, tu índice se queda huérfano. Reindexar no es trivial: implica reprocesar todo el corpus, regenerar los vectores, reconstruir el índice HNSW y validar que la calidad de recuperación sigue siendo la esperada.
Hay además dos dimensiones adicionales:
- Residencia de datos: en la UE, muchos equipos legales aún miran con recelo enviar el corpus completo a la API de OpenAI. Un modelo local elimina esa fricción.
- Transparencia: Nomic publicó el dataset de entrenamiento, lo que permite a un equipo de cumplimiento entender qué datos vio el modelo y razonar sobre sus sesgos.
Qué es nomic-embed-text-v1 exactamente
El modelo tiene 137 millones de parámetros, produce vectores de 768 dimensiones y acepta hasta 8192 tokens de contexto. Ese último número es el más sorprendente: la mayoría de embeddings abiertos de la generación anterior (E5, BGE, GTE) se quedaban en 512 tokens, lo que obligaba a trocear documentos largos en fragmentos pequeños. 8k permite embedir un artículo entero o una conversación completa sin chunkear artificialmente.
El entrenamiento siguió un esquema contrastivo en dos fases:
- Preentrenamiento débilmente supervisado sobre ~235M de pares (Common Crawl, Wikipedia, StackExchange, Reddit).
- Fine-tuning supervisado con MSMARCO, NQ, HotpotQA y datasets curados por Nomic.
En MTEB, v1 promedia alrededor de 62.4 puntos. Para contexto: text-embedding-3-small ronda 62.3. Nomic no es el mejor modelo abierto, pero está dentro del margen del embedding propietario que la mayoría de equipos usa por defecto, con 768 dimensiones en lugar de 1536. Menos dimensiones se traducen en índices más pequeños y búsquedas más rápidas.
Prefijos de tarea y la versión v1.5
Una peculiaridad operativa importante: el modelo usa prefijos al estilo de Cohere Embed v3. Hay que anteponer el prefijo correcto según el uso:
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("nomic-ai/nomic-embed-text-v1.5", trust_remote_code=True)
doc = model.encode("search_document: RAG combina retrieval con generación.")
query = model.encode("search_query: ¿qué es RAG?")
Ignorar los prefijos degrada notablemente la calidad de recuperación. Es el error más frecuente al migrar desde OpenAI, donde no existen prefijos.
La versión v1.5 añade Matryoshka Representation Learning: el modelo se entrena para que los primeros N componentes del vector sean útiles por sí solos. Puedes quedarte con las 768 dimensiones completas o truncar a 512, 256, 128 o 64 según tus restricciones de almacenamiento, con una degradación gradual y predecible. Pasar de 768 a 256 dimensiones reduce el espacio en casi un 70% a cambio de un par de puntos de MTEB. Para un corpus grande donde el coste del índice vectorial empieza a pesar, ese trade-off vale la pena.
Rendimiento e integración
En CPU servidor de 16 núcleos, el modelo sirve alrededor de 100 embeddings por segundo; en una RTX 4090, unos 3000; en Apple Silicon M2 Pro con backend MPS, unos 500. Con Ollama (ollama pull nomic-embed-text) se expone una API compatible con el endpoint de embeddings de OpenAI, lo que permite migrar código existente cambiando solo la base_url. Para pgvector basta con declarar la columna como vector(768) e indexar con HNSW sobre vector_cosine_ops. Ver también pgvector y madurez en producción para detalles de configuración del índice.
Hay una variante nomic-embed-text-v1-multilingual entrenada sobre un centenar de idiomas, incluyendo español. No iguala a Cohere Embed v3 en multilingüe serio, pero cubre razonablemente los casos europeos más habituales. Para sistemas RAG donde la evaluación de la recuperación importa, ver frameworks de evaluación para retrieval.
Expectativas realistas
Nomic no es frontier: si tu aplicación depende del último 3% de precisión en recuperación que separa un modelo bueno de uno excelente, text-embedding-3-large o mxbai-embed-large seguirán ganando. Tampoco es la mejor opción si:
- Tu corpus es fuertemente multilingüe (Cohere Embed v3 sigue siendo mejor).
- Necesitas más de 8192 tokens de contexto (caso inusual, pero existe).
- El equipo no puede permitirse gestionar un modelo local.
Lo que sí ofrece, y pocos modelos lo hacen, es una combinación aceptable en los cuatro ejes que suelen importar a la vez: calidad cercana al estándar propietario, contexto largo, licencia permisiva de verdad y datos de entrenamiento publicados.
Conclusión
El hecho de que exista un modelo como nomic-embed-text, con toda la cadena de suministro abierta y calidad competitiva, es probablemente más importante a medio plazo que su posición exacta en el benchmark del mes. Para un RAG en producción donde el equipo prefiere no depender de una API externa y el inglés es el idioma principal, Nomic se convierte en la opción por defecto razonable.
