Quando falamos de LLM, o "contexto" é o conjunto de tudo o que enviamos ao modelo a cada chamada: o system prompt, o histórico da conversa, os documentos recuperados via RAG, os resultados de ferramentas, as instruções de negócio. Tudo isso forma a janela de contexto, o único espaço de memória que o modelo possui no momento de gerar sua resposta.
Um modelo como GPT-4o ou Claude 3.5 aceita hoje janelas de 128K a 200K tokens. Em teoria, bastante espaço. Na prática, isso dá a ilusão de que podemos colocar tudo lá dentro sem consequências. É aí que o problema começa.
O contexto, o que é exatamente?
A janela de contexto agrega todas as fontes de informação disponíveis: system prompt com as instruções de negócio, histórico da conversa em andamento, chunks recuperados via busca vetorial (RAG), e resultados de ferramentas (API, SQL, funções). O modelo gera sua resposta unicamente a partir do que recebe nessa janela.
Sua qualidade determina diretamente a qualidade do output. Não o tamanho do modelo. Não o número de parâmetros. A qualidade do contexto.
Context bloat: quando mais se torna menos
O context bloat é o acúmulo descontrolado de informação na janela de contexto. Acontece naturalmente, progressivamente, muitas vezes sem que percebamos.
Histórico de conversa não limpo. Uma sessão de chatbot acumula 30 trocas desde o início. As primeiras mensagens já não são mais relevantes, mas continuam lá, ocupando tokens e diluindo o sinal útil.
RAG generoso demais. O pipeline recupera os 10 chunks mais próximos semanticamente, mesmo quando 3 bastariam. Resultado: o modelo recebe informações contraditórias ou redundantes, e a resposta se perde na massa.
System prompts que incham. Ao longo das iterações, a equipe de produto adiciona regras, exemplos, exceções. O prompt passa de 200 tokens para 3.000. Cada adição parece justificada. O conjunto se torna ingerenciável.
Resultados de ferramentas verbosos. Uma chamada de API retorna um JSON de 2.000 tokens, dos quais 1.800 não são úteis para a tarefa. Tudo é injetado mesmo assim porque ninguém teve tempo de filtrar.
Estudos empíricos com GPT-4 mostram que a precisão de recuperação de informação cai significativamente quando os elementos relevantes estão perdidos em um contexto amplo. É o lost in the middle: o modelo processa melhor o que aparece no início ou no final do contexto. Tudo o que está no meio é frequentemente ignorado.
A melhoria contínua do contexto, na prática
Não é um problema que se resolve uma vez no início do projeto. É uma disciplina operacional, da mesma forma que o monitoramento de performance ou a gestão de dependências.
Auditoria regular do system prompt. Pegar o prompt de produção, identificar cada bloco de instruções e se perguntar: essa regra ainda é necessária? Um bom prompt tem de 400 a 800 tokens bem construídos, não 3.000 tokens desordenados.
Compressão ativa do histórico. Em vez de cortar brutalmente o histórico além de um certo comprimento, podemos pedir ao próprio modelo que produza um resumo estruturado das trocas passadas. Esse resumo substitui as 20 últimas mensagens verbosas. Preservamos a memória, reduzimos o ruído.
Seleção rigorosa nos pipelines RAG. O número de chunks recuperados deve ser calibrado dinamicamente conforme a complexidade da consulta, não fixado em 5 ou 10 por padrão. Um reranker (Cohere, BGE Reranker) permite manter apenas os chunks realmente relevantes. E a relevância se mede, não é uma intuição.
Limpeza dos resultados de ferramentas. Antes de injetar um resultado de API ou de consulta SQL no contexto, uma etapa de transformação deve extrair apenas o que é útil para a tarefa em andamento. Isso é trabalho de engenharia, não prompt engineering.
Métricas de contexto em produção. Acompanhar a evolução da razão tokens úteis / tokens totais. Rastrear a distribuição do tamanho dos contextos nas chamadas reais. Se a média sobe sem razão funcional, é um sinal de alerta.
O que custa não fazer nada
As consequências do context bloat não são abstratas.
| Dimensão | Contexto não controlado | Contexto otimizado |
|---|---|---|
| Custo de inferência | x2 a x4 (cada token input/output é cobrado) | Previsível, razão token útil controlada |
| Latência | +800ms a 2s, prefill mais longo em contexto amplo | Estável, tempo de resposta previsível |
| Qualidade do output | Degradação progressiva, alta variância nos casos complexos | Estável, menos variância nos casos limites |
| Alucinações | Risco elevado, contradições internas não detectadas | Reduzido, contexto coerente, menos conflitos |
| Manutenibilidade | Difícil, prompts de 3K tokens ilegíveis | Controlada, cada parâmetro se torna uma alavanca de gestão |
Por que isso é ignorado
A resposta honesta: porque o sistema funciona mesmo assim. Não perfeitamente, mas bem o suficiente para que ninguém soe o alarme.
O context bloat é um problema de degradação progressiva, não de falha abrupta. Não há alerta nos logs. Não há exceção lançada. As respostas continuam sendo geradas, os usuários continuam usando o sistema. A qualidade cai lentamente, sem sinal claro.
É também um problema que exige ter pensado na avaliação previamente. Se você não tem uma baseline de qualidade definida, casos de teste, métricas de output, não consegue detectar uma regressão. Na maioria dos projetos que vemos, essa baseline não existe no momento de ir para produção.
O que muda quando tratamos isso a sério
Gerenciar o contexto como um ativo a otimizar continuamente é uma postura que muda várias coisas.
Primeiro, os custos de inferência se tornam previsíveis e controlados. Sabemos o que pagamos e por quê. Podemos fazer arbitragens conscientes entre qualidade, latência e custo. Depois, a qualidade dos outputs é mais estável. Menos variância, menos casos limites que se comportam de forma estranha.
E sobretudo, as equipes retomam o controle. Em vez de sofrer degradações incompreensíveis, elas têm alavancas concretas: o tamanho do prompt, o número de chunks RAG, a política de compressão do histórico. Esses parâmetros se tornam variáveis de gestão, não constantes congeladas desde o primeiro deploy.
O contexto de um LLM não é um detalhe de implementação. É a principal alavanca de qualidade e custo de um sistema de IA em produção. Deixá-lo crescer sem controle porque "funciona mesmo assim" é aceitar uma degradação lenta e custosa. Não é um problema de modelo. É um problema de engenharia operacional.
