Contexto de 1M tokens não matou o RAG: quando cada um ganha

Toda geração de modelos com janela maior reacende a mesma previsão: "agora o RAG morreu, é só jogar tudo no contexto".

Em setembro de 2026, com 1,05 milhão de tokens virando padrão de mercado e preço de entrada em US$ 0,10 por milhão, a previsão parece finalmente razoável. Cabe muita coisa, e cabe barato.

Só que "cabe" e "funciona" são perguntas diferentes. Três coisas continuam verdadeiras: você paga pelo contexto a cada requisição, o prefill custa tempo antes do primeiro token, e a atenção não é uniforme ao longo da janela.

Este artigo faz as contas e chega numa conclusão menos empolgante e mais útil: a arquitetura que vence quase sempre usa os dois.

TL;DR

• Contexto longo cobra por requisição. Índice de busca cobra uma vez na ingestão.
• 800 mil tokens de contexto a US$ 0,10/M custam US$ 0,08 por chamada — US$ 2.400/dia em 30 mil requisições.
• Cache de entrada (90% de desconto) muda a conta quando o corpus é estável e compartilhado. Não ajuda quando é por usuário.
• Prefill de contexto grande adiciona segundos ao tempo até o primeiro token.
• Degradação no meio do contexto continua existindo: informação no miolo é recuperada pior que no começo ou no fim.
• RAG dá citação de origem. Contexto longo dá uma resposta e a esperança de que ela veio da parte certa.
• O híbrido — recuperar generosamente e deixar a janela grande absorver a imprecisão — costuma ser a melhor escolha.

A conta de custo, direto

def compare_cost(
    corpus_tokens: int,
    requests_per_day: int,
    price_in_per_1m: float = 0.10,
    cached_price_per_1m: float = 0.01,
    cache_hit_rate: float = 0.0,
    rag_chunk_tokens: int = 6_000,
    embedding_price_per_1m: float = 0.02,
) -> dict:
    # contexto longo: paga o corpus inteiro toda vez
    billed = corpus_tokens * (1 - cache_hit_rate) * price_in_per_1m
    cached = corpus_tokens * cache_hit_rate * cached_price_per_1m
    long_daily = (billed + cached) / 1e6 * requests_per_day

    # rag: paga a indexação uma vez, depois só os trechos recuperados
    index_once = corpus_tokens / 1e6 * embedding_price_per_1m
    rag_daily = rag_chunk_tokens / 1e6 * price_in_per_1m * requests_per_day

    return {
        "contexto_longo_dia": round(long_daily, 2),
        "rag_dia": round(rag_daily, 2),
        "rag_indexacao_unica": round(index_once, 4),
        "razao": round(long_daily / rag_daily, 1) if rag_daily else None,
    }

Corpus de 800 mil tokens, 30 mil requisições por dia, sem cache:

compare_cost(800_000, 30_000)
# {'contexto_longo_dia': 2400.0, 'rag_dia': 18.0,
#  'rag_indexacao_unica': 0.016, 'razao': 133.3}

US$ 2.400 por dia contra US$ 18. A indexação inteira custou menos de dois centavos, uma única vez.

A razão de 133× não é um detalhe de otimização. É a diferença entre uma funcionalidade viável e uma inviável.

Onde o cache muda o jogo

Se o corpus é o mesmo para todas as requisições, o cache de entrada com 90% de desconto muda bastante:

compare_cost(800_000, 30_000, cache_hit_rate=0.95)
# {'contexto_longo_dia': 348.0, 'rag_dia': 18.0, 'razao': 19.3}

De 133× para 19×. Melhor, e ainda longe de empatar.

E o cache só funciona sob condições específicas: prefixo idêntico byte a byte, estável no tempo, compartilhado entre requisições. Se o corpus varia por usuário — que é o caso da maioria dos produtos —, a taxa de acerto despenca e você volta para os US$ 2.400.

Latência: o custo que o usuário sente

Custo aparece na fatura no fim do mês. Latência aparece na cara do usuário agora.

Processar o contexto antes de gerar o primeiro token — o prefill — escala com o tamanho da janela:

Os números variam por modelo, hardware e otimização de cache, mas a forma da curva não muda: contexto grande empurra o primeiro token para longe.

RAG inverte a distribuição. Você paga uma busca vetorial — tipicamente dezenas de milissegundos — e entra no modelo com uma janela pequena. O tempo até o primeiro token fica quase constante, independente do tamanho do corpus.

Para qualquer coisa conversacional, essa é frequentemente a razão decisiva, antes mesmo do custo.

Degradação no meio: a janela não é uniforme

O terceiro fator é o menos intuitivo e o mais teimoso.

Modelos recuperam melhor informação posicionada no começo e no fim da janela do que no meio. Janelas maiores não eliminaram o efeito; elas apenas deram mais espaço para o miolo crescer.

Isso significa que "está no contexto" não é o mesmo que "o modelo vai usar". Um documento crítico enterrado no token 400.000 pode ser efetivamente invisível para a resposta.

Um teste barato mede isso no seu corpus, em vez de confiar em benchmark de terceiro:

def needle_test(client, corpus_chunks, needle: str, question: str, positions=(0.0, 0.25, 0.5, 0.75, 1.0)):
    """Insere um fato em posições diferentes e mede a taxa de recuperação."""
    results = {}
    for pos in positions:
        idx = int(len(corpus_chunks) * pos)
        salted = corpus_chunks[:idx] + [needle] + corpus_chunks[idx:]
        answer = client.complete("\n".join(salted) + f"\n\n{question}")
        results[f"{pos:.0%}"] = needle_fact_present(answer)
    return results

# resultado típico: forte nas pontas, fraco no miolo
# {'0%': True, '25%': True, '50%': False, '75%': True, '100%': True}

Rode isso com o seu conteúdo real antes de decidir jogar tudo na janela. Se o miolo falha, contexto longo não é uma solução de recuperação — é uma aposta.

Auditabilidade: a pergunta que decide em domínio regulado

Com RAG, a resposta vem com endereço:

{
  "answer": "O prazo de reembolso é de 30 dias corridos.",
  "sources": [
    {"doc": "politica-reembolso-v4.pdf", "chunk": 12, "score": 0.89},
    {"doc": "faq-financeiro.md", "chunk": 3, "score": 0.71}
  ]
}

Com contexto longo, você tem a resposta e a suposição de que ela veio da parte certa dos 800 mil tokens.

Em suporte ao cliente, jurídico, saúde ou finanças, isso não é um detalhe de produto. É a diferença entre uma resposta utilizável e uma que ninguém pode assinar embaixo.

Há um meio-termo razoável: pedir citação explícita mesmo em contexto longo, com IDs de seção no material. Funciona parcialmente, e continua sem oferecer a garantia estrutural que a recuperação dá — o modelo pode citar uma seção e ter usado outra.

Quando contexto longo realmente ganha

Não é uma lista vazia. Existem casos em que RAG é a escolha errada:

O corpus é pequeno e cabe inteiro. Menos de ~50 mil tokens, estável. Montar pipeline de embeddings, índice e reranking para isso é over-engineering.

A tarefa exige o documento inteiro. Resumir um contrato de 200 páginas, encontrar contradições entre cláusulas distantes, rastrear um argumento ao longo de um livro. Recuperação por trecho quebra justamente a relação entre partes distantes que a tarefa precisa.

O raciocínio atravessa muitos saltos. Perguntas que exigem combinar cinco fatos espalhados costumam falhar com top-k, porque o trecho relevante para o quinto salto não se parece com a pergunta original.

É uma tarefa única, não um produto. Análise pontual de um corpus que você nunca mais vai consultar. Custo de indexação não se amortiza.

Conversa longa. O histórico da sessão é naturalmente linear e relevante por inteiro. Resumir turnos antigos ainda ajuda, mas recuperação por similaridade raramente melhora.

A arquitetura que costuma vencer

A escolha real quase nunca é binária. É quanto recuperar antes de entrar no modelo.

Com janela grande e barata, você pode ser generoso na recuperação — o que remove a parte mais frágil do RAG clássico, que é acertar o top_k pequeno.

def hybrid_context(query: str, index, budget_tokens: int = 60_000) -> list[Chunk]:
    """Recupera generosamente e deixa a janela grande absorver a imprecisão."""
    # 1. busca híbrida: semântica + léxica cobre falhas diferentes
    dense = index.search_dense(query, k=80)
    sparse = index.search_bm25(query, k=80)
    merged = reciprocal_rank_fusion(dense, sparse)

    # 2. rerank para ordenar bem o começo da janela
    ranked = reranker.rank(query, merged[:60])

    # 3. preencher até o orçamento, não até um k fixo
    selected, used = [], 0
    for chunk in ranked:
        if used + chunk.tokens > budget_tokens:
            break
        selected.append(chunk)
        used += chunk.tokens

    # 4. o mais relevante no início e no fim — evita o miolo fraco
    return interleave_by_relevance(selected)

Quatro escolhas deliberadas aqui:

Busca híbrida. Densa erra em nomes próprios, códigos e termos raros; léxica erra em paráfrase. Juntas cobrem falhas diferentes.

Orçamento em tokens, não top_k. Trechos têm tamanhos diferentes. Orçamento em tokens é a unidade que realmente restringe.

60 mil em vez de 6 mil. Com contexto grande e barato, ser generoso é acessível — e a precisão da recuperação deixa de ser o ponto único de falha.

Posicionamento consciente. Colocar o mais relevante nas pontas contorna, em vez de ignorar, a degradação do miolo.

Esse desenho fica com custo por requisição na casa de US$ 0,006 — uma ordem de grandeza abaixo do contexto cheio — e recall muito acima do RAG com top_k=5.

Matriz de decisão

Checklist

• O custo diário das duas opções foi calculado com o seu volume real.
• A taxa de acerto de cache foi estimada com honestidade (corpus por usuário ≈ 0%).
• O tempo até o primeiro token foi medido no contexto de produção, não em demo.
• O teste de agulha foi rodado no seu conteúdo, em cinco posições.
• A necessidade de citação de fonte foi decidida com o time de negócio.
• A busca é híbrida, não só densa.
• O orçamento de recuperação é em tokens, não em top_k fixo.
• Trechos mais relevantes ficam nas pontas da janela.
• Existe um caminho para quando a recuperação não traz nada relevante.
• A decisão foi revisada depois da última mudança de preço do provedor.

Conclusão

A janela de 1 milhão de tokens não tornou o RAG obsoleto. Ela mudou o tamanho ótimo do que você recupera.

Antes, com janelas de 8 mil, o RAG precisava ser cirúrgico: top_k=3 e reze. Essa precisão era o ponto frágil de todo o sistema. Agora você pode recuperar sessenta mil tokens de material provavelmente relevante e deixar o modelo filtrar — o que é muito mais robusto do que acertar os três trechos certos.

A conta continua clara: contexto longo cobra por requisição, índice cobra uma vez. A 133× de diferença no cenário deste artigo, "jogar tudo dentro" não é simplicidade, é uma decisão de custo que alguém vai questionar.

E se o seu domínio exige responder "de onde veio isso?", a discussão sobre custo e latência nem chega a acontecer.

Leituras relacionadas

• Custo por tarefa: a métrica que substitui preço por token
• Self-hosting de pesos abertos: a matemática de VRAM
• Seu eval de domínio em um dia

Os preços usados são um snapshot de 22 de setembro de 2026. Os tempos de prefill são ordens de grandeza típicas e variam bastante por modelo, hardware e otimização; meça no seu ambiente antes de decidir.