RAG vs contexto longo: quando cada abordagem faz sentido na prática

Com janelas de contexto passando de um milhão de tokens em alguns modelos, apareceu uma pergunta razoável: se dá para simplesmente colar o documento inteiro no prompt, ainda vale a pena montar todo o aparato de busca vetorial do RAG? Às vezes sim, às vezes não, e a resposta depende de três coisas bem concretas: custo, atualização de dado e precisão.

Custo por consulta cresce diferente em cada abordagem

Enviar um documento inteiro dentro do contexto significa pagar pelo processamento daquele volume de token em toda consulta, mesmo que a pergunta específica só dependa de uma fração pequena daquele conteúdo. Em corpus grande, com muitas consultas, esse custo se acumula rápido, porque o mesmo contexto extenso é reprocessado repetidamente.

RAG desloca boa parte desse custo para uma etapa que acontece uma vez (gerar e armazenar embeddings do corpus inteiro), deixando cada consulta pagar só pelo processamento da pergunta e dos poucos trechos recuperados como relevantes. Isso tende a ser mais barato por consulta, especialmente à medida que o corpus cresce e o volume de consultas aumenta.

Vale registrar que cache de prompt, oferecido por vários provedores, reduz parcialmente essa desvantagem do contexto longo quando o mesmo documento extenso é reutilizado em múltiplas consultas seguidas sem mudar: parte do custo de processar aquele contexto pode ser amortizada entre chamadas, em vez de pago do zero a cada consulta. Isso não elimina a diferença de custo entre as duas abordagens, mas diminui a distância em cenários onde o mesmo contexto grande é consultado repetidamente num intervalo curto de tempo.

Atualização de dado: reindexar um trecho vs reenviar tudo de novo

Quando um documento específico muda, um pipeline RAG bem desenhado só precisa reprocessar e reindexar aquele documento, atualizando os embeddings correspondentes no vector store, sem tocar no resto do corpus. Colar o corpus inteiro num contexto longo, por outro lado, significa que qualquer consulta seguinte já usa a versão atualizada automaticamente, contanto que o texto enviado no prompt já reflita a mudança, o que exige montar esse contexto de novo a cada vez que algo muda, dependendo de como o corpus é gerenciado.

Em corpus que muda com pouca frequência, essa diferença importa menos. Em corpus que muda constantemente, reindexar seletivamente no RAG tende a ser mais barato do que remontar e reenviar um contexto gigante repetidamente.

Precisão degrada de formas diferentes em cada caso

Contexto muito longo tem um problema documentado: modelos tendem a prestar menos atenção em informação posicionada no meio de um contexto extenso, um efeito conhecido informalmente como “lost in the middle”. Isso significa que, mesmo com toda a informação relevante tecnicamente presente no prompt, o modelo pode falhar em usá-la corretamente se ela estiver posicionada numa parte do contexto que recebe menos atenção durante a geração.

RAG, ao recuperar só os trechos mais relevantes para aquela pergunta específica, reduz o volume total de contexto que o modelo precisa processar, o que tende a mitigar esse problema, desde que a etapa de busca realmente encontre os trechos certos. Se a busca falhar em recuperar a informação relevante, o modelo simplesmente não tem acesso a ela, o que é um modo de falha diferente (falta de informação) do modo de falha do contexto longo (informação presente, mas subutilizada).

Quando contexto longo realmente é a escolha mais simples

Para corpus pequeno, que cabe inteiro dentro da janela de contexto disponível sem chegar perto do limite, ou para uma tarefa pontual que não vai se repetir em volume, montar toda a infraestrutura de embedding e vector store do RAG pode ser complexidade desnecessária. Colar o documento inteiro no prompt, nesses casos, resolve o problema com menos peças móveis, mesmo pagando um pouco mais por consulta individual.

A pergunta que decide

O corpus é grande o suficiente para que reprocessá-lo inteiro em toda consulta pese no custo? Ele muda com frequência o bastante para que reindexação seletiva compense o esforço de manter um vector store? A precisão da tarefa depende de recuperar informação específica em meio a muito conteúdo irrelevante? Três respostas afirmativas apontam para RAG. Um corpus pequeno, estável e usado esporadicamente aponta para simplesmente colar tudo no contexto e seguir em frente.