RAG Agentivo

O que significa “RAG agentivo”

RAG agentivo (Agentic RAG) é uma família de sistemas de geração aumentada por recuperação (Retrieval-Augmented Generation, RAG) em que um modelo de linguagem grande (LLM) faz mais do que “recuperar uma vez e depois responder”. Em vez disso, o modelo (ou uma camada de orquestração (orchestration layer) ao redor dele) se comporta como um agente (agent) que pode:

  • Decompor uma consulta complexa em subperguntas menores
  • Recuperar iterativamente informações ao longo de várias etapas (recuperar → ler → refinar → recuperar novamente)
  • Fazer autocrítica do rascunho de resposta e decidir quando mais evidências são necessárias (auto-RAG)
  • Escolher estratégias/ferramentas de recuperação de forma dinâmica (busca vetorial, busca por palavras-chave, filtros, bases de conhecimento, APIs)

Em comparação com RAG básico, o RAG agentivo é menos um pipeline único e mais um sistema de controle em malha fechada (closed-loop control system) que planeja, coleta evidências, verifica e só então produz uma resposta.

Essa abordagem é especialmente útil quando as perguntas são de múltiplos saltos (multi-hop) (“A depende de B depende de C”), ambíguas ou exigem alta confiabilidade e citações.

Por que o RAG agentivo existe (limitações do “RAG de uma tentativa”)

Um fluxo padrão de RAG é:

  1. Gerar embedding da consulta
  2. Recuperar os top-k trechos
  3. Alimentá-los no LLM
  4. Gerar a resposta

Isso pode falhar quando:

  • A pergunta tem múltiplas facetas (política + técnico + cronograma).
  • A melhor consulta não é a consulta original do usuário (precisa ser reescrita).
  • A evidência está espalhada por vários documentos (recuperação de múltiplos saltos).
  • A recuperação inicial tem baixa revocação; o top-k perde fatos-chave.
  • O modelo deve verificar afirmações e produzir citações ancoradas (ver Ancoragem e Citações).

O RAG agentivo aborda isso permitindo que o modelo tome ações — sobretudo, recuperar novamente com consultas e restrições melhores.

Fundamentos conceituais

O RAG agentivo combina ideias de:

  • Recuperação de informação: formulação de consulta, feedback de relevância, reordenamento, recuperação esparsa + densa
  • Uso de ferramentas por LLM: chamadas estruturadas para recuperadores e outras ferramentas (ver Chamada de Funções / Uso de Ferramentas)
  • Planejamento e loops de controle: decidir o próximo passo com base no estado intermediário
  • Autoavaliação / reflexão: crítica, estimativa de incerteza e bloqueio do tipo “precisa de mais evidência”

Você pode pensar nisso como trazer “sessões de busca” (o Googling iterativo de uma pessoa) para um loop programático dirigido por um LLM.

Padrões centrais em RAG agentivo

1) Decomposição de consulta

A decomposição de consulta (query decomposition) divide uma pergunta complexa em tarefas menores de recuperação, cujos resultados podem ser compostos em uma resposta final.

Estilos comuns de decomposição:

  • Decomposição em subperguntas: transformar uma pergunta em uma lista de subperguntas respondíveis.
  • Decomposição por facetas: separar por aspectos (“preço”, “segurança”, “SLA”, “limites”).
  • Decomposição por entidade/relação: identificar entidades-chave e relações necessárias (“Quem aprovou X?” “Quando a política Y mudou?”).
  • Decomposição temporal: “política atual” vs “política histórica na data T”.

Exemplo prático:

Pergunta do usuário:

“Podemos armazenar dados de saúde de clientes da UE no Fornecedor X e quais configurações são necessárias para estar em conformidade com a HIPAA?”

Possível decomposição:

  • “O Fornecedor X oferece residência de dados na UE e em quais regiões?”
  • “O Fornecedor X oferece BAA para HIPAA e sob quais condições?”
  • “Quais configurações são necessárias (criptografia, logs de auditoria, controles de acesso)?”
  • “Qual política interna se aplica ao armazenamento de dados de saúde com terceiros?”

Essa decomposição melhora a recuperação porque cada subconsulta é mais estreita e tem mais chance de corresponder a trechos relevantes.

Nota de implementação: a decomposição pode ser feita pelo mesmo LLM (com um prompt para produzir subconsultas) ou por um modelo “planejador” menor. Em produção, muitas vezes você restringe a saída a JSON (ver Saídas Estruturadas).

2) Recuperação iterativa (Recuperar → Ler → Refinar → Recuperar)

A recuperação iterativa (iterative retrieval) é um loop que usa achados intermediários para orientar buscas subsequentes. Isso espelha como humanos pesquisam: você lê algo, percebe o que falta e então busca novamente com termos melhores.

Loop típico:

  1. Recuperar top-k trechos para uma consulta inicial
  2. Resumir o que foi aprendido e o que ainda é desconhecido
  3. Reescrever/refinar a consulta (adicionar restrições, entidades, datas, sinônimos)
  4. Recuperar novamente (possivelmente de um índice diferente ou usando filtros distintos)
  5. Repetir até que critérios de parada sejam atendidos (cobertura, confiança, orçamento)

Exemplo: depuração de um incidente em produção

  • Primeira recuperação: visão geral do runbook
  • Segunda recuperação: runbook específico do serviço + postmortems de incidentes recentes
  • Terceira recuperação: referência de configuração para o código de erro exato

Esse padrão costuma ser combinado com:

3) Auto-RAG (Geração Aumentada por Recuperação Auto-Reflexiva)

Auto-RAG (Self-RAG) (como usado em pesquisa e na prática) se refere a sistemas em que o modelo avalia o próprio rascunho e decide se deve recuperar mais, revisar ou se abster.

Um enquadramento prático:

  • Rascunhar a resposta com base nas evidências atuais
  • A etapa de crítica pergunta:
    • “Quais afirmações não têm citação?”
    • “Há evidência conflitante?”
    • “A evidência está desatualizada?”
    • “Estamos perdendo uma definição ou exceção importante de política?”
  • Se houver problemas, disparar recuperação direcionada (“encontrar fonte para a afirmação X”, “checar a versão mais recente”, “buscar exceções”)
  • Revisar a resposta com o contexto atualizado

Auto-RAG não é mágica; é um mecanismo de controle que reduz alucinações ao:

  • Tornar “evidência insuficiente” um estado de primeira classe
  • Forçar uma ligação entre afirmações e fontes recuperadas (ver Ancoragem e Citações)

4) Estratégias de recuperação orientadas por agente (escolhendo ferramentas e táticas)

Em RAG agentivo, a recuperação não é uma única chamada de ferramenta. O agente pode escolher entre:

  • Busca vetorial sobre embeddings (ver Busca Vetorial e Embeddings)
  • Busca por palavras-chave/BM25 ou busca no estilo de logs (boa para identificadores, códigos de erro)
  • Recuperação híbrida (densa + esparsa)
  • Fontes estruturadas: SQL, armazenamentos chave-valor, sistemas de tickets, wikis
  • Consultas a grafo de conhecimento (ver RAG com Grafo de Conhecimento (Híbridos))
  • Recuperação multimodal para diagramas/imagens/páginas de PDF (ver RAG Multimodal)

A parte “agentiva” é a política de decisão: dada a incerteza atual, qual ação de recuperação é a melhor a seguir?

Exemplos de escolhas do agente:

  • Se a pergunta menciona um código de erro exato → busca por palavras-chave primeiro
  • Se pede similaridade conceitual (“incidentes similares”) → busca vetorial
  • Se os resultados forem amplos → adicionar filtros de metadados (serviço, período)
  • Se as fontes conflitarem → recuperar o documento de política mais recente e a fonte canônica oficial

Uma arquitetura de referência

Uma arquitetura comum de RAG agentivo se parece com isto:

  • Planejador (LLM): decompõe a consulta, propõe ações de busca
  • Ferramentas de recuperação:
    • recuperação densa/híbrida + filtros de metadados
    • reordenador opcional
  • Leitor (LLM): extrai fatos relevantes e citações dos trechos recuperados
  • Crítico/Verificador (LLM ou regras): verifica evidência faltante, afirmações sem suporte
  • Compositor (LLM): escreve a resposta final com citações e formatação estruturada
  • Armazenamento de estado: mantém notas intermediárias, IDs de trechos recuperados, questões em aberto
  • Caches: caches de prompt/resultado/embedding para custo e latência (ver Cache)

Em sistemas menores, um LLM pode desempenhar vários papéis; em sistemas maiores, separar papéis melhora a controlabilidade e a avaliação.

Exemplo prático: pergunta de política de múltiplos saltos

Usuário:

“Prestadores de serviço podem acessar logs de produção contendo e-mails de clientes e, em caso afirmativo, quais aprovações são necessárias?”

Por que isso é de múltiplos saltos:

  • Precisa da definição de “prestador de serviço” na política interna
  • Precisa da política de classificação de dados de logs (PII)
  • Precisa do fluxo de aprovação e controles (menor privilégio, acesso com tempo limitado)
  • Precisa de exceções (resposta a incidentes)

Um fluxo agentivo poderia ser:

  1. Decompor

    • “Qual é a política sobre acesso de prestadores de serviço a sistemas/logs de produção?”
    • “E-mails de clientes são classificados como PII e há regras especiais?”
    • “Quais aprovações são exigidas e quem as concede?”
    • “Há exceções de resposta a incidentes?”

  2. Recuperar iterativamente

    • Buscar “política de acesso de prestadores a produção”
    • Depois “definição de PII endereço de e-mail”
    • Depois “processo de aprovação acesso a log de produção”
    • Depois “procedimento de acesso emergencial resposta a incidentes”

  3. Crítica auto-RAG

    • A resposta cita a versão atual da política?
    • Estamos misturando regras de funcionários com regras de prestadores de serviço?
    • Temos uma fonte para “quem aprova”?

  4. Compor a resposta

    • Lista de condições + passos de aprovação + citações por afirmação

Isso é substancialmente mais confiável do que a recuperação de uma tentativa porque cobre explicitamente cada dependência.

Esboço de implementação (pseudocódigo)

Abaixo está um loop simplificado em estilo Python. Sistemas reais adicionam observability, rate limiting, retries, and secure handling of retrieved content.

from dataclasses import dataclass, field

@dataclass
class RagState:
    user_question: str
    subquestions: list[str] = field(default_factory=list)
    notes: list[str] = field(default_factory=list)
    citations: list[dict] = field(default_factory=list)  # {chunk_id, source, quote}
    open_issues: list[str] = field(default_factory=list)
    steps: int = 0

MAX_STEPS = 6

def agentic_rag_answer(user_question, llm, retriever, reranker=None):
    state = RagState(user_question=user_question)

    # 1) Plan / decompose
    state.subquestions = llm.decompose(user_question)  # returns list[str]

    for _ in range(MAX_STEPS):
        state.steps += 1

        # 2) Decide next retrieval target
        query = llm.choose_next_query(state.subquestions, state.notes, state.open_issues)

        results = retriever.search(query, top_k=20, filters=llm.suggest_filters(state))
        if reranker:
            results = reranker.rerank(query, results)[:6]

        # 3) Read/extract evidence
        extracted = llm.extract_facts_with_citations(user_question, results)
        state.notes.extend(extracted.notes)
        state.citations.extend(extracted.citations)

        # 4) Self-RAG critique: do we have enough grounded support?
        critique = llm.critique_answer_readiness(user_question, state.notes, state.citations)

        if critique.ready:
            break

        state.open_issues = critique.open_issues

        # Optionally: update subquestions based on what was learned
        state.subquestions = llm.refine_subquestions(state.subquestions, state.notes, state.open_issues)

    # 5) Compose final answer with citations
    return llm.compose_final(user_question, state.notes, state.citations)

Ponto-chave de design: a condição de parada do loop não é “recuperamos uma vez”, mas “o crítico diz que a resposta está suficientemente suportada (ou atingimos um orçamento)”.

Padrões de prompting que funcionam bem

O RAG agentivo melhora quando você separa explicitamente tarefas e saídas.

Prompt de decomposição (estruturado)

Peça subconsultas pesquisáveis, não explicações longas:

  • Inclua entidades, sinônimos e restrições (intervalo de tempo, versão do produto)
  • Evite pronomes
  • Garanta que as subperguntas sejam recuperáveis de forma independente

Isso muitas vezes é reforçado com esquema JSON (JSON schema) (ver Saídas Estruturadas).

Leitura com evidência em primeiro lugar

Ao extrair fatos, exija:

  • Citações/snippets diretos
  • Identificadores de fonte (título do doc, URL, ID do trecho)
  • Uma breve explicação “por que é relevante” para cada snippet

Isso dá suporte à formatação posterior de citações e à resolução de conflitos.

Prompt de crítica (porta de auto-RAG)

Exija que o crítico rotule:

  • Afirmações sem suporte
  • Definições faltantes
  • Risco de política desatualizada
  • Conflitos entre fontes
  • Se deve recuperar mais ou se abster

Uma prática forte é permitir que o crítico retorne consultas de recuperação direcionadas (“buscar exceção de política para resposta a incidentes”).

Táticas de recuperação usadas por agentes

Reescrita e expansão de consulta

Agentes frequentemente reescrevem consultas para:

  • Adicionar sinônimos (“SSO” ↔ “SAML”, “SOC2” ↔ “SOC 2”)
  • Adicionar restrições (“após 2024-01”, “API v2”, “região UE”)
  • Converter perguntas em frases de palavras-chave para busca esparsa

Alternar modos de recuperação

Uma heurística confiável:

  • Use busca por palavras-chave para identificadores, códigos, nomes, formulações exatas.
  • Use busca vetorial para conceitos e paráfrases.
  • Use híbrida quando estiver em dúvida (ver Busca Híbrida (Esparsa + Densa)).

Reordenamento para precisão

Em loops agentivos, a revocação costuma melhorar recuperando mais candidatos e, então, usando um reordenador cross-encoder (cross-encoder reranker) para precisão (ver Reordenamento). Isso reduz “poluição de contexto” antes de o modelo ler.

Filtros de metadados

Agentes podem propor filtros como:

  • doc_type in {policy, runbook, RFC}
  • product=“X”, team=“Security”
  • date >= “2025-01-01”
  • jurisdiction=“EU”

Essa é uma das melhorias de maior ROI em RAG corporativo porque reduz contexto irrelevante cedo.

Aplicações práticas

Suporte ao cliente e troubleshooting

O RAG agentivo pode:

  • Fazer perguntas de esclarecimento (ou simulá-las internamente)
  • Recuperar docs do produto, problemas conhecidos, histórico de tickets
  • Restringir iterativamente até chegar à correção certa
  • Gerar instruções passo a passo ancoradas em fontes

Conformidade e QA jurídico/de políticas

Ele pode:

  • Decompor por domínio de política (privacidade, retenção, controle de acesso)
  • Forçar citações para cada afirmação
  • Detectar conflitos entre versões de políticas
  • Escalar/abster-se quando faltar evidência

Isso se encaixa naturalmente com Ancoragem e Citações.

Assistentes de conhecimento para engenharia

Tarefas típicas:

  • “Como migro o serviço A para a plataforma B?”
  • “Quais são as dependências e as etapas de rollout?” Isso exige síntese de múltiplos documentos e frequentemente se beneficia de recuperação iterativa e refinamento de consulta.

Fluxos de trabalho de pesquisa e analytics

Um agente pode:

  • Coletar múltiplos artigos/notas
  • Extrair campos consistentes (método, dataset, resultados)
  • Identificar informações faltantes e recuperar mais

Para tarefas de “extração estruturada”, combine com Saídas Estruturadas.

Avaliação: como saber que está funcionando

O RAG agentivo adiciona partes móveis, então você deve avaliar em múltiplas camadas:

Qualidade de recuperação

  • Revocação@k (Recall@k) para saber se o trecho necessário aparece nos conjuntos de candidatos
  • nDCG / MRR para qualidade de ranqueamento
  • Impacto do reordenador (antes vs depois)

Qualidade de ancoragem

  • Cobertura de citações: % de afirmações-chave com citações
  • Fidelidade: a resposta corresponde ao texto citado?
  • Taxa de contradição: combina fontes conflitantes incorretamente?

(Ver também Ancoragem e Citações.)

Comportamento do agente

  • Etapas por consulta (e distribuição)
  • Precisão de chamada de ferramenta: as ferramentas escolhidas são apropriadas?
  • Qualidade de término do loop: para cedo demais vs recupera em excesso
  • Custo/latência por resposta bem-sucedida

Sucesso de tarefa ponta a ponta

Correção, conformidade com políticas e utilidade julgadas por humanos ou por um conjunto de testes.

Uma boa prática é registrar “motivo para recuperar” e “motivo para parar” para que você possa depurar falhas de planejamento.

Modos de falha comuns (e mitigações)

Loops infinitos / recuperação em excesso

Sintoma: o agente continua buscando sem convergir.

Mitigações:

  • Orçamentos rígidos de etapas/tokens
  • Parar quando o ganho marginal for baixo (por exemplo, nenhum novo fato/entidade encontrado)
  • Usar um crítico que possa escolher “responder com incerteza” ou “abster-se”

Deriva de consulta

Sintoma: a reescrita iterativa se afasta da intenção do usuário.

Mitigações:

  • Manter a pergunta original como um invariante
  • Manter uma checklist de subperguntas ligada à intenção do usuário
  • Exigir que o agente justifique reescritas de consulta

Poluição de contexto

Sintoma: trechos recuperados demais confundem o modelo.

Mitigações:

  • Reordenamento (ver Reordenamento)
  • Top-k menor indo para o leitor
  • Extrair e depois compor: ler trechos individualmente, armazenar fatos e então escrever

Citações alucinadas ou ancoragem fraca

Sintoma: citações não sustentam as afirmações.

Mitigações:

  • Exigir objetos de evidência “citação + localização”
  • Gerar a resposta a partir de objetos de evidência, não de memória bruta
  • Usar um verificador pós-hoc que checa cada afirmação contra o texto citado

Fontes desatualizadas ou conflitantes

Sintoma: o agente mistura políticas antigas e novas.

Mitigações:

  • Filtros de metadados por data/versão
  • Preferir fontes canônicas (repositório de políticas) em vez de cópias
  • Detectar conflitos e reportá-los explicitamente

Relação com técnicas adjacentes de RAG

O RAG agentivo não substitui a engenharia de recuperação fundamental; ele se apoia nela.

Quando usar RAG agentivo (e quando não usar)

Use RAG agentivo quando:

  • As perguntas forem complexas, de múltiplas etapas ou ambíguas
  • Você precisar de alta fidelidade e rastreabilidade
  • Múltiplas fontes precisarem ser reconciliadas
  • O domínio tiver casos de borda de cauda longa (suporte, política, operações)

Prefira um RAG mais simples quando:

  • Consultas forem curtas, de busca de um único fato
  • Orçamentos de latência/custo forem extremamente apertados
  • Seu corpus for pequeno e a recuperação já for de alta precisão

Uma abordagem pragmática é o aprimoramento progressivo: comece com um RAG de base forte e só então adicione loops agentivos quando o sistema detectar baixa confiança ou falta de evidência.

Resumo

O RAG agentivo estende RAG com planejamento e controle: ele decompõe consultas, recupera iterativamente, critica as próprias respostas (auto-RAG) e escolhe dinamicamente estratégias e ferramentas de recuperação. Quando bem feito, melhora substancialmente cobertura, ancoragem e confiabilidade para tarefas do mundo real — ao custo de mais complexidade de engenharia, latência e trabalho de avaliação.

A chave para o sucesso é tratar o RAG agentivo como um sistema orientado por evidências: recupere com intenção, extraia com citações, critique lacunas e só então componha.