O mito do 1 milhão de tokens em janelas de contexto de IA

TL;DR

Mandar o repositório inteiro para a IA não garante resposta melhor: capacidade do modelo, tamanho da janela de contexto de IA, qualidade do que entra e memória são quatro coisas diferentes que o mercado costuma misturar. Esta é a distinção que separa o uso medíocre do uso profissional de LLM em produção.

• “1 milhão de tokens” é limite mecânico de entrada, não indicador de inteligência — e custa caro por token de input, mesmo quando a maior parte é ruído.
• Quanto mais texto entra, pior a alocação de atenção no meio do prompt — o paper “Lost in the Middle” (Liu et al., 2023) documenta isso empíricamente.
• A Estratégia A (mandar tudo) perde em quase todo cenário real; a Estratégia B (interpretar, buscar, recuperar, entregar só o necessário) é o padrão de produção.
• RAG, embeddings e busca semântica existem porque selecionar contexto é mais barato e mais correto do que carregar contexto.
• Memória persistente e contexto de sessão são camadas distintas da arquitetura — tratá-las como a mesma coisa é o erro que produz agente que esquece e prompt que não para de crescer.

A confusão central: capacidade, contexto, qualidade e memória

O mercado de IA generativa vendeu “1 milhão de tokens” como se fosse uma bala de prata. A mensagem implícita, repetida em demo de fornecedor, slide de venda e thread de Twitter: “manda tudo que o modelo resolve”. O resultado prático em produção é um sistema que gasta dez mil tokens de input, cobra caro pelo privilégio, e devolve resposta medíocre. O problema não é o modelo. O problema é a confusão entre quatro coisas que se parecém, mas não são a mesma coisa.

Capacidade do modelo é o que ele consegue fazer quando recebe a entrada certa: o tamanho do vocabulário de padrões que aprendeu no pré-treinamento, a capacidade de seguir instruções, a qualidade do raciocínio. É uma propriedade do checkpoint. Não cresce quando o prompt cresce.

Tamanho do contexto é o limite mecânico de tokens que cabem na janela de entrada. OpenAI, Anthropic e Google anunciam números como 200 mil, 1 milhão e 2 milhões de tokens. É um teto de engenharia, não um indicador de qualidade.

Qualidade do contexto é o que de fato importa: a fração dos tokens de entrada que carrega informação relevante para a tarefa. Cinco mil tokens bem escolhidos costumam ser superiores a cem mil tokens com 80% de ruído.

Memória é a persistência entre sessões. Um sistema que lembra do usuário, do projeto, das decisões tomadas em interações anteriores, opera em outra camada de arquitetura — e é aí que entram bancos vetoriais, sumarização, hierarquia de informação.

Misturar essas quatro coisas é o que faz a equipe gastar vinte mil dólares por mês em API de LLM e ainda assim receber respostas inconsistentes. Tamanho do contexto é ferramenta, não destino.

O que é a janela de contexto, finalmente

Janela de contexto é o limite de tokens que o modelo consegue processar em uma única chamada, somando input do usuário, system prompt, histórico de conversa e instruções. O transformer que sustenta os modelos atuais foi apresentado em “Attention Is All You Need” (Vaswani et al., 2017) com mecanismo de atenção que opera sobre toda a sequência de entrada. O custo computacional do mecanismo é quadrático em relação ao comprimento da sequência: dobrar o contexto quadruplica o trabalho de atenção. Isso impõe um teto prático que a engenharia foi contornando aos poucos, de 4 mil tokens (GPT-3 original, 2020) para 128 mil, 200 mil, 1 milhão e 2 milhões de tokens nos modelos atuais.

O ponto que confunde quem está começando: “tokens” não é a mesma coisa que “palavras”. Um token é uma unidade subpalavra, definida pelo tokenizador do modelo. Em inglês, uma palavra costuma virar 1 a 2 tokens. Em português, sobe para 2 a 4 tokens por palavra. O post Token não é palavra destrincha essa unidade e por que ela define simultaneamente memória, latência e custo de cada chamada.

Esse teto é, portanto, três coisas ao mesmo tempo:

• Limite mecânico de tokens por chamada (input + output).
• Custo: a cobrança da API é por token de input, e cada token adicional entra na conta mesmo que não contribua para a resposta.
• Atenção: cada token novo concorre com todos os outros pela capacidade de atenção do modelo. Adicionar contexto não soma informação — pode diluir a existente.

A confusão aparece quando o fornecedor apresenta “1 milhão de tokens” como diferencial competitivo. A leitura correta: é um teto maior de uma das três dimensões acima. Nada garante que usar todo o teto produza resposta melhor. Em vários casos, produz resposta pior.

Por que mais contexto pode dar resposta pior

A intuição leiga diz que mais informação disponível leva a respostas mais precisas. Para LLM, isso não é linear — tem platôs, regressões e regiões onde adicionar contexto piora a saída. O paper “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023) documenta o fenômeno de forma empírica: quando a informação relevante está no começo ou no fim da janela, o modelo recupera bem. Quando está no meio, a taxa de acerto cai de forma estatísticamente significativa.

O mecanismo é a curva em U da alocação de atenção. Modelos treinados com attention window limitada aprendem a confiar mais em posições de borda do que em posições centrais, porque o pré-treinamento reforçou essa distribuição. Aumentar a janela de contexto na arquitetura não corrige o viés automaticamente: ele persiste como artefato de treinamento. Treinar com janela maior atenua, mas não elimina.

Os efeitos observados em produção são quatro:

• Atenção diluida: tokens de prompt competem por peso de atenção. Quanto mais tokens, mais distribuidos ficam os pesos. A informação relevante recebe menos atenção relativa.
• Recall do meio: a taxa de uso efetivo da informação posicionada no meio do prompt cai em comparacao com as bordas.
• Custo de processamento quadratico: a atenção scale em O(n²) no comprimento da sequência. Janela de 1 milhão de tokens custa 25 vezes mais que janela de 200 mil para o mesmo modelo. Para 2 milhões, 100 vezes mais.
• Latencia de primeira resposta: o tempo ate o primeiro token emitido cresce na mesma proporção. Janela cheia significa TTFT de segundos em vez de centenas de milissegundos.

Ha também o risco de context poisoning: informação contraditoria ou antiga no prompt induz o modelo a gerar saídas inconsistentes com a base de conhecimento real. Mais contexto significa mais superficie para esse tipo de contaminacao.

A frase de calibragem que vale para 2026: aumentar o teto da janela não substitui selecionar contexto. Trocar capacidade de janela por qualidade de contexto e a decisão errada em quase todo caso de produção.

A Estratégia A: mandar tudo (e quando ela perde)

A Estratégia A — copiar o repositório inteiro, colar o historico completo, anexar toda a documentação e mandar para o modelo — e intuitiva e comercialmente atraente. A promessa: “o modelo ve tudo, então responde tudo”. A realidade em produção e diferente.

Os pontos em que a Estratégia A vence são raros e específicos:

• Code review de arquivo unico menor que a janela, sem dependencia externa relevante.
• Sumarizacao de documento longo em que o resumo precisa preservar nuance do meio.
• Debugging de log extenso em que o evento relevante esta em posição aleatoria.
• Perguntas que exigem conhecimento agregado de varios arquivos simultaneos.

Fora desses casos, a Estratégia A perde em quatro dimensoes mensuraveis:

• Custo: input de 500 mil tokens a US$ 10 por milhao de tokens de input sai por US$ 5 por chamada. Em sessão de desenvolvimento iterativo, esse custo explode.
• Latencia: TTFT de 10 a 30 segundos para janela cheia de 1M de tokens quebra o fluxo de quem esta esperando resposta no editor.
• Atenção: a taxa de acerto cai conforme cresce o input — Lost in the Middle mostra queda mensuravel a partir de poucos milhares de tokens.
• Iteracao: o ciclo “manda tudo, recebe resposta, corrige, manda tudo de novo” multiplica custo a cada iteracao. Estratégia que seleciona contexto permite iteracao barata.

A crenca que sustenta a Estratégia A e que contexto e informação. Não são a mesma coisa. Contexto e tudo o que esta na janela. Informacao e a fracao desse tudo que e relevante para a tarefa em maos. A Estratégia A trata as duas como sinonimos. Por isso perde.

A Estratégia B: interpretar, buscar, recuperar

A Estratégia B trata o problema de outra forma. Em vez de empurrar tudo para o modelo, o sistema faz tres coisas antes da chamada:

• Interpretar: decompor a pergunta do usuario em intencao, entidades e necessidade de informação.
• Buscar: localizar no corpus externo (documentação, base de código, historico de conversa, banco de dados) os trechos que respondem aquela intencao.
• Recuperar: montar um contexto enxuto, ranqueado por relevancia, com os top-K trechos mais uteis e envia-lo ao modelo.

Esse e o nucleo do padrão RAG (Retrieval-Augmented Generation), formalizado em “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (Lewis et al., 2020). A hipotese central do paper: para tarefas intensivas em conhecimento, gerar resposta condicional a um conjunto recuperado de documentos e superior a gerar resposta a partir dos parametros do modelo sozinho. A prática em produção confirmou: o padrão virou base de arquitetura de assistentes, copilots e agentes.

A Estratégia B ganha da Estratégia A em quatro eixos:

• Custo: contexto de 5 mil tokens selecionados custa uma fracao do contexto de 500 mil tokens empurrados.
• Latencia: input pequeno significa TTFT sub-segundo, adequado a fluxos interativos.
• Acuracia: contexto selecionado tem maior densidade de informação relevante por token.
• Auditabilidade: cada chunk recuperado e identificavel. E possivel saber por que o modelo gerou cada parte da resposta — e citar fonte.

Ha um custo arquitetural: o sistema precisa de pipeline de indexacao, embeddings, busca vetorial ou lexical, reranking e orçamento de contexto. Nada disso e trivial. Mas o custo de construir essa pipeline e, em geral, ordens de grandeza menor que o custo recorrente de queimar tokens desnecessariamente em produção.

A frase que resume o trade-off: a Estratégia B troca trabalho de engenharia por eficiencia de inferencia. Em volume de produção, essa troca e quase sempre vantajosa.

Embeddings, RAG e a arte de selecionar

Embedding e a representacao numerica de um trecho de texto como vetor denso de tamanho fixo, normalmente entre 384 e 3072 dimensoes, treinada para preservar semantica: textos com significado parecido ficam perto no espaco vetorial. Isso permite busca semantica: dado um trecho de consulta, recuperar os K trechos do corpus mais proximos em cosseno, produto interno ou distancia euclidiana.

O pipeline classico de RAG tem seis camadas:

• Chunking: dividir o documento fonte em trechos de tamanho controlado (tipicamente 256 a 1024 tokens) com sobreposição para preservar contexto de borda.
• Embedding: gerar vetor para cada chunk via modelo de embedding (OpenAI text-embedding-3, Cohere embed-v3, Sentence-Transformers, BGE, E5).
• Indexacao: armazenar vetores em banco especializado (Pinecone, Weaviate, Qdrant, pgvector, LanceDB) com suporte a busca aproximada por vizinhos mais proximos (ANN).
• Retrieval: dada a consulta do usuario, embedar a consulta e buscar os top-K chunks mais proximos.
• Reranking: opcional mas recomendado, aplicar modelo cross-encoder (Cohere Rerank, BGE Reranker) para refinar a ordem dos top-K.
• Composição de prompt: montar o prompt final com system instruction, contexto recuperado, e a pergunta do usuario, dentro do orçamento de tokens.

A camada de chunking e a mais subestimada. Chunk grande demais perde granularidade na busca; chunk pequeno demais perde contexto semantico. A escolha depende da natureza do corpus. Código fonte pede chunk por funcao ou classe. Documentação longa pede chunk por secao com sobreposição. Conversa de suporte pede chunk por turno de usuario.

O retorno economico do RAG vem do fato de que seleção de contexto tem custo computacional muito menor do que processamento de contexto completo. Busca vetorial em corpus de 1 milhao de chunks custa poucos milissegundos; processar 1 milhao de tokens pelo LLM custa segundos e centavos de dolar.

Memoria persistente, contexto de sessão e o erro de tratar tudo como a mesma coisa

Sistemas agenticos confundem tres camadas de persistencia de informação e pagam o preco em produção. São camadas distintas, com arquiteturas distintas:

• Contexto de sessão: a janela de tokens ativa na conversa atual. E temporaria, descartada quando a sessão encerra, limitada pelo tamanho da janela do modelo.
• Memoria de curto prazo: resumo ou extracao estruturada dos pontos chave da sessão, persistido em arquivo, banco de dados ou vector store, para consulta em sessões subsequentes.
• Memoria de longo prazo: fatos duraveis sobre o usuario, preferencias, decisões tomadas, conhecimento acumulado, persistido por periodo longo, com governanca de privacidade e revisão periodica.

Tratar as tres como a mesma coisa produz dois padrões ruins:

• Sistema que esquece o usuario a cada sessão porque so tem contexto de sessão.
• Sistema que cresce o prompt indefinidamente ate estourar a janela porque tenta acumular tudo em contexto de sessão.

A arquitetura correta separa as camadas. Contexto de sessão carrega o resumo atual e os trechos relevantes para a tarefa imediata. Memoria de curto prazo entra no inicio da sessão, carregada como parte do system prompt ou recuperada via RAG da base de sessões anteriores. Memoria de longo prazo entra como facts estruturados, atualizados por criterio explicito do agente ou do usuario.

O risco de context poisoning cresce quando essas camadas não são separadas: informação antiga, contraditoria ou simplesmente desatualizada mistura com informação relevante e degrada a saída. Governanca de memoria exige versão, data de validade e mecanismo de revogacao.

A janela de contexto de IA é ferramenta, não destino. Saber o tamanho da janela não diz nada sobre a qualidade do que entra nela. A decisão que importa é de arquitetura: o que colocar no prompt, em que ordem, com que orçamento de tokens. E essa decisão define o custo, a latência, a acurácia e a auditabilidade do sistema inteiro.

Leitura relacionada

• Chatbot não é agente: a camada invisível que decide o que a IA vê — mostra onde mora a decisão de orquestração que este post atribui à camada de seleção de contexto.
• Token não é palavra: entenda a unidade que define memória, velocidade e custo da IA — base de unidade para entender por que “1 milhão de tokens” significa custo e latência em ordens de grandeza diferentes do que parece.
• A próxima dívida técnica será escrita por IA — onde a ilusão de “IA resolve tudo porque tem contexto” cobra a próxima sprint, em código gerado sem critério de seleção.