RAG Agêntico: Como os agentes de IA estão transformando a geração aumentada por recuperação
Updated on
O RAG padrão (Retrieval-Augmented Generation) tem uma limitação fundamental: recupera uma vez e gera uma vez. O sistema pesquisa um banco de dados vetorial, pega os Top-K chunks, os insere em um prompt e espera que a resposta esteja nesses chunks. Quando as informações relevantes estão espalhadas por múltiplos documentos, requerem raciocínio multi-passo ou precisam de esclarecimento antes da recuperação, o RAG básico falha silenciosamente -- retornando respostas que soam convincentes construídas sobre contexto incompleto.
O RAG agêntico resolve isso substituindo o pipeline estático de recuperar-depois-gerar por um agente de IA autônomo que pode planejar, recuperar iterativamente, avaliar resultados e decidir quando tem informação suficiente para responder. O agente não apenas busca documentos -- ele raciocina sobre o que pesquisar, julga se o conteúdo recuperado é suficiente e toma ações adicionais quando não é.
RAG Básico vs RAG Agêntico
Pipeline de RAG Básico
Consulta do usuário → Embeder consulta → Busca vetorial → Top-K Chunks → LLM → RespostaProblemas com esta abordagem:
- Recuperação única: Se a primeira busca não encontrar documentos relevantes, não há recuperação
- Sem raciocínio sobre o que recuperar: A consulta é embedada como está, sem decomposição
- Sem avaliação: O sistema não pode julgar se os chunks recuperados realmente respondem à pergunta
- Sem recuperação multi-passo: Não pode encadear buscas onde o primeiro resultado informa a próxima consulta
Pipeline de RAG Agêntico
Consulta do usuário → Agente planeja → Ferramenta de busca → Avaliar resultados →
→ Precisa de mais info? → Refinar consulta → Buscar novamente →
→ Contexto suficiente? → Sintetizar → RespostaO agente atua como um orquestrador inteligente que pode:
- Decompor consultas complexas em sub-perguntas
- Escolher ferramentas: busca vetorial, busca web, consulta SQL, chamada API
- Avaliar se o contexto recuperado é suficiente
- Iterar com consultas refinadas até estar confiante
- Sintetizar informações de múltiplas rodadas de recuperação
Como funciona o RAG Agêntico
Arquitetura central
| Componente | RAG Básico | RAG Agêntico |
|---|---|---|
| Processamento de consulta | Embedding direto | Decomposição e planejamento de consulta |
| Recuperação | Busca vetorial única | Múltiplas ferramentas, recuperação iterativa |
| Avaliação | Nenhuma | Auto-avaliação do contexto recuperado |
| Raciocínio | Chamada LLM única | Raciocínio multi-passo com uso de ferramentas |
| Recuperação de erros | Nenhuma | Retentativa com consultas refinadas |
| Fontes de dados | Geralmente um BD vetorial | Múltiplas fontes (BD, web, APIs) |
Fluxo de decisão do agente
Um sistema de RAG agêntico tipicamente segue este padrão de decisão:
- Analisar a pergunta: É simples (recuperação única) ou complexa (precisa de decomposição)?
- Planejar estratégia de recuperação: Quais fontes consultar? Em que ordem?
- Executar recuperação: Buscar na primeira fonte
- Avaliar resultados: Esses chunks contêm a resposta?
- Decidir próxima ação: Responder, refinar consulta ou buscar em outra fonte
- Sintetizar: Combinar informações de todos os passos de recuperação
# Loop conceitual de RAG agêntico (pseudocódigo)
def agentic_rag(query, tools, max_iterations=5):
context = []
plan = agent.plan(query) # Decompor em sub-perguntas
for step in plan:
# Agente decide qual ferramenta usar
tool = agent.select_tool(step, tools)
results = tool.execute(step.query)
context.extend(results)
# Agente avalia se tem informação suficiente
if agent.has_sufficient_context(query, context):
break
# Agente refina a consulta com base no que aprendeu
step.query = agent.refine_query(step, results)
return agent.synthesize(query, context)Padrões chave no RAG Agêntico
1. Decomposição de consultas
Dividir perguntas complexas em sub-consultas mais simples:
Original: "Compare o crescimento de receita da Apple e Microsoft no Q3 2025
e explique qual empresa teve melhores margens operacionais"
Decomposta:
1. "Apple Q3 2025 crescimento de receita"
2. "Microsoft Q3 2025 crescimento de receita"
3. "Apple Q3 2025 margem operacional"
4. "Microsoft Q3 2025 margem operacional"Cada sub-consulta recupera documentos focados e relevantes em vez de esperar que uma única busca ampla retorne todas as informações necessárias.
2. Recuperação adaptativa
O agente decide como recuperar com base no tipo de consulta:
| Tipo de consulta | Estratégia de recuperação |
|---|---|
| Busca factual | Busca vetorial única |
| Comparação | Buscas paralelas para cada entidade |
| Raciocínio multi-passo | Buscas sequenciais, cada uma informada pela anterior |
| Temporal | Filtrar por data, depois busca semântica |
| Agregação | Consulta SQL + busca de documentos |
3. Auto-avaliação
Após cada passo de recuperação, o agente avalia:
- Relevância: Os chunks recuperados são sobre o tópico correto?
- Completude: Contêm informação suficiente para responder?
- Consistência: Múltiplas fontes concordam?
- Atualidade: A informação é suficientemente atual?
4. Seleção de ferramentas
O RAG agêntico não se limita à busca vetorial:
| Ferramenta | Quando usar |
|---|---|
| Busca vetorial | Consultas de similaridade semântica |
| Busca por palavras-chave (BM25) | Correspondência exata de termos, consultas técnicas |
| Busca web | Eventos atuais, informações recentes |
| Consulta SQL | Dados estruturados, agregações |
| Chamada API | Dados em tempo real (preços, clima) |
| Execução de código | Cálculos, transformações de dados |
Abordagens de implementação
Agente LangChain
from langchain.agents import create_react_agent
from langchain_openai import ChatOpenAI
from langchain.tools import Tool
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
# Criar ferramenta de recuperação
vectorstore = FAISS.from_texts(documents, OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
def search_docs(query: str) -> str:
results = retriever.invoke(query)
return "\n".join([doc.page_content for doc in results])
tools = [
Tool(
name="SearchDocuments",
func=search_docs,
description="Search the knowledge base for relevant information"
),
]
llm = ChatOpenAI(model="gpt-4o", temperature=0)
agent = create_react_agent(llm, tools, prompt_template)Agente LlamaIndex
from llama_index.core.agent import ReActAgent
from llama_index.core.tools import QueryEngineTool
from llama_index.core import VectorStoreIndex
# Criar ferramentas de motor de consulta
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(similarity_top_k=5)
tools = [
QueryEngineTool.from_defaults(
query_engine=query_engine,
name="knowledge_base",
description="Search the company knowledge base"
),
]
agent = ReActAgent.from_tools(tools, llm=llm, verbose=True)
response = agent.chat("What were our Q3 results?")Quando usar RAG Agêntico
| Cenário | RAG Básico | RAG Agêntico |
|---|---|---|
| Q&A simples de uma fonte | Melhor escolha | Excessivo |
| Raciocínio multi-documento | Tem dificuldade | Excelente |
| Perguntas que precisam de cálculos | Não consegue | Usa ferramentas de código |
| Dados dinâmicos (APIs, bancos de dados) | Limitado | Encaixe natural |
| Consultas ambíguas | Resultados ruins | Pode esclarecer e iterar |
| Sensibilidade a custos | Mais barato (1 chamada LLM) | Mais caro (múltiplas chamadas) |
| Requisitos de latência | Mais rápido | Mais lento (iterativo) |
Compensações
| Vantagem | Desvantagem |
|---|---|
| Maior qualidade de resposta | Maior latência (múltiplas chamadas LLM) |
| Lida com consultas complexas | Maior custo por consulta |
| Recuperação auto-corretiva | Mais complexo para construir e depurar |
| Integração multi-fonte | Agente pode ficar preso em loops |
| Melhor para consultas ambíguas | Comportamento mais difícil de prever |
Construindo pipelines de dados para RAG Agêntico
Configurar o pipeline de dados para RAG agêntico -- fragmentar documentos, criar embeddings, construir índices vetoriais -- é trabalho experimental iterativo. O RunCell (opens in a new tab) fornece um ambiente Jupyter com IA onde você pode prototipar pipelines RAG com assistência de IA, depurar a qualidade de recuperação interativamente e iterar sobre estratégias de fragmentação.
Para visualizar métricas de avaliação de recuperação (pontuações de relevância, distribuições de latência, qualidade de resposta), o PyGWalker (opens in a new tab) permite explorar seus conjuntos de dados de avaliação RAG interativamente no Jupyter.
FAQ
O que é RAG agêntico?
RAG agêntico combina Geração Aumentada por Recuperação com agentes de IA autônomos. Em vez de um pipeline estático de recuperar-depois-gerar, um agente de IA planeja estratégias de recuperação, executa múltiplas buscas, avalia resultados e itera até ter contexto suficiente para responder com precisão.
Como o RAG agêntico difere do RAG básico?
O RAG básico realiza uma única recuperação e gera uma resposta. O RAG agêntico usa um agente de IA que pode decompor consultas, selecionar diferentes ferramentas (busca vetorial, busca web, SQL), avaliar se o contexto recuperado é suficiente e iterar com consultas refinadas. Ele lida com perguntas complexas e multi-passo que o RAG básico não consegue.
O RAG agêntico é mais caro que o RAG básico?
Sim, o RAG agêntico tipicamente custa mais por consulta porque faz múltiplas chamadas LLM (planejamento, avaliação, síntese) e múltiplas operações de recuperação. A compensação é uma qualidade de resposta significativamente maior para consultas complexas. Para buscas factuais simples, o RAG básico é mais custo-efetivo.
Quais frameworks suportam RAG agêntico?
LangChain, LlamaIndex e Haystack todos suportam padrões de RAG agêntico. O LangChain fornece agentes ReAct com uso de ferramentas, o LlamaIndex oferece agentes de planejamento de consultas e o Haystack tem arquiteturas de agentes baseadas em pipelines. Você também pode construir agentes personalizados usando as APIs de function-calling da OpenAI ou Anthropic diretamente.
Quando devo usar RAG agêntico vs RAG básico?
Use RAG básico para Q&A factual simples de uma única base de conhecimento. Use RAG agêntico quando as consultas requerem raciocínio sobre múltiplos documentos, envolvem comparações, precisam de dados em tempo real ou quando o RAG básico retorna consistentemente respostas incompletas.
Conclusão
O RAG agêntico aborda as limitações centrais do RAG básico substituindo pipelines estáticos por agentes inteligentes que planejam, recuperam iterativamente e avaliam seus próprios resultados. Ele lida com consultas complexas que abrangem múltiplos documentos, requerem raciocínio ou precisam de dados de múltiplas fontes. A compensação é maior custo e latência por consulta. Para a maioria das aplicações, a melhor abordagem é começar com RAG básico para consultas simples e rotear perguntas complexas para o RAG agêntico -- usando o agente apenas quando o sistema mais simples teria dificuldade.