Um agente recebe a tarefa: investigar por que uma função falha, encontrar os arquivos envolvidos e propor uma correção. O repositório tem mil documentos. A resposta intuitiva seria entregar tudo ao modelo e esperar que ele encontre o caminho certo. Na prática, isso transforma uma pergunta objetiva em uma pilha de texto cara, lenta e difícil de controlar.
O mecanismo que torna agentes úteis é outro: recuperação dirigida. O agente procura sinais, aplica filtros, lê pequenos trechos e só amplia a busca quando a evidência pede. Ele não trata o repositório como um livro que precisa ser lido do começo ao fim. Trata-o como uma cidade: primeiro encontra o bairro, depois a rua, depois a porta.
O primeiro passo é descobrir que tipo de busca fazer
Em algumas arquiteturas, a recuperação começa antes da busca vetorial. O agente precisa interpretar a tarefa e transformá-la em perguntas menores.
Se o pedido é “descubra por que o relatório mensal ficou diferente”, há várias buscas possíveis escondidas ali: qual relatório mudou, em que período, quais consultas o alimentam, quais dados de entrada foram alterados e onde o resultado é calculado.
Essa decomposição é importante porque uma única consulta semântica costuma ser ampla demais. Ela pode encontrar documentos que falam de “relatório”, mas não necessariamente o código que calcula o indicador. O agente cria então uma sequência de consultas, cada uma com uma finalidade.
Aqui já aparece uma diferença essencial entre um chatbot e um agente. O chatbot responde ao contexto que recebeu. O agente decide qual contexto ainda precisa obter.
Esse comportamento é recorrente em sistemas que usam ferramentas: o modelo alterna entre pensar sobre a próxima ação, chamar uma ferramenta, observar o resultado e revisar o plano. A autonomia não está em saber tudo. Está em saber qual pergunta fazer em seguida.
A busca vetorial encontra significado, não prova
Para procurar informação sem comparar palavra por palavra, os documentos são transformados em embeddings. Cada trecho vira uma representação numérica que aproxima conteúdos semanticamente parecidos.
Uma consulta sobre “erro no cálculo de receita recorrente” pode encontrar um trecho que fala em “totalização de contratos ativos”, mesmo sem repetir os mesmos termos. Essa é a força da busca vetorial: ela recupera ideias próximas.
Mas ela também tem um limite. Similaridade não é relevância garantida. Dois trechos podem falar do mesmo assunto e tratar de versões, ambientes ou regras diferentes. Um comentário antigo pode parecer tão relevante quanto o código atual.
Por isso, o agente combina a busca vetorial com filtros estruturados. Metadados como caminho do arquivo, extensão, data de atualização, ambiente, linguagem e tipo de documento funcionam como placas de trânsito. Eles reduzem o espaço de busca antes que o modelo precise ler.
Uma investigação pode procurar semanticamente por “cálculo de receita”, restringir os resultados a arquivos de consulta e código, eliminar documentos arquivados e priorizar o diretório responsável pelo relatório. O embedding sugere onde olhar. O filtro impede que o agente se perca em lugares plausíveis, mas errados.
O repositório vira um mapa em camadas
A recuperação funciona melhor quando o agente não recebe apenas trechos soltos. Ele precisa de uma estrutura que mostre relações.
Primeiro vêm os índices baratos: nomes de arquivos, símbolos, títulos, tags e metadados. Depois, os embeddings ajudam a encontrar conteúdo parecido. Em seguida, o agente lê partes pequenas dos documentos recuperados. Só então ele decide se precisa abrir o arquivo inteiro, seguir uma referência ou fazer uma nova busca.
Essa ordem é a leitura incremental. Ela parece simples, mas muda o custo do sistema. Um arquivo pode ter uma função cujo nome resolve a pergunta imediatamente. Outro pode exigir a leitura de uma definição, depois de uma configuração e, por fim, de um teste.
O agente não sabe tudo isso de antemão. O agente ajusta a rota conforme observa os resultados. Se um trecho menciona outra função, a próxima ação é procurar essa função. Se dois arquivos discordam, ele busca a versão mais recente ou procura testes que indiquem qual regra vale.
A analogia com uma biblioteca ajuda, mas falha em um ponto: o agente não segue apenas o catálogo. Ele também formula novas consultas com base no que encontrou. O mapa muda durante a investigação.
A conta mostra por que ler tudo é uma má ideia
Considere um cenário ilustrativo. Suponha que cada um dos mil documentos tenha 2 mil tokens. Uma leitura completa exigiria cerca de 2 milhões de tokens antes mesmo de o agente raciocinar sobre o problema.
Agora suponha que a recuperação encontre 20 documentos, cada um com 2 mil tokens, e que o agente leia apenas 3 trechos de 500 tokens em cada documento antes de escolher 4 arquivos para inspeção mais profunda. A primeira triagem consumiria cerca de 30 mil tokens. Mesmo somando 8 mil tokens para os arquivos escolhidos, o total ficaria perto de 38 mil tokens.
A conta não prevê o desempenho de um sistema real. Ela mostra a ordem de grandeza: 38 mil tokens são muito menos que 2 milhões. O ganho não vem de uma mágica no modelo. Vem de não pagar pela leitura de informação que provavelmente não participa da resposta.
Também existe latência. Se cada chamada a uma ferramenta levar 300 milissegundos e o agente fizer 8 consultas sequenciais, só a comunicação adiciona cerca de 2,4 segundos. Se cada rodada de inferência levar 2 segundos e houver 5 rodadas, são mais 10 segundos. Um fluxo inteligente pode ser mais barato que a leitura completa e ainda assim parecer lento quando faz muitas decisões em série.
Esse é o ponto que apresentações de agentes costumam esconder: recuperação reduz o volume de contexto, mas planejamento e ferramentas também custam tempo.
O que realmente muda quando a recuperação participa da ação
A busca deixa de ser uma etapa isolada. Ela passa a decidir o próximo passo.
Um agente que recupera informação de modo passivo apenas adiciona trechos ao prompt. Um agente que recupera informação para agir usa o resultado para escolher entre abrir um arquivo, executar um teste, consultar um banco de dados ou pedir esclarecimento ao usuário.
Isso resolve problemas concretos. Em desenvolvimento, reduz a quantidade de código irrelevante antes de uma alteração. Em análise de documentos, separa políticas vigentes de versões antigas. Em operações, combina eventos recentes com filtros de ambiente e serviço. Em todos esses casos, a recuperação organiza a atenção do agente.
O que é novo não é a busca semântica isolada. Também não é a janela de contexto maior. A mudança está na combinação entre recuperação, ferramentas e um ciclo de decisão que pode continuar até a evidência ser suficiente.
Chamar isso de “entendimento completo do repositório” seria exagero. O agente não constrói automaticamente uma representação perfeita de tudo. Ele constrói uma hipótese local sobre o problema e tenta confirmá-la.
O erro mais perigoso acontece antes da resposta
O maior risco não é o agente esquecer um detalhe que leu. É nunca recuperar o detalhe certo.
Um índice mal dividido pode separar uma função da configuração que define seu comportamento. Metadados desatualizados podem fazer o agente priorizar um arquivo removido. Um filtro rígido pode excluir justamente o documento que explica a exceção. Quando isso ocorre, o modelo produz uma resposta coerente baseada em um contexto incompleto.
Por isso, a qualidade de um agente depende de métricas que vão além da resposta final. É preciso medir se o trecho correto apareceu entre os primeiros resultados, quantas chamadas foram necessárias, quantas vezes o agente repetiu uma busca e em que ponto uma pessoa precisou intervir.
Também vale registrar o caminho da recuperação. Um agente confiável deve mostrar quais documentos consultou, quais filtros aplicou e por que decidiu seguir determinada pista. A aprovação humana protege ações perigosas, mas não corrige uma busca que nunca encontrou a evidência relevante.
Uma direção possível é buscar menos e formular consultas melhores
A tendência mais importante não é colocar repositórios cada vez maiores dentro do contexto. É construir agentes que aprendam a reduzir a incerteza com consultas menores.
Isso favorece arquiteturas híbridas: índices estruturados para localização exata, embeddings para semelhança, grafos ou referências para relações e leitura incremental para confirmação. Cada mecanismo responde a uma pergunta diferente. Nenhum deles resolve o problema sozinho.
Na prática, um bom projeto começa com uma regra simples: antes de aumentar o modelo, melhore o caminho que leva a informação até ele. Defina quais metadados existem, divida os documentos em unidades que preservem sentido, registre as relações entre símbolos e permita que o agente amplie a busca quando a evidência for fraca.
O agente autônomo não é aquele que lê tudo sem ajuda. É aquele que transforma um espaço enorme em uma sequência curta de perguntas verificáveis. Quando essa sequência funciona, a autonomia pode ser percebida como comportamento inteligente. Quando falha, o modelo apenas age com confiança dentro do pedaço errado do mundo.
