Modelos de embeddings en Ollama para RAG

Diferencia entre modelos de chat y de embeddings

Los modelos de chat (llama3.2, qwen3, gemma3, etc.) están pensados para generar texto: completar prompts, mantener conversaciones o seguir instrucciones. Los modelos de embeddings están optimizados para convertir texto en vectores (listas de números) que representan el significado semántico. Esos vectores se usan para comparar textos por similitud (búsqueda semántica, clustering) o como entrada a flujos RAG (Recuperación Aumentada por Generación): indexas fragmentos de documentos como vectores, conviertes la pregunta del usuario en vector, recuperas los fragmentos más similares y los pasas como contexto a un modelo de chat para que responda.

En Ollama, los embeddings se obtienen con el endpoint /api/embed, vistos anteriormente. Aquí nos centramos en qué modelos usar, qué dimensiones tienen y cómo sacarles partido en RAG y búsqueda semántica.

No conviene usar un modelo de chat genérico para embeddings. Los modelos específicos de embeddings suelen dar vectores más útiles para similitud y con dimensiones adecuadas para almacenar y comparar.

Modelos recomendados y dimensiones

La biblioteca de Ollama incluye varios modelos de embeddings. La documentación y la web de Ollama listan los actuales, y estos son ejemplos típicos:

• nomic-embed-text: muy usado, 768 dimensiones, buen equilibrio entre calidad y rendimiento. Adecuado para documentos largos y contexto amplio.
• mxbai-embed-large: 1024 dimensiones, orientado a alta calidad en benchmarks (por ejemplo MTEB). Útil cuando priorizas precisión sobre tamaño del vector.
• all-minilm: 384 dimensiones, ligero y rápido. Idóneo cuando tienes poco hardware o muchas consultas.
• bge-m3: 1024 dimensiones, multilingüe y con buen rendimiento en rankings. Buena opción para textos en varios idiomas.
• embeddinggemma, qwen3-embedding: modelos recientes que la documentación suele recomendar. Comprueba en la web de Ollama las dimensiones y requisitos de cada uno.

La dimensión del vector (384, 768, 1024, etc.) afecta al espacio que ocupa en disco o en memoria y, en la práctica, a la calidad de la similitud: más dimensiones suelen permitir representaciones más ricas, pero a cambio de más almacenamiento y cómputo. Para RAG en español o multilingüe, 768 o 1024 dimensiones son opciones habituales, y para prototipos o recursos limitados, 384 puede bastar.

Algunos modelos aceptan el parámetro dimensions en la petición a /api/embed para reducir la dimensión del vector (por ejemplo 256 en lugar de 768). No todos lo soportan, así que revisa la documentación del modelo concreto.

Buenas prácticas para RAG

• Mismo modelo para indexar y consultar: usa siempre el mismo modelo de embeddings para generar los vectores de tus documentos y el vector de la pregunta del usuario. Si indexas con un modelo y consultas con otro, la similitud no es comparable y el RAG se degrada.
• Similitud coseno: para búsqueda semántica y RAG se recomienda similitud coseno (o producto escalar si los vectores están normalizados. Ollama devuelve vectores L2-normalizados, por lo que producto escalar y coseno coinciden). Ordena los fragmentos por esa similitud y toma los N más altos como contexto.
• Lotes: si tienes muchos fragmentos, llama a /api/embed con input como array de cadenas para generar varios vectores en una sola petición y aprovechar mejor el rendimiento.
• Longitud del texto: cada modelo tiene un límite de tokens por entrada. Si un fragmento es muy largo, puede truncarse (por defecto suele aplicarse truncado) o dar error. Fragmenta documentos en trozos de tamaño manejable (por ejemplo párrafos o ventanas con solapamiento) antes de generar embeddings.

flowchart TB
  D[Documentos] --> F[Fragmentar]
  F --> E["/api/embed"]
  E --> V[(Vectores)]
  Q[Pregunta] --> E2["/api/embed"]
  E2 --> V
  V --> S[Similitud coseno]
  S --> C[Top-K fragmentos]
  C --> G["/api/chat"]
  G --> R[Respuesta]

Documentos se fragmentan y se convierten en vectores con el mismo modelo, y la pregunta también se convierte en vector. Se calcula similitud, se eligen los fragmentos más similares y se envían como contexto al modelo de chat para generar la respuesta.

Uso con la API y con el mismo modelo

Recuerda que en la petición a /api/embed debes indicar el modelo por nombre (por ejemplo nomic-embed-text, embeddinggemma). Descárgalo antes con ollama pull nombre-modelo si lo usas en local. Ejemplo mínimo en Python:

import ollama

# Un solo texto
r = ollama.embed(model='nomic-embed-text', input='El cielo es azul.')
vector = r['embeddings'][0]
print(len(vector))  # 768 para nomic-embed-text

# Varios textos en una llamada
r = ollama.embed(
  model='nomic-embed-text',
  input=['Primer párrafo.', 'Segundo párrafo.', 'Tercer párrafo.'],
)
for i, v in enumerate(r['embeddings']):
  print(f'Fragmento {i}: {len(v)} dimensiones')

En un flujo RAG típico: indexas todos los fragmentos de tu base de documentos con ese modelo, guardas los vectores (y los textos originales) en tu índice o base vectorial. Cuando llega una pregunta, generas su embedding con el mismo modelo, buscas los K vectores más cercanos por similitud coseno, recuperas los textos asociados y los pasas como contexto a /api/chat (o /api/generate) para que el modelo responda. Así los modelos de embeddings en Ollama te permiten montar RAG y búsqueda semántica de forma local o integrada en tu stack.