En febrero de 2024 Nomic AI liberó nomic-embed-text-v1[1] y, semanas después, la variante v1.5[2] con representaciones Matryoshka. No es el primer modelo de embeddings open source, pero sí el primero que llega a la vez con tres cosas. Trae pesos bajo Apache 2.0, datos de entrenamiento completamente auditables y un número de MTEB lo bastante cerca de text-embedding-3-small. Con eso, la conversación deja de ser "open source o calidad" y pasa 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 que los modelos abiertos de la generación anterior.

  • 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, enviar el corpus completo a la API de OpenAI sigue chocando con la revisión legal. 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: los 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 informe técnico de Nomic[3] describe un esquema de entrenamiento 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 de referencia, 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?")

Sin el prefijo correcto, la calidad de recuperación cae. 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.

Muñecas Matryoshka anidadas que representan el concepto de representaciones anidables: igual que las muñecas contienen versiones más pequeñas de sí mismas, los vectores Matryoshka contienen subvectores útiles independientemente

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[4] (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 declaras la columna como vector(768) e indexas con HNSW sobre vector_cosine_ops.

Ver también pgvector y madurez en producción para detalles de configuración del índice. Para la versión en inglés de este artículo, ver nomic-embed-text: Competitive Open Embeddings.

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. Son calidad cercana al estándar propietario, contexto largo, licencia permisiva de verdad y datos de entrenamiento publicados.

Conclusión

Que exista un modelo como nomic-embed-text, con toda la cadena de suministro abierta y calidad competitiva, importa probablemente más 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.

Fuentes:

  1. Hugging Face — nomic-ai/nomic-embed-text-v1 model card[1]
  2. Nomic AI — Unboxing Nomic Embed v1.5: Resizable Embeddings with Matryoshka Representation Learning[2]
  3. arXiv — Nomic Embed: Training a Reproducible Long Context Text Embedder[3]
  4. Ollama — nomic-embed-text library page[4]

Preguntas frecuentes

¿Por qué baja la calidad de recuperación al migrar de OpenAI a nomic-embed-text?

Casi siempre por omitir los prefijos de tarea, que en Nomic son obligatorios al estilo de Cohere Embed v3: los documentos se codifican con search_document: y las consultas con search_query:. En la API de OpenAI no existen prefijos, así que al portar código se suelen olvidar, y sin ellos la calidad de recuperación cae. Con Ollama (ollama pull nomic-embed-text) se expone un endpoint compatible con el de embeddings de OpenAI, de modo que basta cambiar la base_url, pero los prefijos siguen siendo necesarios.

¿Puedo reducir las dimensiones de los vectores para ahorrar espacio en el índice?

Sí, con la variante v1.5, que incorpora Matryoshka Representation Learning. Los primeros N componentes del vector son útiles por sí solos, así que puedes truncar las 768 dimensiones a 512, 256, 128 o 64 con una degradación gradual y predecible. Pasar de 768 a 256 reduce el espacio casi un 70% a cambio de solo 2-3 puntos de MTEB. En pgvector la columna se declara como vector(768) con índice HNSW sobre vector_cosine_ops; si truncas, ajusta la dimensión de la columna.

¿Cuántos embeddings por segundo genera nomic-embed-text según el hardware?

En una CPU de servidor de 16 núcleos, alrededor de 100 embeddings por segundo; en una RTX 4090, unos 3000; en un Apple Silicon M2 Pro con backend MPS, unos 500. El modelo tiene 137 millones de parámetros y acepta hasta 8192 tokens de contexto, frente a los 512 de embeddings abiertos anteriores como E5, BGE o GTE. Ese contexto permite embedir un artículo entero sin trocearlo. En MTEB promedia unos 62.4 puntos, prácticamente lo mismo que text-embedding-3-small (62.3) con 768 dimensiones en lugar de 1536.

Fuentes

  1. nomic-embed-text-v1
  2. variante v1.5
  3. informe técnico de Nomic
  4. Ollama