Agentic RAG en n8n: por qué el RAG clásico falla a menudo — y cómo hacerlo mejor

Muchas empresas apuestan hoy por asistentes de IA que respondan preguntas sobre sus propios documentos: actas de reuniones, tablas de indicadores o comentarios de clientes. El procedimiento habitual detrás se llama Retrieval Augmented Generation (RAG). Está extendido, bien soportado y se implementa rápido en herramientas no-code como n8n. Solo que, en la práctica, el RAG clásico entrega respuestas erróneas o incompletas con sorprendente frecuencia. Cole Medin muestra en su vídeo a qué se debe y cómo un montaje llamado agentic RAG evita las debilidades típicas. Resumimos los puntos más importantes con sobriedad.

Por qué el RAG clásico decepciona en la práctica

El RAG funciona mediante una búsqueda por similitud: la consulta se compara con fragmentos de texto guardados (“chunks”) y los más afines se pasan al modelo de lenguaje. El problema está en esa selección, que pasa por alto contexto importante con regularidad.

Medin señala dos puntos débiles concretos:

• Sin visión de los documentos completos: el RAG solo recupera fragmentos sueltos. Quien quiera analizar tendencias en una tabla quizá reciba únicamente una cuarta parte de las filas, y con ella un resultado erróneo.
• Sin análisis de datos real: las sumas o los valores máximos de una tabla no se calculan de forma fiable con una búsqueda puramente textual.

A esto se suma una molestia práctica: si se pregunta por el acta de una fecha concreta, el RAG recupera a veces el documento del día equivocado, aunque la fecha figure en el título. Y enlazar documentos distintos para establecer un contexto más amplio rara vez funciona.

Qué hace distinto el agentic RAG

La idea central es sencilla: en lugar de dar al agente de IA una única herramienta de búsqueda, recibe varias y puede decidir por sí mismo cómo explorar la base de conocimiento. Medin define el agentic RAG así:

Agentic RAG significa dar al agente la capacidad de pensar cómo consulta la base de conocimiento, en lugar de atarlo a una sola herramienta.

En concreto, así el agente puede mejorar sus consultas, elegir otra herramienta cuando haga falta y probar varias vías hasta tener una respuesta sólida. Si la búsqueda RAG pura falla, ya no se queda bloqueado.

Las cuatro herramientas del agente

En el workflow de n8n el agente dispone de estas herramientas:

• Búsqueda RAG: la búsqueda por similitud clásica, en su versión mejorada con indicación de la fuente.
• Listar documentos: el agente recupera todos los documentos con sus títulos e ID y valora cuáles podrían ser relevantes.
• Recuperar el contenido de un archivo: mediante el ID del archivo obtiene el texto completo de un documento concreto (por ejemplo, el acta del 23 de febrero, reconocible por el título).
• Consulta SQL sobre tablas: los archivos CSV y Excel se consultan como tablas SQL, para permitir sumas, máximos y evaluaciones similares.

En el prompt de sistema se indica al agente que empiece con RAG y que solo recurra a las demás herramientas si la búsqueda no entrega lo adecuado. Una indicación importante del vídeo: pedir explícitamente honestidad al agente — es decir, que diga abiertamente cuando no ha encontrado respuesta — reduce de forma notable las alucinaciones.

Cómo se guardan los datos de las tablas

La parte técnicamente más interesante son las tablas. Para ello se crean tres tablas en Supabase:

• documents: contiene los embeddings para RAG, los metadatos y el contenido de cada chunk.
• document_metadata: guarda información de nivel superior: título, URL para citar la fuente y, en el caso de las tablas, el esquema (es decir, los nombres de las columnas).
• document_rows: almacena las filas de las tablas. Los datos propiamente dichos van a una columna flexible JSONB llamada row_data.

El truco: con JSONB pueden guardarse estructuras de columnas arbitrarias sin tener que crear una tabla SQL propia para cada archivo CSV o Excel. El agente lee primero el esquema desde los metadatos, entiende qué columnas hay disponibles y formula después una consulta SQL contra row_data. Medin advierte expresamente de que este montaje está simplificado: el esquema no dice nada sobre los tipos de datos, por lo que una suma sobre una columna con signos de dólar puede fallar. A él le interesa el concepto, no una implementación perfecta.

La pipeline de RAG: de Google Drive a Supabase

Antes de que el agente pueda trabajar hay que llenar la base de conocimiento. La pipeline transcurre en varios pasos:

• Disparador: un trigger de Google Drive comprueba cada minuto si hay archivos nuevos o modificados. Como alternativa funcionan Dropbox o un trigger de archivos local. Los archivos borrados, eso sí, no se detectan.
• Varios archivos a la vez: un bucle añadido procesa ahora también varios archivos que lleguen en el mismo intervalo de polling, una carencia conocida de la versión anterior.
• Borrar datos antiguos: antes de cada importación se eliminan los registros existentes del ID de archivo correspondiente. Así no queda ningún chunk obsoleto cuando un documento se ha acortado.
• Extraer el contenido: un nodo Switch ramifica según el tipo de archivo: PDF, Google Doc, texto o tabla se leen de manera distinta. Otros formatos como JSON o HTML pueden añadirse con nodos adicionales.
• Guardar las tablas por partida doble: los archivos CSV se preparan por un lado como documento de texto para RAG y, por otro, se almacenan fila a fila en document_rows para las consultas SQL.

Un escollo práctico durante la configuración: según el vídeo, para la conexión Postgres con Supabase hay que usar el transaction pooler (puerto 6543), no la conexión directa. La documentación de n8n resulta poco clara en este punto.

Modelos utilizados

Para los embeddings se usa text-embedding-3 de OpenAI y, como modelo de lenguaje, GPT-4o mini, elegido a propósito por barato y rápido. Para casos más exigentes, Medin recomienda modelos más potentes como GPT-4o o Claude Sonnet 4. Importante: al insertar y al recuperar debe usarse el mismo modelo de embeddings con el mismo número de dimensiones.

Tres ejemplos del vídeo

Medin demuestra cómo el agente elige distintas herramientas según la pregunta:

• Pregunta sobre una tabla: ante «¿En qué mes tuvimos más clientes nuevos?», el agente escribe una consulta SQL y entrega el resultado correcto (diciembre, 129 clientes nuevos), en lugar de fiarse de chunks incompletos.
• Pregunta puramente RAG: ante «¿Dónde podemos mejorar?», la búsqueda por similitud encuentra el documento de comentarios de clientes, aunque deliberadamente no se usó la palabra «mejora».
• Recuperación de archivo con fuente: al recuperar un acta de reunión completa, el agente entrega los action items y, si se le pide, un enlace pinchable a la fuente.

Conclusión

El artículo muestra con sobriedad por qué un RAG ingenuo no basta para muchas aplicaciones de negocio: pasa por alto el contexto y no sabe calcular sobre tablas. El enfoque agentic lo resuelve de forma pragmática dando al agente de IA varias herramientas y margen de decisión. Para quienes deciden en una pyme y se plantean un asistente documental, esa es una conclusión importante: la calidad no depende solo del modelo, sino de la arquitectura que hay detrás. Quien adopte el montaje de n8n presentado debería entenderlo como punto de partida: los prompts, las herramientas y el modelo de datos hay que ajustarlos al propio conjunto de datos. Precisamente la consulta SQL sobre tablas y el tratamiento de los tipos de datos dejan margen de mejora.

Fuente: Cole Medin – „I Built the ULTIMATE n8n RAG AI Agent Template”, https://www.youtube.com/watch?v=mQt1hOjBH9o