Usar AI

Engenharia de Contexto

Também conhecido como: Context Engineering

A prática de projetar, montar e manter tudo o que um modelo vê em sua janela de contexto — prompt de sistema, documentos recuperados, saídas de ferramentas, memória e histórico da conversa — para que consiga executar seu trabalho com confiabilidade. O termo surgiu em 2025 como sucessor da engenharia de prompts, refletindo uma mudança do ajuste manual de uma única instrução para a engenharia de todo o ambiente de informações ao redor do modelo.

Por que isso importa

Um modelo só consegue raciocinar sobre o que está à sua frente, portanto a qualidade do contexto muitas vezes importa mais que o próprio modelo: um modelo de fronteira que recebe um contexto inchado e contraditório terá desempenho pior que um modelo menor com um contexto limpo e bem curado. Em sistemas de produção, especialmente agentes e pipelines RAG, a maioria das falhas remonta a problemas de contexto — informações ausentes, dados obsoletos, contradições, sinal afogado —, não à capacidade bruta do modelo.

Em profundidade

A engenharia de contexto trata a Janela de contexto como um recurso gerenciado, com orçamento, ciclo de vida e modos de falha conhecidos. Uma chamada típica a LLM monta seu contexto de muitas fontes: um Prompt de sistema que define o comportamento, exemplos few-shot, documentos trazidos por recuperação, definições de ferramentas e seus resultados, memória de longo prazo e o histórico corrente da conversa. A disciplina consiste em decidir o que merece lugar nessa janela, em qual formato e ordem, quando atualizar ou comprimir e como manter informações irrelevantes ou erradas do lado de fora. Enquanto a engenharia de prompts pergunta como formular a instrução, a engenharia de contexto pergunta o que o modelo deve saber quando a instrução chegar.

O Orçamento de Contexto

Janelas de contexto cresceram de poucos milhares de tokens para centenas de milhares e além, mas o espaço nunca é gratuito. Cada token extra acrescenta latência e custo a toda chamada, e a Atenção não escala de maneira elegante: pesquisas sobre modelos de contexto longo mostram que informações enterradas no meio de um prompt longo são usadas com menos confiabilidade que aquelas perto do início ou do fim, padrão conhecido como "lost in the middle". Por isso, a engenharia prática de contexto exige orçamento. Equipes comprimem turnos antigos da conversa em resumos correntes, reduzem saídas verbosas de ferramentas aos campos importantes, eliminam boilerplate repetido e retiram material de referência do prompt, colocando-o na recuperação para que só seja buscado quando relevante. O objetivo é o menor contexto que ainda contenha tudo de que o modelo precisa para a etapa atual.

Montando o Contexto em Runtime

Aplicações modernas constroem o contexto dinamicamente, em vez de escrevê-lo à mão. Um pipeline de RAG recupera documentos relevantes à pergunta do usuário e os injeta no momento da chamada; um sistema de Memória carrega fatos duráveis sobre o usuário entre sessões; o Uso de ferramentas e protocolos como MCP permitem ao modelo buscar dados atuais no meio da conversa, com cada resultado acrescentado ao contexto para a etapa seguinte. Loops de Agente levam isso ao extremo: cada observação, ação e resultado intermediário cai no contexto, de modo que o contexto efetivamente vira o estado de trabalho do agente, sua memória de curto prazo e seu plano reunidos. É por isso que a engenharia de contexto aparece com tanta força no projeto de agentes — decidir o que persistir, o que resumir e o que descartar durante uma execução de cinquenta etapas costuma ser a diferença entre um agente que permanece na tarefa e outro que deriva.

Uma Janela Maior Não é a Solução

Um equívoco comum é que janelas de contexto de um milhão de tokens tornam a engenharia de contexto desnecessária — basta despejar tudo e deixar o modelo resolver. Na prática, contexto longo introduz seus próprios modos de falha. Context rot descreve a degradação gradual do desempenho conforme a janela se enche: a precisão em perguntas no estilo recuperação cai com o aumento do comprimento da entrada, até em modelos anunciados para contextos muito longos. Context poisoning é pior: quando uma Alucinação, um fato obsoleto ou uma instrução injetada entra no contexto, o modelo tende a tratá-lo como verdade fundamental e construir sobre ele, e agentes que escrevem suas próprias saídas de volta no contexto podem amplificar um erro inicial em todas as etapas seguintes. Modos de falha relacionados incluem context distraction, em que material irrelevante tira o modelo da tarefa, e context clash, em que informações contraditórias na janela produzem hesitação ou escolhas arbitrárias. Curar as entradas, validar o que é escrito de volta, defender-se contra Injeção de Prompt e reiniciar periodicamente o contexto são as contramedidas padrão.

Da Engenharia de Prompts à Engenharia de Contexto

A Engenharia de prompts, a disciplina mais antiga, concentrava-se na formulação: palavras usadas nas instruções, seleção de exemplos few-shot, prompts de papéis. Ela presumia um humano escrevendo um único prompt diante de uma janela quase vazia. Conforme aplicações cresceram para pipelines e agentes, o gargalo mudou — a parte difícil passou a ser gerenciar o fluxo de informações para uma janela compartilhada por instruções, dados, ferramentas e histórico, em sua maioria montados por software, não digitados pelo usuário. O termo engenharia de contexto pegou entre profissionais em 2025 para nomear exatamente essa mudança e permaneceu porque descrevia o que as equipes já faziam. A arte de escrever prompts ainda importa, e o Aprendizado em Contexto continua sendo o mecanismo que sustenta tudo, mas a formulação agora é um componente dentro de uma superfície de engenharia mais ampla, que também cobre qualidade da recuperação, projeto de memória, formatação de saídas de ferramentas e gerenciamento do ciclo de vida do contexto.

Conceitos relacionados

← Todos os termos

← Endpoint Engenharia de prompts →