Model Context Collapse: Por Que Agentes de IA Esquecem

💡 TL;DR (Resumo em 90 segundos)

Pontos principais em 90 segundos:

• O gargalo dos agentes de programação: Sessões longas de desenvolvimento com agentes de IA inevitavelmente levam à degradação de contexto, processo que chamamos de degradação de contexto. O modelo começa a esquecer variáveis, interpretar mal estruturas de arquivos e introduzir bugs silenciosos.
• A mecânica do declínio de contexto: À medida que o histórico da conversa cresce, os LLMs lutam para prestar atenção a instruções críticas devido ao problema da agulha no palheiro. A diluição atencional faz o modelo focar nas mensagens recentes enquanto ignora regras globais.
• O bug silencioso no PR: Os modelos não geram erros quando o contexto entra em colapso. Em vez disso, geram código sintaticamente perfeito que viola sutilmente restrições arquiteturais anteriores, passando pelos testes unitários locais.
• Respostas arquiteturais: O Context Caching do Gemini e o Preserved Thinking do GLM-4.7 oferecem respostas sistêmicas ao congelar a porção estática do contexto, como esquemas de repositório, regras e bibliotecas base, reduzindo drasticamente custos e mantendo a atenção.
• O caminho a seguir: Adote estratégias rígidas de gerenciamento de contexto: mantenha o histórico de sessões curto, estruture os esquemas do repositório, isole tarefas e utilize endpoints com cache de contexto para manter os agentes focados.

A promessa dos agentes de programação baseados em IA é a capacidade de delegar tarefas complexas de engenharia a um modelo que lê, raciocina e edita código em todo o repositório. No entanto, qualquer engenheiro que já programou em dupla com um LLM por mais de uma hora já esbarrou em um limite frustrante: o modelo começa a cometer erros simples, esquece regras dadas no primeiro prompt e passa a alucinar APIs.

Isto não é uma falha de inteligência, mas sim uma falha de atenção. À medida que o histórico da conversa cresce, a janela de contexto se enche, provocando um fenômeno que chamamos de colapso de contexto ou degradação de contexto.

Neste artigo, analisaremos a mecânica técnica de como a inflação da janela de contexto degrada o desempenho do modelo, por que isso resulta em bugs silenciosos nos pull requests e como inovações arquiteturais como o Context Caching do Gemini e o Preserved Thinking do GLM-4.7 mudam a forma como agentes gerenciam seu estado de longo prazo.

A Física Atencional da Inflação de Contexto

Para entender por que os LLMs esquecem, precisamos examinar o mecanismo de atenção da arquitetura Transformer. Quando um modelo processa um prompt, a camada de autoatenção calcula o produto escalar de consulta-chave-valor (QKV) para cada token contra todos os outros tokens.

Em uma janela de 2.000.000 de tokens, o modelo tem acesso a todo o histórico. Contudo, acesso não é o mesmo que atenção. Pesquisas sobre o problema da Agulha no Palheiro (NIAH) mostram que, à medida que o contexto cresce, a precisão de recuperação do modelo cai, especialmente no meio da janela de contexto.

Vários fatores aceleram essa perda de atenção:

1. Diluição Atencional (Suavização Softmax)

Na autoatenção, os pesos são normalizados usando a função Softmax. À medida que o número de tokens (N) aumenta, o vetor de consulta precisa distribuir seus pesos de atenção por uma matriz muito maior de vetores de chaves. Isso suaviza matematicamente a distribuição da atenção. A menos que uma chave específica tenha uma correlação extremamente alta, seu peso é diluído. Instruções dadas no início do chat, como diretrizes para nunca usar certas bibliotecas ou para mockar o banco de dados, perdem peso atencional frente aos blocos maciços de código e logs de terminal adicionados depois.

Essa distribuição atencional pode ser modelada de forma simples como:

Attention(Q, K, V) = softmax((Q * K_T) / sqrt(d_k)) * V

Conforme a cardinalidade das chaves (K) escala para centenas de milhares de tokens, os elementos do vetor de atenção para qualquer token individual tendem a zero.

2. Viés de Recência em Codificações Posicionais

A maioria dos LLMs modernos utiliza Codificações Posicionais Rotativas (RoPE) para modelar a ordem dos tokens. Embora o RoPE permita ao modelo generalizar para sequências longas, o fator de decaimento no design matemático de sua frequência base privilegia inerentemente os tokens que estão fisicamente mais próximos do ponto de geração da resposta. Na prática, o modelo se fixa fortemente nos últimos 2 ou 3 turnos do assistente e passa a ignorar o prompt do sistema ou restrições antigas do repositório.

A sequência abaixo ilustra como a inflação do contexto leva diretamente ao colapso de contexto:

A Anatomia da Degradação de Contexto

Quando um agente de codificação sofre de colapso de contexto, ele não exibe um erro de falta de memória. Ele falha silenciosamente. O código gerado continua sintaticamente perfeito e compila sem avisos, o que o torna particularmente perigoso.

Veja como a degradação de contexto costuma se manifestar nos fluxos de trabalho dos desenvolvedores:

1. Desvio Arquitetural

Um engenheiro inicia uma sessão definindo um limite claro: "Estamos usando o padrão de repositório, e nenhuma chamada ao banco de dados deve ocorrer dentro de componentes React." Nos primeiros dez turnos, o agente obedece. Mas conforme o volume de tokens cresce com logs de depuração e novos requisitos, o prompt do sistema inicial é empurrado para trás na janela de atenção. No turno vinte, o agente gera consultas ao banco diretamente dentro de um evento de clique de botão, violando a arquitetura.

2. Bugs de Digitação e Assinaturas Alucinadas

Em sessões longas, os agentes frequentemente esquecem as assinaturas de funções definidas em outros arquivos, mesmo que esses arquivos tenham sido enviados no início da sessão. O modelo recorre às suas associações de pré-treino, adivinhando estruturas de argumentos ou nomes de parâmetros com base em padrões comuns de bibliotecas públicas, ignorando a implementação local real.

3. Loops de Viés de Confirmação

Se o agente introduz um bug sutil e o desenvolvedor cola o erro de compilação, o agente tenta corrigi-lo usando apenas as informações do turno recente. O desenvolvedor e o agente entram em um loop de edição das mesmas três linhas de código de um lado para o outro, porque o agente perdeu o contexto global de como essas linhas se comunicam com o restante do sistema.

Mitigações Sistêmicas: Caching e Preserved Thinking

Para construir agentes de codificação confiáveis, não podemos depender de os desenvolvedores manterem os chats curtos. Devemos tratar a perda de atenção nas camadas de infraestrutura e arquitetura dos modelos. Duas abordagens surgiram como principais soluções:

1. Context Caching do Gemini

O Gemini introduziu o cache de contexto para permitir que os desenvolvedores congelem um grande bloco de contexto estático, como um esquema completo de base de código, documentações extensas de APIs ou um conjunto robusto de regras do sistema.

Em vez de analisar e calcular a autoatenção nesse bloco estático a cada turno do usuário, o cache armazena os estados de chave-valor (KV) calculados desses tokens.

Sem Cache: [Contexto Estático (Atenção calculada)] + [Turno 1] -> Resposta
            [Contexto Estático (Atenção recalculada)] + [Turno 2] -> Resposta

Com Cache:  [Estados KV em Cache (Bloco Estático)] + [Turno 1] -> Resposta
            [Estados KV em Cache (Bloco Estático)] + [Turno 2] -> Resposta

Esta arquitetura traz três vantagens importantes:

• Redução de Custo: Tokens em cache são processados por uma fração do custo de tokens de entrada padrão, tipicamente reduzindo os gastos com API em até 80% em sessões longas.
• Redução de Latência: Como os estados KV já estão pré-calculados, o tempo para o primeiro token cair drasticamente.
• Estabilidade Atencional: Por estar isolado em um bloco armazenado em cache, o contexto estático mantém uma linha de base atencional forte e estável, sofrendo menos com a degradação causada pelo histórico recente de chat.

2. Preserved Thinking do GLM-4.7

O GLM-4.7 implementa uma abordagem alternativa chamada preserved thinking (pensamento preservado). Durante sequências de raciocínio longas, agentes de codificação costumam gerar cadeias de pensamento intermediárias. Modelos padrão inserem essas cadeias de raciocínio diretamente no histórico de chat, consumindo rapidamente a janela de contexto.

O GLM-4.7 implementa uma memória de via dupla:

• Caminho do Contexto Ativo: Retém os turnos diretos do chat, blocos de código e arquivos.
• Caminho da Memória de Raciocínio: Comprime e armazena trilhas e raciocínios intermediários.

Quando o agente precisa de detalhes históricos do raciocínio, ele consulta a memória de raciocínio comprimida em vez de varrer logs de conversa brutos, preservando a janela de contexto ativo para as alterações reais de código e entradas do usuário.

Gerenciamento Ativo de Contexto para Enxames de Agentes

Enquanto os provedores de modelos aprimoram as arquiteturas de contexto, engenheiros de software que constroem fluxos agenticos devem praticar uma engenharia de contexto defensiva. Veja a seguir os principais padrões usados para construir enxames de programação robustos:

1. Poda Ativa de Contexto (Janela Deslizante com Resumo)

Nunca envie todo o log de conversas bruto para o modelo. Implemente uma janela deslizante dos últimos 4 ou 5 turnos. Para os turnos mais antigos, execute uma etapa de resumo em segundo plano: "Resuma as decisões tomadas nos turnos 1 a 10 em menos de 150 palavras." Adicione este resumo ao prompt do sistema.

2. Representação do Repositório (AST vs Arquivos Brutos)

Não envie arquivos de código brutos de todo o projeto para o modelo. Em vez disso, construa um mapa leve do repositório usando Árvores de Sintaxe Abstrata (AST) para extrair apenas assinaturas de funções, interfaces de classes e caminhos de diretórios. Envie este esquema como um bloco de contexto armazenado em cache, e forneça o conteúdo do arquivo bruto apenas quando o agente solicitar explicitamente a edição dele.

3. Estado Guiado por Ferramentas (Sem Variáveis no Chat)

Evite armazenar o estado do sistema, variáveis de configuração ou a estrutura do banco de dados no histórico de conversas. Use ferramentas para salvar e ler estados. Por exemplo, em vez de pedir ao agente para lembrar a versão atual do banco de dados, forneça uma ferramenta chamada get_database_version() que consulte o banco diretamente. Isso economiza tokens preciosos de atenção.

Demonstração Interativa: Calculadora de Peso de Contexto

Para ajudar você a compreender como seu repositório escala na janela de atenção, utilize esta ferramenta interativa. Insira os parâmetros estimados do seu projeto para visualizar o consumo de tokens e o ponto onde a degradação da atenção começa.

Praticando uma higiene rígida de contexto e aproveitando arquiteturas de cache, você pode construir agentes de IA que permanecem precisos, rápidos e alinhados às regras do seu código, mesmo em sessões de programação longas e complexas.