Agentes RAG con bases de datos vectoriales: guía profesional paso a paso con n8n y Supabase

Tiempo de lectura estimado: 15 minutos

Key takeaways

• RAG complementa al LLM con contexto real para reducir alucinaciones y mejorar la precisión. Aprende la receta completa: ingestión, chunking, metadatos, búsqueda vectorial, reranking y generación.
• Si tu app vive en Postgres, Supabase pgvector simplifica el stack; para cargas extremas y filtrado vectorial avanzado, Qdrant brilla.
• Una ingestión robusta es idempotente, limpia duplicados con hash y record manager, y preserva metadatos que sí filtran.
• Clasifica la consulta antes de buscar, filtra por metadatos y aplica reranking para recuperar menos pero mejor.
• En n8n: orquesta con nodos de extracción, hashing, embeddings, Supabase y Cohere; mide recall, tokens y latencia para iterar con confianza.
• Política clara: “sin evidencia, no respondo” y siempre devuelve fuentes (file_id, chunk_id) para trazabilidad.

Tabla de contenidos

• Objetivo e intención de búsqueda
• Contexto y fundamentos
• Elección del stack y comparativa
• Preparación del entorno
• Diseño de la ingestión profesional
• Implementación RAG en n8n
• Consulta optimizada y generación de respuesta
• Ejemplos guiados
• Métricas, pruebas y calidad
• Buenas prácticas y resolución de problemas
• Extensiones y variantes avanzadas
• Checklist final para implementación
• Conclusión
• Preguntas frecuentes (FAQ)

Objetivo e intención de búsqueda

– Objetivo: enseñarte, de forma práctica y replicable, cómo construir un workflow RAG con n8n robusto y optimizado que no “se rompa”, no alucine y responda con contexto real.

– Público: desarrolladores y makers que usan n8n, y equipos que quieren desplegar RAG en producción con Supabase o Qdrant.

Contexto y fundamentos

Qué es RAG y por qué importa

Los LLM no lo saben todo ni recuerdan documentos privados. RAG (Retrieval Augmented Generation) añade contexto externo: recupera trozos relevantes de tus datos y se los pasa al modelo para responder con evidencia. Así reduces alucinaciones y mejoras precisión. Piensa en RAG como “una libreta de apuntes” que el modelo consulta antes de contestar.

Bases de datos vectoriales en RAG

• Embeddings: convierten texto en vectores (números). Textos similares quedan cerca en el espacio vectorial.
• Búsqueda por similitud: ante una pregunta, calculas su embedding y recuperas los vectores más cercanos (coseno o distancia euclídea).
• Chunks: partimos documentos en trozos coherentes para indexarlos. Luego el LLM sintetiza la respuesta usando esos trozos.

Para profundizar, explora esta guía sobre bases de datos vectoriales con RAG y la definición de RAG.

Arquitectura general del sistema

• Ingestión de documentos → preprocesamiento → chunking → embeddings → almacenamiento vectorial con metadatos.
• Consulta: clasificación de intención → recuperación filtrada → reranking → generación de respuesta por el agente.

Este patrón lo orquestaremos con n8n y Supabase/Qdrant; es un enfoque probado en producción: workflow RAG con n8n y Supabase.

Elección del stack y comparativa

Qdrant vs Supabase para vectores

• Qdrant: motor vectorial nativo, open source, autohospedable, APIs REST/gRPC, muy rápido y escalable. Ideal si tienes cargas intensivas de vector, sharding y filtrado avanzado.
• Supabase pgvector para RAG: Postgres + extensión pgvector. Stack consolidado, SQL, fácil de integrar con apps full‑stack y con tus datos relacionales. Cloud o self‑host.
• Pinecone (mención breve): servicio gestionado y potente, pero no autohospedable; coste mensual relevante si creces.

Criterios de decisión: hosting (cloud vs VPS), coste, rendimiento y facilidad de integración. Resumen práctico: si tu app ya usa Postgres, pgvector suele ser suficiente; si buscas máxima performance y clustering nativo, Qdrant es superior. Revisa esta comparativa práctica para RAG.

Herramientas clave del workflow

• n8n para la orquestación: flujos sin código duro, conectores, control de estados y reintentos. Mira este video de n8n.
• Supabase (cloud o self‑host) con pgvector para el índice vectorial y tabla auxiliar de control.
• Modelos de embeddings: OpenAI small (1536) y large (3072) según recall y coste.
• LLM para clasificación y respuesta en modo JSON estructurado.
• Cohere Rerank v3.5 para reranking antes del LLM.

Cómo encaja todo en un flujo real: workflow RAG con n8n y Supabase.

Preparación del entorno

Supabase pgvector para RAG

• Cloud vs autohospedado: cloud listo en minutos; VPS = control total.
• Credenciales: Service Role Key, URL/host de la base.
• Tablas:
  • documents_chunks: id, file_id, chunk_id, content, embedding (1536/3072), metadata (categoría, resumen, título, fuente, created_at).
  • record_manager: file_name (único), content_hash, updated_at.
• Seguridad: Service Role solo en n8n; RLS según tus políticas; acceso de solo lectura para APIs públicas.

Consulta por similitud y filtros con SQL es directa. Véase este video de n8n + Supabase pgvector.

Alternativa con Qdrant: despliegue y conexión

• Despliegue con Docker (volumen para persistencia) o servicio cloud de Qdrant.
• Conexión desde n8n vía API REST/gRPC (HTTP Request) o conector comunitario.
• Colecciones: tamaño de vector acorde al modelo; payload con metadatos para filtros por categoría, file_id, fecha.

Si tu índice crece mucho o necesitas filtros complejos y alta QPS, Qdrant será tu amigo.

Diseño de la ingestión profesional (evitar fallos y duplicados)

Una buena ingestión evita dolores después. La idea: idempotencia, trazabilidad y metadatos que realmente filtran.

Tipos de documentos a soportar

• PDF, DOCX, CSV/Excel, HTML.
• Rutas de ingestión: Google Drive, OneDrive, formularios n8n, raspado web.

Consejo: empieza con PDFs y DOCX. Añade CSV/HTML cuando el flujo esté estable.

Extracción de contenido

• PDFs con texto: extractores nativos (evita “basura” de encabezados/pies).
• PDFs escaneados: aplica OCR (Tesseract) o parsers con LLM cuando haya tablas/figuras complejas.
• Normalización: limpia saltos raros, elimina boilerplate, conserva títulos y listas.

Ejemplo: si el PDF repite “Página X de Y” en cada hoja, bórralo antes de crear embeddings.

Preprocesamiento y chunking

Usa un Recursive Character Text Splitter para no romper ideas a mitad.

• chunk_size: 400–1000 (corto/denso) o 1000–2000 (manuales largos).
• chunk_overlap: 10–30% según densidad.

Reglas: no cortes títulos, agrupa párrafos afines, conserva listas coherentes.

Metadatos estratégicos (clave para la consulta)

• file_id para trazabilidad y actualizaciones.
• categoría (taxonomía de tu dominio).
• resumen breve (1–2 líneas).
• otros: autor, fecha, fuente, permisos.

Genera metadatos con un LLM en JSON estructurado y valida el JSON. Filtrarás por categoría antes de la búsqueda vectorial.

Embeddings y almacenamiento

• Modelo small (1536) por defecto; large (3072) para dominios complejos.
• Guarda content → embedding y metadatos en columnas separadas.
• Indexa por file_id + chunk_id para borrar/actualizar rápido.

Control de versiones/actualizaciones

• Hash SHA‑256 del texto normalizado (nodo Crypto en n8n).
• record_manager: file_name + content_hash como clave.
• Flujo: insertar si no existe; ignorar si hash igual; borrar+reinsertar si hash cambia.

Este control te ahorra índices inflados y respuestas obsoletas. Ver guía práctica: bases de datos vectoriales con RAG.

Implementación RAG en n8n (paso a paso)

Objetivo: un workflow que va de “archivo nuevo” a “chunks vectorizados y limpios”, listo para consultar. Inspírate en este workflow RAG con n8n y Supabase y en el video.

Ingesta

• Trigger: Google Drive (archivo nuevo/actualizado) o Webhook.
• Loop por archivos: uno a uno para controlar errores.
• Descarga + extracción: PDF/DOCX/CSV/HTML → normaliza y limpia.
• Hash + record manager: SHA‑256 → decide insertar/ignorar/actualizar.
• Split + embeddings: chunking configurado; genera embeddings por chunk.
• Inserción en Supabase vector store con content, embedding, metadatos y chunk_id.

Nodos principales

• Google Drive (trigger/descarga)
• PDF/DOCX/CSV parsers
• Crypto (hash)
• LLM Chain (Structured Output) para categoría/resumen
• Supabase (tabla normal + pgvector)
• Aggregate, Switch, HTTP (Cohere Rerank)

Hasta aquí, tienes una ingesta profesional lista para producción. Lo siguiente: consulta optimizada, filtrado por metadatos y reranking para responder mejor con menos tokens.

Consulta optimizada y generación de respuesta

Aquí armamos el “cerebro” del agente: clasifica, busca, reordena y responde con trazabilidad. El objetivo es recuperar menos, pero mejor, y que el LLM siempre tenga evidencia.

Clasificación previa de la consulta

• Usa un LLM en modo JSON que devuelva: {categoria: “…”, confianza: 0–1}.
• Si la confianza < 0.5, deja la categoría vacía.
• Beneficios: reduce el espacio de búsqueda, baja tokens y latencia.

Base conceptual de RAG aplicada a clasificación previa.

Recuperación desde el vector store (Supabase pgvector)

• Genera el embedding de la pregunta.
• topK inicial: 20 (ajústalo según densidad del corpus).
• Filtros por metadatos: WHERE category = $1 si hay categoría; filtra también por file_id/fecha/permisos.
• Devuelve content, file_id, chunk_id, category, resumen y la distancia/similitud.

Con SQL es sencillo combinar filtros y similitud en Supabase pgvector para RAG y aplicar patrones de RAG con bases de datos vectoriales.

Reranking con Cohere

• Pasa los 20 candidatos a Cohere Rerank v3.5 con el texto de la consulta.
• Reordena por relevance_score y selecciona los mejores 5–7.
• Ventajas: menos tokens, mejor precisión y orden lógico.

Generación de respuesta por el agente

• Instrucciones: “Responde solo con base en los chunks entregados. Si falta evidencia, di que no puedes responder.”
• Trazabilidad: devuelve fuentes (file_id y chunk_id) y un breve porqué.
• Opcional: memoria conversacional y guardado del rastro (categoría, filtros, scores).

Este patrón, alineado a RAG, reduce alucinaciones y entrega respuestas auditables. Inspírate en el flujo n8n + Supabase.

Ejemplos guiados

Ejemplo 1: “Ventajas de un SGBD”

Clasificación: “base de datos” (confianza 0.84). Recuperación: topK=20 con filtro; Rerank→ top 6 con los pros más claros.

Respuesta del agente: integridad, concurrencia, seguridad, respaldo, consultas eficientes, escalabilidad; cita 2–3 chunks con file_id y chunk_id; cierra con precaución si falta evidencia. Ver enfoque práctico en RAG + vector DB.

Ejemplo 2: “Qué es HTTP”

Clasificación: “programación web” (confianza 0.92). Recuperación: topK=20; Rerank→ 5 trozos (definición, métodos, estado, headers, ciclo request/response).

Respuesta: define HTTP como protocolo de aplicación para la web; resume métodos (GET, POST, PUT, DELETE), códigos y cabeceras; menciona fuentes con file_id/chunk_id. Si la base no lo cubre, el agente debe decirlo. Conceptos base de RAG.

Métricas, pruebas y calidad

Un RAG serio se mide y audita. Crea un tablero con:

• Calidad de recuperación: % de consultas con evidencia suficiente; Recall@K.
• Reranking: distribución de relevance_score; ahorro de tokens.
• Coste y latencia: embeddings/mes; tokens/respuesta; latencia por etapa.
• Auditoría: log de categoría, filtros y fuentes; errores por documento.

Itera con A/B: chunk_size 800 vs 1200; topK 15 vs 30; overlap 10% vs 20%. Referencia de campo: workflow RAG con n8n.

Buenas prácticas y resolución de problemas

• Nombres de archivo estables (humano + versión).
• PDFs escaneados: OCR robusto o parsers con LLM para tablas/figuras.
• Duplicados: hash SHA‑256 + record_manager obligatorio.
• Ruido: limpia headers/footers repetidos; recorta firmas/páginas en blanco.
• topK y umbral: si llega vacío, sube topK y mejora taxonomía; si difuso, baja topK y endurece filtros.
• Latencia: embeddings por lotes, cache de clasificaciones, rerank para enviar menos texto.
• Seguridad: keys en credenciales n8n; RLS/roles de lectura; cuotas de APIs.
• Escalabilidad: limpieza de versiones viejas; índices en metadatos; evalúa Qdrant si necesitas sharding/QPS alto. Ver buenas prácticas RAG + vectorial.

Extensiones y variantes avanzadas

• RAG híbrido: une SQL + vectorial (p. ej., tenant_id o fechas → luego similitud).
• Multi‑fuente: DOCX/CSV/HTML + scraping/APIs; marca cada chunk con source_type.
• Control de acceso: metadatos tenant_id/role; los filtros aplican antes de la búsqueda.
• Agente con herramientas: si no hay evidencia, solicita más contexto/archivos.
• Qdrant end‑to‑end: para índices grandes y filtros vectoriales avanzados; mantén el mismo contrato de metadatos para migrar sin dolor. Más en esta guía.

Checklist final para implementación

• Vector DB elegido: Qdrant vs Supabase.
• Taxonomía y metadatos mínimos: file_id, categoría, resumen.
• Preprocesamiento probado: limpieza y normalización.
• Chunking calibrado: tamaño y overlap.
• Record manager con hash funcionando (insert/update/delete).
• Inserción en el vector store verificada con muestras.
• Consulta: clasificación previa en JSON, similitud con filtros, reranking activo.
• Agente: prompt de “evidencia o no respondo”; fuentes y trazabilidad.
• Observabilidad: logs de categoría, topK, scores y latencia.
• Seguridad: manejo de keys, RLS/roles, cuotas.

Puedes apoyarte en el video y en el workflow de ejemplo para acelerar la puesta en marcha.

Conclusión

Con un workflow RAG en n8n bien armado, tus respuestas salen de tu propio conocimiento, no de suposiciones. La combinación de clasificación, filtros por metadatos, búsqueda vectorial, reranking y un buen prompt hace que el agente sea útil, confiable y barato.

Si tu app vive en Postgres, Supabase pgvector te da simplicidad y control; si necesitas rendimiento extremo y clustering nativo, Qdrant es excelente. En ambos casos, la receta es la misma: ingesta limpia, metadatos útiles, control de versiones y una consulta afinada. Inspírate en este flujo real de n8n + Supabase y la definición de RAG.

Preguntas frecuentes (FAQ)

¿Cuándo conviene Qdrant vs Supabase para vectores?

– Supabase + pgvector: ideal si ya usas Postgres y quieres SQL, permisos y simplicidad.
– Qdrant: mejor para índices enormes, clustering nativo y filtros vectoriales avanzados. Revisa esta comparativa de RAG + vector DB.

¿Qué tamaño de chunk elijo?

Empieza con 800–1200 caracteres y overlap 10–20%. Ajusta tras medir recall y latencia: documentos densos → chunks más pequeños; manuales largos → más grandes.

¿Necesito siempre reranking?

No siempre, pero casi siempre ayuda. Reduce tokens al LLM y ordena mejor los resultados, sobre todo con consultas ambiguas.

¿OpenAI embeddings small o large?

Small (1536) suele bastar. Large (3072) mejora recall en dominios técnicos y multilingües, a mayor coste.

¿Cómo manejo PDFs escaneados?

Aplica OCR sólido. Si hay tablas/imágenes complejas, prueba parsers con LLM. Revisa calidad antes del chunking.

¿Cómo evito duplicados en el índice?

Hash del contenido normalizado + record_manager. Si el hash no cambia, no reinsertes. Si cambia, borra por file_id e inserta de nuevo.

¿Qué pasa si el agente “no sabe”?

Debe decirlo. Política clara: “sin evidencia, no respondo”. Luego sugiere subir documentos o ampliar la búsqueda. Ver principios de RAG.

¿Puedo mezclar SQL y vector en la misma consulta?

Sí. Filtra primero con SQL (p. ej., tenant_id o fechas) y luego aplica similitud. Es un patrón de RAG híbrido muy útil.

¿Cómo integro todo en n8n sin escribir código?

Usa nodos: embeddings, Supabase (insert/select), HTTP (Cohere Rerank), LLM Chain (JSON), y Switch/Aggregate. Puedes guiarte por el video y el ejemplo público.

¿Y la seguridad?

Guarda API keys en credenciales de n8n. Define roles de solo lectura si expones respuestas. En Supabase, usa RLS o roles limitados.