Agentic RAG: Como agentes de IA que buscam, raciocinam e agem estão substituindo pipelines de retrieval tradicionais

Você montou um pipeline RAG. Dividiu os documentos em chunks, fez embedding num banco vetorial e colocou um passo de retrieval antes da chamada ao LLM. Pra perguntas simples funciona bem. Aí um usuário pergunta algo assim:

"Compara os modelos de preço do plano enterprise e starter, e me diz qual teve melhor retenção no último trimestre com base nos dados do dashboard de analytics."

Seu pipeline RAG traz uns chunks vagamente relacionados a preço. Sobre retenção não sabe nada, porque esses dados vivem numa fonte completamente diferente. O LLM inventa uma resposta que soa confiante, e o usuário toma uma decisão de negócio errada.

Esse cenário se repete milhares de vezes por dia em sistemas de IA em produção. E expõe a limitação fundamental do RAG tradicional: é uma busca de passo único num mundo que precisa de raciocínio multi-passo.

É aí que entra o Agentic RAG — o padrão arquitetural onde a IA não só busca e gera. Ela planeja, busca iterativamente, avalia o que encontrou, decide que precisa de mais informação, consulta fontes diferentes, e sintetiza uma resposta final só quando tem evidência suficiente. É a diferença entre um motor de busca e um analista de pesquisa.

Neste guia vamos a fundo. Cobrir por que RAG tradicional bate no teto, como Agentic RAG funciona por baixo dos panos, padrões de arquitetura prontos pra produção com código, e os trade-offs reais que você precisa entender antes de adotar.

Por que RAG tradicional bate no teto

Vamos definir exatamente o que é "RAG tradicional" e onde ele falha de forma sistemática.

O pipeline RAG padrão

Query do usuário → Embedding da query → Busca vetorial → Top-K chunks → LLM + contexto → Resposta

É um pipeline single-pass, buscar-e-gerar. O retrieval roda uma vez, pega os K chunks mais similares, enfia na janela de contexto do LLM e torce pro melhor. Funciona bem pra:

• Consultas factuais simples ("Qual é nossa política de reembolso?")
• Perguntas onde a resposta mora numa seção contígua de um documento
• Corpora documentais pequenos e bem organizados

Mas falha sistematicamente nestas categorias:

Falha 1: Perguntas multi-hop

"Qual time de engenharia teve a maior melhoria de velocidade depois de adotar o novo pipeline CI/CD, e que mudanças específicas eles fizeram?"

Precisa: (1) dados de velocidade por time, (2) identificar quais times adotaram o novo pipeline, (3) cruzar os dois datasets, e (4) detalhes de implementação do time vencedor. Uma busca vetorial retorna chunks espalhados de documentos diferentes, e o LLM não tem o quadro completo.

Falha 2: Análise comparativa

"Como difere nossa abordagem de auth entre a API mobile e a web? Tem alguma brecha de segurança?"

Precisa buscar documentação de dois sistemas separados, entender ambos em contexto completo e fazer análise comparativa. Uma única chamada de retrieval mistura chunks dos dois.

Falha 3: Queries que precisam de cálculo

"Qual foi nosso tempo médio de resposta pro endpoint de pagamentos na última semana, e como se compara com o SLA?"

Precisa consultar um banco de métricas (não um document store), fazer aritmética e comparar contra um valor armazenado em outra fonte. RAG tradicional nem consegue fazer as chamadas API necessárias.

Falha 4: Queries ambíguas que precisam de clarificação

"Me fala sobre a migração."

Qual migração? De banco? De cloud? De React 18 pra 19? RAG tradicional traz os chunks com maior score pra "migração" e torce. Um sistema inteligente pediria esclarecimento — ou ao menos buscaria em múltiplos contextos possíveis.

O problema central

RAG tradicional trata retrieval como um passo de pré-processamento caixa-preta. O LLM não controla o que é buscado, quantas vezes busca, nem em que fontes. Consome passivamente o que recebe.

Agentic RAG vira isso de ponta-cabeça: o LLM vira o orquestrador da própria coleta de informação.

O que é Agentic RAG de verdade

Agentic RAG não é uma lib nem um produto. É um padrão de arquitetura onde um agente LLM tem controle autônomo sobre o processo de retrieval:

Query do usuário
    ↓
Agente (LLM com ferramentas)
    ├── Analisar complexidade da query
    ├── Planejar estratégia de retrieval
    ├── Ferramenta: Busca vetorial (documentos)
    ├── Ferramenta: SQL Query (dados estruturados)
    ├── Ferramenta: API Call (dados em tempo real)
    ├── Ferramenta: Busca web (conhecimento externo)
    ├── Avaliar: "Tenho o suficiente pra responder?"
    │     ├── Não → Refinar query, buscar de novo
    │     └── Sim → Sintetizar resposta
    └── Resposta final (com citações)

Diferenças chave do RAG tradicional:

O loop do agente

O coração do Agentic RAG segue o padrão ReAct (Reason + Act):

1. Raciocinar: O agente analisa a query e decide que informação precisa
2. Agir: Chama uma ferramenta (busca, query, API) pra obter a informação
3. Observar: Examina os resultados
4. Raciocinar de novo: Decide se tem o suficiente ou precisa buscar mais
5. Repetir até ter evidência suficiente pra sintetizar

Construindo Agentic RAG: Padrões de arquitetura

Três padrões dominantes, cada um com trade-offs diferentes.

Padrão 1: Agente Roteador (Mais simples)

Em vez de sempre bater no banco vetorial, um LLM decide qual fonte de retrieval consultar com base na pergunta.

import { ChatOpenAI } from '@langchain/openai';
import { tool } from '@langchain/core/tools';
import { createReactAgent } from '@langchain/langgraph/prebuilt';
import { z } from 'zod';

const searchDocs = tool(
  async ({ query }) => {
    const results = await vectorStore.similaritySearch(query, 5);
    return results.map(r => r.pageContent).join('\n\n');
  },
  {
    name: 'search_documentation',
    description: 'Buscar na documentação interna e base de conhecimento.',
    schema: z.object({ query: z.string() }),
  }
);

const queryMetrics = tool(
  async ({ sql }) => {
    const result = await metricsDb.query(sql);
    return JSON.stringify(result.rows);
  },
  {
    name: 'query_metrics',
    description: 'Executar queries SQL no banco de métricas.',
    schema: z.object({ sql: z.string() }),
  }
);

const searchTickets = tool(
  async ({ query, status }) => {
    const tickets = await jiraClient.search(
      `text ~ "${query}" AND status = "${status}"`
    );
    return JSON.stringify(tickets.issues.map(i => ({
      key: i.key, summary: i.fields.summary, status: i.fields.status.name,
    })));
  },
  {
    name: 'search_tickets',
    description: 'Buscar tickets no Jira.',
    schema: z.object({
      query: z.string(),
      status: z.enum(['Open', 'In Progress', 'Done', 'All']).default('All'),
    }),
  }
);

const agent = createReactAgent({
  llm: new ChatOpenAI({ model: 'gpt-4o', temperature: 0 }),
  tools: [searchDocs, queryMetrics, searchTickets],
});

O Roteador lida bem com as falhas 2 e 3, mas só faz um retrieval por fonte. Pra multi-hop, precisa de algo mais potente.

Padrão 2: Agente de retrieval iterativo (Mais comum)

O workhorse de produção. O agente busca, avalia e decide se refina a query e busca de novo.

import { StateGraph, Annotation } from '@langchain/langgraph';
import { ChatOpenAI } from '@langchain/openai';

const AgentState = Annotation.Root({
  question: Annotation<string>,
  retrievedDocs: Annotation<string[]>({
    reducer: (a, b) => [...a, ...b], default: () => []
  }),
  searchQueries: Annotation<string[]>({
    reducer: (a, b) => [...a, ...b], default: () => []
  }),
  evaluation: Annotation<string>,
  finalAnswer: Annotation<string>,
  iterations: Annotation<number>({
    reducer: (_, b) => b, default: () => 0
  }),
});

const llm = new ChatOpenAI({ model: 'gpt-4o', temperature: 0 });

async function planRetrieval(state: typeof AgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Analise esta pergunta e gere 1-3 queries de busca específicas.
      Considere o que já foi recuperado.
      Retorne JSON: { "queries": [...], "reasoning": "..." }`,
    },
    {
      role: 'user',
      content: `Pergunta: ${state.question}\n\nJá recuperado:\n${state.retrievedDocs.join('\n---\n') || 'Nada ainda'}`,
    },
  ]);
  const plan = JSON.parse(response.content as string);
  return { searchQueries: plan.queries };
}

async function retrieve(state: typeof AgentState.State) {
  const newDocs: string[] = [];
  for (const query of state.searchQueries.slice(-3)) {
    const results = await vectorStore.similaritySearch(query, 3);
    newDocs.push(...results.map(r =>
      `[Fonte: ${r.metadata.source}]\n${r.pageContent}`
    ));
  }
  return { retrievedDocs: newDocs, iterations: state.iterations + 1 };
}

async function evaluate(state: typeof AgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Avalie se a informação recuperada é suficiente pra responder
      a pergunta de forma completa e precisa.
      Retorne JSON: { "sufficient": true/false, "missing": "o que falta", "confidence": 0-100 }`,
    },
    {
      role: 'user',
      content: `Pergunta: ${state.question}\n\nInformação:\n${state.retrievedDocs.join('\n---\n')}`,
    },
  ]);
  return { evaluation: response.content as string };
}

async function synthesize(state: typeof AgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Responda a pergunta baseando-se SOMENTE na informação recuperada.
      Cite fontes pra cada afirmação.`,
    },
    {
      role: 'user',
      content: `Pergunta: ${state.question}\n\nEvidência:\n${state.retrievedDocs.join('\n---\n')}`,
    },
  ]);
  return { finalAnswer: response.content as string };
}

function shouldContinue(state: typeof AgentState.State) {
  if (state.iterations >= 5) return 'synthesize';
  try {
    const eval_ = JSON.parse(state.evaluation);
    if (eval_.sufficient && eval_.confidence >= 70) return 'synthesize';
    return 'plan';
  } catch { return 'synthesize'; }
}

const graph = new StateGraph(AgentState)
  .addNode('plan', planRetrieval)
  .addNode('retrieve', retrieve)
  .addNode('evaluate', evaluate)
  .addNode('synthesize', synthesize)
  .addEdge('__start__', 'plan')
  .addEdge('plan', 'retrieve')
  .addEdge('retrieve', 'evaluate')
  .addConditionalEdges('evaluate', shouldContinue, {
    plan: 'plan', synthesize: 'synthesize',
  })
  .addEdge('synthesize', '__end__')
  .compile();

Este padrão é poderoso porque o agente decompõe perguntas complexas, avalia qualidade do retrieval, itera quando falta informação e limita iterações pra evitar custos descontrolados.

Padrão 3: RAG multi-agente (Mais poderoso)

Pros casos mais complexos, múltiplos agentes especializados colaboram em paralelo:

import { StateGraph, Annotation } from '@langchain/langgraph';

const MultiAgentState = Annotation.Root({
  question: Annotation<string>,
  subQuestions: Annotation<string[]>,
  agentResults: Annotation<Record<string, string>>({
    reducer: (a, b) => ({ ...a, ...b }), default: () => ({}),
  }),
  finalAnswer: Annotation<string>,
});

async function decompose(state: typeof MultiAgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Decomponha esta pergunta complexa em 2-4 sub-perguntas
      independentes que possam ser pesquisadas em paralelo.
      Retorne JSON: { "subQuestions": [...] }`,
    },
    { role: 'user', content: state.question },
  ]);
  const { subQuestions } = JSON.parse(response.content as string);
  return { subQuestions };
}

async function researchDocs(state: typeof MultiAgentState.State) {
  const results: Record<string, string> = {};
  for (const q of state.subQuestions) {
    const docs = await vectorStore.similaritySearch(q, 5);
    results[`docs_${q.slice(0, 30)}`] = docs.map(d => d.pageContent).join('\n');
  }
  return { agentResults: results };
}

async function synthesizeMulti(state: typeof MultiAgentState.State) {
  const allEvidence = Object.entries(state.agentResults)
    .map(([key, val]) => `### ${key}\n${val}`).join('\n\n');

  const response = await llm.invoke([
    {
      role: 'system',
      content: `Sintetize uma resposta abrangente com os achados
      de múltiplos agentes de pesquisa. Cite fontes.`,
    },
    {
      role: 'user',
      content: `Pergunta original: ${state.question}\n\nAchados:\n${allEvidence}`,
    },
  ]);
  return { finalAnswer: response.content as string };
}

const multiAgentGraph = new StateGraph(MultiAgentState)
  .addNode('decompose', decompose)
  .addNode('research_docs', researchDocs)
  .addNode('research_metrics', researchMetrics)
  .addNode('synthesize', synthesizeMulti)
  .addEdge('__start__', 'decompose')
  .addEdge('decompose', 'research_docs')
  .addEdge('decompose', 'research_metrics')
  .addEdge('research_docs', 'synthesize')
  .addEdge('research_metrics', 'synthesize')
  .addEdge('synthesize', '__end__')
  .compile();

Desafios em produção: As partes difíceis

Montar um demo de Agentic RAG leva um dia. Deixar production-ready leva meses.

1. Budget de latência

Cada iteração soma latência. RAG tradicional: 1-2s. Agentic RAG com 3 iterações: 5-10s. Multi-agente: 10-20s.

// Classificação de queries — roteia simples pro RAG tradicional
const complexity = await classifyComplexity(userQuery);
if (complexity === 'simple') {
  return traditionalRag(userQuery);  // ~1-2s
} else {
  return agenticRag(userQuery);  // ~5-15s, mas muito mais preciso
}

2. Controle de custos

Cada iteração queima tokens. Uma query Agentic RAG de 3 iterações pode usar 10-15x mais tokens.

// Rastreamento de orçamento de tokens
const MAX_INPUT_TOKENS = 50_000;
const MAX_OUTPUT_TOKENS = 10_000;
let totalInputTokens = 0;

async function trackedLlmCall(messages: Message[]) {
  const tokenEstimate = messages.reduce(
    (sum, m) => sum + (typeof m.content === 'string'
      ? m.content.length / 4 : 0), 0
  );
  if (totalInputTokens + tokenEstimate > MAX_INPUT_TOKENS) {
    // Forçar síntese com o que temos
    return { action: 'force_synthesize' };
  }
  const response = await llm.invoke(messages);
  totalInputTokens += response.usage?.input_tokens || 0;
  return response;
}

// Deduplicação inteligente pra reduzir tamanho do contexto
function deduplicateChunks(docs: Document[]): Document[] {
  const seen = new Set<string>();
  return docs.filter(doc => {
    // Hash de conteúdo pra detectar quase-duplicatas
    const hash = simpleHash(doc.pageContent.slice(0, 200));
    if (seen.has(hash)) return false;
    seen.add(hash);
    return true;
  });
}

3. Avaliação: como saber se tá funcionando?

A parte mais difícil. Como avaliar um sistema Agentic RAG?

// Framework de avaliação pra Agentic RAG
interface AgentEvalMetrics {
  // Qualidade do retrieval
  retrievalPrecision: number;   // % dos docs recuperados que eram relevantes
  retrievalRecall: number;      // % dos docs relevantes que foram recuperados

  // Comportamento do agente
  avgIterations: number;        // Loops médios até responder
  unnecessaryIterations: number; // Loops que não agregaram info
  toolSelectionAccuracy: number; // Escolheu a ferramenta certa?

  // Qualidade da resposta
  answerCorrectness: number;    // Precisão factual vs ground truth
  answerCompleteness: number;   // Respondeu todas as partes?
  citationAccuracy: number;     // As citações estão corretas?

  // Eficiência de custo
  totalTokensUsed: number;
  latencyMs: number;
  costPerQuery: number;
}

// Golden dataset com comportamentos esperados
const evalDataset = [
  {
    query: 'Compare retenção do plano enterprise e startup do último trimestre',
    expectedTools: ['search_documentation', 'query_metrics'],
    expectedMinIterations: 2,
    expectedSources: ['pricing-docs', 'analytics-dashboard'],
    groundTruth: 'Enterprise: 94.2% retenção, Startup: 87.1% retenção...',
  },
  // ... mais casos de teste
];

// Executar avaliação
async function evaluateAgent(dataset: EvalCase[]) {
  const results: AgentEvalMetrics[] = [];

  for (const testCase of dataset) {
    const trace = await agentGraph.invoke(
      { question: testCase.query },
      { configurable: { tracing: true } },
    );

    results.push({
      retrievalPrecision: calculatePrecision(
        trace.retrievedDocs, testCase.expectedSources
      ),
      toolSelectionAccuracy: calculateToolAccuracy(
        trace.toolCalls, testCase.expectedTools
      ),
      answerCorrectness: await llmJudge(
        trace.finalAnswer, testCase.groundTruth
      ),
      avgIterations: trace.iterations,
      totalTokensUsed: trace.tokenUsage.total,
      latencyMs: trace.durationMs,
      costPerQuery: calculateCost(trace.tokenUsage),
      // ...
    });
  }

  return aggregateMetrics(results);
}

4. Guardrails de segurança

Sistemas agênticos podem sair dos trilhos. Um agente com acesso SQL poderia, em tese, fazer DROP TABLE. Precisa de múltiplas camadas de defesa:

// 1. Validação no nível da ferramenta
const querySql = tool(
  async ({ sql }) => {
    // Validar SQL antes de executar
    const forbidden = ['DROP', 'DELETE', 'UPDATE', 'INSERT', 'ALTER', 'TRUNCATE'];
    const upperSql = sql.toUpperCase();

    for (const kw of forbidden) {
      if (upperSql.includes(kw)) {
        return `Erro: ${kw} não permitido. Apenas SELECT suportado.`;
      }
    }

    // Timeout e limite de linhas
    const safeSql = `${sql} LIMIT 1000`;
    const result = await db.query(safeSql, { timeout: 5000 });
    return JSON.stringify(result.rows);
  },
  {
    name: 'query_database',
    description: 'Queries SQL somente leitura. Apenas SELECT permitido.',
    schema: z.object({ sql: z.string() }),
  }
);

// 2. Limites de iteração (já mostrado acima)

// 3. Validação de output — detecção de alucinação
async function validateResponse(
  response: string,
  context: string
): Promise<{ isGrounded: boolean; hallucinations: string[] }> {
  const validation = await llm.invoke([
    {
      role: 'system',
      content: `Verifique se cada afirmação factual na resposta é sustentada
      pelo contexto. Liste afirmações NÃO sustentadas (alucinações).
      Retorne JSON: { "isGrounded": boolean, "hallucinations": [...] }`,
    },
    {
      role: 'user',
      content: `Resposta: ${response}\n\nContexto: ${context}`,
    },
  ]);

  return JSON.parse(validation.content as string);
}

5. Observabilidade

Sem rastreabilidade completa não dá pra debugar sistema agêntico. Cada decisão do agente precisa ser rastreável.

// Logging estruturado pra cada passo do agente
interface AgentTrace {
  traceId: string;
  question: string;
  steps: {
    node: string;
    input: Record<string, unknown>;
    output: Record<string, unknown>;
    llmCalls: {
      model: string;
      inputTokens: number;
      outputTokens: number;
      latencyMs: number;
    }[];
    toolCalls: {
      tool: string;
      input: Record<string, unknown>;
      output: string;
      latencyMs: number;
    }[];
    durationMs: number;
  }[];
  totalDurationMs: number;
  totalTokens: number;
  finalAnswer: string;
}

// Integração com LangSmith, Langfuse ou tracing custom
import { Client } from 'langsmith';

const langsmith = new Client();

const tracedGraph = graph.withConfig({
  callbacks: [langsmith.getTracer()],
  runName: 'agentic-rag',
  metadata: {
    userId: currentUser.id,
    sessionId: session.id,
    queryComplexity: complexity,
  },
});

Benchmarks reais: Agentic RAG vs RAG tradicional

Benchmarkamos três arquiteturas contra 200 perguntas reais de complexidades variadas:

Os números falam por si:

• Queries simples: Os três rendem parecido. Agentic RAG é overkill aqui.
• Queries complexas: Agentic RAG ganha de lavada, especialmente multi-hop e comparativas.
• Custo: 10x mais caro por query. Roteie as simples pro RAG tradicional.
• Alucinações: O loop de auto-avaliação pega mais erros.

Quando NÃO usar Agentic RAG

Não use quando:

• A maioria das queries são lookups simples → RAG tradicional é mais rápido e barato
• Requisito de latência é <2 segundos → o agent loop é lento demais
• Orçamento é apertado → custos de token escalam rápido
• Dados vivem em uma fonte bem estruturada → RAG tradicional resolve
• Não pode investir em infra de avaliação → não vai saber se funciona

Use quando:

• Usuários fazem perguntas complexas multi-parte regularmente
• Precisa consultar múltiplas fontes pra uma resposta
• Precisão importa mais que velocidade (Q&A enterprise, jurídico, médico)
• A resposta precisa de cálculo ou chamadas API
• A precisão do seu RAG estagnou e precisa de um salto

Ecossistema de frameworks em 2026

LangGraph (LangChain): A opção mais madura pra grafos de agentes. SDKs TypeScript e Python são production-ready.

LlamaIndex Workflows: Sistema baseado em eventos assíncronos, abstração diferente do grafo de estados.

Semantic Kernel (Microsoft): Pro ecossistema .NET, com integração nativa com Azure AI Search.

Implementações custom: Muitos times constroem loops de agentes custom sem frameworks, com controle total mas reinventando padrões comuns.

Conclusão: A mudança de paradigma

RAG tradicional foi revolucionário — deu aos LLMs acesso a dados privados sem fine-tuning. Mas a arquitetura single-pass tem um limite fundamental. Perguntas complexas exigem uma abordagem que consiga planejar, iterar e raciocinar entre múltiplas fontes.

Agentic RAG não é melhoria incremental. É uma mudança de paradigma de "buscar e torcer" pra "pesquisar e verificar." A melhoria de precisão em queries complexas (34% → 78%) não é marginal — é a diferença entre um sistema útil e uma responsabilidade.

Mas adote com olhar crítico:

1. Comece com classificação de queries. Roteie as simples pro RAG tradicional (rápido, barato) e as complexas pro Agentic RAG (preciso, caro). A maioria dos sistemas em produção usa ambos.

2. Construa avaliação primeiro. Se não pode medir, não pode melhorar. Crie um golden dataset antes de escrever código de agentes.

3. Instrumente tudo. Cada decisão do agente, cada retrieval, cada avaliação precisa ser rastreável.

4. Coloque limites hard. Máximo de iterações, tokens e latência. Sistema agêntico sem guardrails é sistema caro e imprevisível.

5. Invista nas ferramentas. A qualidade do agente depende diretamente da qualidade das tools. Um agente com raciocínio perfeito não compensa banco vetorial mal configurado.

O futuro do retrieval não são embeddings melhores ou janelas de contexto maiores. É dar à IA o mesmo workflow de pesquisa que especialistas humanos usam: entender a pergunta, planejar a busca, coletar evidência de múltiplas fontes, avaliar o que encontrou e sintetizar só quando tem confiança.

Isso é Agentic RAG. E é a arquitetura que vai dominar sistemas de IA em produção em 2026 e além.