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.

Comparativa de modelos de embeddings

Para facilitar la elección, esta tabla resume las características de los modelos más habituales:

| Modelo | Dimensiones | Tamaño | Mejor para | |--------|-------------|--------|------------| | nomic-embed-text | 768 | ~274 MB | Uso general, buen equilibrio calidad/velocidad | | mxbai-embed-large | 1024 | ~670 MB | Alta precisión en benchmarks (MTEB) | | all-minilm | 384 | ~45 MB | Prototipado rápido, hardware limitado | | bge-m3 | 1024 | ~1.2 GB | Textos multilingües |

La elección depende de tu caso de uso: para un prototipo en un portátil, all-minilm es rápido y ligero. Para producción con documentos en varios idiomas, bge-m3 suele dar mejores resultados. Para la mayoría de proyectos en español, nomic-embed-text con 768 dimensiones es una opción sólida que equilibra calidad y recursos.

Así los modelos de embeddings en Ollama te permiten montar RAG y búsqueda semántica de forma local o integrada en tu stack.

Estrategias de chunking para embeddings

La calidad de un sistema RAG depende tanto del modelo de embeddings como de cómo se parten los documentos. Un buen chunking asegura que cada fragmento sea autónomo (suficiente contexto para que el modelo entienda de qué habla) y a la vez pequeño (para que quepa holgadamente en el límite de tokens del modelo). Estas son las estrategias más usadas:

• Por caracteres o tokens fijos: la más simple. Divides el texto cada N tokens (por ejemplo 500) con un solapamiento de 50 tokens para no cortar frases en seco. Rápida y suficiente para documentación técnica bien estructurada.
• Por estructura semántica: cortas por cabeceras Markdown, párrafos o secciones. Produce fragmentos más naturales y mejora la recuperación en manuales, libros o artículos largos.
• Por oraciones: usas un splitter que respete los puntos y signos de cierre. Ideal para textos literarios o legales donde cada oración tiene peso.
• Basada en contenido: combinas las anteriores con reglas propias (por ejemplo, mantener cada definición junto con su ejemplo) para casos muy específicos.

Un buen valor de partida para modelos de 768 u 1024 dimensiones es 500-800 tokens por fragmento con 10-15 % de solapamiento. Itera con consultas reales: si el modelo no encuentra la respuesta, probablemente el fragmento es demasiado pequeño; si devuelve varios casi idénticos, probablemente es demasiado grande o el solapamiento es excesivo.

Ejemplo completo: búsqueda semántica mínima

Este script crea un índice de embeddings en memoria y responde a una consulta buscando los tres fragmentos más cercanos. No necesita base de datos externa y sirve perfectamente como punto de partida para un prototipo:

import ollama
import numpy as np

MODELO = "nomic-embed-text"

documentos = [
    "Ollama permite ejecutar modelos de lenguaje en local con una CLI sencilla.",
    "Los embeddings convierten texto en vectores para buscar por similitud.",
    "El endpoint /api/chat mantiene conversaciones con modelos como llama3.2.",
    "Modelfile es el archivo que describe cómo crear un modelo personalizado.",
    "RAG combina recuperación de contexto y generación con un LLM.",
]

respuesta = ollama.embed(model=MODELO, input=documentos)
indice = np.array(respuesta["embeddings"], dtype="float32")

def buscar(pregunta: str, k: int = 3) -> list[tuple[float, str]]:
    q = np.array(
        ollama.embed(model=MODELO, input=pregunta)["embeddings"][0],
        dtype="float32",
    )
    # Ollama devuelve vectores L2-normalizados, así que el producto
    # escalar equivale a la similitud coseno.
    similitudes = indice @ q
    top = np.argsort(-similitudes)[:k]
    return [(float(similitudes[i]), documentos[i]) for i in top]

for score, texto in buscar("¿Cómo hago búsquedas semánticas con Ollama?"):
    print(f"{score:.3f}  {texto}")

Este mismo patrón escala perfectamente a bases vectoriales reales como Qdrant, Chroma, Weaviate o pgvector: lo único que cambia es dónde guardas el indice y cómo consultas el top-K. La lógica de generar embeddings con un modelo consistente sigue siendo idéntica.

Parámetros útiles de /api/embed

La petición al endpoint acepta varios parámetros que merece la pena conocer:

| Parámetro | Tipo | Uso | |----------|------|-----| | model | cadena | Nombre del modelo de embeddings (nomic-embed-text, etc.) | | input | cadena o lista | Un texto o una lista de textos a vectorizar en lote | | truncate | booleano | Si true (por defecto), trunca las entradas demasiado largas; si false, la API devuelve error | | keep_alive | cadena | Tiempo que el modelo permanece cargado (5m, 30m, -1 para indefinido) | | options | objeto | Opciones avanzadas del runtime del modelo, igual que en /api/generate |

Para lotes grandes conviene dejar keep_alive en -1 mientras dura la indexación, evitando que Ollama tenga que recargar el modelo entre lotes.

Errores comunes al trabajar con embeddings

• Usar un modelo distinto para indexar y consultar: los vectores no serán comparables y la búsqueda degenerará en ruido.
• Olvidar normalizar cuando el modelo no lo hace: si combinas embeddings de distintas fuentes, normaliza a L2 antes de calcular similitudes.
• Fragmentos gigantes que superan el límite del modelo: la API los trunca y pierdes información relevante del final del fragmento.
• No deduplicar antes de indexar: fragmentos idénticos inflan el índice y producen top-K repetidos.
• Confundir similitud con relevancia: dos frases pueden ser semánticamente cercanas y aun así responder a preguntas distintas. Combina siempre con una instrucción clara al LLM del paso generativo.
• Reindexar sin necesidad: cada vez que cambias el modelo de embeddings tienes que regenerar todo el índice; planifica los cambios como migraciones.

Mejores prácticas

1. Guarda metadatos junto a cada vector (fuente, título, fecha, sección). Te permitirá filtrar antes o después de la búsqueda semántica.
2. Versiona el modelo en la configuración del sistema: si mañana cambias de nomic-embed-text a bge-m3, podrás reconstruir el índice sin ambigüedad.
3. Mide la calidad con un set de preguntas-respuestas conocido; compara el top-K antes y después de cada cambio.
4. Empieza simple: un índice en memoria o en SQLite es más que suficiente para los primeros cientos de miles de vectores.
5. Acompaña los embeddings con búsqueda léxica (BM25) en escenarios mixtos: el conjunto híbrido suele ganar al puramente vectorial.

Con estas pautas, los modelos de embeddings de Ollama dejan de ser una caja negra y se convierten en la pieza central de cualquier arquitectura RAG seria, manteniendo los datos dentro de tu infraestructura y con plena trazabilidad.