RAG com despachante: por que o chamado RAG agêntico nem sempre precisa de agentes autônomos

O problema dos loops que se acumulam

Nos últimos artigos de uma série sobre inteligência documental corporativa, a engenheira Angela Shi construiu padrões de loop um a um: reanalisar quando a checagem de uma página falha, uma segunda recuperação quando a resposta aponta para outra seção, uma varredura de agregação quando a pergunta pede uma lista completa. Cada padrão funciona sozinho. Mas perguntas reais não chegam um padrão por vez.

Veja uma pergunta que um oficial de conformidade faria de verdade sobre o NIST Cybersecurity Framework: “Quais são todas as Categorias sob GOVERN, e qual cobre risco de cadeia de suprimentos?”. Parece comum. Dentro do pipeline, ela dispara três padrões ao mesmo tempo: recuperação por índice (TOC), agregação de listagem e uma síntese para escolher o item certo. Cada um carrega sua própria mecânica de iteração. Rode-os na mesma pergunta e surge um problema prático: quem decide quando parar?

A resposta da moda hoje é entregar essa decisão a um agente e deixar o modelo orquestrar. Para um pipeline corporativo, a autora defende algo mais controlável: um despachante (dispatcher) que transforma a pergunta analisada e o perfil do documento em um plano explícito — e loops com limites escritos em código.

Cinco degraus de controle

O artigo se posiciona em uma escada de cinco níveis da mesma função de perguntas e respostas sobre PDFs. O primeiro nível (linha de base) encadeia os quatro blocos — análise do documento, análise da pergunta, recuperação e geração — uma única vez. O último nível (agêntico) move o controle para dentro do LLM, que escolhe o próximo passo sozinho. Este artigo para dois degraus abaixo, onde o pipeline ainda é reprodutível e auditável: o controle fica no código até o último salto.

O coração do artigo é a função pdf_qa_loop, que faz três coisas em ordem: lê a pergunta analisada e decide quais padrões ativar; executa os padrões ativos na ordem certa (TOC antes de keyword, recuperação primária antes de two-hop); e gerencia os loops de feedback — decidindo se itera e quantas vezes, com um orçamento compartilhado entre todos os loops e um teto rígido de quatro iterações.

Do RAG ingênuo ao RAG guiado por feedback

Um RAG ingênuo roda os quatro blocos em sequência e devolve o que sair. Se a recuperação errou o trecho certo, a resposta está errada; se a análise foi insuficiente, o LLM alucina em volta da lacuna — e o usuário nunca sabe.

O pipeline composto adiciona uma etapa de crítica ao final, com dois trilhos de feedback que retroalimentam quando o LLM sinaliza um problema: volta à recuperação quando a resposta está incompleta e volta à análise quando o contexto saiu desestruturado. A crítica lê campos estruturados produzidos pelo próprio LLM: o contexto está completo? o LLM descobriu novas palavras-chave? a análise foi suficiente?

Cada loop tem três dimensões: o sinal (o que o LLM ou uma checagem programática reporta), o gatilho (qual estado da saída inicia um retry) e a ação (o que o pipeline muda na próxima passada). Os sinais vêm de três fontes: autoavaliação do LLM, checagens programáticas (mais fortes, por não dependerem do julgamento do modelo) e validação externa (a mais cara).

Limitando os loops

O maior risco de pipelines iterativos é a iteração sem limite. O artigo define três controles:

• Iterações máximas: duas a três cobrem a grande maioria dos casos; além disso, os retornos caem rápido.
• Condições de parada: parar quando o mesmo gatilho dispara duas vezes com a mesma ação, quando a recuperação retorna as mesmas passagens, ou quando a confiança começa a cair.
• Detecção de deriva: a expansão de palavras-chave pode desviar a resposta do tema original — o exemplo clássico: o usuário perguntou sobre “premium”, o LLM viu “insurance”, expandiu para “policy”, depois “coverage”, depois “reinsurance”, e a resposta termina sobre economia de resseguros. A correção é manter a pergunta original no escopo a cada iteração: palavras expandidas somam, nunca substituem as âncoras originais.

Despachante versus agente autônomo

O artigo aponta que o termo “RAG agêntico” é usado de três formas diferentes. A primeira é marketing vazio. A segunda — controle guiado por feedback, com o LLM no sistema mas não no controle — é o que a autora construiu. A terceira é o agente autônomo, em que o LLM tem um conjunto de ferramentas e decide a cada passo qual chamar. A distinção entre a segunda e a terceira é a decisão de arquitetura que mais importa para RAG corporativo.

O agente autônomo é atraente na teoria — pode combinar ferramentas de formas que o engenheiro não previu. Na prática, para RAG empresarial, três coisas dão errado: a reprodutibilidade quebra (a mesma pergunta pode seguir caminhos diferentes, o que é desqualificante para auditoria e compliance); o custo explode (cada decisão de ferramenta é uma chamada ao LLM, um a dois ordens de magnitude mais caro); e a depuração vira adivinhação (é preciso ler rastros longos e incoerentes em vez de apontar a regra exata que falhou).

Autonomia tem seu lugar — quando o conjunto de ferramentas é aberto, o espaço de perguntas é variado demais e a reprodutibilidade não é requisito. Para RAG sobre documentos corporativos, o problema é bem compreendido, e o padrão do despachante captura esse conhecimento em código testável e auditável. O compromisso arquitetural, em uma frase: as decisões vivem no decide.py, não em um prompt do LLM em tempo de execução.