Quem deu o RAG por morto se enganou
Em 2024 e 2025 virou moda anunciar o fim do Retrieval-Augmented Generation. O argumento: se um modelo processa um milhão de tokens de uma vez, basta jogar o corpus inteiro no contexto e dispensar toda a ginástica com banco vetorial.
Na prática, nada disso aconteceu. Contextos longos são caros, lentos e — a parte que costuma ficar de fora do discurso — não são tão robustos em qualidade quanto os slides de marketing sugerem. Os modelos até encontram a agulha no palheiro de 800 mil tokens com surpreendente frequência, mas raciocinam pior sobre o que encontram à medida que mais ruído se acumula ao redor.
Ainda assim, o RAG que construíamos em 2023 está obsoleto em quase todo lugar. Top-k vetorial ingênuo produz resultados piores do que os novos padrões — e nem sequer é mais barato. O que mudou não é o direito do RAG existir, e sim a receita.
Como era o RAG ingênuo
Vale lembrar, porque muitos sistemas ainda são exatamente assim: os documentos são fatiados em chunks de 500 tokens, cada chunk passa por um modelo de embedding, os vetores vão para um banco. Na consulta, a própria pergunta é embebida, os cinco vizinhos mais próximos são puxados, despejados no prompt, pronto.
Essa receita funciona para FAQ bots simples. Para qualquer outra coisa, ela rui nas bordas:
Contexto perdido entre chunks: A frase decisiva está no chunk 3, a definição do termo está no chunk 1. O top-k traz o chunk 3, o modelo alucina a definição.
Vizinhos errados: Similaridade vetorial não é relevância semântica. Uma pergunta sobre „prazos de rescisão" traz parágrafos sobre demissão de funcionários porque são lexicalmente próximos, embora o direito contratual esteja falando de outra coisa.
Fragilidade à formulação: Quem pergunta „Como cancelo?" recebe resultados diferentes de quem pergunta „direito de devolução" — embora a resposta devesse ser a mesma.
Nenhuma iteração: Um único passo de busca só vê o que a pergunta original entrega. Pesquisas reais exigem várias rodadas.
Os padrões que sustentam em 2026
Retrieval agêntico
Em vez de buscar uma vez e queimar o resultado, deixamos o próprio modelo decidir quando e o que buscar. A busca vira uma ferramenta que o agente chama tantas vezes quanto precisar. Uma primeira busca traz pistas grosseiras, o modelo formula consultas de acompanhamento mais precisas, vai mais fundo.
Isso é significativamente mais caro por requisição — e significativamente melhor em perguntas não triviais. Para tarefas de pesquisa, revisão jurídica ou suporte técnico, virou padrão.
Retrieval hierárquico
Indexamos em dois níveis: um resumo por documento e o texto completo. A busca roda primeiro sobre os resumos — é rápida e acerta o documento certo. Só depois olhamos em detalhe dentro dos documentos selecionados.
O efeito: o modelo nunca perde o rastro de onde veio um trecho, e o contexto de um parágrafo permanece intacto. Para corpora estruturados — contratos, manuais, literatura científica — é um salto de qualidade enorme.
Busca híbrida com reranker
A busca vetorial sozinha perde para o clássico BM25 no instante em que entram nomes próprios, números de processo ou termos raros. Quem busca „acórdão 4 AZR 123/24" não quer comparação de embeddings — quer um match exato.
A solução é simples e antiga: rodar BM25 e busca vetorial em paralelo, fundir os resultados, depois passar um reranker por cima. Rerankers são modelos menores que atribuem uma pontuação de relevância a um par pergunta-documento. Custam latência, mas empurram para o topo os hits realmente relevantes. Em todo projeto em que adicionamos um reranker, a qualidade da resposta deu um salto perceptível.
Documentos inteiros em vez de chunks
Quando a janela de contexto permite, deixamos de buscar chunks e passamos a buscar documentos inteiros. Um contrato de 30 páginas cabe confortavelmente em 200 mil tokens. O modelo vê o contrato como um advogado veria — com preâmbulo, definições e letras miúdas.
Isso elimina a maior fraqueza do RAG clássico: o contexto perdido. O pré-requisito é que a camada de retrieval encontre o documento certo. Busca hierárquica e híbrida existem exatamente para isso.
Context caching para corpora estáveis
Provedores como Anthropic e Google cobram pelo input em cache muito mais barato do que pelo input fresco. Para corpora que mal mudam — manuais de produto, obras jurídicas de referência, bases de código — dá para manter grandes partes em cache permanentemente e pagar uma fração por requisição.
Em dois projetos em andamento, reduzimos os custos de inferência entre 60 e 80 por cento dessa forma, sem mudar fundamentalmente a arquitetura. Context caching é uma das alavancas subestimadas do ano.
A matriz de decisão
Quando usar o quê? A regra prática que aplicamos internamente:
Contexto longo, quando: O corpus relevante é pequeno e estável, cada requisição pode precisar acessar tudo, e há tolerância a latência. Exemplo: um whitepaper de 50 páginas sobre o qual um bot responde perguntas.
RAG, quando: O corpus é grande demais, muda com frequência, ou apenas uma parte pequena e dinamicamente escolhida é relevante por requisição. Exemplo: um hub interno de conhecimento com dezenas de milhares de documentos.
Fine-tuning, quando: Não se trata de conhecimento factual, mas de estilo, formato ou comportamento. Fine-tuning é surpreendentemente ruim para ensinar fatos novos e surpreendentemente bom para fazer um modelo escrever de forma consistente em um tom específico.
Na maioria dos sistemas reais, combinamos dois ou três desses. RAG puro ou contexto longo puro são exceção.
Erros comuns
Idolatria do banco vetorial: A escolha do banco vetorial quase nunca é o gargalo. Pinecone vs. Weaviate vs. Postgres com pgvector — praticamente não muda a qualidade da resposta. O que importa é a lógica de retrieval por cima.
Caça por embeddings melhores: Um novo modelo de embedding pode trazer dois a cinco por cento em benchmarks. Retrieval hierárquico, um reranker ou um segundo passo de busca costumam trazer dez vezes isso.
Avaliação como pensamento posterior: Sem um conjunto de avaliação contra perguntas reais, toda otimização vira intuição. Cem pares de pergunta-resposta curados à mão a partir do caso de uso real valem mais do que qualquer benchmark sintético.
Otimização excessiva de chunking: Horas gastas afinando o tamanho perfeito de chunk rendem menos do que meio dia gasto numa estrutura de índice melhor. Chunks são detalhe de implementação, não fundamento de arquitetura.
Na nh labs
Hoje praticamente não construímos mais sistemas de RAG como um setup puro de top-k vetorial. O stack padrão é retrieval hierárquico com busca híbrida, reranker, loop agêntico para consultas mais complexas e context caching para as partes do corpus que não mudam com frequência. Soa mais complexo do que é — a maioria desses componentes hoje está disponível como biblioteca pronta ou serviço gerenciado.
Mais importante do que o stack é a disciplina em torno da avaliação. Sem um conjunto de perguntas reais contra o qual medir cada mudança, constrói-se no escuro. Com avaliação no lugar, a iteração é rápida e as melhorias são mensuráveis.
Conclusão
RAG não está morto, mas a receita de 2023 está. Janelas de contexto longas ampliaram a caixa de ferramentas, não a substituíram. Quem está construindo hoje deveria começar com retrieval hierárquico, busca híbrida e um reranker — e tratar contexto longo como complemento dirigido, não como substituto. Os sistemas que rodam bem em produção em 2026 não são os com a maior janela de contexto ou o embedding mais caro. São os com a lógica de retrieval mais bem pensada e uma avaliação honesta. As duas coisas já eram necessárias dois anos atrás — só pesam mais agora.