¿Chatbot RAG demasiado lento? Optimizar los tiempos de respuesta (Thread: 16s+)

Cuando un chatbot RAG en n8n tarda 16 segundos o más en responder preguntas sencillas, rara vez se debe únicamente al modelo de lenguaje, sino sobre todo a la combinación de la elección del vector store, el tamaño de los chunks, la selección del modelo y la falta de caching. En un hilo muy seguido del foro de n8n un usuario informó de tiempos de respuesta de 16 a 18 segundos en un chatbot RAG en producción con un nodo AI Agent, mientras que un pipeline HTTP/código más ligero con los mismos datos lograba de 3 a 5 segundos. Las siguientes palancas suelen poder ajustarse en workflows de n8n existentes sin una reconstrucción completa. Actualizado: julio de 2026.

Elección del vector store: no toda base de datos está hecha para la velocidad

n8n integra de forma nativa varios vector stores: Pinecone, Qdrant, Supabase Vector Store y PGVector como extensión de Postgres, además de un store en memoria para prototipos. Para el tiempo de respuesta cuenta menos el nombre del proveedor que la combinación del método de indexación, la latencia de red hacia la base de datos y la capacidad de filtrado en la búsqueda por similitud. En un caso documentado por la comunidad con PGVector unos tiempos de respuesta elevados y un consumo de tokens excesivo llevaron a los usuarios a probar un vector store dedicado como Qdrant, ya que este está diseñado para la búsqueda vectorial pura con opciones de filtrado, mientras que PGVector, como extensión de una base de datos relacional, conlleva una sobrecarga adicional. Quien quiera conservar PGVector por motivos de soberanía de datos debería comprobar si la instancia de Postgres está cerca del servidor de n8n, ya que parte de la latencia proviene de los viajes de ida y vuelta en la red entre el nodo agente y la base de datos.

Tamaño de chunk y overlap: más pequeño suele ser más rápido

El tamaño del chunk determina cuánto texto por sección va al vector store y cuánto contexto se envía al modelo de lenguaje en cada solicitud. n8n utiliza por defecto en el Recursive Character Text Splitter un tamaño de chunk de 1000 caracteres con un overlap de 200 caracteres. En el mismo caso de PGVector, valores más pequeños resolvieron problemas notables: el usuario redujo el tamaño de chunk de 1200 a 512 caracteres, el overlap de 200 a 100 y el tamaño de lote de inserción de 200 a 32, lo que redujo notablemente el consumo de tokens y el tiempo de respuesta. El efecto es plausible: chunks más pequeños significan menos texto irrelevante por coincidencia, por lo que los prompts son más cortos y se necesita menos tiempo de cómputo en el modelo de lenguaje. La contrapartida es la fragmentación, información relacionada puede quedar repartida entre varios chunks. Un buen punto de partida para muchas bases de conocimiento se sitúa entre 500 y 800 caracteres con un 10 a 20 por ciento de overlap, ajustado a la estructura textual de los documentos fuente.

Elección del modelo y arquitectura del agente: de dónde vienen realmente los segundos

La verdadera causa de los 16 segundos en el hilo referenciado fue menos la elección del modelo que la arquitectura: el nodo AI Agent realiza típicamente entre dos y cuatro llamadas internas al modelo de lenguaje por solicitud, entre otras para la selección de herramientas y bucles de razonamiento, antes de que se genere la respuesta real. Un pipeline más ligero compuesto por embedding, búsqueda vectorial, construcción del prompt y una única llamada al modelo de lenguaje logró de 3 a 5 segundos en el mismo hilo, precisamente porque se salta estos pasos intermedios. Para escenarios sencillos de recuperación y respuesta sin una selección real de herramientas, el modo agente completo suele estar por tanto sobredimensionado. Además, la elección del modelo influye directamente en el tiempo de respuesta: los modelos más pequeños y rápidos suelen ofrecer menor latencia que los modelos más grandes, aunque a costa de la calidad de la respuesta en preguntas más complejas. Quien realmente necesite toda la flexibilidad del agente, por ejemplo porque el chatbot deba elegir entre varias herramientas y fuentes de datos, difícilmente puede evitar esta sobrecarga. Para todos los demás casos, merece la pena migrar a una cadena de recuperación determinista.

Caching: no recalcular las solicitudes repetidas cada vez

El caching no se discutió explícitamente en el hilo del foro referenciado, pero es una de las palancas evidentes en cuanto un chatbot RAG está en producción. Los documentos se vectorizan y se escriben en el vector store una sola vez, en cada nueva solicitud solo hay que vectorizar de nuevo la pregunta del usuario, el embedding de la propia base de conocimiento no debería recalcularse en cada llamada del chat. Las preguntas recurrentes o muy similares pueden interceptarse además mediante un simple paso de caché en el workflow, por ejemplo almacenando la pregunta y la respuesta y devolviéndolas directamente en caso de repetición, sin volver a pasar por la búsqueda vectorial y el modelo de lenguaje. Esto merece la pena sobre todo en casos de uso con muchas FAQ y formulaciones recurrentes, en solicitudes de soporte individuales el efecto es menor. Quien quiera reducir la latencia de forma sistemática debería abordar el caching solo después de las primeras tres palancas, ya que no soluciona problemas estructurales de chunking o arquitectura, sino que solo reduce la frecuencia con la que estos se ejecutan.

Quien no quiera repasar solo estas palancas en un workflow de n8n existente, o quiera que se configure desde el principio un chatbot con una arquitectura clara, encontrará en el desarrollo de agentes de IA de NordFlux un punto de contacto con precio fijo y soberanía de datos alemana. Para la automatización con n8n independientemente del tema del chatbot, la consultoría de n8n es el punto de partida adecuado.

Preguntas frecuentes sobre chatbots RAG lentos en n8n

¿De dónde procede el valor de 16 segundos?

De un hilo del foro de n8n, en el que un usuario documentó tiempos de respuesta de 16 a 18 segundos para un chatbot RAG en producción con un nodo AI Agent y conexión a un vector store, mientras que un pipeline más sencillo con los mismos datos lograba de 3 a 5 segundos.

¿Es el nodo AI Agent fundamentalmente demasiado lento para RAG?

No. Está diseñado para escenarios con una selección real de herramientas y razonamiento en varios pasos, y allí realiza sus llamadas con razón. En un flujo sencillo de recuperación y respuesta sin estos requisitos, sin embargo, genera una sobrecarga que puede evitarse con una cadena más ligera.

¿Qué tamaño de chunk es adecuado para la mayoría de las bases de conocimiento?

Un rango de 500 a 800 caracteres con un 10 a 20 por ciento de overlap es un buen punto de partida para muchos casos de uso, pero debería probarse según la propia estructura documental. Los chunks demasiado pequeños pueden romper relaciones de contexto, los chunks demasiado grandes inflan los prompts y el tiempo de respuesta.

¿Merece la pena cambiar de vector store solo por la velocidad?

No como primer paso. Primero conviene comprobar si la latencia de red, el tamaño de chunk o la arquitectura del agente son la causa real. Cambiar de vector store supone más esfuerzo que un ajuste de configuración y solo debería hacerse una vez agotadas las demás palancas.