Janela de Contexto (Context Window)

1. Visão geral do conceito e problema sistêmico

Desenvolvedores iniciantes frequentemente percebem a janela de contexto como um análogo ao disco rígido: um espaço onde se pode despejar qualquer quantidade de documentação para que o modelo "simplesmente saiba" tudo.

No entanto, na física real das redes neurais, a janela de contexto é a memória RAM da GPU (VRAM), envolvida em cálculos matriciais intensivos:

1. Complexidade quadrática da atenção: No mecanismo Attention clássico, a relação é calculada entre cada par de tokens ($O(N^2)$). Aumentar o comprimento da entrada em 10 vezes exige 100 vezes mais recursos computacionais na etapa de prefill.
2. Limitações de hardware de memória: Quando o comprimento do diálogo atinge centenas de milhares de tokens, o tamanho do KV-cache excede a capacidade da memória de vídeo da placa gráfica (Out of Memory - OOM).
3. Limite de extrapolação posicional: O modelo não consegue interpretar adequadamente posições de tokens fora dos limites de seu treinamento sem métodos especiais de interpolação (RoPE / YaRN).

A Janela de Contexto (Context Window) define o horizonte da memória de trabalho ativa do sistema: tudo o que entra na janela participa do cálculo de probabilidades; tudo o que fica fora dela fisicamente não existe para o modelo.

2. Taxonomia arquitetural e modelo mental

O trabalho com a janela de contexto divide-se em duas fases de computação e otimizações correspondentes:

• 1. Fase de Prefill (Prefill Phase): Processamento paralelo de toda a solicitação de entrada do usuário. É uma fase limitada por computação (Compute-bound), otimizada por tecnologias como FlashAttention-2/3, que eliminam acessos desnecessários à memória global da GPU.
• 2. Fase de Decodificação (Decode Phase): Geração sequencial de novos tokens, um por passo. É limitada pela largura de banda da memória (Memory-bandwidth bound), onde a velocidade depende da recuperação de vetores do KV-cache.
• 3. Arquiteturas de longo contexto:
  • RoPE (Rotary Position Embeddings): embeddings posicionais rotativos que permitem escalar a janela de 8K para 1M tokens através de escalonamento de frequência.
  • Ring Attention: distribuição do cálculo do mecanismo de atenção por um anel de dezenas de servidores GPU para processar sequências de milhões de tokens.
• 4. Estrutura do orçamento da janela: Total Window = System Prompt + Long-term Memory + Ingestion Files + History + Tools Output + Max Generation Tokens.

3. Pipeline técnico e mecânica interna

O ciclo de vida do contexto atravessando o transformer:

1. Tokenization & BPE Mapping (Tokenização): A string bruta de código ou texto é traduzida em um vetor numérico de IDs de tokens através do dicionário BPE/Tiktoken.
2. Positional Encoding Injection (Injeção de coordenadas): Cada token recebe um vetor de posição na sequência (via matrizes de rotação RoPE).
3. Multi-Head Self-Attention & KV Cache Allocation (Cálculo de atenção): As matrizes Query, Key e Value são calculadas. Os vetores $K$ e $V$ são gravados no buffer VRAM do KV-cache para evitar recálculos nos passos subsequentes.
4. Context Length Enforcement (Controle de limites): Se o número total de tokens exceder max_context_length, o runtime lança um erro 400 BadRequest: context_length_exceeded ou trunca automaticamente as mensagens mais antigas (Sliding Window Truncation).

4. Cenários de engenharia prática em produção

01. In-Context Learning sobre todo o repositório do projeto

Carregar 200.000 tokens da base de código diretamente na janela do modelo (Cursor / Claude Code). O modelo vê todos os tipos, imports e padrões arquiteturais simultaneamente, gerando um novo módulo com preservação perfeita das convenções do projeto.

02. Análise de pacotes jurídicos de M&A e auditorias

Transmitir um pacote de contratos de 500 páginas para a janela do Gemini 2.5/3 Pro (1M tokens) para buscar contradições mútuas, condições financeiras inconsistentes e obrigações ocultas sem perda de contexto entre documentos.

03. Otimização econômica via Prompt Caching

Em assistentes de longa duração, o system prompt e a documentação da API (por exemplo, 40.000 tokens) são cacheados pelo provedor (Anthropic/OpenAI). Isso faz com que cada solicitação subsequente seja processada 4 vezes mais rápido e custe 90% menos.

5. Armadilhas, erros comuns e segurança

• Truncamento silencioso de contexto (Silent Truncation): Alguns clientes ingênuos descartam automaticamente o início do diálogo ao se aproximarem do limite. Se lá estavam regras importantes de segurança do sistema, o modelo torna-se vulnerável.
• Out of Memory (OOM) em servidores self-hosted: Executar Llama 3 70B em um nó próprio com 80GB de VRAM funciona bem em testes curtos, mas falha com erro crítico de memória quando o usuário envia uma solicitação de 64K tokens devido ao inchaço do KV-cache. Sempre limite max_model_len no vLLM.
• Crescimento exponencial da fatura: O envio descontrolado do histórico a cada mensagem faz com que um chat simples de 20 réplicas gere centenas de milhares de tokens de entrada cobrados.