O que é engenharia de contexto?

Engenharia de contexto é decidir o que ocupa a janela de contexto do modelo a cada chamada: instruções do sistema, definições de ferramentas, histórico da sessão, documentos recuperados e a pergunta. A engenharia de prompts cuida de uma dessas partes, o texto que você escreve. A engenharia de contexto cuida do conjunto e de como repartir o espaço entre as partes.

O modelo não vê a divisão. Ele recebe uma sequência de tokens e responde. Quem decide o que está nessa sequência é o seu código.

As cinco fatias

A separação entre “instrução do sistema” e “resultado de ferramenta” existe no seu código e nos delimitadores da API, não na atenção do modelo. O que existe de verdade é um teto de tokens e cinco tipos de conteúdo disputando o espaço abaixo dele.

Instruções do sistema. Papel, regras, formato de saída, política de recusa, critério de quando usar cada ferramenta. Em produção raramente é curto: um system prompt de agente passa de 2.000 tokens só com as regras. É a fatia mais estável entre chamadas, e por isso a que melhor aproveita cache.

Definições de ferramentas. Cada ferramenta entra como um schema com nome, descrição e parâmetros. Uma ferramenta bem descrita custa algumas centenas de tokens; quinze delas custam alguns milhares, em toda chamada, inclusive nas iterações em que o modelo não chama nenhuma.

Histórico. Tudo que já foi dito na sessão, incluindo o que o modelo respondeu e o que as ferramentas devolveram. Cresce a cada iteração e não para sozinho. É a fatia que ninguém orça e a que estoura primeiro.

Documentos e resultados. Trechos recuperados por busca, arquivos lidos, saída de comando, resposta de API. Um git diff grande, um log de teste que falhou, o HTML de uma página: qualquer um desses passa de 10.000 tokens com facilidade.

A pergunta. O que o usuário acabou de escrever. É quase sempre a menor fatia da janela, e é a única que a maioria das equipes revisa com atenção.

A soma tem um teto. Modelos comerciais em julho de 2026 anunciam janelas entre 200 mil e 1 milhão de tokens. O limite anunciado é a parte fácil do problema.

Repare em como as fatias se comportam ao longo de uma sessão. Duas são fixas e você escreve as duas. Uma cresce sozinha a cada iteração. Uma varia conforme o que o modelo resolve buscar. A última é minúscula. A engenharia de contexto acontece quase toda nas duas do meio, que são justamente as que ninguém escreveu.

Por que o termo apareceu em 2025

O nome é recente. Circulou em junho de 2025 em posts de Tobi Lütke e Andrej Karpathy, e ganhou tratamento sistemático quando a Anthropic publicou um guia de engenharia sobre o assunto, em setembro do mesmo ano¹. A prática é mais velha que o nome. O que mudou foi a proporção.

Numa chamada única de chat, o que você escreve é praticamente todo o contexto. Você controla o que o modelo lê, e melhorar a resposta significa melhorar aquele texto. Isso é engenharia de prompts, e a disciplina inteira cabe nela.

Num agente que roda vinte iterações com quinze ferramentas, o que você escreve é o system prompt. Todo o resto entra em tempo de execução: o modelo decide chamar uma busca, a busca devolve 8.000 tokens, isso volta para a janela, o modelo lê e decide chamar outra coisa. Na décima iteração, a maior parte da janela é conteúdo que nenhuma pessoa escreveu nem revisou.

A pergunta útil deixa de ser “como escrevo esta instrução” e passa a ser “o que deveria estar na janela agora, e o que já não deveria estar”. As duas disciplinas continuam existindo e resolvem problemas diferentes, o que rende uma comparação própria em engenharia de contexto ou de prompt.

Contexto longo degrada antes do limite

Encher a janela porque ela é grande não é uma estratégia. Três resultados explicam por quê.

Um trabalho de 2023 mediu o efeito da posição. Em perguntas sobre múltiplos documentos e em recuperação de chave-valor, o acerto é mais alto quando a informação relevante está no começo ou no fim da entrada, e cai quando ela fica no meio. O efeito aparece inclusive em modelos vendidos como de contexto longo². É o fenômeno que ficou conhecido como lost in the middle.

Em 2024, o benchmark RULER testou 17 modelos em 13 tarefas de contexto longo, indo além do teste de agulha no palheiro para incluir rastreamento em múltiplos saltos e agregação. Todos os 17 anunciavam janela de 32 mil tokens ou mais. Metade não sustentou desempenho aceitável já em 32 mil³.

Em 2025, o NoLiMa atacou um viés dos testes anteriores: quando a pergunta e a informação buscada compartilham as mesmas palavras, o modelo resolve por casamento literal e o teste fica fácil demais. Com sobreposição lexical mínima, 11 de 13 modelos que anunciam pelo menos 128 mil tokens caíram abaixo de metade do próprio desempenho em contexto curto ao chegar em 32 mil. O GPT-4o, um dos melhores da leva, foi de 99,3% para 69,7%⁴.

A leitura razoável é que a janela anunciada é um limite de alocação, não uma promessa de qualidade. O número que importa para o seu caso é onde a sua tarefa começa a degradar, e ele é sempre menor.

As cinco perguntas

Quanto cabe. O limite físico da janela, quanto ele custa e como o modelo se comporta perto dele. É a única pergunta com resposta numérica dada pelo provedor.

O que degrada. Onde a qualidade cai antes do limite, e por qual motivo. Posição, volume de distratores e acúmulo de histórico irrelevante são causas diferentes, com correções diferentes.

Como repartir. Quanto do espaço vai para instruções, ferramentas, histórico e recuperação. Sem um orçamento explícito, a repartição é definida por acidente, e quem cresce mais rápido leva tudo.

O que sai. Toda sessão longa chega no ponto em que algo precisa ser descartado ou resumido. A compactação é a técnica central aqui, e a ideia é antiga: um sistema de 2023 já tratava o contexto como memória paginada, movendo conteúdo entre a janela e um armazenamento externo, no molde de um sistema operacional⁵.

Em que ordem. Onde colocar cada bloco dentro da janela, dado que as pontas são lidas melhor que o meio, e como delimitar os blocos para o modelo saber o que é instrução e o que é dado.

Buscar na hora ou carregar antes

A decisão mais concreta da disciplina, e a que mais aparece quando alguém está montando o primeiro agente, é o que colocar na janela antes de começar.

Pré-carregar significa juntar tudo que talvez seja útil e mandar de uma vez: o esquema do banco, os cinco documentos de política, o arquivo de configuração. Fica previsível, entra no prefixo estável e é barato de manter com cache. O preço é gastar espaço com o que não será consultado naquela execução, e esse espaço sai do que sobra para o trabalho de verdade.

Carregar sob demanda significa dar ao modelo uma ferramenta de leitura e passar só os identificadores: os nomes das tabelas, os títulos das políticas, a árvore de diretórios. O modelo pede o que precisa. Você gasta menos janela e paga em latência, porque cada leitura é uma ida e volta a mais, e assume o risco de o modelo pedir a coisa errada ou não pedir nada.

A regra prática que sobrevive ao contato com produção: pré-carregue o que é usado em quase toda execução, deixe o resto atrás de uma ferramenta, e faça o índice caber em poucas centenas de tokens. Uma lista de vinte caminhos de arquivo custa quase nada e resolve a maior parte dos casos em que o modelo precisaria adivinhar.

O erro comum é tratar isso como decisão única para o agente inteiro. Costuma ser decisão por tipo de conteúdo: o esquema do banco entra sempre, o histórico de tickets do cliente entra sob demanda, e a política de reembolso entra dependendo da rota. O detalhe de cada estratégia está em buscar na hora ou pré-carregar.

Onde isso falha

A parte que os textos introdutórios costumam omitir.

Você não sabe o que perdeu ao compactar. Um resumo de histórico parece bom até a iteração 30, quando o agente refaz uma decisão que já tinha tomado porque a justificativa ficou de fora do resumo. O erro só aparece depois, e não aparece nos testes curtos.

A evidência sobre ordenação é fina. Que as pontas são lidas melhor que o meio está medido. Que colocar as instruções depois dos documentos rende mais que antes é uma heurística que varia por modelo e some quando a família de modelos muda. Trate como algo a medir no seu caso, não como regra.

Benchmark sintético não prevê o seu caso. Um modelo que acerta agulha no palheiro em 1 milhão de tokens pode falhar em 32 mil quando a tarefa exige agregar informação espalhada. Esse é exatamente o resultado do RULER, e é o motivo de “suporta 1M de contexto” não responder nada sobre a sua aplicação.

Às vezes o contexto não é o problema. Uma parte considerável do esforço de engenharia de contexto é gasto em tarefas que o modelo simplesmente não sabe fazer. Antes de otimizar a janela, rode a tarefa com o contexto ideal montado à mão. Se falhar assim, o problema é outro.

Ferramenta demais confunde e custa. Quinze ferramentas gastam tokens em toda chamada e aumentam a chance de escolha errada. Cortar cinco ferramentas pouco usadas costuma render mais que qualquer ajuste de prompt.

O cache empurra na direção errada. Como o prefixo estável é cobrado mais barato quando reaproveitado, existe um incentivo a nunca reescrever o começo da janela. Isso preserva o cache e preserva também o lixo que já está lá.

Por onde começar

1. Meça por categoria. Registre, em cada chamada, quantos tokens foram para system prompt, definições de ferramentas, histórico e documentos. Sem isso você vai otimizar a fatia errada.
2. Ataque a maior primeiro. Em quase todo agente é histórico ou resultado de ferramenta, e quase nunca é o system prompt, que é onde as equipes olham.
3. Corte ferramentas. Remova as que foram chamadas menos de uma vez a cada cem execuções e encurte as descrições das que sobraram.
4. Trunque na origem. Resultado de ferramenta deve vir cortado por quem chama a ferramenta, com um identificador para buscar o resto. Um log de 40 mil tokens vira 2 mil linhas relevantes e um caminho de arquivo.
5. Compacte por limiar, não por estouro. Defina um ponto, algo como 60% da janela, e resuma o histórico antigo ali, preservando decisões tomadas e pendências abertas.
6. Ponha o crítico nas pontas. Instruções no começo, pergunta atual no fim, volume no meio.
7. Refaça a medição a cada troca de modelo. O ponto onde a degradação começa muda com o modelo, e sua configuração foi calibrada para o anterior.

A conta em tokens

O custo de contexto num agente não é linear, e isso pega quase todo mundo de surpresa. Cada iteração reenvia tudo que veio antes. Se o histórico cresce 5 mil tokens por iteração, a vigésima chamada processa 100 mil tokens de entrada, e o total processado na tarefa inteira é a soma da série: cerca de 1 milhão de tokens, não os 100 mil da última chamada.

Reduzir o crescimento por iteração de 5 mil para 1,5 mil derruba esse total para algo em torno de 315 mil. É o mesmo agente, com o mesmo modelo, resolvendo a mesma tarefa por menos de um terço do preço, e normalmente com acerto maior, porque a janela ficou mais limpa.

O prompt caching muda a parte estável dessa conta. System prompt e definições de ferramentas são reenviados em toda iteração, e os provedores cobram bem menos por token lido de cache do que por token novo: em meados de 2026, entre um décimo e um quarto do preço de entrada, dependendo do provedor. Vale conferir a razão atual antes de dimensionar qualquer coisa, porque é o número que mais muda.

O que o cache não resolve é o histórico, que é novo a cada iteração por definição. Essa parte só melhora cortando conteúdo.

Footnotes

1. O guia de engenharia da Anthropic, publicado em setembro de 2025, define a disciplina como curar o conjunto de tokens disponível durante a inferência e descreve quatro técnicas: compactação, notas estruturadas fora da janela, subagentes e recuperação sob demanda. ↩

2. Liu et al. (2023) mediram desempenho em perguntas sobre múltiplos documentos e em recuperação de chave-valor, variando a posição da informação relevante. A queda no meio aparece inclusive em modelos de contexto longo. ↩

3. Hsieh et al. (2024) avaliaram 17 modelos em 13 tarefas, incluindo rastreamento em múltiplos saltos e agregação, que vão além do teste de recuperação simples. ↩

4. Modarressi et al. (2025) construíram um conjunto de testes com sobreposição lexical mínima entre pergunta e resposta, forçando associação latente em vez de casamento de palavras. ↩

5. Packer et al. (2023) propuseram gerenciar a janela como memória virtual, movendo conteúdo entre a janela e um armazenamento externo por decisão do próprio modelo. ↩