O que É Engenharia de Contexto? Dê à IA a Informação Certa, Não Mais Palavras

Por uns dois anos, o conselho padrão foi simples: escreva um prompt melhor. Aí as pessoas passaram a usar assistentes que leem arquivos, pesquisam na web e usam ferramentas em dezenas de etapas, e surgiu outro problema. O modelo não falhava porque a instrução estava mal escrita. Falhava porque estava olhando para a informação errada, ou para informação demais. Engenharia de contexto (em inglês, "context engineering") foi o nome que pegou para resolver isso. Este guia explica o que é engenharia de contexto, como ela se diferencia da engenharia de prompt, o que de fato entra no contexto de um modelo, por que mais não é melhor e como aplicá-la, seja no chat com o ChatGPT, seja construindo um agente.

O que engenharia de contexto significa na prática

Um modelo de linguagem não guarda memória entre solicitações e não vê a sua tela, os seus arquivos nem a sua empresa. Toda vez que responde, ele trabalha apenas com o texto (e as imagens) que recebe naquela solicitação: a sua janela de contexto. Engenharia de contexto é a prática de decidir o que entra nessa janela — o que incluir, o que deixar de fora, em que formato e em que ordem — para que o modelo tenha o que precisa para a próxima etapa e quase nada além disso.

O termo ganhou força em junho de 2025, quando o CEO da Shopify, Tobi Lütke, disse que o preferia a "engenharia de prompt", e Andrej Karpathy concordou, descrevendo a prática como "the delicate art and science of filling the context window with just the right information for the next step" (em tradução livre: "a delicada arte e ciência de preencher a janela de contexto exatamente com a informação certa para a próxima etapa"). Mais tarde, a equipe de engenharia da Anthropic a definiu como o conjunto de estratégias para selecionar e manter o melhor conjunto possível de tokens enquanto um modelo está trabalhando. Palavras diferentes, mesma ideia: o prompt que você digita é só uma parte do que o modelo lê, e muitas vezes a menor.

Uma imagem útil: o modelo é um prestador de serviço muito competente que chega toda manhã com amnésia total. O que estiver na mesa quando ele se sentar é tudo o que sabe sobre o trabalho. Engenharia de contexto é preparar essa mesa.

Engenharia de contexto vs. engenharia de prompt

Uma não concorre com a outra. A engenharia de prompt trata de como você formula uma instrução: o papel, a tarefa, as restrições e o formato. Nossos fundamentos de engenharia de prompt cobrem essa parte. A engenharia de contexto fica uma camada acima e cuida de tudo o que está em volta da instrução.

• Alcance — a engenharia de prompt molda uma mensagem. A engenharia de contexto molda o pacote inteiro que o modelo recebe: system prompt, histórico da conversa, documentos, exemplos e resultados de ferramentas.
• Momento — um prompt costuma ser escrito uma vez. O contexto muitas vezes é dinâmico: muda a cada turno da conversa e a cada etapa da execução de um agente.
• A falha que resolve — a engenharia de prompt resolve o "ele entendeu errado o que eu pedi". A engenharia de contexto resolve o "ele entendeu, mas não tinha os fatos" e o "ele tinha tanto material que se perdeu".

Um prompt bem escrito com o contexto errado ainda gera uma resposta confiante e errada. Um prompt simples com exatamente o contexto certo muitas vezes funciona de primeira. Por isso o termo pegou entre quem constrói produtos de IA, mas vale igualmente para quem usa um assistente de chat no trabalho.

O que entra no contexto de um modelo

Num chat ou num app, o contexto é montado com os mesmos poucos ingredientes:

• Instruções — o system prompt ou as instruções personalizadas que definem o papel, as regras e o tom. Nosso guia de system prompts mostra como escrevê-los.
• A tarefa — o seu pedido atual, de preferência com o objetivo e o público, e não só a ação.
• Exemplos — algumas amostras de um bom resultado. Dois ou três exemplos bem escolhidos muitas vezes rendem mais do que uma página de regras, e nosso texto sobre prompts few-shot vs. zero-shot explica o porquê.
• Conhecimento — os documentos, dados ou resultados de busca de onde a resposta deve sair, colados por você ou buscados automaticamente (o que costuma se chamar RAG, geração aumentada por recuperação).
• Histórico e memória — os turnos anteriores da conversa e tudo o que a ferramenta salvou sobre você ou sobre o projeto.
• Ferramentas e seus resultados — as descrições do que o modelo pode fazer (pesquisar, executar código, ler um arquivo) e o resultado que volta cada vez que ele faz isso.
• Formato de saída — a estrutura que você espera receber, como uma tabela, um JSON ou um limite de palavras.

Cada um desses itens ocupa espaço, e todos disputam a atenção do modelo. Boa parte da engenharia de contexto é equilibrá-los: o suficiente de cada um para a tarefa, e nada que puxe para outro lado.

Por que mais contexto não é melhor

As janelas de contexto cresceram para centenas de milhares de tokens, e alguns modelos aceitam um milhão ou mais. É tentador colar tudo e deixar o modelo se virar. Na prática, isso costuma sair pela culatra, por quatro motivos:

• A atenção se dilui — o conhecido estudo "Lost in the Middle" mostrou que os modelos aproveitam muito melhor a informação do começo e do fim de uma entrada longa do que a que fica enterrada no meio. A Anthropic descreve um efeito parecido como context rot (algo como "apodrecimento do contexto"): à medida que o contexto cresce, o modelo fica pior em lembrar e usar cada parte dele.
• Distração — material irrelevante não é neutro. Um documento meio relacionado é um convite para puxar uma frase que não cabe na resposta.
• Conflito — duas versões de uma política, uma instrução antiga e uma nova, uma nota que contradiz os dados. O modelo pode seguir qualquer uma, ou misturar as duas, e nem sempre avisa que precisou escolher.
• Custo e velocidade — cada token é processado a cada chamada, então um contexto inchado deixa os apps mais lentos e mais caros de rodar.

Quando um modelo competente dá uma resposta ruim, a causa costuma ser um de quatro problemas de contexto: algo estava faltando, algo estava desatualizado, duas coisas se contradiziam ou a parte útil estava enterrada no meio do ruído. Descubra qual deles é antes de reescrever o prompt pela quinta vez. A falta de contexto também é grande causa das alucinações de IA: quando os fatos não estão lá, o modelo preenche a lacuna com algo que soa plausível.

Engenharia de contexto no chat do dia a dia

Você não precisa construir nada para se beneficiar. Se usa o ChatGPT, o Claude ou o Gemini no trabalho, já faz engenharia de contexto toda vez que decide o que colar na conversa, bem ou mal. Alguns hábitos fazem uma diferença real:

• Comece com um briefing — antes do pedido, dê o contexto de que um colega novo precisaria: para quem é, o que já foi decidido e como é um bom resultado.
• Cole a fonte, não o seu resumo dela — se a resposta precisa bater com um documento, inclua a parte relevante desse documento.
• Corte antes de colar — os três parágrafos relevantes de um contrato funcionam melhor do que o PDF inteiro de 40 páginas.
• Cuide do que fica salvo — instruções personalizadas, projetos com arquivos enviados e memórias salvas são contexto que carrega automaticamente. Mantenha tudo curto e atualizado: uma memória sobre o emprego que você deixou no ano passado continua sendo contexto.
• Recomece quando a conversa desandar — um chat longo acumula ideias abandonadas e erros já corrigidos. Quando as respostas misturarem material antigo, abra um chat novo com um resumo limpo.

Um briefing reutilizável fica assim:

Quando a resposta precisa sair de um conjunto específico de documentos, uma ferramenta baseada nas suas próprias fontes faz boa parte desse trabalho. Nosso guia sobre como usar o NotebookLM mostra como isso funciona na prática.

Engenharia de contexto para agentes e apps de IA

A engenharia de contexto faz mais diferença quando um modelo trabalha ao longo de muitas etapas. Um agente de IA que pesquisa, lê arquivos e chama ferramentas gera contexto novo a cada ação. Sem gestão, a janela se enche de resultados velhos de ferramentas até ele perder o fio da meada. As técnicas usadas para evitar isso são surpreendentemente pé no chão:

• Buscar na hora certa — em vez de carregar todos os documentos de início, mantenha referências leves (caminhos de arquivos, links, consultas salvas) e deixe o agente buscar o que precisa no momento em que precisa.
• Compactar — quando uma sessão longa se aproxima do limite, resuma o que importa (decisões, problemas em aberto, fatos-chave) e continue a partir do resumo. Limpar resultados antigos de ferramentas é a versão mais simples.
• Fazer anotações fora da janela — peça ao agente para manter um arquivo de progresso ou uma lista de tarefas que ele possa reler, para que o estado importante sobreviva mesmo quando a conversa for cortada.
• Dividir o trabalho — subagentes cuidam de uma tarefa específica num contexto limpo e devolvem um resumo curto, para que o agente principal não carregue cada detalhe de cada pesquisa.
• Ter poucas ferramentas, e claras — ferramentas que se sobrepõem e têm descrições vagas deixam o modelo adivinhando qual usar. Cada descrição de ferramenta também é contexto.
• Calibrar o system prompt na "altitude" certa — a expressão da Anthropic para o meio-termo entre regras frágeis do tipo "se isto, então aquilo" e incentivos vagos: específico sobre objetivos e limites, flexível sobre o método.

A compactação é algo que você pode testar à mão em qualquer chat longo antes de passar para um novo:

Um checklist de contexto para reutilizar

Antes de um pedido importante, ou quando um assistente erra a mesma coisa repetidamente, passe por esta lista:

1. Objetivo — o contexto diz para que serve o resultado, e não só o que fazer?
2. Fontes — cada fato de que a resposta depende está de fato na frente do modelo?
3. Atualização — algo está desatualizado: um briefing antigo, uma versão substituída, uma memória que não vale mais?
4. Conflitos — há duas partes que discordam? Tire uma delas ou diga qual prevalece.
5. Ruído — o que você poderia apagar sem perder nada de que a tarefa precisa?
6. Rótulos — os documentos e trechos estão bem identificados e separados, para que o modelo (e você) consiga distingui-los?
7. Ordem — a instrução principal está no começo ou no fim, e não enterrada no meio de um texto longo colado?
8. Formato — você mostrou ou descreveu o resultado que quer receber?

Você também pode pedir ao modelo que revise o próprio contexto antes de responder:

O que a engenharia de contexto não resolve

A engenharia de contexto é útil, mas não faz milagre, e parte do hype promete mais do que entrega. Limites que vale a pena conhecer:

• Ela não dá ao modelo uma capacidade que ele não tem — um contexto perfeito não faz um modelo pequeno raciocinar como um grande, nem torna qualquer modelo confiável num tipo de tarefa em que ele vai mal.
• Ela não garante fidelidade — mesmo com os documentos certos na frente, um modelo pode ler errado, exagerar ou misturar fontes. Confira as afirmações que importam.
• As suas fontes definem o teto — se os documentos estiverem errados, enviesados ou desatualizados, as respostas também estarão, com exatamente a mesma confiança.
• A recuperação pode trazer a coisa errada — a busca automática nos seus documentos às vezes devolve algo que quase serve, e o modelo raciocina com cuidado a partir do trecho errado.
• Conteúdo não confiável é um risco — páginas da web, e-mails e arquivos que você entrega a uma IA podem conter instruções escondidas, o que se chama prompt injection (injeção de prompt). Trate tudo o que o modelo lê como dado, não como comando, e mantenha uma pessoa aprovando qualquer ação irreversível.
• É um trabalho contínuo — o contexto envelhece. Instruções, memórias e arquivos de referência precisam de manutenção, como qualquer documentação.

A ideia central é simples: um modelo só consegue trabalhar com o que vê, então decida de propósito o que ele vai ver. Dê o objetivo, os fatos e um exemplo de bom resultado, deixe de fora o excesso e confira o que voltar. Esse hábito melhora as respostas com mais consistência do que qualquer frase engenhosa.

Referências

• Anthropic — Engenharia de contexto eficaz para agentes de IA (em inglês)
• Prompt Engineering Guide (DAIR.AI) — Guia de engenharia de contexto (em inglês)
• Liu et al. — Lost in the Middle: como os modelos de linguagem usam contextos longos (arXiv, em inglês)