A IA não lembra de tudo: entenda o que realmente significa contexto

TL;DR

Modelo, contexto e memória são conceitos diferentes — e confundir os três é a fonte dos piores erros com contexto de IA generativa. Uma IA extremamente capaz pode parecer limitada simplesmente porque recebeu o contexto errado. Se existem milhões de tokens de código no repositório, a questão deixa de ser qual modelo é mais inteligente e passa a ser como selecionar exatamente a informação necessária para resolver o problema. A janela de contexto cresce a cada nova geração de modelos, mas o gargalo real mudou: não é mais o tamanho da janela, e sim a capacidade de preenchê-la com o conteúdo certo.

• Contexto é tudo que o modelo recebe na inferência — fora disso, a IA não tem acesso a nenhuma informação persistente entre requisições.
• Janela de contexto de 128K a 1M tokens não significa atenção perfeita: o fenômeno “lost-in-the-middle” degrada respostas quando o conteúdo relevante está cercado de ruído.
• Contexto temporário (janela atual) e memória persistente (vetores, sumários, bancos de dados) são sistemas distintos que operam em camadas separadas — o modelo não “lembra” entre sessões.
• Fornecer informação demais piora a precisão da resposta: contexto enxuto e relevante consistentemente supera contexto grande com ruído incorporado.
• Context engineering — a disciplina de projetar o que entra e o que fica fora da janela — tornou-se a habilidade crítica para equipes que operam IA em produção em 2026.

~ 11 min de leitura · 1839 palavras

O que é contexto de IA — e por que a IA não “lembra”

Contexto é todo o conteúdo que o modelo recebe no momento da inferência: instrução do system prompt, histórico da conversa, documentos anexados, código fonte, resultados de chamadas de ferramenta, dados recuperados por RAG. Fora desse conjunto, o modelo não tem acesso a nada. Não há camada de memória residente entre requisições — a arquitetura dos transformers não inclui estado persistente.

A ilusão de continuidade existe porque o sistema cliente re-injeta o histórico da conversa a cada turno. Quando um assistente parece “lembrar” o que foi dito há vinte mensagens, ele está apenas processando o mesmo texto reinserido na janela de contexto de IA. Se a aplicação não reenviar o histórico, o modelo começa cada interação do zero — sem saber quem é o usuário, qual era o tópico ou o que foi decidido no turno anterior.

Essa distinção é o ponto de partida para entender por que modelos com janelas de 1 milhão de tokens ainda cometem erros que parecem “falta de memória”. O problema não está na capacidade de armazenamento da janela, mas na arquitetura de atenção que precisa encontrar o trecho relevante entre milhares de tokens.

Janela de contexto: entrada e saída

A janela de contexto de um modelo divide-se em duas regiões funcionais: o contexto de entrada (prompt do sistema, histórico, documentos, resultado de ferramentas) e o contexto de saída (tokens gerados como resposta). Modelos modernos oferecem janelas que variam de 128K tokens (GPT-4o, Claude 3 Sonnet) até 200K (Claude Opus) e 1 milhão de tokens (Gemini 1.5 Pro, DeepSeek). O contexto de saída, porém, permanece limitado a alguns milhares de tokens por chamada.

• Entrada: system prompt, histórico, documentos anexados, código, tool calls, RAG.
• Saída: tokens gerados como resposta, limitados a alguns milhares por chamada.
• Modelos de entrada longa: Gemini 1.5 Pro (1M), DeepSeek (1M), Claude Opus (200K), GPT-4o (128K).
• Fenômeno crítico: “lost-in-the-middle” — a precisão da resposta cai quando o fato relevante está no meio da janela, cercado por tokens anteriores e posteriores. Estudos mostram queda significativa de recall além dos primeiros 20% da janela.

A implicação prática é direta: uma base de código com 500 mil tokens de repositório alimentada integralmente na janela não produz respostas melhores que a mesma base reduzida aos 20 mil tokens mais relevantes. O tamanho da janela importa menos que a densidade de informação relevante dentro dela.

Os seis componentes do contexto de uma interação

Uma chamada típica a um modelo de linguagem contém seis camadas de contexto que competem por espaço na janela:

1. System prompt — as regras fixas que moldam o comportamento do assistente: tom, formato de saída, restrições de segurança. Ocupa entre 500 e 2 mil tokens. 2. Instrução do usuário — a solicitação atual. Varia de dezenas a centenas de tokens dependendo da complexidade. 3. Histórico da conversa — turns anteriores que o sistema re-injetou para manter continuidade. Um diálogo de trinta mensagens pode ocupar de 5 a 15 mil tokens. 4. Documentos anexados — PDFs, especificações, arquivos de requisitos enviados como parte da consulta. 5. Código fonte — arquivos de repositório incluídos para análise ou modificação. Dependendo da base, pode consumir dezenas ou centenas de milhares de tokens. 6. Resultados de ferramentas e RAG — respostas de tool calls, resultados de busca, chunks relevantes recuperados de uma base vetorial. Cada execução de ferramenta adiciona centenas a milhares de tokens ao contexto.

Cada camada compete por posição dentro da janela. O system prompt tende a ficar no início, onde a atenção do modelo é mais forte. O histórico recente ocupa o final. Os documentos e chunks RAG disputam o meio — exatamente a região onde o fenômeno lost-in-the-middle é mais agressivo. Entender essa disputa por posição é o primeiro passo para projetar o que entra e o que fica fora.

Contexto temporário versus memória persistente

Contexto temporário é o conteúdo que está na janela durante uma única inferência ou sessão. Ele morre quando a sessão termina — o modelo não retém nada entre requisições. Memória persistente, por outro lado, é o que o sistema armazena fora do modelo entre sessões: vetores em banco de dados, sumários de conversas anteriores, arquivos de configuração, logs de decisões.

A diferença crítica é que a memória não está no modelo — está no banco de vetores, no resumo de sessão, no arquivo de metadados. O modelo não tem memória; o sistema tem. Quando uma aplicação “lembra” de uma preferência do usuário em uma conversa futura, o que ocorre é um pipeline de recuperação: a preferência foi armazenada como embedding em um banco vetorial, recuperada por similaridade semântica, e reinserida no contexto temporário como um chunk de RAG.

• Contexto temporário: janela atual, morre com a sessão, depende de re-injeção.
• Memória persistente: banco vetorial, sumários, metadados, sobrevive entre sessões.
• Pipeline típico: persistir → embedding → recuperação por similaridade → re-injeção como chunk RAG.

Essa arquitetura em duas camadas — contexto temporário no modelo, memória persistente no sistema — é o padrão adotado por plataformas como LangChain e LlamaIndex. A confusão entre as duas camadas leva a expectativas irreais: quando um usuário diz “a IA deveria lembrar do que discutimos ontem”, ele está pedindo que o sistema tenha um banco de dados funcional, não que o modelo individual tenha capacidade de recordação.

Context caching e compactação

Context caching é a técnica de reutilizar o prefixo de tokens entre chamadas consecutivas. Em vez de reprocessar o system prompt e os documentos de contexto a cada requisição, o cache armazena os estados de atenção (KV cache) do prefixo compartilhado. Modelos como GPT-4o e Claude 3.x oferecem suporte nativo a context caching, reduzindo custo e latência em cenários com contexto grande e estável — como assistentes que atendem milhares de consultas sobre a mesma base de documentos.

A compactação de histórico é a técnica complementar: em vez de manter cada turno da conversa integralmente, o sistema sumariza turns antigas e armazena apenas o resumo. Uma conversa de quarenta mensagens sobre o mesmo tópico pode ser compactada de 15 mil tokens para 500 tokens de sumário, liberando espaço na janela para novas interações.

• Context caching: reuso de KV cache do prefixo, ideal para contexto estável, invalidado por qualquer variação no system prompt.
• Compactação de histórico: sumarização de turns antigas, libera espaço na janela, perde granularidade.

Ambas as técnicas têm limites. Context caching funciona bem quando o prefixo é idêntico entre requisições — qualquer variação no system prompt invalida o cache. Compactação de histórico perde granularidade: detalhes específicos de turns antigas podem ser omitidos no resumo, e o modelo passa a responder com base em informação incompleta. A escolha entre cache e compactação depende do perfil de uso: conversas longas com mudanças frequentes de tópico favorecem compactação; assistentes documentais com contexto estável favorecem caching.

O problema de fornecer informação demais

Janela grande não é garantia de resposta boa. Estudos de recuperação de informação em contexto longo mostram que a precisão do modelo cai monotonicamente conforme a quantidade de tokens irrelevantes no contexto aumenta. Um modelo com janela de 1 milhão de tokens que recebe 980 mil tokens de código não relacionado ao problema misturados com 20 mil tokens de contexto relevante produz respostas sistematicamente piores que o mesmo modelo alimentado apenas com os 20 mil tokens certos.

O mecanismo causal é a dispersão da atenção. O transformer distribui um orçamento fixo de atenção entre todos os tokens da janela. Quando a maior parte dos tokens é ruído — código de módulos não relacionados, logs antigos, documentação desatualizada — a fração de atenção dedicada ao conteúdo relevante diminui proporcionalmente. O resultado é perda de recall, alucinações sobre detalhes periféricos e respostas genéricas que poderiam vir de um modelo com janela muito menor.

• Custo de contexto grande: provedores cobram por token de entrada. Uma chamada com 100 mil tokens custa ordens de magnitude mais que uma com 5 mil tokens.
• Degradação de precisão: recall cai monotonicamente conforme tokens irrelevantes aumentam.
• Dispersão de atenção: orçamento fixo de atenção dividido entre ruído e sinal.

O custo também é financeiro. Provedores como OpenAI e Anthropic cobram por token de entrada. Uma chamada com 100 mil tokens de contexto custa ordens de magnitude mais que uma com 5 mil tokens. O padrão “joga tudo na janela” queima orçamento sem contrapartida de qualidade.

Context engineering: a skill do momento

Context engineering é a disciplina de projetar o que entra na janela de contexto de IA e como cada componente é posicionado, formatado e priorizado. Não se trata de prompt engineering — que foca na redação da instrução — mas de arquitetura de informação para modelos de linguagem. As decisões de context engineering incluem:

• Chunking inteligente: dividir documentos em fragmentos que preservam coesão semântica e cabem na janela com margem para outras camadas.
• Priorização dinâmica: ordenar chunks RAG por relevância estimada, colocando os mais relevantes no início da janela, onde a atenção é mais forte.
• System prompt enxuto: remover instruções redundantes ou implícitas que o modelo já internalizou durante o treinamento, liberando espaço para contexto específico da tarefa.
• Compactação seletiva: sumarizar apenas turns antigas ou documentos de baixa prioridade, mantendo o conteúdo crítico em sua forma original.
• RAG calibrado: ajustar o número de chunks recuperados por consulta para maximizar recall sem saturar a janela com resultados de baixa relevância.

O modelo “mais contexto é melhor” está em transição para “melhor contexto é melhor”. Empresas que operam IA em produção — como aquelas que utilizam contexto de IA para análise de código, suporte ao cliente ou automação de documentos — já adotam métricas de densidade de contexto: proporção de tokens relevantes sobre tokens totais na janela. Uma densidade abaixo de 30% é sinal de que a janela contém mais ruído que sinal.

A habilidade de projetar contexto substitui a corrida por janelas maiores como diferencial competitivo. Um modelo com janela de 128K tokens e contexto bem projetado entrega respostas superiores a um modelo com 1 milhão de tokens e contexto mal projetado.

O ponto de partida para qualquer diagnóstico de contexto de produção é o mesmo: medir antes de cortar. Contar tokens por camada, calcular densidade de informação, auditar onde a atenção do modelo está sendo desperdiçada. Sem métrica, a engenharia de contexto é opinião. Com métrica, é projeto.

Leitura relacionada

• Token não é palavra: entenda a unidade que define memória, velocidade e custo da IA — explica a unidade fundamental que compõe cada elemento do contexto discutido neste post, da janela de entrada aos chunks de RAG.
• Cinco decisões no prompt. Aqui está como tomar cada uma. — mostra como as decisões de redação de prompt interagem com as camadas de contexto e por que instrução mal posicionada degrada a atenção do modelo.
• Estrutura de prompt é diferença entre alucinar e acertar — aprofunda como a organização do conteúdo dentro do system prompt e das instruções afeta diretamente a qualidade da saída, complementando a discussão sobre context engineering.