Construir RAG con n8n: el conocimiento de la empresa como chatbot, paso a paso

Retrieval-Augmented Generation (RAG) conecta un modelo de lenguaje con los propios documentos de la empresa, de modo que un chatbot ofrezca respuestas basadas en conocimiento interno real en lugar de basarse solo en el conocimiento general de entrenamiento del modelo. En n8n, en la práctica se construye un sistema RAG como dos workflows separados: el primer workflow carga documentos, los divide en secciones de texto, los convierte en vectores mediante un modelo de embedding y los almacena en un nodo Vector Store. El segundo workflow conecta este Vector Store mediante un nodo AI Agent como herramienta consultable, de modo que el chatbot busca por sí mismo los fragmentos de texto adecuados en cada consulta y los incorpora a su respuesta. Actualizado: julio de 2026.

¿Qué componentes necesita un workflow RAG en n8n?

Según la documentación de n8n, un workflow RAG en n8n se compone de cuatro componentes que interactúan entre sí: Document Loader, Text Splitter, Embeddings y Vector Store con Retriever. El Document Loader obtiene los datos de origen externos, por ejemplo de un archivo, un webhook o una consulta a una base de datos. El Text Splitter divide documentos largos en secciones más pequeñas, llamadas chunks, para que el modelo de embedding pueda procesarlas de forma adecuada. Los Embeddings convierten el texto en vectores, es decir, en representaciones numéricas de significado, y según la documentación n8n solo admite embeddings de texto. Por último, el Retriever recupera de la base de datos los vectores correspondientes a una consulta y los traduce de nuevo a texto utilizable. Los detalles de estos componentes se describen en la documentación oficial en Store and search data with vectors.

¿Cómo se construye el primer workflow para cargar documentos en el Vector Store?

Para la ingesta, añada un nodo Vector Store con la operación "Insert Documents", conecte un modelo de embedding y añada un nodo Default Data Loader para la división en chunks.

• Tamaño de chunk: La documentación de n8n recomienda secciones de 200 a 500 tokens para una búsqueda de grano fino, complementadas con cierto solapamiento entre los chunks para que no se pierda contexto en los límites.
• Elección del splitter: Puede elegir entre el Character Text Splitter, que divide según la longitud de caracteres, el Token Text Splitter, que divide según el número de tokens, y el Recursive Character Text Splitter, que n8n recomienda para la mayoría de los casos de uso porque se orienta según las estructuras de Markdown, HTML o código.
• Metadatos: Opcionalmente, los chunks pueden enriquecerse con información adicional como fuente, tipo de documento o fecha, lo que facilita el filtrado posterior.
• Clear Store: Una opción del modo de inserción para vaciar el almacén existente antes de volver a rellenarlo.

Para pruebas rápidas es adecuado el nodo Simple Vector Store (In-Memory), que mantiene los vectores directamente en la memoria de trabajo de n8n. Según la documentación oficial del nodo este nodo está pensado explícitamente solo para el desarrollo.

¿Cómo se hace que el Vector Store sea consultable para un chatbot de IA?

Para la recuperación, conecte el mismo nodo Vector Store en modo "Retrieve Documents (As Tool for AI Agent)" a un nodo AI Agent, que entonces activa la búsqueda por sí mismo cuando la necesita para una respuesta. En este modo se configuran el Name y la Description de la herramienta para que el agente entienda cuándo debe acceder a ella, así como un límite para el número de chunks devueltos y, opcionalmente, "Include Metadata" para incluir referencias de fuente. Según la documentación, es importante usar el mismo modelo de embedding al consultar que al insertar los datos, de lo contrario los espacios vectoriales no coinciden y la búsqueda ofrece malos resultados. Alternativamente existe la consulta directa mediante la operación "Get Many", en la que usted mismo establece una consulta de búsqueda fija en lugar de dejarla al agente. El proceso exacto se describe en Retrieve relevant context descrito. Quien no quiera mantener esta configuración por sí mismo encontrará, en el servicio Agentes de IA de NordFlux, una implementación con precio fijo y soberanía de datos alemana.

¿Dónde están los límites del RAG con n8n?

El RAG no es un remedio milagroso: la calidad de las respuestas depende directamente de la estructura de los documentos de origen, y el Simple Vector Store integrado en n8n está, según la documentación, pensado explícitamente solo para el desarrollo, porque los datos se pierden al reiniciar y, según la documentación, son visibles a nivel de instancia para todos los usuarios, independientemente de los permisos del workflow individual. Por eso, para el uso en producción necesita un Vector Store externo persistente, para el que n8n ofrece nodos propios, por ejemplo para PGVector o Azure AI Search. Documentos de origen mal estructurados, como PDFs escaneados sin una capa de texto real o tablas grandes y desordenadas, provocan chunks mal cortados y, por tanto, respuestas imprecisas o incompletas del chatbot. Unos datos de origen limpios y bien estructurados suelen ser más importantes para la calidad del resultado que la elección de un modelo de embedding más grande.

Preguntas frecuentes sobre RAG con n8n

¿Cuál es la diferencia entre el Vector Store como herramienta y la consulta directa mediante Get Many?

Con "Get Many" se plantea al Vector Store una consulta de búsqueda fija y predefinida, mientras que el modo "Retrieve Documents (As Tool for AI Agent)" deja la decisión al agente. El propio agente comprueba, a partir del Name y la Description de la herramienta, si y cuándo tiene sentido una búsqueda en el Vector Store para la pregunta actual del usuario. Esto hace que la configuración sea más flexible para un chatbot que también debe responder preguntas generales sin relación con los documentos.

¿Qué modelo de embedding debería elegir para un chatbot de conocimiento empresarial?

Según la documentación de n8n, los modelos de embedding más pequeños son más rápidos y económicos y son adecuados para documentos generales, mientras que los modelos más grandes ofrecen una mejor comprensión semántica para temas especializados complejos. En cualquier caso, es fundamental usar el mismo modelo al insertar los datos y al consultarlos posteriormente, ya que modelos distintos generan espacios vectoriales distintos.

¿Se puede usar el Simple Vector Store de n8n en producción?

No, según la documentación de n8n, el nodo Simple Vector Store (In-Memory) está pensado explícitamente solo para el desarrollo, porque los datos se pierden al reiniciar la instancia y, según la documentación, son visibles a nivel de instancia para todos los usuarios. Para un chatbot de conocimiento empresarial usado en producción necesita un Vector Store persistente y alojado externamente.

¿Qué tamaño deben tener las secciones de texto para la búsqueda?

Para una búsqueda de grano fino, la documentación de n8n recomienda tamaños de chunk entre 200 y 500 tokens, combinados con cierto solapamiento entre secciones vecinas para que no se pierda contexto en los límites de los chunks. Como estrategia de splitter, n8n propone el Recursive Character Text Splitter para la mayoría de los casos de uso, porque se orienta según la estructura natural del documento en lugar de dividir arbitrariamente según el número de caracteres.