RAG con embeddings locales: Ollama y ChromaDB en producción

Español 7 min de lectura
rag embeddings local-ai

RAG (Retrieval-Augmented Generation) es el método más práctico para conectar un modelo de lenguaje con la base de conocimiento propia de una empresa — sin necesidad de reentrenar el modelo. La tecnología es madura. El problema es que la mayoría de las guías de producción aún dependen de APIs de embeddings en la nube — OpenAI, Cohere, Pinecone — que envían cada documento y cada consulta a servidores externos.

Para organizaciones que gestionan datos sensibles — despachos de abogados, asesorías, empresas de ingeniería, consultas médicas — ese flujo de datos no es aceptable. Esta guía cubre la construcción de un stack RAG completamente local: embeddings, almacenamiento vectorial, recuperación, re-ranking y evaluación, todo ejecutado en hardware propio.

Qué modelos de embeddings locales funcionan en producción

Un modelo de embeddings convierte texto en un vector numérico que captura el significado semántico. Un sistema bien configurado encuentra la cláusula contractual o el procedimiento correcto incluso cuando la pregunta del usuario utiliza palabras distintas a las del texto fuente.

Dos modelos se han establecido como fiables en entornos de producción:

  • nomic-embed-text: Vector de 768 dimensiones, multilingüe, disponible directamente vía Ollama. Según mediciones reportadas por la comunidad, su calidad es competitiva con modelos de embeddings anteriores de OpenAI, con una latencia significativamente menor para consultas locales. Especialmente adecuado para documentación en español.
  • mxbai-embed-large: Publicado por Mixedbread.ai, también disponible vía Ollama. Practitioners reportan resultados sólidos en el benchmark MTEB y buena calidad de recuperación para documentos en inglés.

Para corpus de documentos en español o multilingüe — habitual en pymes españolas con documentación en varios idiomas — nomic-embed-text ofrece la cobertura lingüística más amplia.

Configurar Ollama como backend de embeddings

La API de embeddings de Ollama está disponible desde la versión 0.1.x. Un único comando descarga el modelo:

ollama pull nomic-embed-text

La generación de embeddings se realiza mediante un endpoint REST local:

curl http://localhost:11434/api/embeddings \
  -d '{"model": "nomic-embed-text", "prompt": "Su texto de documento aquí"}'

Sin clave de API. Sin solicitud de red. Sin coste por llamada. El servicio de embeddings se ejecuta en el mismo hardware que el modelo de lenguaje — sin segundo equipo, sin infraestructura adicional. Para una visión general del stack de IA local, consulte local-ai.html.

ChromaDB como base de datos vectorial local

ChromaDB es una base de datos vectorial de código abierto que se ejecuta localmente como biblioteca Python o como contenedor Docker independiente. Para despliegues de escala pyme — habitualmente menos de un millón de chunks de documentos — el modo embebido es suficiente y no requiere proceso de servidor separado:

import chromadb
client = chromadb.Client()
collection = client.create_collection("documentos_empresa")

Múltiples proyectos activos de la comunidad en GitHub demuestran este stack en entornos de producción: Ollama para embeddings e inferencia LLM, combinado con ChromaDB para almacenamiento vectorial. La combinación está bien probada y es operativamente sencilla.

Chunking: la decisión más determinante

La calidad de un sistema RAG depende más de cómo se dividen los documentos que del modelo de lenguaje que los procesa. Los chunks demasiado grandes diluyen la relevancia; los demasiado pequeños pierden contexto.

Para documentos típicos de pyme — contratos, procedimientos, especificaciones técnicas, archivos de correo electrónico — estos valores son un punto de partida fiable:

  • Tamaño del chunk: 400–800 tokens, aproximadamente 300–600 palabras en español
  • Solapamiento: 50–100 tokens para evitar cortar frases en los límites
  • Estrategia de división: por párrafos antes que por tamaño fijo — los límites de párrafo como puntos de división primarios

Para documentos legales, practitioners recomiendan un enfoque jerárquico: artículos como unidad de nivel superior, párrafos como chunk recuperable, con el número de artículo almacenado en los metadatos. Esto permite citas precisas en las respuestas generadas.

Re-ranking: mejorar la precisión tras la recuperación

La búsqueda de similitud vectorial recupera candidatos rápidamente, pero no siempre los más relevantes primero. Un re-ranker cross-encoder evalúa la consulta y cada documento candidato juntos, produciendo un ranking de relevancia más preciso.

Un pipeline de re-ranking local práctico:

  1. Recuperación: Top 20 chunks vía búsqueda vectorial en ChromaDB
  2. Re-ranking: Top 5 vía cross-encoder (p.ej., un modelo ms-marco-MiniLM ejecutado localmente)
  3. Generación: Solo los 5 chunks principales se pasan al LLM como contexto

La búsqueda híbrida — combinando coincidencia de palabras clave BM25 con embeddings densos — mejora adicionalmente la calidad de los candidatos. Especialmente útil para corpus con códigos de producto, referencias de artículos o terminología de dominio específico que la búsqueda semántica sola gestiona con dificultad.

Evaluar la calidad del RAG con RAGAS

Sin evaluación, la calidad del RAG es una conjetura. RAGAS es un framework de código abierto que mide los sistemas RAG en cuatro dimensiones:

  • Faithfulness: ¿La respuesta está en línea con lo que dicen los documentos recuperados?
  • Answer Relevance: ¿La respuesta aborda la pregunta formulada?
  • Context Precision: ¿Los chunks recuperados son realmente relevantes para la pregunta?
  • Context Recall: ¿Se recuperaron todos los fragmentos relevantes?

RAGAS puede ejecutarse completamente de forma local usando un modelo juez de código abierto — Llama 3.3, Qwen2.5 o Gemma 3 vía Ollama — por lo que incluso el paso de evaluación permanece dentro de la infraestructura propia. No se requiere ninguna llamada a API en la nube.

Un conjunto de prueba de 50–100 preguntas representativas es suficiente para identificar debilidades en el chunking o la recuperación antes de que el sistema entre en producción.

RGPD: el cumplimiento como ventaja estructural

Un stack RAG completamente local significa que ningún documento, ninguna consulta y ninguna respuesta generada sale de la infraestructura propia. Para las organizaciones que procesan datos de clientes bajo el RGPD, esto elimina tres cargas de cumplimiento específicas:

  • No se requiere contrato de encargo de tratamiento con un proveedor de nube de EE.UU. o tercer país
  • Sin transferencia internacional de datos según el Capítulo V del RGPD
  • Sin exposición a obligaciones de acceso a datos contradictorias bajo legislación extranjera

Para pymes españolas que acceden al programa Kit Digital, la implementación de un sistema RAG local puede encuadrarse dentro de la categoría de Gestión de Procesos y Automatización, según nuestra interpretación del catálogo de soluciones vigente. Recomendamos verificar la elegibilidad con el agente digitalizador correspondiente.

En cuanto al hardware, un stack RAG local de nivel productivo es viable en equipos Apple Silicon actuales. Practitioners reportan que un Mac Studio M3 Ultra (192 GB de memoria unificada) gestiona simultáneamente inferencia LLM y generación de embeddings sin cuellos de botella de rendimiento. Un Mac Mini M4 Pro (48 GB) es suficiente para volúmenes de documentos inferiores a 500.000 chunks.

kAIra: stack RAG local preconfigurado para pymes

La plataforma kAIra de Freshlab integra embeddings nomic-embed-text, ChromaDB e inferencia Ollama como sistema preconfigurado y listo para producción. La indexación de documentos es automática al subir archivos; los cambios en documentos existentes se detectan y el índice vectorial se actualiza en consecuencia. Sin necesidad de programación para operar el sistema.

El módulo WikiHub hace que los documentos internos, procedimientos y archivos de contratos sean consultables en lenguaje natural. El módulo MailForge aplica la misma recuperación RAG a la redacción de correos electrónicos, extrayendo respuestas contextualmente precisas de la misma base de conocimiento local.

Si desea evaluar si un stack RAG local encaja con sus documentos y procesos, un proyecto piloto es la vía más rápida para obtener una respuesta concreta: Solicitar un piloto.