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.