Arquitetura, compensações e quando usar cada uma – n8n Blog

A geração de recuperação aumentada ganhou seu lugar ao fundamentar modelos de linguagem em dados externos, em vez de suposições. Mas o RAG clássico trata cada consulta de forma idêntica, e essa suposição é quebrada no momento em que uma pergunta precisa de mais de uma pesquisa.

O debate RAG vs RAG de agente é realmente sobre correção, rastreabilidade e resiliência sob carga de produção. É também uma questão de saber se um agente de IA que analisa cada consulta e escolhe sua própria estratégia de recuperação vale a complexidade adicional.

RAG clássico: como funciona o RAG simples

O RAG clássico segue um caminho direto e previsível. Uma consulta do usuário aciona uma etapa de recuperação que busca o contexto relevante de uma fonte de conhecimento externa. Dependendo do sistema, a recuperação pode usar pesquisa por similaridade vetorial, pesquisa por palavra-chave, recuperação híbrida e consultas SQL antes que o modelo gere uma resposta. Todo o pipeline não tem estado: ele nunca retorna e esquece cada solicitação no momento em que termina.

Essa simplicidade é uma força. A latência permanece previsível porque cada solicitação executa as mesmas etapas fixas. A sobrecarga de infraestrutura permanece baixa — você mantém um recuperador, um modelo de incorporação e qualquer infraestrutura de indexação que o recuperador exija, como um banco de dados vetorial para pesquisa baseada em incorporação ou um índice de palavras-chave para recuperação lexical. Quando uma resposta sai errada, a superfície de depuração é pequena o suficiente para ser inspecionada manualmente. Um suporte Chatbot RAG responder perguntas frequentes a partir de uma única base de conhecimento é exatamente onde esse design linear ganha seu sustento. E para um corpus estável, geralmente é a opção confiável mais barata disponível.

O problema começa quando a resposta não está dentro de um pedaço organizado. Como o pipeline recupera uma vez e confia no que obtém, resultados de baixa relevância se transformam silenciosamente em alucinações confiantes. Três modos de falha aparecem repetidamente:

• Perguntas multi-hop quebram isso: Pergunte “Quais fornecedores integramos após nossa auditoria SOC 2?” e o sistema precisa da data de auditoria de um documento e da lista de fornecedores de outro, mas uma única etapa de recuperação busca apenas um salto.
• A incompatibilidade de vocabulário deixa o retriever faminto: Um usuário pergunta sobre “folga” enquanto a política usa “licença remunerada”, e até mesmo a pesquisa semântica pode perder a passagem relevante quando os embeddings não estão alinhados. A pesquisa híbrida que combina palavras-chave e incorporações reduz esse risco, mas os pipelines RAG clássicos geralmente dependem de um único método de recuperação.
• Os limites dos pedaços dividem as evidências: Quando uma resposta abrange dois pedaços e o recuperador retorna apenas um, o modelo preenche a lacuna com ficção plausível em vez da metade que falta.

Agentic RAG: Recuperação como uma malha de controle

Um agente RAG é um grande modelo de linguagem com um conjunto de ferramentas e autoridade para decidir como usá-las. O RAG clássico faz uma pergunta restrita: quais partes correspondem a esta consulta? Agentic RAG faz uma pergunta mais ampla: quais informações eu preciso para responder a isso e quais ferramentas podem fornecê-las? Isso é o que as pessoas entendem por recuperação agente.

Essa mudança transforma a recuperação de uma única etapa em um loop de controle e é a resposta mais clara sobre o que é AI RAG de agente e como funciona. O agente recupera, lê o que retornou, avalia se a evidência é suficiente e decide o próximo passo – reformular a consulta, trocar de fonte, chamar uma API ou parar e responder. É o Padrão ReAct na prática: raciocinar, agir, observar, repetir. Configurado com memória, o agente transporta contexto entre iterações, de modo que o agente não inicia a cada passagem e pode construir uma resposta multifacetada.

O exemplo do SOC 2 mostra claramente a diferença. Um sistema agente primeiro recupera a data da auditoria, reconhece que ainda precisa da lista de fornecedores, dispara uma segunda consulta em uma fonte diferente e depois sintetiza ambas em uma resposta fundamentada. Este é um trabalho que um retriever de tiro único simplesmente não consegue fazer. Ferramentas como o nó AI Agent em n8n, construídas em LangChain, existem para conectar esse loop. Três recursos o separam de um pipeline fixo:

• Ele se decompõe e planeja: Uma questão ampla é dividida em subconsultas que o agente aborda em sequência, cada resultado alimentando o próximo.
• Autoavalia e reformula: Quando a primeira recuperação retorna fraca, o agente reescreve a consulta e tenta novamente, em vez de forçar uma resposta a partir de um contexto fraco.
• Ele roteia de forma adaptativa: Uma pergunta sobre preços vai para um banco de dados SQL, uma pergunta sobre política para o armazenamento de vetores, uma pergunta ao vivo para pesquisa na web – um agente escolhe a fonte por consulta. O roteamento através de bases de conhecimento especializadas é o que permite que um agente lide com questões de cobrança e segurança sem confundindo os dois.

RAG vs. RAG de agência: a principal diferença

A diferença entre RAG e RAG de agência não é uma atualização geracional em que o novo substitui o antigo. É uma troca arquitetônica. O RAG clássico oferece velocidade e previsibilidade. O Agentic RAG oferece adaptabilidade e raciocínio em várias etapas, pagos em latência, custo e a observabilidade necessária para rastrear o que o agente realmente fez. A chamada certa depende da complexidade da consulta, do seu orçamento de latência e de quanto você pode investir na observação do loop.

Práticas recomendadas de RAG e RAG de agência

Os melhores pipelines de IA possuem proteções RAG para evitar entradas maliciosas, reduzir alucinações e restringir o acesso aos dados. Mas como os dois padrões falham em lugares diferentes, as proteções são diferentes. O RAG clássico falha na qualidade de recuperação, portanto, suas proteções protegem o índice. O Agentic RAG também falha em autonomia, portanto, seus guardrails limitam o que o agente pode fazer.

RAG clássico

• Recuperação de escopo para permissões: O recuperador deve exibir apenas documentos que o usuário solicitante está autorizado a ver, aplicados no momento da consulta, em vez de filtrados depois.
• Índice com pesquisa híbrida: O emparelhamento da recuperação semântica e de palavras-chave captura os casos em que os embeddings por si só perdem termos exatos, como SKUs ou códigos de erro.
• Governe a fragmentação e a sobreposição: Tamanhos de blocos consistentes com sobreposição sensata evitam que uma resposta chegue a um limite e perca metade de seu contexto.

RAG Agente

• Restringir ferramentas com listas de permissões: O agente deve alcançar apenas as fontes que uma política permite explicitamente, de modo que um prompt de leitura incorreta não possa desencadear uma ação que você nunca autorizou.
• Aplicar condições de parada: Limites rígidos para iterações e um orçamento de token evitam que um ciclo de raciocínio gire – e queime custos – quando não consegue convergir.
• Instrumente todo o loop: O histórico de execução passo a passo e o rastreamento distribuído transformam um agente opaco em algo que você pode auditar e avaliando RAG contra um conjunto de teste transforma “parece bom” em um número que você pode defender.

Construir ambos os padrões para um padrão de produção significa incorporar governança e observabilidade desde o início. Esta é a lacuna que o n8n fecha, permitindo que você monte agente RAG em uma tela visual em vez de unir bibliotecas em código – executando OpenAI, Antrópico ou Coerente na nuvem ou Ollama localmente, por trás do mesmo fluxo de trabalho.

Critérios de decisão: RAG clássico vs. RAG agente

Não existe um vencedor universal, apenas um ajuste entre arquitetura e carga de trabalho. O teste honesto é observar suas consultas reais – não as de demonstração – e perguntar com que frequência uma única recuperação realmente as satisfaria.

Escolha RAG clássico quando

• Suas consultas são limitadas e bem especificadas – pesquisas de fonte única, respostas de perguntas frequentes ou páginas de referência onde a resposta fica em um único bloco.
• A latência é uma restrição difícil e cada etapa extra de raciocínio é um custo que você não pode justificar.
• Sua base de conhecimento é estável e bem fragmentada, então como você constrói a Gasoduto RAG por si só se torna a principal alavanca de confiabilidade que você puxa.

Escolha RAG agente quando

• Suas consultas reúnem rotineiramente evidências em vários sistemas — logs, documentos e APIs em uma única resposta.
• Os usuários enviam consultas ambíguas ou subespecificadas que precisam ser reformuladas antes mesmo que a recuperação faça sentido.
• A alucinação silenciosa é inaceitável e você precisa que o agente passe para um humano ou sinalize evidências insuficientes em vez de adivinhar

A maioria das equipes aprende isso de maneira cara. Eles começam com o RAG tradicional, atingem seus limites, depois migram para uma estrutura de agência e reconstroem do zero. Uma plataforma onde ambos os padrões residem em uma tela significa que você estende seu fluxo de trabalho existente dentro de uma pilha familiar e uma biblioteca de fluxos de trabalho RAG da comunidade é um ponto de partida mais rápido do que um arquivo em branco.

Escolhendo a arquitetura certa

Trate isso como uma decisão arquitetônica, não como uma tendência a ser perseguida. A verdadeira questão não é se o RAG de agência é mais recente; é se suas consultas são complexas o suficiente para justificar um ciclo de controle que você terá que observar e governar. Quando isso acontece, a plataforma sobre a qual você constrói decide o quão dolorosa essa governança se tornará.

O n8n executa o pipeline linear e o loop de agente na mesma tela visual, com o histórico de execução e a observabilidade passo a passo que transformam um agente autônomo em algo em que você pode confiar na produção.