Índice do artigofaltam 8 min de leitura
Numa pergunta com duas partes, a busca única trouxe material para uma delas e perdeu a outra inteira. Ao buscar as duas metades separadamente, a parte perdida apareceu em terceiro e a parte encontrada subiu de 14,60 para 19,49 de pontuação.
Um RAG comum tem um roteiro fixo: recebe a pergunta, faz uma busca, entrega os trechos ao modelo e pede a resposta. Esse roteiro funciona muito bem para a pergunta que a demonstração usa, que é curta, completa e sobre um assunto só.
A pergunta real quase nunca é assim. Ela tem duas partes, depende do que foi dito antes, exige comparar dois documentos, ou precisa de um número que não está em documento nenhum. Nesses casos, buscar uma vez e responder produz uma resposta parcial com aparência de completa, que é a pior categoria de erro.
RAG agêntico é a resposta de arquitetura para isso: em vez de receber um pacote pronto de trechos, o modelo passa a controlar a busca. Este artigo mostra onde a busca única quebra, com medição, e os cinco padrões que resolvem cada tipo de quebra.
Resumo do artigo
- A busca única falha de forma previsível: pergunta composta, pergunta de acompanhamento, comparação entre documentos e dado que vive em sistema.
- Recuperar mais trechos não resolve. Dobrar a lista de 10 para 20 comprou apenas 3,6 pontos percentuais de acerto.
- O padrão mais barato e de maior efeito é reescrever a pergunta com o contexto da conversa: medido, levou o top 3 de um resultado relevante para três.
- O preço do agêntico é previsibilidade. Custo e tempo passam a variar por pergunta, o que exige teto de iterações desenhado desde o começo.
A diferença, em uma frase
No RAG comum, o programa decide como buscar e o modelo só escreve. No RAG agêntico, o modelo decide como buscar, olha o que voltou e decide se precisa buscar de novo antes de escrever.
É uma mudança pequena de descrição e grande de consequência. O sistema deixa de ter um número fixo de passos e passa a ter um ciclo, que termina quando o modelo julga que tem material suficiente.
Isso melhora a resposta em pergunta difícil e traz de volta um problema que a arquitetura simples não tinha: um sistema cujo custo e cujo tempo de resposta variam de uma pergunta para a outra.
Onde a busca única quebra
Vale começar pelo que não resolve, porque é a primeira tentativa de todo mundo: recuperar mais trechos. Na nossa medição sobre 638 perguntas reais, dobrar a lista entregue ao modelo de 10 para 20 trechos aumentou o acerto de 74,9% para 78,5%, um ganho de 3,6 pontos percentuais.
O que essa curva achatada diz é que o material faltante não está mais fundo na mesma lista. Ele está fora daquela busca, e nenhuma quantidade de trechos da busca errada traz a resposta certa.
As quebras têm padrão, e reconhecê-lo é o que permite escolher a solução certa em vez de adicionar complexidade genérica.
- Pergunta composta"Vocês fazem X e como isso trata Y?" A metade mais rara vence e a outra some.
- Acompanhamento"E no caso do plano anual?" Sozinha, não aponta para lugar nenhum.
- Comparação"Qual a diferença entre as duas políticas?" Exige dois documentos completos, não trechos soltos.
- Dado de sistema"Qual o saldo do meu contrato?" A resposta está no ERP, não em texto.
- Vocabulário erradoO usuário chama de ticket o que o manual chama de ocorrência.
- Pergunta aberta"O que mudou na política este ano?" Não tem um documento alvo, tem vários.
Padrão 1: decompor a pergunta antes de buscar
Uma pergunta com duas partes vira uma busca só, e nessa busca as palavras das duas metades competem entre si. A metade com termos mais raros domina a pontuação, e a outra desaparece.
Testamos com a pergunta "vocês fazem chatbot com IA e como isso protege dados sensíveis", que é exatamente o formato que um cliente escreve.
| Consulta | O que voltou |
|---|---|
| Pergunta inteira, uma busca | Quatro dos cinco trechos sobre proteção de dados. A página do serviço de chatbot não apareceu |
| Só "vocês fazem chatbot com IA" | A página do serviço aparece em terceiro |
| Só "como proteger dados sensíveis em chatbot" | O artigo correto em primeiro e segundo, com pontuação 19,49 contra 14,60 da busca inteira |
Consultas ao índice do protótipo em 31/08/2026.
Dois efeitos aparecem juntos. A metade perdida volta a existir, e a metade encontrada melhora, porque a consulta deixou de ser diluída por termos de outro assunto. O modelo recebe material dos dois lados e consegue responder a pergunta inteira em vez de metade dela.
Na prática, o padrão é um passo barato antes da busca: um modelo pequeno lê a pergunta e devolve uma ou mais consultas, cada uma buscada separadamente, com os resultados reunidos depois.
Perguntas simples voltam com uma consulta só e o custo adicional é desprezível, o que torna o padrão seguro de aplicar em todas as perguntas em vez de tentar adivinhar quais precisam dele.
Padrão 2: reescrever a pergunta com o contexto da conversa
Este é o padrão de melhor relação entre esforço e resultado, e o mais esquecido nos protótipos, porque em teste manual ninguém faz a segunda pergunta.
Pegamos uma pergunta de acompanhamento real, do tipo que só faz sentido depois de uma resposta anterior, e comparamos a busca crua com a busca reescrita com o assunto da conversa.
O número do topo conta só parte da história. Com a pergunta crua, o primeiro resultado era relevante e os dois seguintes não tinham relação com o assunto. Com a pergunta reescrita, os três primeiros resultados eram relevantes.
Isso importa porque o modelo não recebe o primeiro resultado, recebe a lista inteira. Encher o contexto com dois trechos fora do assunto é convidar o modelo a misturar temas, e é uma das origens mais comuns de resposta confusa em conversa longa.
Padrão 3: buscar, avaliar o que veio, buscar de novo
Aqui começa o comportamento propriamente agêntico. Em vez de entregar os trechos direto para a redação, o sistema pergunta ao modelo se aquele material responde a pergunta. Se não responder, ele busca de novo com outras palavras.
O ganho característico deste padrão é resolver o problema de vocabulário sem banco vetorial. A primeira busca traz documentos parcialmente certos, e neles está a palavra que a empresa usa de verdade. A segunda busca usa essa palavra e acerta.
O risco característico é o ciclo que não converge. Se nenhuma tentativa satisfaz o avaliador, o sistema gasta várias chamadas para terminar sem resposta. Por isso o teto de tentativas e o comportamento de desistência precisam ser definidos antes, e a desistência precisa ser uma recusa honesta, não uma resposta improvisada com o melhor material ruim disponível.
Padrão 4: sair do documento e consultar o sistema
Boa parte das perguntas que chegam a um assistente corporativo não tem resposta em documento nenhum, porque a resposta é um dado que muda: status de pedido, saldo de contrato, vaga em estoque, data da próxima fatura.
Aqui o sistema deixa de ser só recuperação e passa a ter ferramentas: consultas a um ERP, a um CRM ou a uma API interna, que o modelo aciona quando a pergunta pede.
A divisão de trabalho é clara e vale escrever no desenho: o documento continua explicando a regra, e o sistema fornece o número. Misturar os dois papéis, tentando manter valores que mudam dentro de documentos, é o caminho mais rápido para uma base desatualizada.
Essa capacidade é a que mais amplia o que o assistente resolve sozinho, e também a que mais muda o perfil de risco do projeto.
A regra de desenho que reduz esse risco é manter as ferramentas estreitas. Uma consulta que recebe o identificador do contrato e devolve três campos é auditável. Uma ferramenta que aceita uma consulta livre ao banco não é.
Padrão 5: verificar a própria resposta antes de entregar
O último padrão é uma passada de conferência: antes de mostrar a resposta, o sistema checa se cada afirmação tem lastro em algum dos trechos recuperados, e remove ou marca o que não tiver.
É o padrão mais caro por resposta, porque duplica o trabalho de redação, e é o que mais faz sentido em contexto de risco, como jurídico, saúde, financeiro e resposta a auditoria. Em atendimento comum, ele costuma custar mais do que vale.
Vale notar o que ele não faz: ele confere se a resposta corresponde ao material recuperado, não se o material está correto. Se o documento recuperado estiver desatualizado, a verificação aprova com folga. Ela é defesa contra o modelo extrapolar, não contra base errada.
O que o agêntico custa
A troca é sempre a mesma: qualidade em pergunta difícil, paga com previsibilidade.
| O que muda | RAG simples | RAG agêntico |
|---|---|---|
| Chamadas ao modelo por pergunta | Uma, mais o filtro de escopo | Variável, uma por volta do ciclo |
| Tempo de resposta | Estável | Varia com o número de voltas |
| Custo por pergunta | Previsível | Depende da pergunta, precisa de teto |
| Depuração quando erra | Direta, um caminho só | Exige registrar cada decisão do ciclo |
| Superfície de segurança | Leitura de documentos | Cresce muito quando há ferramentas |
A linha da depuração é a que mais surpreende as equipes. Num sistema de passo fixo, investigar uma resposta ruim é olhar o que foi recuperado. Num sistema agêntico, é preciso reconstruir a sequência de decisões que o modelo tomou, e isso só existe se o registro tiver sido construído junto com o sistema, não depois.
Onde compensa e onde é exagero
Compensa
- A pergunta típica tem mais de uma parte
- O uso é conversacional, com acompanhamento
- Parte das respostas vive em sistema, não em texto
- O vocabulário do usuário difere do dos documentos
- O custo de uma resposta errada é alto
É exagero
- As perguntas são curtas, diretas e sobre um assunto só
- O uso é de consulta pontual, sem conversa
- A base ainda não responde bem nem às perguntas simples
- Não existe conjunto de avaliação para provar o ganho
- O tempo de resposta é requisito rígido do produto
O terceiro item da coluna direita é o mais importante e o mais ignorado. Se o RAG simples ainda erra por falta de conteúdo, e essa é a causa mais comum, o agêntico vai buscar mais vezes a mesma informação inexistente, com mais custo e mais demora. Complexidade não cria conteúdo.
O que precisa estar pronto antes
- Um RAG simples funcionando, com números medidos que sirvam de linha de base
- Um conjunto de perguntas reais que roda a cada mudança, para provar que a complexidade melhorou algo
- Teto de iterações e de gasto por pergunta, decididos antes de ligar o ciclo
- Registro do que o sistema decidiu em cada volta, sem o qual não há como investigar uma resposta ruim
- Comportamento de desistência definido, com texto de recusa em vez de improviso
A ordem de adoção que funciona é incremental, e cada passo é verificável sozinho: primeiro a reescrita com contexto, depois a decomposição, depois o ciclo de busca, e só então ferramentas e verificação. Pular direto para o final produz um sistema difícil de depurar cujo ganho ninguém consegue demonstrar.
Fontes e método
As medições vêm de um protótipo de recuperação sobre o conteúdo público da X-Apps, executado em 31 de agosto de 2026, com 374 documentos e 2.563 trechos. A avaliação de recall usou 638 perguntas escritas pelo time de conteúdo com documento de origem conhecido.
As comparações de decomposição e de reescrita com contexto são consultas diretas ao índice, feitas na mesma data, e estão reproduzidas no texto com as pontuações obtidas.
Duas ressalvas de alcance. A primeira é que estas medições avaliam recuperação, e o efeito dos padrões sobre a qualidade final da resposta escrita não foi medido aqui. A segunda é que os padrões 3, 4 e 5 são descritos como decisões de arquitetura, com base no que a medição de falha justifica, e não acompanham medição própria de desempenho em produção.
Perguntas frequentes
É um sistema em que o modelo controla o processo de busca em vez de receber um pacote pronto de trechos. Ele pode dividir a pergunta, buscar de novo com outras palavras, consultar um sistema além dos documentos e avaliar se já tem material suficiente antes de responder.
O RAG comum busca uma vez e responde. O agêntico decide quantas buscas fazer e quais, com base no que encontrou. A troca é qualidade em pergunta complexa por custo, tempo de resposta e previsibilidade.
Em pergunta com duas partes, em pergunta de acompanhamento que depende do contexto da conversa, quando a resposta exige comparar documentos, e quando parte da resposta está num sistema e não num texto.
Porque o ganho satura. Na nossa medição, dobrar a lista de 10 para 20 trechos aumentou o acerto em apenas 3,6 pontos percentuais. O que falta normalmente não está mais fundo na lista, está fora daquela busca.
Sim. Cada volta do ciclo é uma chamada ao modelo, e o número de voltas varia por pergunta. Isso torna o custo e o tempo de resposta menos previsíveis, o que precisa entrar no desenho com teto de iterações e limite de gasto.
Pela reescrita da pergunta com o contexto da conversa, que é o padrão mais barato e o de maior efeito imediato. Só depois vale adicionar decomposição e busca iterativa.
Não, e começar por ele costuma atrapalhar. Sem um RAG simples medido antes, não há como saber se a complexidade adicional resolveu alguma coisa ou apenas encareceu o sistema.
