Cómo construir un pipeline de RAG local con n8n + Ollama: preguntas y respuestas sobre documentos privados 2026

La mayoría de los tutoriales de RAG empiezan con una clave de API de OpenAI. La suposición es que enviarás tus documentos a un modelo de embeddings en la nube y consultarás un LLM alojado en terceros. Eso funciona bien para proyectos personales, pero en el momento en que trabajas con bases de código internas, contratos de clientes, notas de investigación privadas o cualquier cosa sujeta a una política de manejo de datos, subir documentos a una API externa queda descartado.

La alternativa es un stack de RAG completamente local construido con n8n y Ollama. El pipeline de ingesta divide tus documentos en fragmentos, genera embeddings en tu propio hardware con Ollama y almacena los vectores en una instancia de Qdrant autoalojada. El pipeline de consulta embebe las preguntas entrantes, recupera los fragmentos más relevantes y genera respuestas usando un LLM local, también a través de Ollama. Todo corre en un solo mini PC y nada sale de tu red.

Esta guía recorre el proceso completo de principio a fin: configuración de Qdrant, selección del modelo de embeddings y ambos workflows de n8n (ingesta y consulta). Cubro las decisiones de configuración que realmente importan y los errores que suelen ocurrir la primera vez que se intenta montar este stack.

¿Qué es RAG y por qué correrlo localmente?

La Generación Aumentada por Recuperación (RAG) resuelve un problema específico de los LLMs: los modelos de lenguaje solo pueden razonar sobre el texto que cabe en su ventana de contexto y no tienen conocimiento de documentos con los que no fueron entrenados. RAG rodea esta limitación preprocesando tus documentos, dividiéndolos en fragmentos y embbebiéndolos en una base de datos vectorial; luego, al momento de consulta, recupera solo los fragmentos relevantes para incluirlos como contexto. El LLM responde basándose en ese contexto recuperado, no en su conocimiento de entrenamiento general.

El flujo clásico de RAG tiene dos fases. La fase de ingesta: leer el documento, dividirlo en fragmentos, convertir cada fragmento en un vector de embedding y almacenar esos vectores junto con el texto original. La fase de consulta: embeber la pregunta entrante con el mismo modelo, encontrar los vectores más cercanos al vector de la pregunta mediante búsqueda por similitud semántica, recuperar el texto original de esos fragmentos y pasarlos como contexto al LLM. El modelo responde basándose en el texto recuperado, no en datos de entrenamiento inventados.

Correr esto localmente, en lugar de usar embeddings de OpenAI y un LLM en la nube, ofrece tres ventajas concretas. Primero, el costo: text-embedding-3-small de OpenAI cobra por token, lo que se acumula rápido en colecciones de documentos grandes. Según la documentación de Ollama, los modelos locales no tienen costo una vez comprado el hardware. Segundo, la latencia: en un mini PC con una unidad NVMe rápida, el embedding local puede igualar la latencia de la API para tamaños de documento típicos. Tercero, y más práctico para muchos desarrolladores, se elimina por completo el problema de gobernanza de datos: nada sale de tu red, así que no hay ninguna pregunta de cumplimiento normativo que responder.

Si ya tienes n8n y Ollama corriendo en tu homelab (cubierto de principio a fin en este post anterior sobre n8n + Ollama en Proxmox (en inglés)), agregar una capa de RAG es el siguiente paso natural que reutiliza la misma infraestructura sin costo mensual adicional.

Lo que necesitas antes de empezar

Este tutorial asume que tienes una instancia de n8n funcionando y una instancia de Ollama accesible desde n8n. Si estás empezando desde cero, la guía de configuración de Ollama + Open WebUI cubre la instalación completa de Ollama. Para n8n, el camino más directo es Docker: docker run -p 5678:5678 n8nio/n8n levanta una instancia funcional. Los nodos de IA/LangChain vienen incluidos por defecto en n8n v1.x en adelante, no hace falta una instalación separada.

También necesitarás Docker corriendo en un host accesible desde n8n para ejecutar Qdrant. Qdrant es el almacén vectorial que guarda los fragmentos embebidos. Expone una API REST con la que el nodo de Qdrant de n8n se comunica directamente, y tiene un dashboard web para inspeccionar lo que se ha indexado. Hay otras opciones de almacenamiento vectorial compatibles con n8n (Pinecone, Supabase pgvector, Weaviate), pero Qdrant es autoalojable, no tiene latencia de arranque en frío y la integración con n8n funciona muy bien.

Los requisitos de RAM dependen de qué modelos corras simultáneamente. Ejecutar nomic-embed-text junto con un modelo de chat de 7B como LLaMA 3.1 requiere alrededor de 6–7 GB de RAM para los modelos, más 1–2 GB combinados para n8n y Qdrant. Un Beelink SER5 Mini PC (~$299) con su configuración de 16 GB lo maneja sin problemas. Si quieres experimentar con modelos de embeddings de mayor calidad como Qwen3-Embedding-4B, que requiere alrededor de 9 GB de VRAM según la comparativa de modelos de embeddings locales 2026, el MINISFORUM UM890 Pro (~$429) con 32 GB de RAM y los gráficos integrados Radeon 780M del Ryzen 9 8945HS es mejor opción. Para el almacenamiento de documentos y el índice de Qdrant en disco, un NVMe rápido como el WD_BLACK SN850X 2TB mantiene baja la latencia de ingesta y recuperación en colecciones grandes.

Paso 1: Ejecutar Qdrant localmente con Docker

Inicia Qdrant con un solo comando de Docker. Los flags críticos son el volumen para persistencia y los dos mapeos de puertos: n8n usa la API REST en el puerto 6333, y el 6334 es gRPC (usado por algunos otros clientes):

docker run -d   --name qdrant   --restart unless-stopped   -p 6333:6333   -p 6334:6334   -v $(pwd)/qdrant_storage:/qdrant/storage   qdrant/qdrant

Una vez en ejecución, abre http://localhost:6333/dashboard en el navegador. Deberías ver la interfaz web de Qdrant con una lista de colecciones vacía, lo cual es esperado. La colección se crea automáticamente por el nodo de Qdrant de n8n en la primera ejecución de ingesta. El flag --restart unless-stopped asegura que Qdrant se recupere tras reinicios del host sin intervención manual, lo cual importa en hardware de homelab.

Según la documentación oficial de Qdrant, la configuración de colección por defecto usa similitud coseno para medir distancias y HNSW como algoritmo de índice. Para casos de uso típicos de RAG en homelab con unos pocos miles a decenas de miles de fragmentos, estos valores predeterminados funcionan bien sin necesidad de ajuste. Solo necesitarías modificarlos para colecciones muy grandes (millones de vectores) o para casos de uso de búsqueda híbrida que combinen recuperación densa y dispersa.

Una funcionalidad útil del dashboard de Qdrant: tras ejecutar el workflow de ingesta, puedes usar el explorador de puntos para navegar por los fragmentos almacenados y verificar los metadatos adjuntos a cada vector. Si la recuperación devuelve resultados inesperados, revisar lo que realmente está almacenado en la colección suele revelar el problema más rápido que agregar logs de depuración al workflow de n8n.

Paso 2: Descargar tu modelo de embeddings con Ollama

Para la mayoría de los setups de homelab, nomic-embed-text es el punto de partida correcto. Según la biblioteca de modelos de Ollama, tiene 137M de parámetros, produce vectores de 768 dimensiones, admite una ventana de contexto de 8.192 tokens, requiere alrededor de 0,3 GB de VRAM y tiene licencia Apache-2.0 (utilizable en proyectos comerciales sin restricciones). Descárgalo con:

ollama pull nomic-embed-text

Si la calidad de recuperación importa más que el presupuesto de RAM, mxbai-embed-large ofrece mejores puntuaciones en benchmarks. Según la comparativa de modelos de embeddings locales 2026, obtiene 64,68 en el benchmark MTEB frente a 62,28 de nomic-embed-text, usa 0,7 GB de VRAM y también tiene licencia Apache-2.0. El inconveniente es una ventana de contexto máxima de 512 tokens: mantén el tamaño de fragmento por debajo de 400 tokens si usas este modelo. Para la mejor opción compacta de 2026, qwen3-embedding:0.6b con ~1,5 GB es una alternativa a considerar.

ollama pull mxbai-embed-large
# O para la mejor calidad en tamaño compacto (2026):
ollama pull qwen3-embedding:0.6b

También necesitas un modelo de chat para el workflow de consulta. LLaMA 3.1 8B y Qwen2.5 7B son buenas opciones que funcionan bien con los nodos de uso de herramientas de n8n. LLaMA 3.1 tiende a producir texto más fluido; Qwen2.5 sigue instrucciones de salida estructurada de forma más fiable. Cualquiera de los dos maneja bien las preguntas y respuestas sobre documentos en el rango de 7–8B parámetros. Descarga el que se ajuste a tu RAM disponible:

ollama pull llama3.1:8b
# o
ollama pull qwen2.5:7b

Paso 3: Construir el workflow de ingesta de documentos en n8n

El workflow de ingesta es un pipeline de cinco tipos de nodos. En n8n, crea un nuevo workflow y conéctalos en este orden. Un apunte importante según la documentación de integración IA/LangChain de n8n: los sub-nodos de LangChain (modelos de embeddings, divisores de texto, cargadores de documentos) se conectan a sus nodos padre a través del sub-slot de IA, no del conector de datos principal. Esta es la fuente de confusión más común al construir el primer workflow de RAG en n8n.

1. Manual Trigger (o Webhook Trigger para ingesta automatizada): inicia el workflow
2. Read/Write Files from Disk: lee la ruta del archivo objetivo. Alternativamente, usa un nodo HTTP Request para obtener contenido desde una URL.
3. Default Data Loader: se conecta al trigger mediante el conector principal. En la configuración del nodo, selecciona "Binary Data" como tipo de datos y "PDF" para documentos PDF. Los archivos de texto plano y Markdown funcionan sin configuración adicional.
4. Recursive Character Text Splitter: se conecta al sub-slot de IA del Default Data Loader. Tamaño de fragmento: 600, Superposición: 100, son buenos valores de inicio; aumenta el tamaño a 800–1000 para documentación técnica densa.
5. Qdrant Vector Store (Modo: "Insert Documents"): se conecta al conector principal del Default Data Loader. Agrega tu URL de Qdrant (http://localhost:6333) y establece un nombre de colección como mis-docs. Conecta un sub-nodo Embeddings Ollama al sub-slot de Embedding de este nodo, apuntando a http://localhost:11434 con el modelo configurado como nomic-embed-text.

Ejecuta el workflow manualmente con un documento de prueba y revisa el log de ejecución de n8n. Cada nodo debería completarse correctamente, y la salida del nodo de Qdrant reportará la cantidad de puntos insertados. Abre el dashboard de Qdrant y verás la nueva colección con los fragmentos indexados.

Para uso en producción, extiende este workflow con algunas adiciones: un nodo Loop Over Items para procesar múltiples archivos en lote, un nodo Set antes del Default Data Loader para adjuntar metadatos (nombre de archivo, fuente, fecha) a cada fragmento —estos metadatos se almacenan en Qdrant junto con el vector y se devuelven en la recuperación, permitiendo que el LLM cite sus fuentes. También puedes agregar una verificación previa que consulte Qdrant por puntos existentes que coincidan con el nombre de archivo para omitir documentos ya ingestados y evitar fragmentos duplicados.

Paso 4: Construir el workflow de consulta

El workflow de consulta toma una pregunta, recupera fragmentos relevantes de Qdrant y genera una respuesta usando el modelo de chat local. El patrón más limpio en n8n es un nodo AI Agent equipado con una herramienta Qdrant Vector Store: el agente decide cuándo consultar el almacén vectorial, puede manejar conversaciones de múltiples turnos mediante un nodo de memoria y se puede configurar para citar fuentes de los metadatos de los fragmentos.

Crea un nuevo workflow y conecta estos nodos:

1. Chat Trigger: crea una interfaz de chat basada en webhook. Al guardar, n8n te da una URL a la que puedes enviar preguntas por POST, o acceder mediante la interfaz de chat integrada.
2. AI Agent: el nodo central. Establece el prompt del sistema (abajo) y conecta los siguientes nodos a sus sub-slots.
3. Chat Model Ollama → sub-slot Chat Model del AI Agent: host http://localhost:11434, modelo llama3.1:8b
4. Window Buffer Memory → sub-slot Memory del AI Agent: mantiene el contexto de la conversación. Configura la longitud de la ventana a 5–10 turnos.
5. Qdrant Vector Store Tool → sub-slot Tool del AI Agent: misma URL de Qdrant y nombre de colección que en el workflow de ingesta. Conecta un sub-nodo Embeddings Ollama al sub-slot de Embedding de esta herramienta, usando el mismo modelo que en la ingesta.

Prompt del sistema para el nodo AI Agent:

Eres un asistente útil que responde preguntas sobre los documentos del usuario.
Usa la herramienta Qdrant vector store para buscar información relevante antes de responder.
Si la herramienta no devuelve resultados relevantes, dilo claramente en lugar de adivinar.
Cuando tu respuesta provenga de una sección de documento recuperada, menciona la fuente
si esa información está disponible en los metadatos.

La restricción de configuración más crítica: el modelo de embeddings en el sub-nodo Embeddings de la Qdrant Tool debe ser idéntico al modelo usado durante la ingesta. Si embebiste con nomic-embed-text, debes consultar con nomic-embed-text. Los diferentes modelos producen vectores en espacios dimensionales distintos: mezclarlos hace que la búsqueda de similitud devuelva fragmentos semánticamente no relacionados, y las respuestas del LLM parecen alucinadas aunque se generen genuinamente a partir del contenido recuperado (incorrecto). Es un modo de fallo silencioso fácil de pasar por alto si no revisas los fragmentos recuperados en el log de ejecución. Para profundizar en cómo el framework agéntico de n8n maneja las llamadas a herramientas, el post sobre AI Agents de n8n 2.0 (en inglés) cubre el patrón agente/herramienta completo.

Consejos de ajuste y errores frecuentes

El tamaño de fragmento y la superposición son tu primer palanca de ajuste. El tamaño del fragmento determina cuánto contexto contiene cada pieza recuperada; la superposición evita que el contexto importante se divida entre fragmentos y se pierda en la recuperación. Para documentación técnica o texto estructurado, 500–800 caracteres con 100–200 caracteres de superposición es un buen rango inicial. Para contenido con mucho texto corrido como PDFs largos o artículos, fragmentos más grandes (800–1.200 caracteres) tienden a dar al LLM más contexto útil. Según los docs de integración LangChain de n8n, el Recursive Character Text Splitter prioriza dividir en límites de párrafo, luego frases, luego caracteres, respetando la estructura natural del texto cuando es posible.

Reingestar tras cualquier cambio de modelo de embeddings. Cambiar de modelo de embeddings requiere eliminar la colección de Qdrant y reingestar todos los documentos desde cero. Los vectores de diferentes modelos son matemáticamente incompatibles; no existe ruta de migración. Si experimentas con varios modelos, nombra tus colecciones según el modelo (ej., docs-nomic, docs-mxbai) para poder cambiar entre ellas en la configuración del workflow sin perder ningún índice.

La ventana de contexto por defecto de Ollama es de 2.048 tokens. Para modelos de embeddings con ventanas de contexto nativas mayores (nomic-embed-text admite 8.192), Ollama limita la inferencia a 2K por defecto. Si tus fragmentos son mayores a unos 500 caracteres, es posible que los estés truncando silenciosamente al embeber. Corrígelo creando un modelo personalizado con un parámetro num_ctx mayor:

ollama show nomic-embed-text --modelfile > /tmp/nomic.Modelfile
echo "PARAMETER num_ctx 4096" >> /tmp/nomic.Modelfile
ollama create nomic-embed-text-4k -f /tmp/nomic.Modelfile

Usa nomic-embed-text-4k como nombre de modelo en ambos workflows. Ambos deben usar el mismo nombre de modelo personalizado, no una mezcla del base y el personalizado.

La elección del modelo LLM importa menos que el modelo de embeddings. La calidad de la recuperación —si los fragmentos correctos realmente regresan de Qdrant— determina la mayor parte de la calidad de las respuestas. El trabajo del LLM es sintetizar lo que encontró el recuperador. Un setup de recuperación bien ajustado con un modelo de chat pequeño de 7B superará sistemáticamente a un modelo más grande sobre una recuperación deficiente. Ajusta primero el chunking y los embeddings; luego mejora el modelo de chat si las respuestas son precisas pero están mal redactadas.

Para quien quiera el fundamento teórico sobre por qué diferentes estrategias de chunking y recuperación tienen el rendimiento que tienen, AI Engineering de Chip Huyen (~$40) tiene una de las mejores explicaciones de los compromisos en arquitecturas RAG, incluyendo cuándo RAG es la herramienta correcta y cuándo el fine-tuning o el stuffing de contexto lo supera.

El stack completo de un vistazo

Aquí está el mapa de componentes completo del pipeline de RAG local:

El footprint total en una máquina de 16 GB es cómodo. Ambos modelos de Ollama pueden cargarse simultáneamente sin paginación. Una colección de 50.000 fragmentos —que representan varios cientos de documentos PDF de extensión media— usa aproximadamente 200–400 MB de RAM de Qdrant dependiendo de las dimensiones vectoriales, según la documentación de rendimiento de Qdrant. En un NVMe local, las búsquedas de similitud a esa escala típicamente se completan en milisegundos de un solo dígito.

La extensión natural de este setup es una interfaz de usuario: un formulario web, un bot de Telegram o una integración con Slack, todos disponibles como nodos trigger y acción en n8n. El workflow de consulta ya expone un webhook de chat; cualquier cosa que pueda hacer POST a él tiene acceso al sistema local de preguntas y respuestas sobre documentos. También puedes añadir triggers de ingesta encima de los patrones del post de automatización n8n + Ollama en Proxmox (en inglés) para ingestar automáticamente archivos nuevos cuando se agregan a una carpeta vigilada. El resultado es una base de conocimiento privada y sin costo que tu equipo puede consultar en lenguaje natural.