Engenharia de Contexto
A engenharia de prompts é sobre as palavras que você escolhe. A engenharia de contexto é sobre o espaço de trabalho que você entrega ao modelo — o que há nele, em que ordem está e o que você deliberadamente deixou de fora.
A distinção importa porque uma janela de contexto não é um bloco de notas. É um recurso limitado, caro e atencional. Como você a preenche muda no que o modelo se concentra, quanto isso lhe custa e se ela permanece útil à medida que as sessões crescem.
O orçamento de contexto
Todo modelo tem um tamanho máximo de contexto — um teto rígido medido em tokens. Pense nele como um orçamento. Você o gasta em:
- Seu prompt de sistema e instruções permanentes
- Documentos recuperados, trechos de base de código, definições de ferramentas
- Histórico da conversa
- A saída do modelo (que também conta contra a janela em sessões de múltiplos turnos)
Quando você se esgota, algo tem que ceder. Ou conteúdo antigo é descartado, ou a sessão bate numa parede.
A maioria dos guias para iniciantes trata a janela de contexto como "mais é melhor". A engenharia de contexto a trata como um recurso a ser alocado com cuidado: gaste-o no que o modelo realmente precisa para este turno, não em tudo que pode ser relevante.
Apodrecimento de contexto e "perdido no meio"
Há um fenômeno bem documentado em LLMs de contexto longo: os modelos dão atenção desproporcional ao conteúdo perto do início e do fim do seu contexto, e sua capacidade de recordar conteúdo enterrado no meio se degrada. Pesquisadores que estudaram esse efeito o chamaram de "perdido no meio".
A consequência prática: se você empilhar um contexto de 100.000 tokens com documentos e enterrar a instrução mais crítica na posição 60.000, o modelo pode efetivamente ignorá-la — não porque seja incapaz de ler tão longe, mas porque a atenção não é distribuída uniformemente ao longo da janela.
O "apodrecimento de contexto" é o padrão mais amplo: à medida que uma sessão cresce, a qualidade das respostas tende a derivar. Instruções iniciais ficam diluídas. O vai e vem repetido abafa a tarefa original. O modelo começa a hesitar, a se repetir ou a perder o fio do que você realmente pediu.
Esses não são bugs que você consiga corrigir totalmente com um prompt melhor. São propriedades estruturais de como a atenção funciona em escala. A resposta da engenharia é manter o contexto menor e mais afiado, não preenchê-lo e torcer.
A ordem importa
Onde você coloca o conteúdo é tão importante quanto o que você inclui. Boa prática consolidada:
| Posição | O que colocar lá |
|---|---|
| Bem no topo (prompt de sistema) | Instruções estáveis e duráveis. Persona, regras, requisitos de formato. |
| Após o prompt de sistema | A tarefa atual, em termos simples. |
| Logo antes do último turno do usuário | O contexto mais crítico e específico para esta requisição exata. |
| Meio | Documentos de apoio, trechos recuperados — ordenados por relevância, não por cronologia. |
| Histórico da conversa | Apenas o necessário para a continuidade. Pode agressivamente. |
A regra geral: quanto mais perto do turno atual, mais atenção recebe. Instruções críticas que vivem apenas no meio de um histórico longo estão em risco.
Recuperação em vez de empilhamento
A tentação é colocar tudo: todos os documentos, a base de código inteira, a conversa inteira. Resista.
A melhor abordagem é a recuperação seletiva: identifique o que o modelo realmente precisa para esta requisição específica e injete apenas isso. Um trecho bem recuperado de 2.000 tokens do documento certo supera um despejo de 40.000 tokens onde a resposta está em algum lugar no meio.
É por isso que a geração aumentada por recuperação (RAG) existe — não apenas para superar limites de contexto, mas para melhorar a qualidade mantendo o contexto curado.
Para sessões interativas, a mesma lógica se aplica: em vez de acumular tudo, periodicamente compacte ou limpe o histórico para remover conteúdo que não é mais relevante para a tarefa atual. Os comandos /compact e /clear do Claude Code são ferramentas de engenharia de contexto, não apenas de gerenciamento de sessão.
O ângulo do custo
Tokens que você envia são tokens que você paga — tanto em dinheiro quanto em latência. Empilhar contexto com material vagamente relevante infla os dois. Engenharia de contexto e eficiência de custo são o mesmo problema.
Mais concretamente:
- Um prompt de sistema inchado que você copia e cola de um template é pago em cada chamada.
- Histórico antigo de conversa que você carrega adiante porque "pode ser útil" é pago em cada chamada.
- Documentos que você injeta "só por garantia" são pagos em cada chamada.
Aparar o que não precisa estar lá é simultaneamente melhor para a qualidade e mais barato de rodar.
Táticas práticas para usuários do Claude
No Claude.ai:
- Use conversas distintas para tarefas distintas. Não deixe uma tarde de tangentes poluir o contexto de um projeto focado.
- Resuma threads longas antes de fazer uma pergunta complexa que dependa delas. Um resumo explícito muitas vezes é mais útil do que o histórico bruto.
- Coloque a coisa específica que você quer no fim de uma mensagem longa, não enterrada no meio.
No Claude Code:
- Mantenha seu arquivo
CLAUDE.mdenxuto. Cada linha nele é injetada em cada sessão. Veja CLAUDE.md e Gerenciamento de Contexto. - Use
/clearao mudar para uma tarefa genuinamente diferente. Use/compactquando quiser continuar, mas a sessão estiver crescendo. - Referencie arquivos por caminho em vez de colar seu conteúdo quando o arquivo completo não for necessário para a etapa atual.
No nível da API:
- Projete prompts de sistema para conter apenas o que toda requisição realmente precisa. Mova instruções específicas da tarefa para o turno do usuário.
- Para casos de uso com muitos documentos, recupere e injete os trechos relevantes em vez de carregar um corpus inteiro.
- Estruture o prompt de forma que o prefixo estável e reutilizável venha primeiro — isso também habilita o cache de prompts, que é um companheiro natural da engenharia de contexto.
A mudança de mentalidade
A engenharia de prompts pergunta: "O que eu deveria dizer?" A engenharia de contexto pergunta: "O que o modelo deveria ver, em que ordem, e o que eu deveria deliberadamente manter de fora?"
A segunda pergunta é mais difícil, mas é a que realmente determina a qualidade em escala.