Por Que RAG Tradicional Falha em Cenários B2B Complexos
O conceito básico de RAG (Retrieval-Augmented Generation) parece simples nos tutoriais de internet: converta um PDF em pedaços de texto (chunks), guarde em um banco vetorial, faça uma busca por similaridade de cosseno e passe os trechos para o LLM responder.
No entanto, quando essa receita de bolo é colocada em empresas B2B — lidando com tabelas de preços com 500 linhas, manuais de engenharia com 200 páginas ou contratos de prestação de serviços com cláusulas condicionais — o sistema falha miseravelmente:
- Fragmentação de tabelas: Dividir um PDF a cada 500 caracteres quebra linhas de tabelas. O LLM recebe apenas pedaços soltos de preços e inventa o valor final.
- Perda de Contexto Hierárquico: O modelo lê a cláusula 4.2 sem saber se ela se aplica ao Plano Bronze ou ao Plano Enterprise, porque o cabeçalho da seção ficou em outro chunk.
- Over-Retrieval: O banco de dados retorna trechos irrelevantes que apenas contêm palavras parecidas, poluindo o contexto e gerando alucinações.
A Solução: Arquitetura Multi-Agente no n8n
Para resolver a fragilidade do RAG ingênuo, a engenharia da Nexora desenvolveu um padrão de Três Agentes Especialistas Encadeados dentro do ecossistema n8n:
┌────────────────────────────────────────────────────────â”
│ MENSAGEM DO LEAD │
└──────────────────────────┬─────────────────────────────┘
│
â–¼
┌──────────────────────────────────â”
│ AGENTE 1: ROTEADOR DE INTENÇÃO │
│ Classifica: Vendas, Dúvida ou │
│ Requisição de Documento Técnico │
└────────────────┬─────────────────┘
│ (Se necessitar dados técnicos)
â–¼
┌──────────────────────────────────â”
│ AGENTE 2: ESPECIALISTA RAG │
│ • Query Expansion (HyDE) │
│ • Busca HÃbrida (Vetorial+BM25)│
│ • Reranking de Chunks │
└────────────────┬─────────────────┘
│ Chunks verificados + Citações
â–¼
┌──────────────────────────────────â”
│ AGENTE 3: SINTETIZADOR B2B │
│ Aplica regras de negócio, tom │
│ comercial e CTA de fechamento │
└────────────────┬─────────────────┘
│
â–¼
┌────────────────────────────────────────────────────────â”
│ RESPOSTA PRECISA COM CITAÇÃO │
└────────────────────────────────────────────────────────┘Papéis e Responsabilidades de Cada Agente
1. Agente Roteador de Intenção
Ele não acessa o banco vetorial diretamente. Sua única função é analisar a mensagem do usuário e determinar se a pergunta exige consulta documental ou se é apenas uma saudação/pergunta de processo comum.
Isso economiza até 65% de chamadas desnecessárias ao banco vetorial, reduzindo custos e latência no n8n.
2. Agente Especialista RAG (com HyDE e Reranker)
Quando acionado, esse agente não busca simplesmente o texto exato do usuário. Ele aplica a técnica HyDE (Hypothetical Document Embeddings): cria primeiro uma resposta hipotética esperada e busca os vetores com base nessa resposta gerada.
Em seguida, utiliza um modelo de Reranking (como Cohere Rerank ou BGE-Reranker) para reordenar os 10 melhores chunks retornados, entregando apenas os 3 fragmentos matematicamente mais relevantes.
3. Agente Sintetizador de Respostas B2B
Recebe os dados brutos validados pelo Agente 2 e formata a resposta no tom de voz oficial da empresa, aplicando travas de segurança rigorosas:
"Se o dado não constar expressamente nos fragmentos fornecidos, informe educadamente que não possui a informação exata e ofereça encaminhar para um especialista técnico humano."
Configuração Prática no n8n
No n8n, essa arquitetura é montada utilizando os nós oficiais da suÃte LangChain:
- Nó AI Agent (Tools Agent): Funciona como o orquestrador principal com controle de loop autônomo.
- Nó Vector Store Tool: Encapsula o banco vetorial (Pinecone, Supabase pgvector ou Qdrant) como uma ferramenta acionável sob demanda.
- Nó Code (Parser Estruturado): Extrai metadados do PDF no momento da ingestão (ex:
secao,pagina,plano) para permitir filtragem prévia por metadados (Metadata Filtering).
Estratégia de Chunking para PDFs Corporativos
Nunca use chunking puramente por contagem de caracteres em documentos de negócios. Recomendamos a seguinte configuração testada em nossos clientes:
| Parâmetro | Valor Recomendado | Motivo Técnico |
|---|---|---|
| Tipo de Splitter | Recursive Character Text Splitter | Prioriza quebras em parágrafos e tÃtulos antes de cortar palavras. |
| Chunk Size | 600 tokens (~2.200 caracteres) | Espaço ideal para conter um conceito completo ou tabela compacta. |
| Chunk Overlap | 120 tokens (~450 caracteres) | Evita perda de contexto entre o final de um parágrafo e o próximo. |
| Enriquecimento de Metadados | Nome do Arquivo + Seção + Ano | Permite que o LLM filtre apenas manuais da versão vigente do produto. |
Conclusão
Ao desacoplar a busca vetorial da sÃntese de texto e utilizar agentes focados em funções especÃficas, seu fluxo no n8n deixa de ser um brinquedo demonstrativo e se transforma em uma infraestrutura de suporte e vendas B2B de nÃvel corporativo.