Uma janela de contexto grande é um limite de capacidade, não uma estratégia de recuperação. O fato de um modelo aceitar várias centenas de milhares de tokens não significa que ele os lê com atenção uniforme, e certamente não significa que você deva pagar para enviá-los. Todo benchmark de contexto longo que se deu ao trabalho de medir posição e comprimento diz a mesma coisa: a precisão cai conforme a entrada cresce, e as evidências enterradas no meio de um prompt são as menos usadas.

A reformulação que vale a pena internalizar: a janela de contexto é um orçamento que você gasta, não um banco de dados que você consulta. Times que a tratam como armazenamento constroem sistemas mais lentos, mais caros e menos precisos do que o pipeline de recuperação que pularam.

Os dois modos de falha são diferentes

Esses dois problemas costumam ser confundidos, mas têm soluções diferentes.

  • Degradação posicional. O efeito "perdido no meio" (lost-in-the-middle) descrito por Liu et al. (2023): a precisão é maior quando o trecho relevante está bem no início ou bem no fim da entrada, e cai no meio, produzindo uma curva em formato de U. Mova o mesmo fato da borda para o centro e a qualidade da resposta piora, mesmo que nada mais tenha mudado.
  • Degradação por comprimento. A precisão cai conforme a entrada cresce, mesmo quando a evidência é fixa e está bem posicionada. Trabalhos subsequentes como o RULER (Hsieh et al., 2024) testaram modelos de contexto longo em tarefas com múltiplas agulhas e raciocínio sobre o contexto, e descobriram que o comprimento de contexto efetivo é consistentemente menor do que o número anunciado.

A degradação posicional às vezes dá para contornar reordenando o conteúdo. A degradação por comprimento, não, porque o problema é o próprio tamanho do palheiro. Corrigir isso significa colocar menos coisa dentro.

Por que o número do benchmark engana

O teste da agulha no palheiro ganhou popularidade por ser fácil de rodar e fácil de passar. Esconda uma frase fora de lugar em várias profundidades de um documento longo, peça para o modelo repeti-la, plote uma grade verde. Um modelo pode tirar nota quase perfeita nisso e ainda falhar naquilo que você realmente precisa, porque perguntas reais não são buscas léxicas.

Seus usuários fazem perguntas que exigem encontrar quatro fatos relacionados espalhados por um corpus, perceber que dois deles se contradizem e raciocinar sobre o restante. É essa a tarefa que o RULER mede, e é aí que a janela anunciada e a janela realmente utilizável se distanciam. Trate a recuperação de uma única agulha como um teste de fumaça, não como prova de que a janela funciona.

O lado do custo não tem sutileza

A degradação da recuperação é discutível. A conta, não. Tokens de entrada são cobrados por chamada, então um design que enfia 200.000 tokens de contexto em cada requisição paga pelos 200.000 toda vez, quer a resposta precisasse de doze deles ou de nenhum.

# Stuff-the-window: whole handbook, every turn
200,000 input tokens x 50,000 calls/month = 10,000,000,000 tokens

# Retrieve-then-answer: system prompt + 6 chunks
  3,000 input tokens x 50,000 calls/month =    150,000,000 tokens

Isso é um fator de sessenta e seis vezes na linha de entrada, antes mesmo de contar a latência. O tempo até o primeiro token escala com o quanto o modelo precisa ler, então o prompt superlotado também é o mais lento. Você está pagando mais por uma resposta pior, entregue mais tarde. Não existe eixo em que isso vença.

O cache de prompt complica a conta em um caso específico: um prefixo genuinamente estável que se repete entre chamadas pode ser lido com um desconto considerável. Isso é real e vale a pena usar. Mas ele resgata o custo de um preâmbulo estático, não a precisão de um palheiro inchado. Um prompt ruim em cache é apenas um prompt ruim mais barato.

O que fazer em vez disso

A disciplina não tem nada de glamoroso, mas funciona.

  • Recupere, depois responda. Coloque uma etapa de recuperação na frente do modelo e passe apenas o punhado de trechos mais relevantes. Uma Bedrock Knowledge Base faz isso sem que você precise manter um índice próprio. Seis trechos bons vencem seiscentos medíocres, sempre.
  • Ordene a sério. Se você passa dez trechos, a ordem importa porque a posição importa. Coloque a evidência mais forte no topo e a segunda mais forte no final, onde a atenção do modelo é melhor. Preencha o meio com o material marginal, não com o fato que sustenta a resposta.
  • Limite o que cada etapa pode ver. Um teto rígido de tokens por chamada obriga a camada de recuperação a ser seletiva. Sem um limite, o contexto cresce até algo quebrar, geralmente no pior momento.
  • Coloque em cache o prefixo estável, não o corpo variável. O system prompt e os esquemas de ferramentas são iguais em toda chamada e pertencem ao cache. A evidência recuperada muda a cada pergunta e não deve entrar nele.
  • Meça a precisão com suas próprias perguntas. Rode suas consultas reais contra o seu corpus real e avalie as respostas. As alegações de comprimento de contexto do fornecedor são um número de marketing; sua avaliação é a única que descreve o seu sistema.

Quando a janela grande é a resposta certa

Há casos em que preencher a janela é a decisão certa, e recusar-se a fazer isso por princípio é um erro em si. Resumir um único documento do início ao fim precisa do documento inteiro; não há o que recuperar porque tudo é relevante. Um raciocínio que exige manter uma base de código ou um contrato inteiro à vista de uma vez genuinamente precisa desse alcance. Uma análise pontual em que construir um pipeline de recuperação custa mais do que os tokens é um bom lugar para ser preguiçoso de propósito.

O teste é se você consegue nomear o subconjunto que importa. Se conseguir, recupere-o. Se genuinamente não conseguir, porque a tarefa envolve o corpus inteiro e não uma parte dele, então a janela está fazendo um trabalho real e você deve usá-la.

A conclusão

Janelas de contexto maiores são uma conquista real de engenharia, e continuam crescendo. Também são a forma mais cara de evitar escrever uma etapa de recuperação. A precisão degrada com o comprimento e com a posição, a conta escala com cada token enviado, e a latência acompanha o tamanho do prompt. Decida o que o modelo precisa ver, envie só isso, e pare de confundir capacidade com competência.

Leia isso a seguir

Para o lado de infraestrutura de rodar recuperação em escala, as notas de campo de cloud e plataforma estão em ercan.cloud, e o hub fica em ercanermis.com.