RAG en n8n: cómo darle a tu agente IA acceso a tu base de conocimiento (paso a paso)

Guía técnica para implementar RAG (Retrieval-Augmented Generation) en n8n con embeddings, base vectorial y agente conversacional. Con código y configuraciones reales.

ACTUALIZADO: 21 DE MAYO DE 2026
7 min de lectura
D

DevActivo

Contenido del articulo

RAG (Retrieval-Augmented Generation) es la diferencia entre un chatbot que inventa respuestas genéricas y un agente que conoce tu negocio real. En n8n, montar un sistema RAG funcional toma 4-8 horas si sabes lo que haces y entre 2-5 días en el primer intento.

En esta guía técnica paso a paso te explicamos cómo construir un sistema RAG en n8n: desde la ingesta de documentos hasta el agente conversacional que responde con tu información. Con configuraciones reales que funcionan en producción.

Qué es RAG y por qué importa

Cuando le preguntas algo a GPT-4 o Claude, el modelo responde basado en lo que aprendió hasta su fecha de corte. No conoce tus catálogos, tus políticas internas, tus tickets de soporte ni tu manual operativo.

RAG cambia eso. El flujo es:

  1. Tomas tus documentos (PDFs, docs, FAQs, base de tickets)
  2. Los conviertes en “embeddings” — vectores numéricos que capturan significado
  3. Los guardas en una base vectorial (Pinecone, Supabase pgvector, Qdrant)
  4. Cuando un usuario pregunta algo, calculas el embedding de su pregunta
  5. Buscas los documentos cuyo embedding es más cercano (relevancia semántica)
  6. Le pasas al LLM esos documentos + la pregunta del usuario
  7. El LLM responde basado en tu información, no en su entrenamiento genérico

Resultado: agentes que conocen tu negocio real, citan fuentes, mantienen consistencia con tu información oficial.

Stack recomendado para n8n

Después de probar varias combinaciones en producción, este es el stack que más nos gusta:

  • n8n: orquestador del flujo (ingesta y consulta)
  • Embeddings: OpenAI text-embedding-3-small (0.02 USD por millón de tokens, suficiente para 90% de casos)
  • Vector store: Supabase pgvector (free tier generoso, SQL familiar, sin lock-in)
  • LLM para respuestas: GPT-4o-mini para casos simples, GPT-4o o Claude Sonnet para complejos
  • Chunking: n8n nodos nativos de LangChain

Stack alternativo si necesitas escala mucho mayor: Pinecone como vector store. Es más caro pero mejor performance en bases grandes (>10M vectores).

Paso 1: Preparar Supabase pgvector

Crea un proyecto en Supabase (free tier alcanza para empezar). En el SQL editor, activa la extensión:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  metadata JSONB,
  embedding VECTOR(1536)
);

CREATE INDEX ON documents 
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

1536 es la dimensionalidad del modelo text-embedding-3-small de OpenAI. Si usas otro modelo, ajusta.

Crea también una función helper para búsqueda por similaridad:

CREATE OR REPLACE FUNCTION match_documents(
  query_embedding VECTOR(1536),
  match_threshold FLOAT,
  match_count INT
)
RETURNS TABLE (
  id BIGINT,
  content TEXT,
  metadata JSONB,
  similarity FLOAT
)
LANGUAGE plpgsql
AS $$
BEGIN
  RETURN QUERY
  SELECT 
    documents.id,
    documents.content,
    documents.metadata,
    1 - (documents.embedding <=> query_embedding) AS similarity
  FROM documents
  WHERE 1 - (documents.embedding <=> query_embedding) > match_threshold
  ORDER BY documents.embedding <=> query_embedding
  LIMIT match_count;
END;
$$;

Paso 2: Workflow de ingesta en n8n

Workflow #1 toma documentos (PDFs, Word, Markdown, URLs) y los carga al vector store. Estructura del workflow:

  1. Trigger: manual, webhook o cron para procesar archivos nuevos en una carpeta de Google Drive
  2. File source: nodo de descarga del documento
  3. Text extraction: según el tipo (PDF → pdfplumber, Word → docx2txt, HTML → BeautifulSoup)
  4. Text splitter: nodo LangChain Text Splitter — recommended size 800 caracteres con overlap 200
  5. Embeddings: nodo OpenAI Embeddings con modelo text-embedding-3-small
  6. Vector store insert: nodo Supabase Vector Store en modo “Insert”

Tips críticos de chunking:

  • Chunks muy chicos (200 chars) pierden contexto. Muy grandes (3000+) confunden al modelo en retrieval.
  • 800-1200 caracteres con overlap de 150-250 es el sweet spot para mayoría de casos.
  • Para FAQs, splitter por pregunta (no por caracteres) funciona mejor.
  • Incluye metadata útil: fuente, página, fecha, categoría. Te servirá para filtrar en retrieval.

Paso 3: Workflow del agente conversacional

Workflow #2 maneja las consultas del usuario. Estructura:

  1. Trigger: webhook (WhatsApp, Telegram, formulario web)
  2. Get user query: extraer mensaje del usuario y su contexto (user_id, session_id)
  3. Get conversation history: traer los últimos 5-10 mensajes de esta sesión desde una tabla en Postgres/Redis
  4. Generate query embedding: nodo OpenAI Embeddings sobre la pregunta del usuario
  5. Vector search: ejecutar match_documents en Supabase con threshold 0.7 y limit 5
  6. Build prompt: ensamblar contexto: pregunta + chunks recuperados + historia conversacional
  7. LLM call: nodo OpenAI Chat con system prompt que incluya las reglas del agente
  8. Save to history: guardar pregunta y respuesta en la tabla de conversaciones
  9. Send response: webhook respuesta o mensaje WhatsApp/Telegram

System prompt que funciona

El system prompt del paso 7 es crítico. Esta plantilla funciona en producción:

Eres el asistente oficial de [nombre empresa]. 
Tu trabajo es responder consultas usando ÚNICAMENTE la 
información proporcionada en el contexto.

Reglas:
1. Si la respuesta NO está en el contexto, di: 
   "No tengo información sobre eso. Déjame conectarte 
   con un humano." No inventes.

2. Cita la fuente cuando aporta credibilidad. 
   Ejemplo: "Según nuestro manual de garantías..."

3. Sé conciso. Máximo 3-4 oraciones por respuesta.

4. Tono: profesional pero cercano. Usa "tú", no "usted".

5. Si el usuario pregunta algo fuera de tema 
   (clima, política, chistes), redirige amablemente.

Contexto de tu base de conocimiento:
{retrieved_chunks}

Historial de la conversación:
{conversation_history}

Pregunta actual del usuario:
{user_query}

Errores comunes y cómo evitarlos

1. El agente sigue inventando aunque digas “no inventes”. Solución: temperature en 0.1-0.3 (no 0.7+). Y reforzar la regla con ejemplos negativos en el system prompt.

2. Retrieval devuelve documentos irrelevantes. Subir el threshold (de 0.7 a 0.78). Si tu base es muy variada por temas, filtrar por metadata antes del retrieval.

3. Chunks cortados a mitad de frase. Usar text splitter consciente de oraciones (RecursiveCharacterTextSplitter con separadores apropiados).

4. Respuestas demasiado largas o demasiado cortas. Ajustar max_tokens del LLM call y reforzar en system prompt: “máximo 3-4 oraciones”.

5. El agente pierde contexto de la conversación anterior. Asegurarte que la historia conversacional se está cargando correctamente. Probar con 5-10 mensajes anteriores como límite.

6. Costos altos en producción. Cache de embeddings (no recalcular para la misma pregunta), usar GPT-4o-mini en lugar de GPT-4o para mayoría de queries, monitorear tokens consumidos.

Cuánto cuesta correr esto al mes

Costo típico para un agente RAG con 10,000 conversaciones/mes:

  • OpenAI embeddings (one-time para ingesta + cada query): 5-15 USD/mes
  • OpenAI GPT-4o-mini (10K llamadas con ~2K tokens promedio): 15-30 USD/mes
  • Supabase (pgvector): free tier alcanza hasta ~50K vectores; arriba de eso 25 USD/mes
  • n8n self-hosted: solo costo de servidor (10-30 USD/mes)
  • Total: 50-100 USD/mes para volumen mediano

Para 100K conversaciones/mes, escala a 200-400 USD/mes. Sigue siendo mucho más barato que un equipo humano respondiendo.

Casos de uso reales que hemos implementado

  • Bot de soporte para SaaS: RAG sobre documentación + base de tickets resueltos. Resuelve 60% de consultas sin escalar a humano.
  • Agente de pre-venta para e-commerce: RAG sobre catálogo + políticas de envío + FAQs. Aumentó conversión 28%.
  • Asistente interno para empresa: RAG sobre manuales operativos + procesos. Onboarding de nuevos empleados 50% más rápido.
  • Bot para clínicas: RAG sobre servicios + horarios + protocolos. Filtra 70% de consultas antes de llegar a recepcionista.

Cuándo NO necesitas RAG

RAG es overkill si:

  • Tu base de conocimiento es estática y cabe en el system prompt (menos de 8,000 tokens). Pásala directamente.
  • Las consultas son muy estructuradas y un FAQ con botones resuelve. RAG agrega complejidad sin valor.
  • El volumen es muy bajo (menos de 100 consultas/mes). El ROI del setup no se justifica.
  • Los datos cambian más rápido de lo que puedes re-indexar (precios en tiempo real, por ejemplo). Mejor consultar APIs directamente.

Quieres que lo construyamos

Si esto suena complejo, lo es. La parte conceptual es accesible; la implementación correcta en producción con chunking optimizado, retrieval afinado y system prompts probados toma experiencia.

En DevActivo construimos agentes RAG completos en n8n como parte de nuestro servicio de automatización con n8n e IA. Setup típico: 2-3 semanas para sistemas medianos, presupuesto desde 2,500 USD.

Servicios relacionados:

Articulos relacionados