RAG + Agent: arquitetura de IA da próxima geração

Uma empresa passou três meses construindo um sistema RAG. Na primeira semana após o lançamento, o chefe já criticou: “Como isso não consegue responder nem a uma pergunta simples sobre reembolso de viagem?”

O RAG tradicional parece aquele aluno que só sabe consultar o dicionário: procura o que foi perguntado, mas não pensa na intenção por trás da questão. Se alguém pergunta “Por que meu reembolso de viagem do mês passado foi recusado?”, o RAG tradicional pode recuperar vários documentos sobre a política de viagens, sem perceber que antes deveria consultar o pedido específico daquele usuário.

É esse problema que o Agentic RAG tenta resolver.

A seguir, vamos tratar da arquitetura que combina RAG e agentes, uma abordagem que está remodelando as aplicações empresariais de IA. O percurso vai da evolução arquitetural e da escolha de frameworks até um roteiro concreto de implantação, além de um caso prático de atendimento inteligente ao cliente.

Do RAG tradicional ao Agentic RAG: a evolução da arquitetura

O funcionamento do RAG tradicional é bem simples: pergunta do usuário → busca vetorial → recuperação de documentos relevantes → envio ao LLM para gerar a resposta. São três etapas, e pronto.

As vantagens são claras: rapidez, baixo custo e facilidade de implementação. Mas os problemas aparecem logo em seguida.

Recuperação imprecisa. Quando a pergunta é vaga, a busca por similaridade vetorial pode encontrar vários documentos que “parecem relacionados”, mas não são. Ao perguntar “Como configurar a conexão com o banco de dados?”, por exemplo, o resultado pode misturar documentos de MySQL e PostgreSQL, deixando para o usuário a tarefa de separar um do outro.

Falta de raciocínio. O RAG tradicional só executa a sequência “recuperar-gerar” e se perde quando o problema exige várias etapas. Se você perguntar “Compare os pontos fortes e fracos das soluções A e B”, ele pode recuperar apenas a documentação de uma delas e inventar o restante com toda a confiança.

"Uma pesquisa da McKinsey mostra que 47% dos usuários de GenAI já enfrentaram consequências negativas, e apenas 27% revisam todos os resultados."

O que muda com o Agentic RAG

A ideia central do Agentic RAG é permitir que a IA “pense” ativamente em como resolver o problema, em vez de executar de forma mecânica a sequência de recuperação e geração.

Seu ciclo central é:

Plan → Retrieve → Act → Reflect → Answer

Vamos entender cada etapa:

Plan (planejar): primeiro, o sistema analisa a pergunta do usuário e a divide em subtarefas. “Meu reembolso de viagem do mês passado foi recusado” pode ser decomposto em: consultar o pedido de reembolso do usuário, consultar a política de viagens e comparar as informações para identificar o motivo da recusa.

Retrieve (recuperar): com base no plano, o sistema decide onde buscar e o que procurar. Talvez seja necessário consultar ao mesmo tempo uma base de conhecimento, um banco de dados e até uma API externa.

Act (agir): o sistema executa as buscas, chama ferramentas e obtém informações. Nessa etapa, pode descobrir um novo problema e precisar refazer o planejamento.

Reflect (refletir): o sistema avalia se os resultados recuperados são suficientes e se a resposta faz sentido. Se não estiverem bons o bastante, ele pode voltar à etapa Plan e tentar novamente.

Answer (responder): por fim, gera a resposta e inclui as fontes consultadas.

Em resumo, o RAG tradicional funciona como uma consulta ao dicionário. O Agentic RAG se parece mais com um assistente de pesquisa: ele analisa o problema, procura informações, confere os dados e então entrega uma resposta confiável.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Por trás desse número está a mudança nas expectativas das empresas em relação à IA: de algo que simplesmente “funciona” para algo que “funciona bem”. O Agentic RAG é uma etapa decisiva dessa evolução.

Dez padrões de arquitetura RAG em detalhes

Há bastante conteúdo nesta parte, então vamos nos concentrar no essencial. A tabela completa de comparação aparece mais adiante e ajuda a formar uma visão geral.

Naive RAG: a opção de entrada

É a arquitetura mais simples: pergunta do usuário → busca vetorial → geração da resposta. Serve para validar uma ideia rapidamente, mas quase nunca é suficiente em produção.

Os problemas mais comuns são baixa precisão na recuperação, desperdício da janela de contexto e alucinações frequentes. Eu recomendaria esse modelo apenas para uma POC ou uma ferramenta interna.

Hybrid RAG: o padrão de produção nas empresas

Hoje, esse modelo já é a referência para ambientes empresariais de produção. A ideia central é combinar dois tipos de recuperação: a busca lexical, baseada em palavras-chave, e a busca semântica, baseada em similaridade vetorial.

O motivo é simples: cada método tem seus pontos fortes. A busca lexical é boa para correspondências exatas, enquanto a busca semântica entende melhor a intenção. A combinação tende a produzir resultados melhores.

Na implementação, você pode usar BM25 para a busca lexical e um banco de dados vetorial — Pinecone, Weaviate ou Milvus, por exemplo — para a busca semântica. Depois, combine os resultados com Reciprocal Rank Fusion (RRF).

Graph RAG: ideal para raciocínio em múltiplos saltos

Se o seu cenário precisa responder perguntas como “por quê?” ou “qual é a relação?”, vale considerar o Graph RAG.

Ele extrai entidades dos documentos para construir um grafo de conhecimento e permite raciocínio em múltiplos saltos. Diante da pergunta “Quais produtos usam peças deste fornecedor?”, o Graph RAG consegue seguir as relações do grafo até encontrar a resposta.

O custo é de três a cinco vezes maior do que o de um RAG básico, pois construir e manter um grafo de conhecimento não é barato.

Agentic RAG: raciocínio ativo

O ciclo central já foi explicado. Aqui, vale acrescentar que a flexibilidade do Agentic RAG é uma faca de dois gumes.

Por um lado, ele consegue lidar com problemas complexos. Por outro, apresenta maior latência e custos difíceis de controlar. Uma pergunta simples pode disparar várias buscas e chamadas de ferramentas, elevando rapidamente a conta das APIs. Por isso, uma implantação real costuma usar uma estratégia de roteamento: perguntas simples seguem pelo RAG tradicional, e apenas as complexas entram no fluxo Agentic.

Self-RAG: autocorreção

Nesse padrão, o modelo avalia a própria saída. Os documentos recuperados são relevantes o bastante? A resposta gerada contém alguma alucinação?

Se a avaliação reprovar o resultado, o modelo faz uma nova busca ou corrige a resposta por conta própria. Parece ideal, mas aumenta o custo de inferência, e a própria avaliação também pode falhar.

Agentic Graph RAG: o nível mais avançado

Esse é o padrão mais avançado atualmente. Ele incorpora a orquestração de agentes à recuperação em grafos de conhecimento, reunindo raciocínio em múltiplos saltos e planejamento ativo.

O custo também está no nível mais alto. A recomendação é reservá-lo para cenários centrais do negócio.

Tabela comparativa dos padrões de arquitetura

Eu sugiro começar pelo Hybrid RAG e evoluir aos poucos, conforme a necessidade real. Buscar a arquitetura mais avançada logo de início aumenta bastante o risco de o projeto dar errado.

Escolha de framework: LangChain vs LlamaIndex vs CrewAI vs AutoGen

Já tive problemas com essa decisão. Em um projeto anterior, escolhemos um framework e, na metade do desenvolvimento, percebemos que o ecossistema ainda não era maduro o suficiente. Foi necessário refatorar tudo, desperdiçando tempo e afetando até o ânimo da equipe.

Por isso, escolher o framework certo é realmente importante. A comparação abaixo reúne as características e os cenários de uso dos principais frameworks para ajudar você a evitar esse tipo de problema.

LangChain / LangGraph: o ecossistema mais completo

Se você não sabe qual escolher, LangChain costuma ser uma opção segura. Hoje, ele tem um dos ecossistemas mais completos, com boa documentação, uma comunidade ativa e mais de 25 mil stars no GitHub no caso do LangGraph.

LangGraph é um framework de máquina de estados em grafo criado pela equipe do LangChain para construir workflows de agentes com estado. Sua principal vantagem é a persistência adequada para produção: o estado do agente pode ser salvo em um banco de dados, permitindo retomar a execução de um ponto interrompido e fazer depuração com time travel.

Cenários indicados: workflows de produção, necessidade de persistir estado e orquestração complexa de agentes.

# Exemplo simplificado com LangGraph: agente de planejamento de consultas
from langgraph.graph import StateGraph

def plan_query(state):
    """Analisa a pergunta do usuário e planeja as etapas de recuperação"""
    query = state["query"]
    # Decompõe o problema e gera subconsultas
    sub_queries = decompose(query)
    return {"sub_queries": sub_queries}

def retrieve(state):
    """Executa a recuperação"""
    results = []
    for q in state["sub_queries"]:
        docs = retriever.invoke(q)
        results.extend(docs)
    return {"context": results}

# Constrói o workflow
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_query)
workflow.add_node("retrieve", retrieve)
workflow.add_edge("plan", "retrieve")

LlamaIndex: a melhor opção para aplicações orientadas a dados

Se o seu cenário de negócio envolve uma grande quantidade de dados não estruturados — documentos, bancos de dados e APIs —, LlamaIndex é uma escolha melhor.

Seu mecanismo de consultas é bem projetado e aceita várias estratégias de recuperação: vetorial, por palavras-chave, híbrida e baseada em grafos de conhecimento. Além disso, oferece bons conectores para diferentes fontes de dados.

Cenários indicados: aplicações RAG orientadas a dados, integração com várias fontes e projetos que priorizam a qualidade da recuperação.

CrewAI: ideal para protótipos rápidos

A proposta do CrewAI é formar “equipes multiagente orientadas por papéis”. Você pode definir vários papéis de agentes e fazer com que eles colaborem em uma tarefa.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Em uma equipe de criação de conteúdo, por exemplo, o pesquisador reúne as informações, o redator escreve e o editor revisa. Cada papel tem seus próprios objetivos e ferramentas.

Cenários indicados: validação rápida de protótipos, automação de processos de negócio e tarefas com responsabilidades bem definidas.

Atualmente, a comunidade de desenvolvedores do CrewAI já passa de 100 mil pessoas, o projeto tem mais de 20 mil stars no GitHub e seu ecossistema cresce rapidamente.

AutoGen: um framework multiagente apoiado pela Microsoft

AutoGen é um framework multiagente de código aberto criado pela Microsoft Research, com foco na colaboração por meio de conversas. Vários agentes concluem uma tarefa dialogando entre si, o que funciona bem em cenários que exigem várias rodadas de interação.

Uma de suas características é permitir colaboração entre pessoas e IA: um usuário pode entrar na conversa a qualquer momento para corrigir a direção dos agentes.

Cenários indicados: projetos de pesquisa, tarefas complexas que exigem colaboração entre pessoas e IA e interações conversacionais.

Com mais de 50 mil stars no GitHub, é atualmente o framework de agentes com o maior número de stars.

Árvore de decisão para escolher o framework

Esta é uma lógica simples de decisão:

Qual é o tipo do seu projeto?
├── Workflow persistente de produção → LangGraph
├── RAG orientado a grandes volumes de dados → LlamaIndex
├── Protótipo rápido/processo de negócio → CrewAI
├── Pesquisa/sistema multiagente conversacional → AutoGen
└── Indefinido/necessidade de máxima flexibilidade → LangChain + LangGraph

Não existe uma resposta única para a escolha do framework. Decida de acordo com a stack técnica da equipe e as necessidades do projeto, sem deixar de observar a frequência de atualizações e a atividade da comunidade. Esses fatores afetam diretamente o custo de manutenção no longo prazo.

Roteiro de implantação empresarial

O modelo abaixo organiza a implantação em 90 dias e se baseia na experiência de várias empresas. Cada organização tem seu próprio ritmo, então ajuste o cronograma à realidade do projeto.

Primeira etapa: dias 0 a 15, definir o problema e os KPIs

Muita gente começa pela escolha da tecnologia, mas essa ordem está errada. Primeiro, é preciso responder: qual problema queremos resolver?

Algumas perguntas essenciais:

1. Quem são os usuários? Funcionários ou clientes externos?
2. Qual é o cenário central? Perguntas e respostas, busca ou raciocínio complexo?
3. Como medir o sucesso? Precisão, tempo de resposta ou satisfação dos usuários?

Nesta etapa, recomendo fazer uma pesquisa simples com os usuários e coletar de 50 a 100 perguntas reais. Depois, essas perguntas formarão o conjunto de testes e a referência para avaliação.

Segunda etapa: dias 16 a 45, preparar os dados e a camada de recuperação

Preparar os dados dá bastante trabalho, mas define o limite de qualidade do sistema.

Limpeza de dados: remova conteúdo duplicado, desatualizado ou confidencial. É uma etapa fácil de ignorar, mas dados ruins prejudicam seriamente a qualidade da recuperação.

Estratégia de chunking: escolha um tamanho adequado para cada tipo de documento. Documentação técnica pode usar blocos de 500 a 1.000 caracteres, enquanto textos jurídicos talvez precisem ser divididos por cláusula.

Escolha dos embeddings: a família text-embedding-3 da OpenAI, Cohere e BGE são boas opções. Compare os resultados primeiro com um conjunto pequeno de dados.

Construção da camada de recuperação: comece com Hybrid RAG, combinando BM25 e busca vetorial.

Terceira etapa: dias 46 a 75, orquestrar agentes e integrar ferramentas

É nesta etapa que os recursos de agentes entram no projeto.

Estratégia de roteamento: nem toda pergunta precisa de um agente. Perguntas simples de FAQ podem usar diretamente o RAG tradicional; somente as complexas entram no fluxo de agentes. Assim, você controla custos e latência.

Integração de ferramentas: conecte os sistemas internos por meio do protocolo MCP. Isso pode incluir consultas a bancos de dados, chamadas de API e busca em documentos.

Projeto da orquestração: use LangGraph ou uma ferramenta semelhante para desenhar o workflow. Comece com um padrão ReAct simples e aumente a complexidade aos poucos.

Quarta etapa: dias 76 a 90, avaliar, testar e reforçar

Para a avaliação, recomendo o framework RAGAS e três métricas principais:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

• Faithfulness (fidelidade): indica se a resposta gerada é fiel aos documentos recuperados; meta >= 0.8
• Answer Relevance (relevância da resposta): indica se a resposta realmente atende à pergunta do usuário
• Context Relevance (relevância do contexto): indica se os documentos recuperados são relevantes o bastante

Há também algumas métricas técnicas:

• Recall@K >= 0.85: taxa de recuperação entre os primeiros K resultados
• Latência P95 <= 2.5s: tempo de resposta de 95% das solicitações
• Controle de custos: quantidade de chamadas de API e consumo de tokens por solicitação

Armadilhas comuns

Por fim, vale observar alguns problemas frequentes:

1. Contorno do controle de acesso: o agente pode burlar permissões por meio de chamadas de ferramentas; os testes de segurança precisam ser rigorosos
2. Contexto desatualizado: em conversas longas, informações iniciais podem se perder; é necessário definir uma estratégia de gerenciamento de contexto
3. Custos fora de controle: o agente pode disparar várias rodadas de recuperação, fazendo o custo das chamadas de API crescer rapidamente

Caso prático: arquitetura de um assistente inteligente de atendimento ao cliente

Este caso vem de um projeto empresarial anterior e produziu bons resultados.

Cenário: a equipe de atendimento precisava responder a perguntas sobre produtos, pedidos, pós-venda, políticas e vários outros temas. As informações estavam espalhadas por uma base de conhecimento, um CRM, o sistema de pedidos e o ERP.

Problema: o RAG tradicional só conseguia pesquisar a base de conhecimento. Ele não tinha acesso ao status dos pedidos nem ao histórico de cada usuário.

Desenho da arquitetura

Criamos uma arquitetura de agentes em três camadas:

Primeira camada: Routing Agent (agente de roteamento)

Ele analisa a pergunta do usuário e decide qual caminho seguir. Por exemplo:

• “Como usar o produto?” → consultar a base de conhecimento
• “Onde está meu pedido?” → consultar o sistema de pedidos
• “Qual é a política de reembolso?” → consultar os documentos de políticas

Segunda camada: Query Planning Agent (agente de planejamento de consultas)

Para perguntas complexas, ele divide o problema em várias subconsultas. Se o usuário perguntar “Posso devolver o celular que comprei no mês passado?”, o sistema precisa:

1. Consultar o histórico de pedidos do usuário
2. Consultar a política de devolução
3. Comparar a data do pedido com o prazo previsto na política

Terceira camada: ReAct Agent (agente de raciocínio e ação)

Executa as buscas e as chamadas de ferramentas, com suporte a várias rodadas de iteração.

Integração de ferramentas

Os sistemas internos foram conectados pelo protocolo MCP:

tools:
  - name: knowledge_search
    type: vector_retrieval
    source: product_docs

  - name: order_query
    type: api_call
    endpoint: /api/orders/{user_id}

  - name: policy_search
    type: hybrid_retrieval
    sources: [policy_docs, faq]

Comparação dos resultados

Após o lançamento, comparamos o desempenho do RAG tradicional com o do Agentic RAG:

A taxa de resolução cresceu 33 pontos percentuais, enquanto a intervenção humana caiu mais da metade. Em contrapartida, o tempo de resposta aumentou. Esse é um custo inevitável da arquitetura de agentes e exige um equilíbrio entre experiência e eficiência.

Conclusão

RAG + Agent está se tornando uma arquitetura padrão para aplicações empresariais de IA. Ao passar da recuperação passiva para o raciocínio ativo, ela permite que a IA lide com problemas realmente complexos.

Algumas recomendações:

1. Comece pelo simples. Não tente adotar Agentic Graph RAG desde o primeiro dia. Comece com Hybrid RAG, valide o valor e só então evolua.

2. Controle os custos. A flexibilidade dos agentes tem um preço, e os gastos com chamadas de API podem sair do controle com facilidade. Estratégias de roteamento e cache são indispensáveis.

3. Leve a avaliação a sério. Sem métricas quantitativas, você nunca saberá se o sistema é bom ou ruim. O básico é combinar o framework RAGAS com um conjunto de testes próprio.

4. Acompanhe os protocolos abertos. O MCP está se tornando um padrão para conectar ferramentas, enquanto o protocolo A2A busca viabilizar a colaboração entre frameworks. Esses protocolos terão um impacto profundo na evolução do ecossistema de agentes.

É isso. Se você está construindo um sistema RAG, espero que este conteúdo ajude a orientar suas decisões. Se tiver alguma dúvida, deixe um comentário.