RAG ou contexto longo: mandar tudo pode acertar mais e custar pior

Enviar documentos inteiros pode melhorar a resposta quando a pergunta depende de relações entre passagens distantes e o conteúdo relevante cabe na janela do modelo. Para um acervo grande, atualizado com frequência ou consultado muitas vezes, RAG tende a reduzir o volume enviado por pergunta. A documentação do Gemini API descreve janelas de 1 milhão de tokens ou mais, mas alerta que localizar várias informações dispersas pode reduzir a precisão e que processar grandes entradas tem custo a cada consulta.

A vantagem de qualidade também muda conforme a tarefa. Na avaliação de Xinze Li e coautores, o contexto longo superou RAG em geral nos testes de perguntas e respostas, sobretudo nos baseados na Wikipédia; RAG teve vantagem em consultas gerais e diálogos. A recuperação baseada em resumos chegou perto do contexto longo, enquanto a recuperação por trechos curtos ficou atrás. A escolha, portanto, depende tanto da pergunta quanto da qualidade da busca usada na comparação.

Quando ler o documento inteiro ajuda

O texto integral mantém a ordem da argumentação, as definições e as ressalvas próximas de suas referências. Isso importa quando a resposta exige reunir condições espalhadas por capítulos, acompanhar uma mudança de posição ao longo de um relatório ou interpretar uma conclusão à luz do método descrito antes. Uma busca que encontra só a passagem com os termos da pergunta pode omitir a exceção que altera seu sentido.

O requisito é que o conjunto relevante caiba na janela, junto com instruções, histórico da conversa, pergunta e espaço para a resposta. Caber tecnicamente não garante a mesma precisão para todas as perguntas: a dificuldade aumenta quando é preciso localizar várias peças de informação. Enviar documentos alheios à tarefa também eleva a entrada processada sem necessariamente acrescentar evidência útil.

Há uma diferença entre ler integralmente um documento e enviar todo o acervo. Se a base contém muitos arquivos, mas a pergunta pede uma síntese de apenas um deles, a aplicação pode localizar esse arquivo primeiro e entregá-lo inteiro ao modelo. Assim preserva as relações internas do documento sem cobrar a leitura dos demais a cada pergunta.

Quando recuperar passagens faz mais sentido

RAG busca conteúdo antes da geração e inclui no prompt apenas as partes selecionadas. A análise técnica da Anthropic sugere o envio integral para bases menores que 200 mil tokens e descreve, para bases maiores, uma recuperação que combina busca semântica com correspondência lexical por BM25. Esse tamanho é uma orientação para o cenário apresentado pela empresa, não um limite universal entre as arquiteturas.

A busca é especialmente útil quando a maior parte das perguntas trata de uma regra, um termo técnico ou uma passagem localizada em uma base extensa. Em acervos que mudam, os documentos alterados precisam ser atualizados no índice; depois, a consulta pode selecionar a versão pertinente sem transportar todo o conteúdo novamente. Identificadores de documento e posição da passagem também facilitam mostrar de onde veio uma afirmação, embora uma citação só seja confiável se o trecho recuperado realmente a sustentar.

O ponto fraco aparece antes de o modelo responder: se a busca deixar a informação correta de fora, a geração não poderá usá-la. Um trecho isolado pode perder o nome do documento, a data de vigência ou a condição que restringe uma regra. Trechos maiores, contexto acrescentado a cada passagem, busca lexical combinada com semântica e reordenação dos resultados podem reduzir essa perda, mas adicionam trabalho de preparação ou custo por consulta.

Matriz de decisão para o acervo

As dimensões abaixo funcionam em conjunto. O tamanho total da base define a necessidade de seleção; o tamanho do conteúdo exigido por cada resposta ajuda a escolher quanto enviar depois da busca.

• Tamanho do corpus: se o material relevante cabe com folga no prompt, o envio integral é viável. Se apenas uma fração cabe, RAG precisa selecionar documentos ou passagens. Uma base grande ainda pode justificar a leitura integral de um arquivo recuperado.
• Frequência de atualização: conteúdo estável favorece reutilizar o mesmo contexto, sobretudo quando há cache. Mudanças frequentes exigem comparar o custo de atualizar o índice com o de recriar ou reenviar o contexto integral.
• Número de consultas: poucas perguntas sobre uma base pequena podem não compensar a construção de um índice. Em consultas repetidas, a diferença entre processar o acervo inteiro e processar somente as partes recuperadas se acumula.
• Tipo de pergunta: sínteses que cruzam passagens distantes favorecem testar o documento completo. Perguntas localizadas, termos exatos, consultas gerais e diálogos exigem avaliar a recuperação apropriada; um único resultado médio não representa todos esses casos.
• Exigência de citação: RAG pode transportar com cada passagem sua origem e posição. Com o texto integral, também é possível produzir referências, mas a aplicação precisa conferir se apontam para a evidência certa.

Essa matriz evita tratar a janela máxima como meta de uso. Ela também mostra por que uma configuração de RAG baseada apenas em pequenos trechos sem contexto pode parecer pior que o envio integral por uma razão corrigível: a passagem necessária existe na base, mas não chega completa ao modelo.

Quanto custa uma sessão

No estudo de Zhuowan Li e coautores, o contexto longo obteve melhor desempenho médio quando recebeu recursos suficientes, enquanto RAG manteve vantagem de custo; os pesquisadores também avaliaram encaminhar perguntas entre as duas rotas. Para traduzir essa diferença em orçamento, compare uma sessão com perguntas e respostas equivalentes, usando a mesma unidade de preço por token.

Defina N como o número de perguntas, D como os tokens do conteúdo integral, r como a média de tokens recuperados por pergunta, q como os demais tokens médios de entrada e o como os tokens médios de saída. Chame de pE o preço do token de entrada comum, pC o do token de entrada servido pelo cache e pS o do token de saída. Se todo D puder ser reutilizado pelo cache durante a sessão, a conta simplificada é contexto longo = H + N × (D × pC + q × pE + o × pS). Para a recuperação, use RAG = I + U + N × (B + (r + q) × pE + o × pS).

H reúne criação e armazenamento do cache; I é a indexação, U representa as atualizações e B inclui busca e eventual reordenação por pergunta. Sem cache, H é zero e pC deve ser igual a pE. Se índice ou cache servirem várias sessões, seus custos devem ser distribuídos entre elas; falhas de cache fazem parte de D voltar ao preço de entrada comum. A fórmula ainda deixa de fora diferenças de latência e revisão das citações, que podem pesar mesmo quando o preço por token favorece uma rota.

Quando as perguntas variam, uma única arquitetura para todas elas pode desperdiçar dinheiro ou contexto. Recuperar uma passagem para respostas localizadas e enviar o documento completo para sínteses que exigem relações distantes permite reservar o custo maior às consultas em que ele traz uma vantagem observável.

Leia também:

• HubSpot ou Pipedrive: o CRM grátis pode custar mais quando a equipe cresce
• O agente barato pode custar 30 vezes mais — calcule por tarefa concluída
• Apache escaneia 230 repositórios com IA — contexto cortou o custo em 20%