Uma pergunta sobre um manual interno pode seguir dois caminhos. Você envia o documento inteiro ao modelo de linguagem e pede uma resposta. Ou transforma o manual em fragmentos, procura os trechos mais relevantes e envia apenas esses pedaços junto com a pergunta.
A primeira opção parece ter vencido. Se a janela de contexto comporta centenas de milhares de tokens, por que ainda manter uma base vetorial, um pipeline de busca e toda a complexidade da geração aumentada por recuperação, conhecida pela sigla RAG?
Porque caber não significa ser barato, rápido ou confiável. A decisão correta depende de uma conta simples: quanto contexto cada pergunta precisa processar, com que frequência esse contexto muda e quanto custa errar.
A janela longa troca busca por leitura
Usar uma janela de contexto longa é como colocar todos os livros relevantes sobre a mesa antes de fazer uma pergunta. O modelo recebe o material completo, encontra relações entre partes distantes e responde sem depender de uma etapa externa de busca.
Isso resolve um problema importante. A recuperação precisa escolher os trechos certos antes que o modelo veja a pergunta em detalhes. Se o sistema buscar pelo termo errado, recuperar documentos antigos ou dividir mal um parágrafo, a resposta começa com informação incompleta. A janela longa elimina essa seleção inicial quando o corpus inteiro cabe no pedido.
O mecanismo por baixo é direto. O texto é convertido em tokens, esses tokens entram no mecanismo de atenção e o modelo calcula relações entre eles para produzir a resposta. Quanto mais texto entra, mais trabalho há para processar, mesmo que a resposta final tenha poucas palavras.
Aqui existe uma diferença que o marketing costuma esconder: tamanho máximo da janela é capacidade, não eficiência. Um modelo pode aceitar um volume enorme e ainda responder mais devagar, custar mais e perder detalhes no meio do material. Em alguns testes, modelos dão menos atenção a informações relevantes posicionadas no meio de contextos muito longos.
A recuperação comprime o problema antes da resposta
Na geração aumentada por recuperação, o sistema não entrega a biblioteca inteira ao modelo. Primeiro, quebra os documentos em fragmentos e transforma cada fragmento em um embedding, uma representação numérica do significado. A pergunta recebe tratamento semelhante. Uma busca por proximidade encontra os fragmentos mais parecidos, que então entram no contexto do modelo.
Pense nisso como pedir a um arquivista que separe cinco páginas antes de chamar alguém para explicar o assunto. O arquivista pode cometer um erro. Em troca, o especialista não precisa ler milhares de páginas a cada pergunta.
A base vetorial não armazena significado como uma pessoa armazena. Ela organiza vetores em um espaço matemático. Textos usados em contextos parecidos ficam próximos nesse espaço. A busca procura vizinhos, não respostas prontas.
Esse detalhe explica tanto a força quanto o limite do método. RAG reduz o volume enviado ao modelo e facilita a atualização: basta indexar novos documentos ou substituir os antigos. Mas a recuperação não entende a pergunta como um investigador entende. Ela pode encontrar um trecho semanticamente próximo, porém insuficiente para responder. Por isso, sistemas confiáveis combinam busca vetorial com filtros por data, categoria, permissões e, em alguns casos, busca por palavras exatas.
A conta muda a escolha
Suponha um corpus de 200 mil tokens e uma pergunta que precisa consultar esse material. Em uma arquitetura de janela longa, o modelo processa cerca de 200 mil tokens na entrada a cada consulta. Em uma arquitetura RAG, suponha que a busca recupere oito fragmentos de 500 tokens, mais 1.000 tokens para a pergunta, instruções e metadados. O contexto enviado ao modelo terá cerca de 5 mil tokens.
Com essas premissas ilustrativas, a diferença de entrada é de aproximadamente 40 para 1. Sob essa hipótese simplificada de proporcionalidade, a arquitetura com recuperação usará cerca de 40 vezes menos tokens por pergunta. Essa é uma conta ilustrativa, não uma tarifa universal. Modelos diferentes cobram e processam de maneiras diferentes, e a etapa de busca também consome recursos.
Agora inclua a latência. Suponha que a busca vetorial leve 80 milissegundos, a montagem do contexto leve 20 milissegundos e a geração leve 2 segundos. O fluxo RAG soma cerca de 2,1 segundos. Se a janela longa fizer a geração em 5 segundos por causa do contexto maior, a busca adiciona uma etapa, mas o sistema ainda termina mais rápido.
A conclusão muda se a base for pequena. Suponha um documento de 3 mil tokens, atualizado uma vez por mês e usado por poucas pessoas. Construir indexação, filtros, monitoramento e tratamento de falhas pode custar mais tempo de engenharia do que simplesmente enviar o documento inteiro. Nesse caso, a janela longa vence pela simplicidade.
Atualização é onde a diferença aparece
Um contexto fixo funciona bem quando o material muda pouco. Uma política interna, uma especificação técnica ou um contrato curto pode entrar inteiro no pedido. A resposta usa a versão fornecida, sem depender de um índice que precisa ser atualizado.
Em um corpus vivo, a recuperação ganha uma vantagem estrutural. Novos documentos podem ser incorporados sem retreinar o modelo. Um filtro pode impedir que páginas antigas apareçam. Permissões podem limitar a busca ao que cada pessoa pode consultar.
Isso não torna RAG automaticamente confiável. Se o índice mantiver duas versões conflitantes, o modelo ainda pode combinar as duas. Se o sistema não preservar data e origem de cada fragmento, fica difícil explicar por que determinada resposta apareceu. O problema deixa de ser apenas geração e passa a ser governança do conhecimento.
O que realmente mudou, e o que foi reembalado
A novidade real das janelas longas é permitir que o modelo raciocine sobre materiais maiores sem uma busca externa obrigatória. Isso pode ajudar em tarefas que dependem de relações espalhadas pelo documento, como comparar cláusulas distantes, revisar uma base de código inteira ou encontrar inconsistências entre seções. O resultado depende do modelo e da tarefa.
A novidade real do RAG não é dar memória ao modelo. É criar uma memória externa que pode ser atualizada, filtrada e auditada. O modelo continua sem saber o corpus permanentemente. Ele recebe uma seleção no momento da pergunta.
Dizer que uma janela enorme torna a recuperação obsoleta é exagero. Dizer que RAG resolve conhecimento externo é outro. Os dois caminhos movem o gargalo para lugares diferentes. A janela longa paga na leitura. A recuperação paga na seleção.
Use o corpus para escolher
Comece com quatro perguntas. O material inteiro cabe com folga no contexto? Ele muda raramente? As perguntas precisam cruzar muitas partes do corpus? O custo e a latência de enviar tudo são aceitáveis? Se as respostas forem sim, a janela longa é o caminho mais simples.
Se o corpus é grande, muda toda semana, exige controle de acesso ou recebe muitas consultas repetidas, essas características são sinais para avaliar primeiro uma arquitetura com recuperação; confirme a escolha com medições de qualidade, custo e latência. Um modelo que escreve muito bem a partir dos documentos errados continua errado.
Na prática, a melhor arquitetura também pode ser híbrida. Use busca para reduzir milhares de documentos a alguns candidatos e uma janela longa para comparar esses candidatos com cuidado. Essa combinação separa duas tarefas: localizar o material e raciocinar sobre ele.
A regra acionável é esta: não escolha pela maior janela anunciada. Estime os tokens enviados por consulta, conte quantas vezes o corpus muda e teste se a recuperação encontra os trechos necessários. Quando o documento é pequeno e estável, lembrar tudo é mais simples. Quando o conhecimento cresce e envelhece, recuperar passa a valer mais do que lembrar.
