RAG no n8n: como dar memória e base de conhecimento ao seu agente de IA

RAG no n8n para dar memória e base de conhecimento a um agente de IA

Resposta rápida: RAG no n8n é a forma prática de dar “memória” e base de conhecimento ao seu agente de IA: você ingere documentos, gera embeddings, salva em um vector store e, a cada pergunta, recupera trechos relevantes para montar o prompt. Quase toda “alucinação” vem de falta de RAG: o modelo responde do que lembra, não do que sua empresa sabe.

· espaço publicitário ·

Em resumo

Sem RAG, o agente vira um chatbot genérico: ele chuta com base no treinamento do modelo.
RAG = ingestão + chunking + embeddings + vector store + retrieval + prompt com citações.
O gargalo costuma ser dado consultável (qualidade/atualização), não “modelo maior”.
n8n serve como orquestrador: conecta fontes (Drive, Notion, site, PDFs), vetorização e busca sem colar tudo no prompt.

1) Defina o que o agente precisa “saber” (e o que não pode inventar)
Liste as perguntas que mais dão erro hoje (preço, política, especificações, prazos, integrações, termos legais). Separe por domínio (produto, suporte, comercial). Escreva regras simples: quando não achar evidência, o agente deve dizer que não encontrou na base e pedir contexto, em vez de completar com suposição.
2) Escolha as fontes de verdade e trate como sistema, não como arquivo solto
RAG bom começa antes do embedding. Priorize fontes versionadas e auditáveis: central de ajuda, manuais, changelog, contratos padrão, páginas de produto, FAQs internas. Evite copiar conversas de WhatsApp como “base” (vira ruído). No n8n, traga essas fontes por conectores (ex.: Google Drive/Docs, Notion, HTTP Request para site) e normalize para texto.
3) Ingestão: extraia texto e normalize (limpeza e metadados)
Crie um workflow de ingestão no n8n: (a) buscar arquivos/URLs, (b) extrair texto (PDF/HTML/Doc), (c) limpar (remover menu, rodapé repetido, tracking), (d) anexar metadados (origem, URL, data de atualização, versão do produto, idioma). Metadados bem-feitos são metade do retrieval.
4) Chunking: corte o texto do jeito que o usuário pergunta
Divida em blocos (chunks) que façam sentido sem o parágrafo anterior. Em geral, chunk pequeno demais perde contexto; grande demais estoura o prompt. Use cortes por títulos, seções e listas. Se você não tiver certeza do tamanho ideal, comece com seções de documentação (por heading) e ajuste observando respostas e custo.
5) Embeddings: transforme chunks em vetores (sem confundir com ‘gerar resposta’)
Embeddings não respondem nada: eles só criam uma representação numérica para buscar “parecido”. No n8n, você gera embeddings para cada chunk e salva junto com o texto e metadados. A escolha do modelo de embedding influencia idioma e nuance; se a base é PT-BR, teste com conteúdo real e avalie se ele recupera termos do seu domínio.
6) Vector store: onde guardar e como indexar
Você precisa de um lugar para armazenar vetores e consultar por similaridade. Pode ser um banco vetorial dedicado ou um Postgres com extensão vetorial — depende da sua infra e do volume. O importante é: (a) suportar filtro por metadados (ex.: ‘produto = X’, ‘versão >= Y’), (b) permitir upsert (atualizar chunks), (c) ter estratégia de deletar documento antigo para não “responder com passado”.
7) Retrieval: busque poucos trechos, mas bons (com filtros)
No workflow do agente, antes do LLM, faça uma consulta ao vector store com a pergunta do usuário. Traga top-k trechos (ex.: 3 a 8) e aplique filtros por contexto (cliente/linha de produto/idioma). Se o usuário perguntar ‘plano X’, o filtro por produto evita recuperar política de outro plano e reduzir ‘alucinação por mistura’.
8) Monte o prompt com evidências e obrigações de resposta
O prompt final deve conter: (a) instruções do papel, (b) pergunta do usuário, (c) trechos recuperados (com fonte e data), (d) regra de recusa quando não houver evidência suficiente. Peça para citar a fonte (URL/título) e para separar ‘o que está nos documentos’ de ‘interpretação’ quando necessário.
9) Avalie e faça manutenção: RAG é produto, não setup
Crie um conjunto de perguntas de teste (as que mais doem no suporte/comercial). Registre: se recuperou o trecho certo? respondeu certo? citou fonte? Quando errar, geralmente é um destes: chunk ruim, metadado faltando, documento desatualizado, filtro inexistente, ou prompt permissivo demais. Ajuste e rode de novo.

A tese: “alucinação” é quase sempre falta de RAG (não falta de modelo)

Quando um agente inventa, o padrão é simples: ele não tem uma base recuperável para consultar. Sem RAG, o LLM tenta preencher lacunas com o que aprendeu no treinamento — que pode estar desatualizado, genérico ou simplesmente não ter nada sobre o seu produto.

Trocar para um modelo maior pode até deixar a resposta mais convincente, mas não necessariamente mais correta. Se o dado não está acessível (ou está bagunçado), o gargalo é o que ele pode consultar — não o tamanho do “cérebro”.

Arquitetura de RAG no n8n (visão de alto nível)

Pense em dois fluxos no n8n: um de ingestão (offline/recorrente) e outro de perguntas (online). O primeiro prepara conhecimento; o segundo usa esse conhecimento para responder com evidência.

Você não precisa “jogar a empresa inteira no prompt”. RAG serve justamente para trazer só os trechos certos, na hora certa.

Workflow A (ingestão): fontes → extração de texto → limpeza → chunking → embeddings → armazenamento vetorial
Workflow B (resposta): pergunta → embeddings da pergunta → busca vetorial (com filtros) → prompt com contexto → LLM → resposta + fontes

Tabela: o que muda com RAG vs sem RAG (na prática)

Na redação do suporte e do comercial, a diferença aparece rápido: com RAG, você discute cobertura e atualização da base; sem RAG, você apaga incêndio de resposta errada.

Situação	Sem RAG	Com RAG no n8n
Pergunta sobre política específica (troca, SLA, reembolso)	Responde “provável” e confiante, mas pode inventar detalhes	Recupera o trecho do documento e responde citando fonte
Mudança recente de produto	Continua repetindo informação antiga	Atualiza na ingestão e passa a recuperar a versão nova
Domínios parecidos (planos, unidades, regiões)	Mistura regras e cria exceções inexistentes	Filtra por metadados e reduz mistura
Auditoria/explicação	Não dá para provar de onde veio	Você consegue mostrar ‘usei estes trechos’

Checklist do RAG que realmente funciona (onde o pessoal tropeça)

Os erros comuns não são “IA ruim”; são engenharia de conhecimento. Se você corrigir isso, o agente para de “viajar” sem precisar de mágica.

Documentos desatualizados convivendo com os novos (sem política de deleção)
Chunks gigantes (o modelo se perde) ou minúsculos (perde contexto)
Sem metadados úteis (produto, versão, data, público)
Prompt que permite “completar” quando não há evidência
Recuperação sem filtros (mistura tudo que é parecido)
Base com ruído (prints, conversas, duplicatas) que enterram o certo

Exemplo de prompt (modelo mental) para usar os trechos recuperados

A ideia não é copiar este texto literalmente, e sim usar a estrutura: obrigação de citar, obrigação de recusar e separação clara entre evidência e inferência.

Sistema: Você é um agente de suporte do produto X. Responda APENAS com base no CONTEXTO. Se o CONTEXTO não trouxer a resposta, diga que não encontrou e pergunte o dado faltante.
Usuário: {pergunta}
Contexto (trechos recuperados): {trecho1 + fonte + data} ... {trechoN + fonte + data}
Formato: Resposta objetiva + seção ‘Fontes’ com links/títulos.

Perguntas frequentes

RAG no n8n substitui um chatbot treinado (fine-tuning)?

Na maioria dos casos de suporte e base de conhecimento, RAG resolve antes e com menos risco: você controla fonte, atualização e citação. Fine-tuning pode ajudar em tom/estilo e tarefas específicas, mas não corrige falta de dado atual. Se a resposta depende de informação mutável (política, preços, versões), RAG costuma ser o caminho principal.

Quantos documentos eu preciso para começar um RAG decente?

Não existe um número mágico. Comece com o que mais gera dúvida e retrabalho (top 20–50 páginas/artigos internos, por exemplo) e garanta que estejam limpos, atualizados e bem segmentados. RAG bom cresce por qualidade e manutenção, não por volume bruto.

Como reduzir alucinação quando o retrieval não encontra nada relevante?

Três travas ajudam: (1) regra explícita no prompt para não inventar sem evidência, (2) limiar de similaridade/top-k conservador (se vier fraco, recusar), (3) perguntas de esclarecimento (“você está falando do plano A ou B?”, “qual versão?”). Em RAG, “não sei” bem dito é vitória.

Dá para fazer RAG no n8n com dados sensíveis e LGPD?

Dá, mas exige desenho: minimize dados pessoais na base, use controle de acesso por contexto (filtros/tenant), registre fontes e retenção, e evite jogar conteúdo sensível inteiro no prompt quando não precisa. Onde o dado fica (vector store) e como você registra logs do workflow importam tanto quanto o modelo.

RAG no n8n: dar memória e base de conhecimento ao seu agente de IA

1) Defina o que o agente precisa “saber” (e o que não pode inventar)

2) Escolha as fontes de verdade e trate como sistema, não como arquivo solto

3) Ingestão: extraia texto e normalize (limpeza e metadados)

4) Chunking: corte o texto do jeito que o usuário pergunta

5) Embeddings: transforme chunks em vetores (sem confundir com ‘gerar resposta’)

6) Vector store: onde guardar e como indexar

7) Retrieval: busque poucos trechos, mas bons (com filtros)

8) Monte o prompt com evidências e obrigações de resposta

9) Avalie e faça manutenção: RAG é produto, não setup

A tese: “alucinação” é quase sempre falta de RAG (não falta de modelo)

Arquitetura de RAG no n8n (visão de alto nível)

Tabela: o que muda com RAG vs sem RAG (na prática)

Checklist do RAG que realmente funciona (onde o pessoal tropeça)

Exemplo de prompt (modelo mental) para usar os trechos recuperados

Perguntas frequentes

Leia também

n8n e LangChain: como usar IA avançada nos seus fluxos (guia 2026)

Como integrar o n8n com a OpenAI (ChatGPT): guia prático 2026

n8n self-hosted e LGPD: onde ficam seus dados e como ficar em conformidade

n8n multi-agente: como orquestrar vários agentes de IA num só fluxo