RAG agêntico substitui um retrieval único por um loop: o modelo busca, lê, decide que precisa de mais, busca de novo, e repete até se satisfazer. Cada salto é uma ida e volta completa ao modelo mais uma busca, e os saltos são sequenciais porque cada um depende do anterior. Para a maioria das perguntas, isso compra uma resposta marginalmente melhor a várias vezes a latência, quando uma query bem construída teria retornado o mesmo contexto em uma única passada. Retrieval multi-hop é uma ferramenta real para uma classe estreita de perguntas, e um padrão que silenciosamente triplica seu tempo de resposta em todo o resto.

O reenquadramento: retrieval agêntico troca latência pela capacidade de decompor uma pergunta em tempo de execução. Essa troca só vale a pena quando a pergunta realmente precisa ser decomposta. A maioria não precisa, e pagar o imposto do loop em perguntas que uma única query responde é a forma mais comum de sistemas de RAG ficarem lentos sem ganho nenhum.

De onde vem a latência

RAG de passada única é um embedding, uma busca vetorial, uma chamada de modelo. RAG agêntico é um loop, e o loop é serial por construção: o modelo não consegue emitir a segunda query até ter lido os resultados da primeira. Então o custo em tempo real não é uma busca mais uma geração, é a soma da busca de cada salto, da chamada de modelo de cada salto para decidir o próximo passo, e a geração final. Três saltos são aproximadamente três vezes as idas e voltas, e como cada chamada de modelo também relê o contexto acumulado, o custo por salto tende a crescer em vez de ficar estável.

Nada disso é trabalho oculto que o usuário pediu. Do lado dele, é uma pergunta que agora leva oito segundos em vez de dois. Se esses oito segundos não compraram uma resposta materialmente melhor, você gastou seu orçamento de latência em nada.

Uma boa query vence um loop esperto, geralmente

Uma quantidade surpreendente de RAG agêntico existe para compensar uma primeira query fraca. Se o retrieval inicial puxa os chunks errados, o trabalho do loop vira "perceber que o contexto está ruim e ir buscar um contexto melhor", que é uma recuperação de erro cara. Conserte a query e o loop muitas vezes não tem mais nada a fazer.

Antes de recorrer ao multi-hop, gaste o esforço na passada única:

  • Reescreva a query. Uma chamada de modelo barata para transformar uma pergunta bagunçada do usuário em uma query de busca limpa melhora o retrieval mais do que um segundo salto, a uma fração da latência.
  • Recupere mais, depois reordene. Puxe um conjunto de candidatos mais amplo em uma busca e reordene-o, em vez de fazer várias buscas estreitas em sequência.
  • Conserte os chunks. A maioria dos retrievals ruins é um problema de chunking. Chunks melhores fazem a primeira query acertar, e o loop se torna desnecessário.

Todas essas são melhorias de passada única. Elas elevam a qualidade da resposta sem adicionar uma ida e volta serial, que é o oposto do que o loop faz.

Quando retrieval agêntico realmente vence

O loop compensa sua latência para perguntas que genuinamente não podem ser respondidas por uma única query, porque a segunda query depende da resposta da primeira. O caso mais claro é raciocínio multi-hop sobre fatos que você precisa encadear: "quais dos nossos fornecedores na região afetada pela nova regulação estão prontos para renovação neste trimestre" é, na verdade, três buscas em que cada uma restringe a próxima, e nenhum retrieval único guarda a resposta combinada.

O padrão a procurar é uma dependência genuína entre buscas: você não consegue escrever a segunda query até saber o resultado da primeira. Quando essa dependência é real, o loop está fazendo trabalho necessário e a latência é o preço de uma resposta que você não conseguiria de outra forma. Quando está ausente, e geralmente está, o loop é maquinaria elaborada para uma pergunta que uma única query teria resolvido.

Decida por pergunta, não por sistema

A falha é fazer do retrieval agêntico o padrão para toda requisição. Um design melhor roteia: perguntas baratas seguem a passada única, e só perguntas que mostram um sinal de decomposição, múltiplas entidades, uma condição encadeada, um "comparar entre" explícito, escalam para o loop. Um pequeno classificador ou até uma heurística na frente do retrieval pode tomar essa decisão. O objetivo é pagar o imposto do multi-hop exatamente nas perguntas que ele compensa, e nunca nas que não compensa.

A conclusão

RAG agêntico não está errado, está superaplicado. Ele transforma retrieval em um loop serial de idas e voltas ao modelo, e para a grande maioria das perguntas que uma boa query única responde, esse loop é latência pura. Gaste seu esforço primeiro na passada única: reescreva a query, recupere mais amplo e reordene, e conserte os chunks. Reserve o multi-hop para perguntas com uma dependência real entre buscas, e roteie para ele por pergunta em vez de colocar o sistema inteiro nesse padrão por default. O sistema de RAG mais rápido é aquele que só faz loop quando a pergunta realmente exige um segundo olhar.

Leia isso a seguir

Para a infraestrutura por trás de retrieval de baixa latência em escala, as notas de campo de cloud estão em ercan.cloud, e o hub fica em ercanermis.com.